top - download
⟦a7c3806f2⟧ Wang Wps File
Length: 72223 (0x11a1f)
Types: Wang Wps File
Notes: GECO
Names: »2499A «
Derivation
└─⟦67e26c09b⟧ Bits:30006222 8" Wang WCS floppy, CR 0244A
└─ ⟦this⟧ »2499A «
WangText
…15……0a……15……0b……15… …14……0d……14……02……14…
…13……0b……13……0c……13…
…12……0a……12……0b……12……0c……12……06……11……09……11……86…1
…02… …02…
…02…
…02…
SEISMIC DATA PREPROCESSING
SYSTEM…02…1982-08-06…02……02…
SECTION II page
#
MANAGEMENT PROPOSAL…02……02…
SEISMIC DATA PREPROCESSING SYSTEM…01……01…SECTION II…01……01…MANAGEMENT PROPOSAL…01……01…DOC.NO. SDPS/PRP/002/CRA
Issue 1
SUBMITTED TO: GEOPHYSICAL COMPANY OF NORWAY A.S.
VERITASVEIEN 1, P.O. Box 330
N-1322 H[VIK, NORWAY
IN RESPONSE TO: SPECIFICATION FOR ON-LINE VERSION
OF PREPROCESSING UNIT FOR "NESSIE"
PF/js/0479J 04.06.1982
PREPARED BY: A.L.FRIEDMAN and
P.E.HOLMDAHL
This proposal contains information proprietary to Christian
Rovsing A/S. The data contained herein, in whole or in part,
may not be duplicated, used or disclosed outside the recipient
as Purchaser for any purpose other than to evaluate the proposal;
provided, that if a contract is awarded to this offerer as a
result of, or in connection with the submission of this data,
the Purchaser shall have the right to duplicate, use, or disclose
the data to the extent provided in the contract. This restriction
does not limit the Purchaser's right to use information contained
in the data if it is obtained from another source without restriction.…86…1
…02… …02… …02… …02… …02… …02… …02… …02…
…06…1 …02… …02… …02… …02… …02… …02… …02… …02… …02… …02… …02… …02… …02… …02… …02… …02… …02… …02…
T̲A̲B̲L̲E̲ ̲O̲F̲ ̲C̲O̲N̲T̲E̲N̲T̲S̲
1. INTRODUCTION ................................
2
1.1 Background to SDPS Implementation ........
2
1.2 Corporate Presentation ....................
3
2. EXPERIENCE ..................................
8
2.1 Christian Rovsing A/S .....................
8
2.2 Remote Sensing Activities .................
8
2.3 Computer Technology .......................
14
3. PROJECT IMPLEMENTATION PROCEDURES ..........
18
4. ILS ........................................
32
5 PROJECT IMPLEMENTATION PLAN ....................
45
5.1 Phase I: Specification .....................
45
5.1.1 WP 110: Phase I Management .............
47
5.1.2 WP 120: Requirements Definition ........
47
5.1.3 WP 130: System Design Spec. (SDS)
...... 48
5.1.4 WP 140: Hardware Specification .........
49
5.1.5 WP 150: Software
Specification
.........
49
5.1.6 WP 160: Test Requirement Spec. .........
49
5.1.7 WP 170: Documentation Requirement
Spec.. 49
5.2 Phase II: Implementation of Raw Data
Recording
System
.................
50
5.2.1 WP 210: Phase II Management ............
50
5.2.2 WP 220: System Engineering .............
52
5.2.3 WP 230: Module Implementation ..........
53
5.2.3.1 WP
231:
System
Management
..........
53
5.2.3.2 WP
232:
Mechanical
and
Electrical
Design
.....................
54
5.2.3.3 WP
233:
Seismic
Data
Interface
.....
54
5.2.3.4 WP
234:
SEG-D
Formatter
Software
...
55
5.2.3.5 WP
235:
6250
PBI
Tape
..............
55
5.2.3.6 WP
236:
Data
Channel
...............
56
5.2.3.7 WP
237:
Test
Software
..............
56
5.2.4 WP 240: Procurement ....................
57
5.2.5 WP 250: System Integration .............
57
5.2.6 WP 260: Delivery .......................
58
5.2.7 WP 270: Acceptance Test ................
58
5.3 Phase III: Implementation of Preprocessing
. 58
System
5.3.1 WP 310: Phase III Management ...........
58
5.3.2 WP 320: System Engineering .............
60
5.3.3 WP 330: Module Implementation ..........
60
5.3.3.1 WP
331:
SDI/MTC
mfg.
Documentation
.
60
5.3.3.2 WP 322: Floating Point Processor ...
60
5.3.3.3 WP 333: Spatial Resampling .........
61
5.3.3.4 WP 334: Time Resampling ............
62
5.3.3.5 WP 335: SEG-D Formatter ............
62
5.3.3.6 WP 336: 1 MW RAM ...................
62
5.3.3.7 WP 337: Test Software ..............
62
5.3.4 WP 340: Procurement ....................
63
5.3.5 WP 350: System Integration .............
63
5.3.6 WP 360: Delivery .......................
64
5.3.7 WP 370: Acceptance Test ................
64
5.3.8 WP 380: Documentation ..................
65
5.3.9 WP 390: Training .......................
65
5.4 Planning ...................................
66
5.4.1 Phase I ................................
66
5.4.2 Phase II ...............................
68
6. KEY PERSONNEL ...............................
1. I̲N̲T̲R̲O̲D̲U̲C̲T̲I̲O̲N̲
1.1 B̲a̲c̲k̲g̲r̲o̲u̲n̲d̲ ̲t̲o̲ ̲S̲D̲P̲S̲ ̲I̲m̲p̲l̲e̲m̲e̲n̲t̲a̲t̲i̲o̲n̲ ̲
The decision to bid the Seismic Data Pre-processing
System (SDPS) represents a definite commitment on the
part of Christian Rovsing A/S (CRA) to devote its resources
and technical talents to specialised computer system
applications.
For the past five to six years, a large percentage
of Christian Rovsing A/S' resources has been devoted
to on-line computer systems. The company has participated
in several major programmes either as prime contractor
or principal sub-contractor. System contracts awarded
to the company are typically worth several millions
of dollars.
Over the same period CRA has maintained an active involvement
in the techniques and applications of remote sensing
and has developed expertise in various aspects of the
processing and handling of remote sensing image data.
We believe that the special skills and know-how which
CRA has developed are vital to a proper understanding
of the SDPS requirements.
This considerable experience in the field of remote
sensing combined with our experience in the prime management
of large computer system projects provide a solid basis
for successful design and implementation of the SDPS
for the Geophysical Company of Norway.
An administratively distinct Project Office will be
established in the Systems Division of CRA to manage
the SDPS project.
The Systems Division was structured in 1979 to consolidate
the management of large, integrated hardware/software
computer system programmes.
Each major project is under the cognizance of a Project
Office with total system responsibility and control
authority to co-ordinate in-house activities and to
provide close liaison with the customer throughout
the duration of the project.
Projects are supported by an Integrated Logistics Support
group who provide a service including site surveys,
installation, training, documentation preparation,
maintenance, spares and other support services.
Quality Assurance reports directly to the Divisional
Manager.
Prime Contractor resposibility for major computer systems,
particularly for military customers such as NATO-SHAPE,
has demanded a professional approach to turnkey project
management with particular emphasis on planning and
documentation in all phases from system design and
development through production, integration, installation,
maintenance and training.
Many of our customers receive training at the company's
modern training facility in Ballerup.
Few companies have the combined engineering talent
and production facilities readily available at Christian
Rovsing A/S.
1.2 C̲o̲r̲p̲o̲r̲a̲t̲e̲ ̲P̲r̲e̲s̲e̲n̲t̲a̲t̲i̲o̲n̲
Christian Rovsing is Denmark's fastest growing high-technology
computer and aerospace-electronics company. Founded
in 1963, Christian Rovsing and its subsidiaries employ
approximately 800 people, many of whom are highly educated
engineers, scientists, and skilled technicians.
In recent years the company's growth rate has approached
40% annually, due in large measure to its advanced,
high-technology CR80 Computer product line and the
excellence of its systems-oriented technical staff.
Today, Christian Rovsing stands as one of Europe's
leading computer systems houses, capable of taking
responsibility for all aspects of hardware/software
projects from concept through implementation to final
acceptance.
Facilities are located in suburban Copenhagen at three
locations - Ballerup, Herlev, and Valby. The administration
and general management are located at the Ballerup
facility.
Christian Rovsing's corporate facilities and divisional
organization have been specifically structured to handle
development and implementation of specialized military
and commercial computer systems. There are five engineering
divisions - electronics, systems, data processing,
production, and development - and inter-divisional
cooperation is stressed to ensure that available project
expertise is shared.
In the three figures to follow are shown:
o Engineering Facilities at Ballerup (Figure 1-1)
o Computer Production Facilities (Figure 1-2)
o Company Organisation (Figure 1-3)
Further details of Christian Rovsing' history, organisation,
and facilities are given in APPENDIX A.
Figure 1-1
ENGINEERING FACILITIES
Figure 1-2
PRODUCTION FACILITIES
Figure 1-3
COMPANY ORGANIZATION
2. E̲X̲P̲E̲R̲I̲E̲N̲C̲E̲
2.1 C̲h̲r̲i̲s̲t̲i̲a̲n̲ ̲R̲o̲v̲s̲i̲n̲g̲ ̲A̲/̲S̲
Christian Rovsing A/S has considerable experience in
the field of remote sensing and in the prime management
of large computer sysem projects which will be applied
to the successful implementation of the Seismic Data
Preprocessing System.
The purpose of this chapter is to present the past
experience of CRA pertinent to our selection as supplier
of for the SDPS.
The presentation describes with the special skills
and know-how which the company has developed over the
last 5 to 6 years within the field of remote sensing
and which we believe are vital for a proper understanding
of the SDPS project.
Sufficient information is included to demonstrate that
CRA has the necessary technical disciplines and management
expertise to design and implement the SDPS.
CRA believes that it has available exceptional, professional
talent dedicated to advanced electronic techniques.
Furthermore, the company excels in applying current
technology to modular equipment design, and has no
outdated product line to support.
In short, CHRISTIAN ROVSING A/S has now acquired extensive
experience in the design, development and implementation
of advanced, on-line computer systems.
The information given in these pages will demonstrate
the breadth of our knowledge and experience which can
be focussed on the Seismic Data Preprocessing System.
2.2 R̲e̲m̲o̲t̲e̲ ̲S̲e̲n̲s̲i̲n̲g̲ ̲A̲c̲t̲i̲v̲i̲t̲i̲e̲s̲
The special skills and know-how which Christian Rovsing
A/S has accumulated over the last 5 or 6 years in the
field of remote sensing provide a solid basis for successful
design and implementation of the Seismic Data Preprocessing
System.
CRA involvement in remote sensing began already in
1975 when we became technical consultants to the Danish
LANDSAT User Group.
Since that time the company has maintained an active
interest in the techniques and applications of remote
sensing and has developed expertise in various aspects
of the processing and handling of image data.
CRA experience covers nationally and internationally
funded projects and also projects with the European
Space Agency. A synopsis of our experience showing
the dates during which the individual projects were
performed is given in Figure 2-1
Fig. 2-1
Remote Sensing Activities.
CRA experience can be divided in four categories:
o The delivery of computer systems (hardware and
software) on a prime contract or sub-contract basis
involving system design, implementation, installation,
and maintenance
o Technology studies involving lspecial elements
of hardware, software or system design for processing
and handling of remote sensing image data
o System studies related to ground segment requirements
for particular remote sensing satellites including
LASS, SPOT, and ERS-1
o User activities related to the treatment and analysis
of remote sensing images
This broad spectrum of activity within remote sensing
has not only developed specific skills and know-how,
but lalso an appreciation of the overall requirements
for the processing, handling and dissemination of remote
sensing data.
o Computer Systems
CRA has designed and supplied a number of computer
systems involving both hardware and software for the
processing and handlihg of remote sensing image data.
For the METEOSAT Ground Computer System at ESOC we
have supplied three computer sub-systems on a turnkey
basis for the Pre-processing, Rectification and Archiving
of the METEOSAT image data. The Archiving subsystem
includes two Honeywell model 96 High Density Digital
Recorders (HDDR) and a Schlumberger ML 26 HDDR. A
picture of the Archiving system is shown in Fig. 2-2.
CRA also participated in the definition of the METEOSAT
software as a member of the Group One
METEOSAT ARCHIVING SYSTEM
Fig. 2-2
For the CEMS (Centre d'Etudes Meteorologie Spatiale)
in Lannion, CRA has delivered a CR80 computer system
for archiving of satellite data onto high density tape
using a Schlumberger ML 26 recorder.
For the Danish Meteorological Institute CRA has delivered
a fully on-line, programmable Bit Synchroniser and
Frame Synchroniser for the acquisition of TIROS-N,
NIMBUS-G and METEOSAT data.
o Technology Studies
CRA has performed a number of technology studies for
both ESA and the Danish Space Committee involving special
aspects of hardware, software or system design for
the processing and handling of remote sensing image
data.
CRA carried out a study on Precision Pre-processing
of remote sensing data for the EARTHNET programme office
of ESA in order to define and size an operational system
suitable for insertion into the EARTHNET structure.
CRA performed a study for ESA on the availability of
commercial products for Archiving and Recording of
large quantities of remotely sensed data, aimed at
upgrading the EARTHNET structure.
CRA has analysed and developed certain algorithms and
methods for the processing of data from a Synthetic
Aperture Radar. Work has concentrated on Look Summation
and Post Processing.
Various studies have been made on the performance for
Bit Synchronisers and Frame Synchronisers, and methods
for improving High Density Digital Tape Recording techniques
related to remotely sensed satellite data.
o Ground Segment System Studies
CRA has performed a number of studies related to the
ground segment requirements for the acquisition, processing
and dissemination of iamge data from a number of remote
sensing satellites.
For the SPOT programme, CRA participated in the Ground
Segment Phase B study for CNES. CRA defined and sized
the requirements for the Archiving and Dissemination
subsystems. The CRA concept allowed for initial utilisation
of LANDSAT D and met the very high data through-put
performance required for the processing of SPOT data
and the production of user products.
For the LASS Phase A study, CRA was responsible for
the definition of the ground segment.
For the ERS-1 Data Dissemination Study, CRA was sub-contractor
to Logica Limited and was responsible for performance
and cost analysis of major archiving sub-system options.
CRA has a study contract from ESA on the Operational
Aspects of SAR Data Acquisition and Processing. The
aim of the study is to address all system related aspects
of an end-to-end SAR processing chain in order to ensure
the generaton of suitable products, consisting of both
magnetic tapes and photographic products, on a operational
basis.
o User Activities
Since 1975 CRA has co-operated with users of remote
sensing data. Our original involvement was as technical
consultants to the Danish LANDSAT User Group.
CRA currently has a contract with the Geological Survey
of Greenland to perform analysis on both MSS and Thermal
image data.
2.3 C̲o̲m̲p̲u̲t̲e̲r̲ ̲T̲e̲c̲h̲n̲o̲l̲o̲g̲y̲
Several years of rapid evolution of computer technology
are reflected in the development of the CR80 computer
product line at Christian Rovsing. This computer family,
a collection of units architecturally structured in
an innovative way, allows configuring powerful multiprocessor
systems. Through a high degree of parallelism and
redundancy, the configurations offer nearly unlimited
operating power and outstanding system reliability.
From the outset, system architects at Christian Rovsing
recognised that micro-electronics was the driving force
behind modern computer technology. The CR80 product
line is based on functional modularity made feasible
by low-cost LSI completed with advanced distributed
architecture and multiprocessing concepts. Though
they appear to be minicomputers, the CR80 systems in
the larger configurations are competitive with and
challenge the power of large mainframes, but with far
superior operational characteristics and heretofore
unrealizable advantages. The CR80 building-block modules
allow a system configuration flexibility previously
unachievable; this has led to the definition of the
CR80 Computer Family depicted in summary block diagrams
in figure 2-3.
The standard CR80 models are divided into two classes
- unmapped and mapped - supported respectively by the
AMOS and DAMOS software operating systems.
The standard unmapped systems are:
- CR80 MINI, a multiprocessor system with up to 4
CPU's and 256 K words of memory with an operating
range of 0.6 to 1.3 million instructions/second.
- CR80 TWIN, a fully-dualised version of the MINI
with twin multiprocessors and a dual bused peripheral
subsystem.
The standard mapped systems are:
- CR80 MAXIM, a multiprocessor system with up to
5 CPU's and 16 megawords of memory with an operating
range of 0.6 to 2.0 million instructions/second
and a Data Channel with megabyte/sec. transfer
rate, interfacing up to 15 channel units for control
of up to 960 peripheral modules.
- CR80 FATOM, a fault-tolerant system consisting
of as many as 16 multiprocessors inteconnected
through a 512 megabit message transport; each multiprocessor
has the same capabilities as a CR80 MAXIM with
256 megawords of memory and an operating range
up to 30 million instructions/second.
(fra CR80 h>ndbog, side 1-2)
Fig. 2-3
The CR80 Family of Minicomputers
These standard configurations encompass a broad range
of physical characteristics to meet requirements from
the smaller stand-alone user up to those of the largest
multi-installation network applications. The four
models offer:
- a 50:1 range in instruction execution rate varying
from 0.6 mips to 30 mips of parallel operation.
- a 1000:1 range in memory capacity from 512 K bytes
to 512 megabytes
- a 80:1 range in processing power utilising one
CPU or up to 16 interconnected multiprocessors
with a maximum of 5 CPU's each.
- a 400:1 range in connectivity through Peripheral
Controllers accomodating a variety of terminations
with as many as 960 peripherals or up to 4096 communication
lines.
Flexible variation in the size and structure of the
CR80 systems are permitted by the unusual degree of
hardware and software modularity. The hardware includes
fast transfer buses joined to each other by adapters
which allow units on one bus to access those on another.
Dualisation at the internal level and multiple redundancy
at the system level provide a CR80 hardware architecture
which is fully exploited by the DAMOS software operating
system and programs to provice survival of operational
failure of individual components.
Reliability, which is of major concern in real-time
and distributed network applilcations, is achieved
in CR80 computer systems by treating all multiprocessors
as equal elements not absolutely dedicated to a specific
role. Fault tolerance and backup are achieved through
an n+1 redundance scheme without preassignment of system
functions to specific processors. This is in marked
contrast to the more common, rigid dualised configurations
often encountered in dedicated applications with on-line
master/slave arrangements, or off-line backup with
switchover facility.
A photograph of the CR80 FATOM hardware is shown in
figure 2-4.
CR80 FATUM CRATE
FIG. 2-4
3. P̲R̲O̲J̲E̲C̲T̲ ̲I̲M̲P̲L̲E̲M̲E̲N̲T̲A̲T̲I̲O̲N̲ ̲P̲R̲O̲C̲E̲D̲U̲R̲E̲S̲ ̲
O̲V̲E̲R̲A̲L̲L̲ ̲P̲R̲O̲J̲E̲C̲T̲ ̲A̲P̲P̲R̲O̲A̲C̲H̲
Christian Rovsing A/S has significant experience as
a participant in major aerospace and defense projects,
and a procedural framework for management, planning,
and implementation has been established. The highlights
of this approach are:
o Reliable, off-the-shelf equipment wherever possible
utilising the latest technology.
o development of special modules to meet the individual
demands of specific projects.
o Effective management controls and reporting procedures.
o A realistic implementation and support plan to
ensure operational capability within schedule.
In its management and implementation plan, Christian
Rovsing A/S has combined a total systems approach with
advanced business and financial techniques. This approach
ensures that the total scope of the effort is identified,
defined, analyzed, and will be responded to in accordance
with the requirements of the project.
For each project undertaken, Christian Rovsing A/S
will dedicate all required resources, assign highly
qualified personnel, and maintain managerial and technical
continuity - through all phases until the successful
completion of the contract.
In the sections to follow, you will find described
the elements of a Project Implementation Plan, Project
Management and Control, System Engineering and Quality
Assurance. After that details of Logistics Support
are presented: This includes Installation and Site
Preparation, Maintenance and Field Support, and Training
and Documentation.
P̲R̲O̲J̲E̲C̲T̲ ̲I̲M̲P̲L̲E̲M̲E̲N̲T̲A̲T̲I̲O̲N̲ ̲P̲L̲A̲N̲
At Christian Rovsing A/S, the Project Implementation
Plan (PIP) is the management tool which is used to
describe all significant aspects of a project - see
Figure 3-1. The PIP establishes a firm baseline for
all project activities; project status, progress and
performance can be evaluated and controlled by means
of this baseline. Therefore, the PIP has a well defined
structure, and each section identifies the activity,
its organization and operating procedures. Each activity
is placed in a schedule network - consistent with a
master schedule - and the relation to other activities
is shown. Documentation produced by the activity is
listed, and a cross-reference with contractual items
is made for accountability of deliverable items and
unique requirements.
W̲O̲R̲K̲ ̲B̲R̲E̲A̲K̲D̲O̲W̲N̲ ̲S̲T̲R̲U̲C̲T̲U̲R̲E̲
A Work Breakdown Structure (WBS) is created by dividing
all aspects of the project into major tasks. For each
of the major tasks a further breakdown is generated
detailing hardware, software and support tasks. The
WBS consists, therefore, of a family tree of hardware,
software, services and tasks organized to define and
display the work to be accomplished for successful
implementation of a project - see Figure 3-2. As a
planning tool, it defines the Work Packages (WP) for
planning, scheduling and cost control.
Changes to a WBS are controlled by the configuration
management staff, and approved project changes are,
therefore, reflected in the baseline WBS.
Figure 3-1
PROJECT IMPLEMENTATION PLAN
Covering all aspects of a project
Figure 3-2
WBS STRUCTURE
program control aided by low-level, detailed work package
P̲R̲O̲J̲E̲C̲T̲ ̲M̲A̲N̲A̲G̲E̲M̲E̲N̲T
Based on experience at Christian Rovsing A/S, the overview
of management tasks shown in Figure 3-3, presents the
most significant activities usually encounted. In this
Figure, key managers and support functions are identified,
and the principal tasks assigned to project office
staff are delineated.
The project office, under the direction of the Project
Manager, is responsible for the overall conduct of
a project. Included in the project office are a System
Engineering Manager, Operation Manager and Logistic
Manager supported by Quality Assurance personnel and
a Contracts Administrator. The principal responsibilities
of the project staff are outlined below.
P̲r̲o̲j̲e̲c̲t̲ ̲M̲a̲n̲a̲g̲e̲r̲.̲ As the executive responsible for successful
execution of the project, the Project Manager has authority
over and is responsible for: budget allocation; cost;
control; schedule and on-time performance; technical
cognizance of design, development and control of production;
and test, integration and support activities. The Project
Manager reports directly to senior management for prompt
resolution of project issues. He is directly supported
by the Project Office staff and indirectly by the managers
of all operating departments within Christian Rovsing
A/S.
E̲n̲g̲i̲n̲e̲e̲r̲i̲n̲g̲ ̲M̲a̲n̲a̲g̲e̲r̲.̲ A senior systems engineer, with
a complete understanding of the technical implications
of top-level system specifications, is responsible
for the ultimate technical performance and compliance
with those specifications. He provides the correct
technical interpretation of all requirements. He plans,
directs, monitors, audits and controls the design,
development, testing, installation and cut-over of
a system with regard to all technical aspects. He provides
the technical liaison with the customer, with in-house
development and production groups, and with sub-contractors
and suppliers.
O̲p̲e̲r̲a̲t̲i̲o̲n̲s̲ ̲M̲a̲n̲a̲g̲e̲r̲.̲ This manager provides the liaison
between the Project Office and the procurement and
production activities. Scheduling, cost control, configuration
control, production status, and quality control are
his major concerns. He is responsible for establishing
and maintaining an up-to-date baseline configuration
and to assess the status and quality of production
during implementation.
L̲o̲g̲i̲s̲t̲i̲c̲s̲ ̲M̲a̲n̲a̲g̲e̲r̲.̲ The installation and site support
tasks are combined under one manager. The Logistics
Manager is responsible for site surveys, delivery and
installation, training, maintenance, spares, documentation
and site support. Logistic support tasks are carried
out by staff from the Integrated Logistics Support
Department of Christian Rovsing A/S.
Q̲u̲a̲l̲i̲t̲y̲ ̲A̲s̲s̲u̲r̲a̲n̲c̲e̲ ̲a̲n̲d̲ ̲C̲o̲n̲t̲r̲a̲c̲t̲s̲ ̲A̲d̲m̲i̲n̲i̲s̲t̲r̲a̲t̲i̲o̲n̲ are
divisional staff functions performed for all projects.
Intensive support is given during start up and critical
phases and continues throughout the project.
Figure 3-3
PROJECT MANAGEMENT TASKS
overview based on extensive experience with complex programs
O̲P̲E̲R̲A̲T̲I̲N̲G̲ ̲P̲R̲O̲C̲E̲D̲U̲R̲E̲S̲
Formal operating procedures and proven management methods
are used by the Project Office to control projects.
Management procedures define the methods used within
Christian Rovsing A/S for planning, work assignment,
monitoring and coordination of activities within a
project.
The Project Office and its staff operate within these
well-established procedures and are responsible for:
P̲l̲a̲n̲n̲i̲n̲g̲:̲ Evaluation of contract require-
ments and allocation of work to
the various functional depart-
ments.
W̲o̲r̲k̲
A̲s̲s̲i̲g̲n̲m̲e̲n̲t̲s̲:̲ Issuance of work statements,
specifications, budget and
schedule requirements.
M̲o̲n̲i̲t̲o̲r̲i̲n̲g̲:̲ Periodic review of technical
schedules and cost performance,
applying program control through
budget authorization.
C̲o̲-̲o̲r̲d̲i̲n̲a̲t̲i̲o̲n̲:̲ Co-ordination of all project ac-
tivities between operating de-
partments.
Internal management cost/schedule procedures produce
valid, auditable and timely performance reports. Variances
from budget and schedule are quickly identified, and
significant deviations are flagged for immediate project
management attention and corrective action.
Technical supervision and monitoring are effected by
periodic design reviews with hardware and software
engineering managers.
The primary management controls are based on a well-planned
WBS, master schedule and budget. Firm baselines established
early in the project provide the basis for management.
The master schedule incorporates customer-directed
milestones and indicates the timing relationships of
the WBS elements. Detailed plans derived from the master
schedule establish work package milestones.
The budget baseline allocates the resources among operating
departments after contract award. Work authorizations
are timephased based on schedule constraints. Internal
budget allocations allow for the retainment of funds
for contingencies and unforeseen efforts.
All detailed packages - identified and assigned from
a WBS - are defined by a statement of work, schedule,
and budget, thus establishing a performance measurement
baseline.
C̲O̲S̲T̲ ̲C̲O̲N̲T̲R̲O̲L̲
The Project Cost and Schedule Control System (CSCS)
applied by Christian Rovsing A/S to medium and large
size projects is based upon a multi-level Work Breakdown
Structure (WBS).
o Level 1 defines the Main WBS items within the responsibility
of the manager of each function.
o Intermediate levels define Summary Work Packages
(SWP) within the responsibility of a single task
manager.
o The lowest level defines the Work Packages (WP)
that a SWP defines. WP's are the units of effort/tasks
from which project schedule and cost performance
are monitored. As a guideline, each WP should not
to exceed a 3 month duration from start to completion.
The total effort is not to exceed 6 man-months.
Reporting by SWP-Managers on progress, i.e. degree
of completion and effort spent on the WP-level, takes
place monthly. These reports can give early warnings
of both schedule delays and cost overruns, and thus
serve a dual purpose.
The overall impact of a threatening delay in completion
of a WP is judged from Tracking Forms which easily
identify the interrelations between SWP's in terms
of due dates for input necessary for on-time performance.
The impact of a threatening cost overrun is judged
from regular quarterly as well as ad hoc project budget
revisions-taking into account both cost-to-date and
the latest estimates of cost for completion. The computerized
processing of these data ensures up-to-date information.
By constantly monitoring schedule and cost performance
from a single source of information, i.e. the SWP-managers
monthly reporting, the CSCS applied by Christian Rovsing
A/S ensures consistency in the information. This aides
to identify problem areas and guides in subsequent
corrective action.
C̲O̲N̲T̲R̲A̲C̲T̲S̲ ̲M̲A̲N̲A̲G̲E̲M̲E̲N̲T̲ ̲A̲N̲D̲ ̲A̲D̲M̲I̲N̲I̲S̲T̲R̲A̲T̲I̲O̲N̲
Contracts Management and Administration is a divisional
staff function providing support services to the Project
Manager.
The function is responsible for:
o Contract terms and conditions in relation to the
customer or prime contractor.
o Contract terms and conditions for purchase orders
to sub-contractors and suppliers of standard equipment
and supplies:
- Project budgets
- Invoicing
- Settlement with suppliers and sub-contractors
- Finance
- Cost control
The function is required to keep such cost and accounting
records as are required to perform audits consistent
with Danish Law and according to the terms and conditions
of the contract.
The function is responsible for the conversion of all
capacity and other budgets and plans into economic
terms permitting the safe establishment of rolling
budgets and long range financial forecasts.
S̲Y̲S̲T̲E̲M̲ ̲E̲N̲G̲I̲N̲E̲E̲R̲I̲N̲G̲ ̲P̲R̲O̲C̲E̲D̲U̲R̲E̲
A product, in the context of the Systems Division at
Christian Rovsing A/S, is the result of integration
of hardware and software elements, where the hardware
and software elements and their integration have been
achieved by following a detailed system engineering
procedure. In the sections to follow, system engineering,
hardware, software and system integration will be discussed
in terms of their relationship to a final product.
S̲Y̲S̲T̲E̲M̲ ̲E̲N̲G̲I̲N̲E̲E̲R̲I̲N̲G̲
Christian Rovsing A/S has the necessary know-how and
experience to take responsibility for all major tasks
of system engineering, i.e.:
- Requirements Specification
- Design Specification
- Reliability
- Quality Assurance and Configuration Management
- Testing
- Technical Coordination
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̲
As the first task in the development of a system product,
all requirements are identified; this provides the
baseline for design procedures and acceptance testing.
D̲E̲S̲I̲G̲N̲ ̲S̲P̲E̲C̲I̲F̲I̲C̲A̲T̲I̲O̲N̲
The design specification describes how requirements
are to be implemented; it shows - point for point -
where in the system each requirement is implemented.
R̲E̲L̲I̲A̲B̲I̲L̲I̲T̲Y
A reliability analysis and trade-off is performed to
achieve a system design that ensures a required level
of availability.
Q̲U̲A̲L̲I̲T̲Y̲ ̲A̲S̲S̲U̲R̲A̲N̲C̲E̲ ̲A̲N̲D̲ ̲C̲O̲N̲F̲I̲G̲U̲R̲A̲T̲I̲O̲N̲ ̲M̲A̲N̲A̲G̲E̲M̲E̲N̲T
To ensure that required levels of quality are met,
from initial design through ensuring changes until
final acceptance, quality assurance and configuration
management functions are carried out by impartial staff
reporting to a Quality Assurance Manager responsible
for all QA tasks within Christian Rovsing A/S. These
functions are described in detail in section 5.
T̲E̲S̲T̲I̲N̲G̲
Subsequent to the design specification, a test plan
and procedure is specified. Examples of typical tests
are:
- factory qualification test
- factory post-production test
- preliminary site acceptance test
- network test for integration with other systems
or
sites
- final acceptance test
T̲E̲C̲H̲N̲I̲C̲A̲L̲ ̲C̲O̲O̲R̲D̲I̲N̲A̲T̲I̲O̲N̲
Staff at Christian Rovsing A/S have acquired significant
experience in development of complete system products
and are familiar with the means of technical coordination
that are required such as design reviews and progress
meetings as well as day-to-day communication with customers,
sub-contractors and suppliers.
H̲A̲R̲D̲W̲A̲R̲E̲
All hardware items are off-the-shelf, NATO qualified
units. However, the flexibility of the modular design
allows hardware to be delivered to meet a wide range
of requirements with respect to memory capacity, computational
speed, fault tolerant operation and expandability.
Hardware design is documented by:
- a system level equipment specification
- equipment product specifications
- equipment data sheets
- logic and wiring diagrams
S̲O̲F̲T̲W̲A̲R̲E̲
All software is well documented and in accordance with
NATO Allied Command Europe (ACE) documentation standards.
The Advanced Multi-Processor Operating System (AMOS)
is the standard operating system for unmapped, single
or dual multi-processor configurations; there are up
to 4 CPUs and 512 Bytes of memory in unmapped multi-processor
systems.
The Distributed Advanced Multi-Processor Operating
System (DAMOS) is the standard operating system for
mapped, virtual memory multi-processor configurations;
these configurations range from a single multi-processor
system with up to 5 CPUs and 32 mega-bytes of memory
to a fault-tolerant system with as many as 16 multi-processors
interconnected through a 512 megabit/sec. message transport.
Both operating systems support assembler, SWELL (a
high-level programming language that provides register
specific data manipulation), Pascal and Cobol. Fortran
77 and ADA will be supported in the near future.
In addition to application functions, programmed in
the forementioned languages, a full range of support
software for input/output, file manipulation, editing
and debugging is provided.
S̲Y̲S̲T̲E̲M̲ ̲I̲N̲T̲E̲G̲R̲A̲T̲I̲O̲N̲
System integration is facilitated by making all software
coding, i.e. project-specific software, contingent
upon acceptance of a detailed software design specification.
Each software module is then unit-tested before SW/HW
integration is attempted. After integration at the
factory, the system is pre-tested before formal acceptance
testing is begun. In this way a customer is presented
a truly finished product when acceptance testing starts.
Q̲U̲A̲L̲I̲T̲Y̲ ̲A̲S̲S̲U̲R̲A̲N̲C̲E̲ ̲(̲Q̲A̲)̲
A Quality Assurance Manager (QAM) is responsible for
all QA tasks within Christian Rovsing A/S. The company
has developed its own internal standard - "Christian
Rovsing A/S Quality Assurancy Policy", and the company's
QA system is fully compliant with "NATO Quality Control
System Requirements for Industry", AQAP-1.
Principal QA tasks are:
o Quality Control (QC) - establishment and control
of company QC procedures and project dedicated
QC procedures as well as requirements to sub-contractors
and suppliers; to ensure that a product meets quality
requirements.
o Configuration Control - ensures that the product
as-built meets design and test requirements as
specified; more details of configuration control
and management are given in the next sub-section.
o Reliability - supervision and control, analysis,
trade-offs, and testing; to ensure that availability
requirements are met.
o Parts and Material Procurement - vendor evaluation
qualification, pruchasing and receiving inspection.
o QA System - series of functions to effect quality
assurance; key functions are:
o Quality Planning with detailed scheduling of design
reviews, factory tests, acceptance tests, etc.
o Design Control to review all new designs of both
hardware and software; no design can be released
for production or programming without proper approval.
o Configuration and Change Control to ensure meeting
baseline requirements in the course of changes.
o Work Instructions to define procedures to be followed
to achieve required levels of quality.
o Inspection and Test procedures to be performed
during development, production and delivery of
product.
o Records to document all inspection tests and results
as well as any other events related to product
quality.
C̲O̲N̲F̲I̲G̲U̲R̲A̲T̲I̲O̲N̲ ̲M̲A̲N̲G̲E̲M̲E̲N̲T̲
The configuration management function is performed
by staff of the Quality Assurance Section with divisional
responsibility for configuration management. For each
project, however, an individual Configuration Management
Plan is prepared. This organizational arrangement provides
consistency from project to project, ensuring that
the benefits of experience are passed on while taking
into account the individual demands of each project
and customer.
Major functions of configuration management are:
o Configuration Identification
o Configuration Control
o Status Accounting
o Configuration
o Configuration Auditing.
Configuration Identification of all items released
as part of the baseline configuration as well as subsequent
change documentation to these items is accomplished
by identifying numbers. Examples of identifying numbers
are:
- drawing or part number
- revision number
- serial number
- specification description number
- change identification number.
Configuration Control of project office initiated changes
is ensured by a Configuration Control Board (CCB) which
includes project relevant experts and which is chaired
by the configuration management staff member responsible
to the project. The CCB is responsible for analysis,
classification and approval of changes to:
- specifications and procedures
- engineering drawings
- hardware and software
- documentation.
Configuration Status Accounting catalogues the information
and documentation required for configuration control.
Examples are:
- approved engineering documentation
- status reports of proposed changes
- implementation status of approved changes.
Configuration Auditing provides the results of formal
examination of the configuration. A Physical Configuration
Audit (PCA) compares the as-built version of a configuration
item with the items technical documentation to establish
whether the item meets the product baseline. A Functional
Configuration Audit (FCA) verifies if the configuration
meets all tests required by development specifications.
4. L̲O̲G̲I̲S̲T̲I̲C̲S̲ ̲S̲U̲P̲P̲O̲R̲T̲ ̲A̲N̲D̲ ̲C̲A̲P̲A̲B̲I̲L̲I̲T̲I̲E̲S̲
I̲N̲T̲R̲O̲D̲U̲C̲T̲I̲O̲N̲
The Systems Division of Christian Rovsing A/S has a
support department named Integrated Logistics Support
(ILS). ILS undertakes the following work:
o Installation and Site Preparation
o Maintenance and Field Support
o Training and Documentation
In accordance with current contracts, including FIKS
(Danish Defense Integrated Communications System) and
CAMPS (NATO wide communication system), ILS provides
Installation, Maintenance and Field Support as well
as training and documentation to 8 Danish and 16 NATO
military headquarters. This service has already started
and will continue at least until mid 1985. It is planned
that ILS will develop a European wide service capability
based on these initial contracts. The services will
also include installation and maintenance of other
manufacturer's equipment.
O̲R̲G̲A̲N̲I̲Z̲A̲T̲I̲O̲N̲
The organization of the Logistics Department is shown
in Figure 4-1 with an indication of major responsibilities.
All ILS personnel have a security clearence to at least
NATO SECRET. Maintenance and installation teams have
a higher clearance determined by the project in question.
The following sections describe the general responsibilities
of the 3 functional areas on a typical, major military
program.
Figure 4-1
Department Organization
I̲N̲S̲T̲A̲L̲L̲A̲T̲I̲O̲N̲ ̲S̲E̲C̲T̲I̲O̲N̲
S̲i̲t̲e̲ ̲P̲r̲e̲p̲a̲r̲a̲t̲i̲o̲n̲ ̲a̲n̲d̲ ̲V̲e̲r̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
On programs involving medium to large sized ADP systems
the Installation Section will perform the following
tasks:
o Conduct Site Surveys
o Generate Civil Works Requirements
o Generate As-Built Drawings
o Perform Site Verification
The Civil Works Requirements package contains the necessary
details for the customer to draft work specifications
for local contractors. As-Built Drawings show how the
specific installation has been made.
T̲r̲a̲n̲s̲p̲o̲r̲t̲a̲t̲i̲o̲n̲ ̲a̲n̲d̲ ̲I̲n̲s̲t̲a̲l̲l̲a̲t̲i̲o̲n̲
The Installation Section is responsible for transportation
of the equipment from the CR factory to the site. This
includes writing the Transportation Plan. CR utilizes
the service of a freight forwarder to handle the details
of the shipments.
The Installation Section has several teams of experienced
installers who, after installation of the equipment,
will run a test to verify that the equipment is functioning
in accordance with specifications.
In conjunction with equipment installation the installation
team will conduct a property inventory check (spare
parts, documentation etc.).
P̲a̲c̲k̲a̲g̲i̲n̲g̲ ̲R̲e̲q̲u̲i̲r̲e̲m̲e̲n̲t̲s̲
The Installation Section is also responsible for the
development of Packaging Requirements for all types
of shipments to the sites. The requirements are formulated
in a procedure.
Special packaging instructions are specified for shipment
of repairable items.
M̲A̲I̲N̲T̲E̲N̲A̲N̲C̲E̲ ̲S̲E̲C̲T̲I̲O̲N̲
M̲a̲i̲n̲t̲e̲n̲a̲n̲c̲e̲ ̲E̲n̲g̲i̲n̲e̲e̲r̲i̲n̲g̲
The Maintenance Section of the Logistics Department
is responsible for giving appropriate input to Systems
Engineering to ensure that the systems developed will
meet the requirements for maintainability. Furthermore,
the maintenance section will give support to the group
writing the Maintenance and Diagnostic Software.
The Maintenance Section will work closely with Systems
Engineering to ensure consistency in determination
of the MTBF (mean time between failures) and MTTR (mean
time to repair) figures. Furthermore, the section may
carry out a Logistics Support Analysis.
Writing the Maintenance Plan and associated procedures
is also the responsibility of the Maintenance Section.
In the area of deliverable documentation the maintenance
section will generate the Maintenance Manual and conduct
maintenance related training.
F̲i̲e̲l̲d̲ ̲S̲u̲p̲p̲o̲r̲t̲
1) Coordinate the implementation of field changes.
2) Assistance to customer's technical personnel with
respect to hardware and software problems.
3) Coordinate warranty repairs.
S̲p̲a̲r̲e̲s̲ ̲M̲a̲n̲a̲g̲e̲m̲e̲n̲t̲
The Maintenance Section is responsible for the specification,
acquisition, packaging and delivery of spares, repair
parts and repairable subassemblies. Normally, a priced
Recommended Spare Parts List will be submitted to the
customer. Provisioning ̲Conferences will be planned
and conducted by the Maintenance Section.
Spare Parts Design Change Notices will be issued and
controlled by the Maintenance Section.
C̲o̲d̲i̲f̲i̲c̲a̲t̲i̲o̲n̲ ̲o̲f̲ ̲S̲u̲p̲p̲l̲y̲ ̲I̲t̲e̲m̲s̲
Codification (assignment of NATO or other stock numbers)
will be carried out by the Maintenance Section.
T̲o̲o̲l̲s̲ ̲a̲n̲d̲ ̲T̲e̲s̲t̲s̲ ̲E̲q̲u̲i̲p̲m̲e̲n̲t̲
The Maintenance Section will specify all tools and
test equipments to be supplied under the contract.
Fur- thermore, a priced list of tools and test equipment
will be submitted to the customer for all items required
at each installation and repair depot to support the
equipment delivered.
F̲a̲i̲l̲u̲r̲e̲ ̲R̲e̲p̲o̲r̲t̲i̲n̲g̲
Generation and implementation of a Failure Reporting
System is the responsibility of the Maintenance Section.
All incoming reports will be recorded and analyzed
and the corrective action coordinated with the customer.
T̲r̲a̲i̲n̲i̲n̲g̲ ̲a̲n̲d̲ ̲D̲o̲c̲u̲m̲e̲n̲t̲a̲t̲i̲o̲n̲ ̲S̲e̲c̲t̲i̲o̲n̲
C̲u̲s̲t̲o̲m̲e̲r̲ ̲T̲r̲a̲i̲n̲i̲n̲g̲
The Training and Documentation section is responsible
for all training offered by the Systems Division. The
following types of courses have been developed and
conducted:
o Systems Courses
o Hardware maintenance
o Software maintenance
o Software programming
o On-the-job training
o Operator courses.
The courses are developed in accordance with contractual
requirements and a typical theory to hands-on training
ratio of 40 to 60 percent.
Her kommer et billede
Her kommer endnu et billede
I̲n̲-̲H̲o̲u̲s̲e̲ ̲T̲r̲a̲i̲n̲i̲n̲g̲ ̲
Christian Rovsing A/S has nominated the Training and
Documentation Section to carry out all in-house training.
These activities include:
o CR80 Hardware Theory
o CR80 Hardware Maintenance
o Programming Courses such as SWELL, PASCAL, ASSEMBLER
o DAMOS and AMOS Operating Systems.
Furthermore, the Training and Documentation Section
plans and manages a program of video courses offered
to the entire company. In addition, regular courses
are offered in Technical Presentation and other personal
development courses.
T̲r̲a̲i̲n̲i̲n̲g̲ ̲F̲a̲c̲i̲l̲i̲t̲i̲e̲s̲
The Training and Documentation Section coordinates
the company's training facilities and equipments.
The section has its own CR80 computer system primarily
for software training. The system has eight terminals
allowing simultaneous hands-on training of eight students.
One of the class rooms is equipped with the necessary
video equipment used during the personal development
courses.
M̲a̲n̲u̲a̲l̲s̲ ̲a̲n̲d̲ ̲H̲a̲n̲d̲b̲o̲o̲k̲s̲
The Training and Documentation section writes the deliverable
manuals and handbooks for all projects undertaken by
the division.
The section has its own staff of technical writers
who develop the manuals based on the project documentation.
Manuals have been developed in accordance with NATO
and other military standards. Figure 4 shows an example
of deliverable documentation on a major communication
Project.
Figure 4
Deliverable Documentation
In addition to project related documentation the Training
and Manuals section writes manuals for other divisions
in the company.
The draft documentation is stored in a word processor
facility for ease of updating.
Illustrations, in the form of drawings or photographs,
are used whereever possible.
5̲ ̲ ̲P̲R̲O̲J̲E̲C̲T̲ ̲I̲M̲P̲L̲E̲M̲E̲N̲T̲A̲T̲I̲O̲N̲ ̲P̲L̲A̲N̲
This section describes the proposed implementation
plan for the Seismic Data Preprocessing System. See
figure 5-1 overleaf.
The work is divided into three phases.
Phase I: System specification,
Hardware specification and
Software specification
Phase II: Design, development, procurement,
integration and delivery of a subset of
the
phase III delivery, capable of recording
in
Raw Data mode
Phase III: Design, development, procurement,
integration and delivery of upgrades to
the
phase II delivery to provide the full SDPS
processing system.
As working-assumptions for this proposal, we have presumed
the following:
a) The phase II delivery is returned TBD months after
the delivery for upgrading to the full SDPS System.
b) The customer furnishes a simulator which provides
an interface equivalent to the "NESSIE", and sufficient
types of test data for development and, in particular,
for the Acceptance testing.
We want to emphasize that we are prepared to discuss
alternatives to these working assumptions, or to other
explicit or implicit presumptions.
5.1 P̲h̲a̲s̲e̲ ̲I̲:̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
Phase I consists of a detailed requirement analysis
and specification of the system to be provided in phase
II and phase III. This is made in close cooperation
between the customer and the contractor.
The output from phase I is a mutually agreed upon technical
specification for the SDPS, and a planning for phase
II.
5.1.1 W̲P̲ ̲1̲1̲0̲:̲ ̲P̲h̲a̲s̲e̲ ̲I̲ ̲m̲a̲n̲a̲g̲e̲m̲e̲n̲t̲
The activities are
a) Project management
o Interface and communication with GECO
o Coordination of activities
o Schedule control
o Action item control
b) Documentation, reporting
o Progress reports (monthly)
o Arrange for meetings and reviews
o Prepare schedules, agendas and minutes
c) Phase II Planning
Output: Progress reports
Phase II Project Implementation Plan
5.1.2 W̲P̲ ̲1̲2̲0̲:̲ ̲R̲e̲q̲u̲i̲r̲e̲m̲e̲n̲t̲s̲ ̲D̲e̲f̲i̲n̲i̲t̲i̲o̲n̲
Purpose: Definition of requirements in view of the
proposed system design.
Activities: Detailed review of the requirements in
close cooperation with the customer and
with the technical solution in view.
Output: SDPS Requirements Specification
5.1.3 W̲P̲ ̲1̲3̲0̲:̲ ̲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̲ ̲(̲S̲D̲S̲)̲
Purpose: The SDS shall provide the basis for a systems
design which implements the required qualities.
Activities: A system design specification is made based
on the agreed requirements specification.
The specification will, for example, consist
of:
o system architecture, SW & HW
o specification of major interfaces, SW & HW
o system performance
o system operation
Output: System Design Specification
5.1.4 W̲P̲ ̲1̲4̲0̲:̲ ̲H̲a̲r̲d̲w̲a̲r̲e̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲ ̲
Purpose: To assure a coherent hardware design with
the required performance
Activities: Specification of all hardware items to
module level
Output: SDPS Hardware Specification
5.1.5 W̲P̲ ̲1̲5̲0̲:̲ ̲S̲o̲f̲t̲w̲a̲r̲e̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
Purpose: To assure a coherent software design with
the requires performance
Activities: Specification of all software to module
level
Output: SDPS Software Specification
5.1.6 W̲P̲ ̲1̲6̲0̲:̲ ̲T̲e̲s̲t̲ ̲R̲e̲q̲u̲i̲r̲e̲m̲e̲n̲t̲ ̲S̲p̲e̲c̲.̲
Activities: Definition of test requirements in cooperation
with customer
Output: SDPS Test Requirement Specification
5.1.7 W̲P̲ ̲1̲7̲0̲:̲ ̲D̲o̲c̲u̲m̲e̲n̲t̲a̲t̲i̲o̲n̲ ̲R̲e̲q̲u̲i̲r̲e̲m̲e̲n̲t̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
Activities: Definition of requirements to documentation
in cooperation with customer
Output: SDPS Documentation Requirement Specification
5.2 P̲h̲a̲s̲e̲ ̲I̲I̲:̲ ̲I̲m̲p̲l̲e̲m̲e̲n̲t̲a̲t̲i̲o̲n̲ ̲o̲f̲ ̲R̲a̲w̲ ̲D̲a̲t̲a̲ ̲R̲e̲c̲o̲r̲d̲i̲n̲g̲ ̲S̲y̲s̲t̲e̲m̲
This preliminary phase II Project Implementation plan
is to be replaced by the one, provided from WP 110
during phase I.
The implementation phase starts after customer approval
of the specifications, and working meetings will be
held as needed.
Design review will be held at the following milestones
D.R.2.1: Phase II HW design complete
Phase II SW design complete
D.R.2.2: HW prototypes have been tested individually
SW modules have been tested individually
D.R.2.3: HW/SW integration on subsystem level complete
D.R.2.4: Phase II review
Installation of phase II and Acceptance
test successfully completed
See work breakdown on figure 5-2 overleaf
5.2.1 W̲P̲ ̲2̲1̲0̲:̲ ̲P̲h̲a̲s̲e̲ ̲I̲I̲ ̲M̲a̲n̲a̲g̲e̲m̲e̲n̲t̲
The activities are
a) Project management
o Interface and communication with GECO
o Coordination of activities
o Schedule control
o Action item control
b) Documentation, Reporting
o Progress reports (monthly)
o Arrange for meetings and reviews
o Prepare schedules, agendas and minutes
c) Phase III planning
Output: Progress Reports
Phase III Project Implementation Plan
5.2.2 W̲P̲ ̲2̲2̲0̲:̲ ̲S̲y̲s̲t̲e̲m̲ ̲E̲n̲g̲i̲n̲e̲e̲r̲i̲n̲g̲
The System engineering comprises
o Technical coordination
o Quality Assurance
o Test plans and procedures
W̲P̲ ̲2̲2̲1̲: Technical coordination
Purpose: To assure the implementation of a system
which fulfils the technical requirements
The activities are
o Technical coordination of all hardware
and software development and procurement
activities
o Participation in all internal and external
technical reviews
o Performance analysis
Output: Engineering notes
Test plans and procedures specification
W̲P̲ ̲2̲2̲2̲: Quality Assurance
Purpose: To assure that required levels of quality
are met
The activities are
o Quality control on hardware design, manufacturing
and documentation
o Quality control on software design and
documentation
o Configuration and change control
o Reliability
Supervision, control, analysis, trade-offs,
testing
Output: Inspection and test procedures
Inspection and test reports
W̲P̲ ̲2̲2̲3̲:̲ Test plans and procedures
Purpose: Assuring Correct and reproducible tests,
according to the requirements.
Activities: Preparation of test plans and procedures
Output: Factory test plan
Factory test procedure
Acceptance test plan
Acceptance test procedure
5.2.3 W̲P̲ ̲2̲3̲0̲:̲ ̲M̲o̲d̲u̲l̲e̲ ̲I̲m̲p̲l̲e̲m̲e̲n̲t̲a̲t̲i̲o̲n̲
The work breakdown follows the modular approach of
the hardware and software.
This work package is a number of sub-packages, each
covering essentially all effort for the detailed design,
development, manufacturing/coding and testing of all
hard, firm and software required for the particular
module.
5.2.3.1 W̲P̲ ̲2̲3̲1̲:̲ ̲S̲y̲s̲t̲e̲m̲ ̲M̲a̲n̲a̲g̲e̲m̲e̲n̲t̲
The system management software is designed, developed,
coded and tested according to the detailed design specification,
provided in WP 222.2.
The following modules are designed, developed, coded
and tested:
WP 231.1: Man-Machine Interface
WP 231.2: Message Interpreter
WP 231.3: Device Control and Monitor
WP 231.4: Error Status Interpreter
WO 232.5: Logging
5.2.3.2 W̲P̲ ̲2̲3̲2̲:̲ ̲M̲e̲c̲h̲a̲n̲i̲c̲a̲l̲ ̲a̲n̲d̲ ̲e̲l̲e̲c̲t̲r̲i̲c̲a̲l̲ ̲d̲e̲s̲i̲g̲n̲
This work package covers efforts related to the housing
and interconnection of crates.
The following activities are included:
WP 232.1: Mechanical design at rack-level and front
panel layout.
WP 232.2: Electrical design, PU crate
WP 232.3: Electrical design, S-I/O crate
WP 232.4: Specification of cables
5.2.3.3 W̲P̲ ̲2̲3̲3̲:̲ ̲S̲e̲i̲s̲m̲i̲c̲ ̲D̲a̲t̲a̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲
The SDI hardware, firmware and software is implemented
according to the corresponding specifications, provided
in phase I.
This work package covers the following activities:
WP 233.1: Detailed SDI and Adapter hardware design,
development, manufacturing and preliminary
test.
This module will be delivered in a wire-wrap
version.
WP 233.2: Detailed firmware design development and
coding
WP 233.3: HW/FW integration and test
WP 233.4: SDI handler detailed design, development,
coding and test
WP 233.5: HW/FW/SW integration
WP 233.6: Maintenance & Diagnostic (M&D) Software
design, development, coding and test
WP 233.7 Built-In-Test design, development, coding
and test.
5.2.3.4 W̲P̲ ̲2̲3̲4̲:̲ ̲S̲E̲G̲-̲D̲ ̲F̲o̲r̲m̲a̲t̲t̲e̲r̲ ̲S̲o̲f̲t̲w̲a̲r̲e̲
The MUX SEG-D software required for the Raw Data recording
is designed, developed, coded and tested.
5.2.3.5 W̲P̲ ̲2̲3̲5̲:̲ ̲6̲2̲5̲0̲ ̲B̲P̲I̲ ̲T̲a̲p̲e̲
The firmware and software is implemented according
to the corresponding specification provided in phase
I. The design of the controller hardware is made under
WP 233.1.
The following activities are covered:
WP 235.1: Adapter design and development. Controller
and Adapter hardware manufacturing and
preliminary test.
This module will be delivered in a wire-wrap
version.
WP 235.2: Detailed firmware development and coding
WP 235.3: HW/FW integration and test
WP 235.4: Handler, detailed design, development,
coding and test
WP 235.5: HW/FW/SW integration
WP 235.6: Maintenance and diagnostic (M & D)
Software design, development, coding and
test.
WP 235.7: Built-In-Test design, development, coding
and test
5.2.3.6 W̲P̲ ̲2̲3̲6̲:̲ ̲D̲a̲t̲a̲ ̲C̲h̲a̲n̲n̲e̲l̲
The design of the existing data channel is used as
the basis for the design of the high speed data channel,
connecting the processing chain with the Storage and
I/O Unit.
The activities are
WP 236.1: Re-design, testing and manufacturing of
the Data Channel Adapter (DACA)
WP 236.2: Re-design, testing and manufacturing of
the Data Channel Interface (DCI)
WP 236.3: Re-design, coding and testing of M & D
Software
5.2.3.7 W̲P̲ ̲2̲3̲7̲:̲ ̲T̲e̲s̲t̲ ̲S̲o̲f̲t̲w̲a̲r̲e̲
This work package covers the Software efforts for performing
the phase II Factory and Acceptance Test.
The activities include:
WP 237.1: Design, development, coding and testing
of phase II Factory Test SW.
WP 237.2: Modifications to the phase II Factory Test
Software to achieve the phase II Acceptance
Test Software.
5.2.4 W̲P̲ ̲2̲4̲0̲ ̲P̲r̲o̲c̲u̲r̲e̲m̲e̲n̲t̲
This work package covers the effort required for the
procurement of all items at module level and above
of the SDPS System.
The activities are:
W̲P̲ ̲2̲4̲1̲:̲ Specification
An ordering specification is worked out,
based upon the proper Hardware Specification
W̲P̲ ̲2̲4̲2̲:̲ Ordering and follow-up.
Supplier schedule control
W̲P̲ ̲2̲4̲3̲:̲ Incoming inspection and test
The procurement action follows the same procedure for
as well in-house products as bought-out equipment.
5.2.5 W̲P̲ ̲2̲5̲0̲:̲ ̲S̲y̲s̲t̲e̲m̲ ̲I̲n̲t̲e̲g̲r̲a̲t̲i̲o̲n̲
This work package covers all the effort required for
the integration and verification checkout of all hardware
modules and equipment, and of all software modules.
The activities comprise:
W̲P̲ ̲2̲5̲1̲: Hardware mechanical integration
W̲P̲ ̲2̲5̲2̲:̲ Hardware electrical subsystem and system
integration testing
W̲P̲ ̲2̲5̲3̲:̲ Software integration
W̲P̲ ̲2̲5̲4̲:̲ Factory test, evaluation and reporting
5.2.6 W̲P̲ ̲2̲6̲0̲:̲ ̲D̲e̲l̲i̲v̲e̲r̲y̲
This work package covers all efforts required for the
transportation and installation of the phase II delivery.
The following activities are foreseen:
WP 261: Packing and shipping
WP 262: Installation and verification Checkout
5.2.7 W̲P̲ ̲2̲7̲0̲:̲ ̲A̲c̲c̲e̲p̲t̲a̲n̲c̲e̲ ̲T̲e̲s̲t̲
This work package covers the formal customer acceptance
testing, evaluation and reporting.
5.3 P̲h̲a̲s̲e̲ ̲I̲I̲I̲:̲ ̲I̲m̲p̲l̲e̲m̲e̲n̲t̲a̲t̲i̲o̲n̲ ̲o̲f̲ ̲P̲r̲e̲p̲r̲o̲c̲e̲s̲s̲i̲n̲g̲ ̲S̲y̲s̲t̲e̲m̲
This Preliminary Phase III Project implementation plan
is to be replaced by the one provided from WP 210 during
phase II.
Phase III starts after the phase II review. Working
meetings will be held as needed, and design reviews
will be held at the following milestones:
D.R.3.1: Phase III HW design complete
Phase III SW design complete
D.R.3.2: HW prototypes and SW modules have been
tested individually.
See work breakdown on figure 5-3 overleaf.
5.3.1 W̲P̲ ̲3̲1̲0̲:̲ ̲P̲h̲a̲s̲e̲ ̲I̲I̲I̲ ̲M̲a̲n̲a̲g̲e̲m̲e̲n̲t̲
The activities are as described for WP 210, excluding
the phase III planning.
5.3.2 W̲P̲ ̲3̲2̲0̲:̲ ̲S̲y̲s̲t̲e̲m̲ ̲E̲n̲g̲i̲n̲e̲e̲r̲i̲n̲g̲ ̲
The activities are as described for WP 220.
5.3.3 W̲P̲ ̲3̲3̲0̲:̲ ̲M̲o̲d̲u̲l̲e̲ ̲I̲m̲p̲l̲e̲m̲e̲n̲t̲a̲t̲i̲o̲n̲
This work package covers the efforts required for the
provision of the remaining modules for the upgrading
of the phase II delivery to a full preprocessing system.
5.3.3.1 W̲P̲ ̲3̲3̲1̲:̲ ̲S̲D̲I̲/̲M̲T̲C̲ ̲m̲f̲g̲.̲ ̲D̲o̲c̲u̲m̲e̲n̲t̲a̲t̲i̲o̲n̲
This work package covers the activities for providing
the Printed Circuit Board (PCB) version of the SDI
and Tape Controller, i.e. manufacturing documentation,
including PCB layout and testing.
5.3.3.2 W̲P̲ ̲3̲2̲2̲:̲ ̲F̲l̲o̲a̲t̲i̲n̲g̲ ̲P̲o̲i̲n̲t̲ ̲P̲r̲o̲c̲e̲s̲s̲o̲r̲
The FPP hardware, firmware and software is implemented
according to the corresponding specifications, provided
in phase I.
This work package covers the following activities:
WP 332.1: FPP hardware detailed design, development
and test
WP 332.2: Basic firmware detailed design development
and coding
WP 332.3: HW/FW integration and test
WP 332.4: FPP handler design, development, coding
and test
WP 332.5: HW/FW/SW integration
WP 332.6: M & D software design, development, coding
and test.
WP 332.7: Built-In-Tese design, development, coding
and test.
5.3.3.3 W̲P̲ ̲3̲3̲3̲:̲ ̲S̲p̲a̲t̲i̲a̲l̲ ̲R̲e̲s̲a̲m̲p̲l̲i̲n̲g̲
This work package covers all the software and firmware
efforts required for performing the Spatial Resampling.
The design, development, coding and testing of the
following modules are comprised:
WP 333.1: Parameter calculation and formatting
WP 333.2: Resample Driver
WP 333.3: Output Handler
5.3.3.4 W̲P̲ ̲3̲3̲4̲:̲ ̲T̲i̲m̲e̲ ̲R̲e̲s̲a̲m̲p̲l̲i̲n̲g̲
This work package covers the software and firmware
efforts required for performing the Time Resampling.
The design, development, coding and testing of the
following modules are comprised:
WP 334.1: Parameter calculation and formatting
WP 334.2: Resample driver
WP 334.3: Output Handler
5.3.3.5 W̲P̲ ̲3̲3̲5̲:̲ ̲S̲E̲G̲-̲D̲ ̲F̲o̲r̲m̲a̲t̲t̲e̲r̲
This work package covers the effort for the design,
development, coding and test of the DEMUX SEG-D module.
5.3.3.6 W̲P̲ ̲3̲3̲6̲:̲ ̲1̲ ̲M̲W̲ ̲R̲A̲M̲
The design of the existing 128K RAM is used as the
basis for the 1 MW RAM.
The activities of this work package cover the re-design,
test and manufacturing documentation for the 1 MW RAM
module.
5.3.3.7 W̲P̲ ̲3̲3̲7̲:̲ ̲T̲e̲s̲t̲ ̲S̲o̲f̲t̲w̲a̲r̲e̲
This work package covers the Software effort for the
formal phase III Factory Test and Acceptance test.
The activities include:
WP 337.1: Upgrading of the phase II Factory Test
Software to the phase III Factory Test
software, i.e. to include the FPP's and
the enhanced memory.
WP 337.2: Modifications to the phase III Factory
Test Software to achieve the phase III
Acceptance Test Software.
5.3.4 W̲P̲ ̲3̲4̲0̲:̲ ̲P̲r̲o̲c̲u̲r̲e̲m̲e̲n̲t̲
This work package covers all effort required for the
procurement of all items at module level and above
of the SDPS System.
The activities are :
WP 341: Specification
An ordering specification is worked out, based
upon the proper Hardware Specification
WP 342: Ordering and follow-up.
Supplier schedule control
WP 343: Incoming inspection and test
The procurement action follows the same procedure for
as well in-house products as bought-out equipment.
5.3.5 W̲P̲ ̲3̲5̲0̲:̲ ̲S̲y̲s̲t̲e̲m̲ ̲I̲n̲t̲e̲g̲r̲a̲t̲i̲o̲n̲
This work package covers all effort required for the
integration and verification checkout of all hardware
modules and equipment, and of all software modules.
The activities comprise :
WP 351: Hardware mechanical integration
WP 352: Hardware electrical subsystem and system integration
testing
WP 353: Software integration
WP 354: Factory test, evaluation and reporting
5.3.6 W̲P̲ ̲3̲6̲0̲:̲ ̲D̲e̲l̲i̲v̲e̲r̲y̲
This work package covers all efforts required for the
transportation and installation of the phase III delivery.
The following activities foreseen are:
W̲P̲ ̲3̲6̲1̲: Packing and shipping.
W̲P̲ ̲3̲6̲2̲: Installation of additional equipment and verification
Checkout
5.3.7 W̲P̲ ̲3̲7̲0̲: Acceptance Test
This work package covers the formal customer acceptance
testing, evaluation and reporting.
5.3.8 W̲P̲ ̲3̲8̲0̲: Documentation
This work package all customer-furnished technical
documentation.
The foreseen activities are:
W̲P̲ ̲3̲8̲1̲: Hardware Manual.
Editing of System design documentation and
documentation on all modules.
W̲P̲ ̲3̲8̲2̲: Software Manual.
Editing of design documentation on all application
software.
W̲p̲ ̲3̲8̲3̲: Maintenance Manual
W̲P̲ ̲3̲8̲4̲:̲ Operator's Manual
5.3.9 W̲P̲ ̲3̲9̲0̲:̲ Training
This work package covers all efforts required for the
training of customer's personnel.
The activities foreseen are:
W̲P̲ ̲3̲9̲1̲:̲ Maintenance Course.
Training in regular and corrective maintenance,
using all available software and hardware aids.
W̲P̲ ̲3̲9̲2̲:̲ Operator's Course.
Training in all normal and corrective operator-actions.
Training in use of the software aids for facilitating
the processing-specification.
5.4 P̲l̲a̲n̲n̲i̲n̲g̲
See bar chart overleaf.
The planning is, in principle, divided into three phases.
It has, however, been found necessary to start the
development work earlier in order to achieve the earliest
possible delivery, such that the three "phases" are
overlapping.
5.4.1 P̲h̲a̲s̲e̲ ̲I̲
The planning at the specification phase is based on
a very close cooperation with the customer, preferably
with a customer-representative working together with
the project team at our premises.
The planning also presumes that the formal customer-approval
of the specifications can be achieved in a very short
turn-around time, not more than one week.
5.4.2 P̲h̲a̲s̲e̲ ̲I̲I̲
Phase II work on hardware development is started two
months before the end of phase I, and as such before
the hardware specification is available.
This relies on the presumption that the approved System
Design Specification does not substantially deviate
from that described in this proposal, such that the
preliminary design of the hardware can be made, based
upon the specification in this proposal, or with only
minor changes.
The preliminary design will then be held up against
the module specifications at the end of phase I and
corrective measures taken if necessary.
The procurement of all major items is made as soon
as the specifications are approved. The tape drives,
for example, are very likely to be long-lead items
Design Review 2.1 is held when the detailed design
has been completed.
All interface specs are frozen after this review.
Design Review number 2.2 is held when all modules have
been developed and tested individually. Any critical
item on module level has been solved and all critical
performance has been verified on module level.
The Customer Furnished Simulator shall be available
not later than this date.
Design Review number 2.3 is held upon successful completion
of HW/SW integration on subsystem level.
The System integration is made progressively, adding
one new module at a time, as far as this is possible.
The integration concludes with a formal Factory Test.
The equipment is shipped to the site of installation
and installed.
The pricing of this proposal presumes a land-based
installation, since we have no information on this,
but we are prepared to discuss other possibilities.
The Acceptance test starts after the successful verification
checkout of the system.
Design Review number 2.4 is held shortly after the
successful Acceptance Test. This review serves to resolve
any outstanding technical matters, and to freeze all
details of the specifications on the modules to be
developed during phase III.
The phase III design and development of the Floating
Point Processor starts after Design Review 2.2.
All other phase III activities start after Design Review
2.4.
Design Review 3.1 is held when the phase III HW and
SW detailed design has been completed.
Design Review 3.2 is held upon individual test of all
modules, developed during phase III.
The System integration commences after this Design
Review and concludes in the Factory Test.
The system, delivered at the end of phase II is to
be available at our site for the integration test at
the latest after review No. 3.2.
The upgraded system is shipped to its destination and
installed as soon as the Factory Test has been successfully
completed. The pricing is based on a re-installation
at the same site as before.
The Acceptance Test is performed immediately after
the successful verification checkout.
The final documentation is finished one month after
the successful Acceptance Test.
The training is envisaged to take place in the period
shortly after the delivery.
