technical management specification for...

VG-SM-200091-C-0003-CNES(2.1)A1.doc SDS validated version

CENTRE NATIONAL D'ETUDES SPATIALES

Sous-Direction Développements Sol

18, Avenue Edouard-Belin 31401 TOULOUSE Cedex 4

Rond-point de l'Espace 91023 EVRY Cedex

SDS/G BP 254 - 97377 KOUROU CEDEX

PROJECT IDENTIFICATION CODE

VG-SM-200091-C-0003-CNES

ISSUE: 2 REVISION : 1

Date édition ou dernière révision :31/03/2003

AUTHOR'S REF. :SDS/PL/SE 2003/0045

CLASSE : 1 CATEGORIE : 1

RESERVED FOR INDUSTRIALIST

ORIGINAL IN FRENCH

PROJECT: VEGA GROUND SEGMENT

TITLE OF DOCUMENT:

TECHNICAL MANAGEMENT

SPECIFICATION FOR CONTROL BENCH CONTRACT

NAME &FUNCTION DATE & SIGNATURE

PREPARED BY:

F. DELAMOTTE SDS/AP/SY

J. TANGUY SDS/PL/SE

FOR APPROVAL: :

P. LEMEUR

SDS/PL/SE

A.RAGOT

SDS/AP

FOR ACCEPTANCE:

M. VALES

VEGA-GS Coordinator

APPLICATION AUTHORISED BY:

M. CARDONE

ESA/IPT

DISTRIBUTION LIST Nb A I

SDS/SG/MS/BT 1 X

SDS/SG 1 X

SDS/AP 1 X

SDS/PL 1 X

SDS/PL/SV M. VALES 1 X

A=Action I=Information



Sous-Direction Développements Sol

18, Avenue Edouard-Belin 31401 TOULOUSE Cedex 4

Rond-point de l'Espace 91023 EVRY Cedex

SDS/G BP 254 - 97377 KOUROU CEDEX

LANGUAGE :Fr ISSUE: 2 REVISION: 1

ISSUE OR LAST REVISION DATE: 31/03/2003

PROJECT IDENTIFICATION CODE

VG-SM-200091-C-0003-CNES

DESCRIPTIVE SHEET

IT FILE

Total number of pages (incl. annexes and cover sheet):

260

Number of pages in Annexes:

TITLE:

TECHNICAL MANAGEMENT SPECIFICATION FOR CONTROL BENCH CONTRACT

AUTHOR NAME(S) J. TANGUY CNES F. DELAMOTTE CNES

DOCUMENT TYPE

MANAGEMENT SPECIFICATION

PHYSICAL CLASSIFICATION CONTRACT N° CLASS: 1

CATEGORY: 1

AUTHOR'S ABSTRACT

This document provides the Technical Management Requirements and Tasks to be applied by the Control Bench Industrial Contractor for the VEGA Ground segment, including a Document Requirement List.

KEYWORDS (entered by Author) RESERVED FOR INDUSTRIALISTS

VEGA Control bench Management



Tite of document: TECHNICAL MANAGEMENT SPECIFICATION FOR

CONTROL BENCH CONTRACT

Sous-direction Développements Sol

VG-SM-200091-C-0003-CNES

Page : 3/260 Iss.: 2 Rev.: 1 Date :31/03/03

ISSUE REVISION DATE REASON FOR CHANGE

1 1 03/02/2003 Creation of document. Translated from french

1 2 07/02/2003 Integration of revision 1.2 of the generic document (VG-SM-21x-C-0002-CNES)

2 0 17/03/2003 Insertion of Product Assurance DRLs and DRDs and of ESA pre-TEB

2 1 31/03/2003 Integration of CNES and ESA comments.






VG-SM-200091-C-0003-CNES

Page : 5/260 Iss.: 2 Rev.: 1 Date :31/03/03

CONTENTS 1. PURPOSE................................................................................................................................................................................................7

2. REFERENCE DOCUMENTS ............................................................................................................................................................8

3. APPLICABLE DOCUMENTS ........................................................................................................................................................10

4. DIRECTORY OF ACRONYMS AND ABBREVIATIONS ....................................................................................................12

5. CONTEXT OF PROJECT................................................................................................................................................................13

5.1. PROJECT ORGANISATION ........................................................................................................................................................ 13 5.2. ROLE OF PARTICIPANTS ........................................................................................................................................................... 13 5.3. PROJECT DEVELOPMENT RATIONALE............................................................................................................................... 14

5.3.1. Phase B2:.................................................................................................................................................................................14 5.3.2. Phase B3:.................................................................................................................................................................................14 5.3.3. Phase C:...................................................................................................................................................................................15 5.3.4. Phase D: Step D1 and Step D2: Realization, Tests and Industrial Acceptance.......................................................15 5.3.5. Step D3: Integrated Tests / Technical Qualification........................................................................................................15 5.3.6. Development Plan (General) ...............................................................................................................................................16 5.3.7. Development milestones........................................................................................................................................................17 5.3.8. Synoptic representation of verification methods applicable to the development phase ............................................18

5.4. PHASING OF INDUSTRIAL ACTIVIT IES INCLUDING SOFTWARE .................................................................................................... 19

6. MANAGEMENT REQUIREMENTS SPECIFIC TO THE CONTRACT .........................................................................20

6.1. GENERAL ............................................................................................................................................................................................ 20 6.2. GENERAL PROGRESS MEETINGS (RGA)......................................................................................................................................... 20 6.3. PROGRESS REPORTS (REPORTING).................................................................................................................................................. 21 6.4. PROJECT CONFIGURATION MANAGEMENT .................................................................................................................................... 22

6.4.1. Product Tree ...........................................................................................................................................................................22 6.4.2. Product classification and development rationale...........................................................................................................25 6.4.3. Contract Configuration Management Plan.......................................................................................................................25 6.4.4. Documents describing the products under configuration management.......................................................................25 6.4.5. Approval of developed product configuration..................................................................................................................26 6.4.6. Product configuration change and management..............................................................................................................26 6.4.7. Modification management process .....................................................................................................................................26 6.4.8. Contract Configuration Audits ............................................................................................................................................27 6.4.9. Configuration Dossiers.........................................................................................................................................................27

6.5. PLANNING MANAGEMENT................................................................................................................................................................ 28 6.5.1. Planning of Project Development and industrial realizations.......................................................................................28 6.5.2. Identified industrial tasks (main tasks)...............................................................................................................................28 6.5.3. Management of Contractual Milestones............................................................................................................................28 6.5.4. Planning progress report......................................................................................................................................................29 6.5.5. Documents and meetings to be held....................................................................................................................................29

6.6. COST MANAGEMENT......................................................................................................................................................................... 29 6.7. RISK MANAGEMENT................................................................................................................................................................... 30

6.7.1. Objectives ................................................................................................................................................................................30 6.7.2. Principles.................................................................................................................................................................................30

6.8. QUALITY ASSURANCE............................................................................................................................................................... 31 6.9. RAMS................................................................................................................................................................................................. 31 6.10. OPERATIONS SUPPORT ........................................................................................................................................................ 31 6.11. DOCUMENTATION MANAGEMENT ................................................................................................................................ 32

6.11.1. Contract Documentation Management Plan.....................................................................................................................32 6.11.2. Identification and presentation of documents...................................................................................................................32 6.11.3. List of document types specific to the Project ...................................................................................................................32 6.11.4. Document recording and access..........................................................................................................................................35






VG-SM-200091-C-0003-CNES

Page : 6/260 Iss.: 2 Rev.: 1 Date :31/03/03

6.11.5. Document circulation and distribution..............................................................................................................................35 6.11.6. Document delivery formats and media:.............................................................................................................................35 6.11.7. Document Delivery List (DDL)............................................................................................................................................36

6.12. WORK DOCUMENTS...................................................................................................................................................................... 37 6.13. DOCUMENT REQUIREMENTS LIST (DRL) ..................................................................................................................... 37

6.13.1. General ....................................................................................................................................................................................37 6.13.2. Tables.......................................................................................................................................................................................38

7. GENERAL MANAGEMENT REQUIREMENTS .....................................................................................................................48

7.1. REQUIREMENT REFERENCES............................................................................................................................................................ 48 7.2. LIST OF APPLICABLE GENERAL MANAGEMENT REQUIREMENTS................................................................................................ 49

8. REPLY TO MANAGEMENT SPECIFICATION .....................................................................................................................75

9. ANNEX 1 « LIST OF DOCUMENT REQ UIREMENTS DESCRIPTION » ...................................................................77

10. ANNEX 2 DOCUMENT REQUIREMENTS DESCRIPTION (DRD)................................................................................81

11. ANNEX 3 LIST OF GUIDELINE DOCUMENTS ................................................................................................................. 233

12. ANNEX 4 DIRECTORY OF ACRONYMS AND ABBREVIATIONS ............................................................................ 246

13. ANNEX 5 - GLOSSARY OF TERMS ........................................................................................................................................ 248






VG-SM-200091-C-0003-CNES

Page : 7/260 Iss.: 2 Rev.: 1 Date :31/03/03

1. PURPOSE

The Management Specification (technical part) of the contract defines the management and development rules applicable to the Contractor's activities for all aspects related to the project steering process, technical co-ordination, production of required documents, information exchange, work follow-up and personnel involved.

The administrative, financial, cost and property management aspects are addressed in (DA0).

The configuration management, quality assurance and RAMS aspects are addressed in document [DA19].

This specification details and sets forth the mutual obligations of the two parties (input to be provided by Customer, activities and results to be provided by Supplier).

The Supplier is referred to hereinafter as the « Industrial Contractor ».

The Management Specification is first incorporated in the request for proposals, then in the Contract.

Structure of Management Specification

- the first part defines the operational set-up and Project context,

- the second part presents the management topics and the methods and tools to be implemented by the Industrial Contractor, as well as the complete list of documents to be delivered to the Customer (DRL - Document Requirements List),

- the third part contains a description of all general requirements to be met (detailed and commented),

- the fourth part contains the Document Requirements Description (DRD) and additional Guideline Documents (GD),

- the fifth part contains directories of acronyms and abbreviations and glossaries of management terms.






VG-SM-200091-C-0003-CNES

Page : 8/260 Iss.: 2 Rev.: 1 Date :31/03/03

2. REFERENCE DOCUMENTS

The table below lists and identifies all reference documents (DR) which have been used to develop this Contract Management Specification.

DR N° DR Reference Title of Document Version Revision Date

1 VG-SM-21-C-0001-CNES VEGA Ground Project Management Specification 2 0 07/11/02

2 VG-PA-21-C-0001-CNES GS Project Product Assurance Plan 1 2 10/12/02

3 ECSS-M-50A Information and Documentation Management 1 1/2002

4 VG-OT-21-C-0001-CNES VEGA Ground Segment WBS 1 1 05/12/2002

5 VG-LI-2-C-0001-CNES Directory of Project Acronyms and Abbreviations 1 1 05/06/02

6 VG-SOW-2-C-0001-IPT Statement of Work of VEGA Ground Segment 2 0 17/06/2002

7 DS-MP-MR-03 Guidelines for project risk management 2 0 19/08/2002

8 VG-ST-200091-C-0015-CNES

VEGA ground checkout equipment requirement specification 3 1 19/03/2003

9 DS-MP-AQ-O7 Non-conformities, anomalies and waivers management 1 5 24/04/2001

10 ECSS-M-00-03A Project Risk Management A 4/6/2002

11 DS-MP-AS-02 Works site regulations 1 1 26/06/2000

12 ECSS-M-40A Space Project Management - Configuration Management A 1/2002

13 ECSS-E-10-02A Space Engineering - Verification A 17/11/1998

14

ECSS-E-10-05A

Space Engineering - Functional Analysis

A 25/4/2000






VG-SM-200091-C-0003-CNES

Page : 9/260 Iss.: 2 Rev.: 1 Date :31/03/03

The above documents will not be communicated to the Contractor, except for DR4, DR7, DR9 and DR11, which will be forwarded on request.






VG-SM-200091-C-0003-CNES

Page : 10/260 Iss.: 2 Rev.: 1 Date :31/03/03

3. APPLICABLE DOCUMENTS

Some of the "general" management requirements derived from (DA0) contain a number of provisions which imply direct links with this document (description of roles of participants, organisation of meetings and reviews, contractual requirements, etc.).

The documents below (DA) are applicable in part or in full according to the particular instructions set forth in (DA0) for the request for proposals, then confirmed at the beginning of the contract.

The chapter "Applicable Documents" of the Statement of Work (DA0) relating to the industrial contract, lists or refers to the technical documents and instructions, as well as the safety regulations and specific clauses to be complied with.

In case of conflict between these documents, the documents specific to the VEGA Project shall have precedence over the general, or "standard" documents.

In the table below, and with the exception of DA0, the order in which the documents are listed does not imply any application priority.

DA N°

Reference Titre Ed. Rev. Date

0 VG– SOW–2-C-0006-IPT Statement of Work of «Control Bench» contract 2 0 26/3/2003

1 VG-OP-2-C-0002-CNES VEGA Ground Segment Product Tree 1 2 06/06/2002

2 ECSS-M-30A Organisation of Reviews A 01/09/1999

3 DS MP CF 08 Review Recommendation Management 1 0 11/02/1999

4 DS MP CF 06 Processing of Modifications (HW & SW) 1 0 13/12/1996

5 Not used

6 DS-MP-AQ-04 Qualification of Hardware and Technologies 1 1 21/08/1997

7 DS-MP-AQ-05 Test and inspection plans, key point inspections 1 1 14/01/1997

8 DS MP AQ 06 Industrial acceptance in factory and on site 2 1 22/10/2001

9 DS MP AQ 07 Anomaly, NC and waiver management procedure 1 5 24/04/2001

10 DS MP AQ 09 Action/Reserve management procedure 1 4 06/03/2001






VG-SM-200091-C-0003-CNES

Page : 11/260 Iss.: 2 Rev.: 1 Date :31/03/03

11 VG-AP-2-C-0002-CNES Vega ground segment software product assurance requirements 1 4 17/3/2003

12 DS MP AQ 11 Production guidelines for accompanying documentation 1 1 13/12/1996

13 DS MP AQ 15 Structure / System hand-over procedure 1 1 12/12/1996

14 DS MP DO 01 Documentation management requirements applicable to Project and Contractors 1 1 28/02/2000

15 not used

16 DS MP AS 02 Working Party rules and regulations 1 0 26/06/2000

17 DS-MP-MR-03 Management of Risk Management Plan 1 0 27/01/2000

18 not used

19 VG-AP-2-C-0005-CNES Control bench contract product assurance requirements and tasks 1 5 28/3/2003

20 DS-MP-SF-04

Guide for management of system safety and maintainability analysis activities

1 0 30/5/2002






VG-SM-200091-C-0003-CNES

Page : 12/260 Iss.: 2 Rev.: 1 Date :31/03/03

4. DIRECTORY OF ACRONYMS AND ABBREVIATIONS

The acronyms and abbreviations used in this management specification are listed in Annex 4.

.






VG-SM-200091-C-0003-CNES

Page : 13/260 Iss.: 2 Rev.: 1 Date :31/03/03

5. CONTEXT OF PROJECT

5.1. PROJECT ORGANISATION

To meet the implementation requirements of the VEGA LV, it has been decided to develop a launch system in Kourou, using the existing facilities (ELA) and the resources of the Ariane Launch Base (BLA), while developing close synergies. The main contractorship of the VEGA Project is ensured by ESA/IPT (Integrated Programme Team), an entity issued from ESA/LAU-V located in Frascati (Italy).

5.2. ROLE OF PARTICIPANTS

The roles of the Ground Segment Manager, Contract Officer, Technical Officer and Project Manager are described in DA0.






VG-SM-200091-C-0003-CNES

Page : 14/260 Iss.: 2 Rev.: 1 Date :31/03/03

5.3. PROJECT DEVELOPMENT RATIONALE

The Project follows the different development phases set forth in the management rules of Reference Documents (DR6) (DR1) and (DA0), which are summarised below for the VEGA system::

PROJECT PHASES AND STEPS

5.3.1. PHASE B2:

Not applicable to the contract.

5.3.2. PHASE B3:

C D DETAILED STUDIES

INDUSTRIAL STUDIES

STUDIES FOLOW UPMOKE UP REALIZATION..

iCDR's

I

BT/CRE

0 A

B1

FEASABILITY

SYSTEMSTUDIES

PRELIMINARY DEFINITION B

B3industrialpreliminarydefintion

B2preliminarydéfinition(optional)

:

D3IntegratedTests

BT/CREI'S

E

D4OpérationalQualification

Glossary : MDR: Program Mission Review . GSKP: Preliminary System Key Point GSQR: . Qualification Review GSPDR: Preliminary Design Review GSSDR: System Definition Review GSIPDR: Industrial Preliminary Design Review GSICDR: Industrial crticial Designreview GSTKP : Technical Qualification review IAR : Industrial Acceptance Review IQR : Industrial qualification Review BT/CRE: Bilan Technique/Commission de Revue des Essais (Acceptance Review) .

D1D2

ExploitationREALISATIONINTEGRATIOVALIDATION

NQUALIFICATION

SYSTEMFEASABILITY STUDIES

FUNCTIONAL NEEDS EXPRESSION

Use

rs T

rain

ing

SUPPORT EXECUTION LOGIC FOR GROUND SEGMENT PROJECT

LV-MDR

GS-KP

GS-PDR

MOA ACTIVITIES MOA ACTIVITY

MOE ACTIVITIES

Support Engineering Activities

INDUSTRIALS CONTRACTORS ACTIVITIES iPDR's

LV-SDR

GS-TKP

RealizationInstallation

GS-QRR

GS-ORR GS-QR

FQR

optionalindustrialsupport

IQR/IAR

FRR






VG-SM-200091-C-0003-CNES

Page : 15/260 Iss.: 2 Rev.: 1 Date :31/03/03

This phase starts with the examination of offers submitted by European Industrialists from member States participating the VEGA Programme.

After selection by the ESA Customer, the technical and contractual negotiations go ahead with the successful tenderer and end with the definition of the contract clauses (including management specification and applicable rules).

This phase marks the beginning of the Industrial Contractor's activities in the VEGA GS Project.

A Technical Kick-off Meeting is organised by ESA and defines the contract T0 (time frame reference).

The Industrial Contractor is then ready to carry out Preliminary Design studies at subsystem level (closed by the iPDR) before starting critical studies.

5.3.3. PHASE C:

Critical Design studies at subsystems level, to be carried out by the Industrial Contractor (see rules 444 onward of chapter 7). This phase closes with the Critical Design Review (ICDR). The Industrial Contractor's activities shall be formalised in an Industrial Design Dossier (DID). A System Definition Review organised by the Customer (GSSDR) shall verify the consistency of the definition after completion of the iPDRs and before the iCDRs of the first delivered products.

5.3.4. PHASE D: STEP D1 AND STEP D2: REALIZAT ION, TESTS AND INDUSTRIAL ACCEPTANCE

These steps are carried out in the factory and on the installation site. The activities carried out by the Industrial Contractor are recorded in the following dossiers (DA14): - Industrial Realization Dossiers (DID), - Industrial Control Dossiers (DIC, DIR) - Industrial Operations Dossiers (DIX). These steps shall close upon Test Readiness Reviews relating to Factory (IQR) and/or Site Acceptance of the Products presented separately (type 0 and 1 tests under Contractor's responsibility). The Test Review Boards held on site (CRE or IAR) are designed to perform a «technical» acceptance, subject to «system» performance which cannot be demonstrated at this stage. The CRE (Test Review Board) end with the hand-over of the system concerned and the passing of ownership between the Contractor and ESA. Then, the GSQRR Board authorises the beginning of integrated tests (grouping of several ground systems). The legal warranties shall take effect upon completion of the CRE (IAR) of each supply received.

5.3.5. STEP D3: INTEGRATED TESTS / TECHNICAL QUALIFICATION






VG-SM-200091-C-0003-CNES

Page : 16/260 Iss.: 2 Rev.: 1 Date :31/03/03

The functions, activities and responsibilities of each entity are specified in the General Test Plan issued by the Customer and SDS (Test Main Contractorship, test Realization). The purpose of these tests is to verify, when several subsystems are implemented jointly, the achievement of the functional and performance requirements of the Ground System, in local mode, then in central mode (integrated tests), and finally with mock-ups of the LV stages (combined tests). Integrated tests are conducted under SDS responsibility. Contractors' participation is required at this stage. It enables them to lift any reserves they may have on the performance of their systems (which could not be demonstrated in the IARs). This step closes with the GSTKP. For combined tests, the operations are conducted under ESA/IPT responsibility. This step closes with the GSORR. Contractors' participation in the combined tests is required for support. When all tests of the whole System are completed and successful, the GSORR Test Review Board (chaired by ESA) formalises the end of phase D3. Finally the CRE/QO Board (GSQR) decides on the operational use of the Ground Segment in the first launch campaign.

5.3.6. DEVELOPMENT PLAN (GENERAL)

The Industrial Contractor shall produce and submit for Customer approval the Development Plan of the specific supplies required under the contract in its preliminary version, then complete it for the subsequent scheduled milestones. It shall give a general description of the following (for Hardware and/or Software):

Topics to be addressed Yes/No For

Schedule and planning networks Y Proposal

Brief description of subsystems and associated functions Y Proposal

Design and justification rationale of the system defined Y ICDR

System realization and validation rationale Y ICDR

General Test Plan and Validation Plan Y Subsystems TRR

The means necessary and subcontracting envisaged Y ICDR

Work contents and detailed work breakdown Y ICDR






VG-SM-200091-C-0003-CNES

Page : 17/260 Iss.: 2 Rev.: 1 Date :31/03/03

The Development Plan is mandatory in the case of Controlled Configuration Products (PCC).

The specific contents of the Development Plans (relating to Hardware or Software products) are described in document DRD-ENG-101.

5.3.7. DEVELOPMENT MILESTONES

The Product Tree (OP) Code is detailed in paragraph 6.4.1.

WP or Product IPDR ADR ICDR IQR IAR GSTKP GSORR

BCV X X X X X support Support

Calculation centre X X X X X Support support

Application X X X support Support

Payload connections X X X X support support

Control bench - top section X X X X support support

GSTKPs and GSORRs are not actual development milestones, but steps in which the Contractor is involved.






VG-SM-200091-C-0003-CNES

Page : 18/260 Iss.: 2 Rev.: 1 Date :31/03/03

5.3.8. SYNOPTIC REPRESENTAT ION OF VERIFICATION METHODS APPLICABLE TO THE DEVELOPMENT PHASE

PRINCIPALES RELATIONS ENTRE EXIGENCES ET DOCUMENTS

RFQ PROPOSAL CONTRACT

DRLSOW

parti

e te

chni

que

parti

e m

anag

emen

t et P

.A.

Requir. Tracab. Matrix

Plans de Gestion (conf, doc, délais)

Plan AQ, PLan SdF,...

Plan de Management du Contrat

Verification Cross Ref. Matrix

Plan de Verification des Exigences P.V.E.

W.B.S.Fiches de Tâches

OrganigrammeProduit P.T.

Plan de Développement

Master Planning

Action Item List, Configuration Reports, Delivery doc status...

A.I.T. Plan or A.I.V. Plan

VerificationControlDossier VC.D.

Rap

port

de

Bila

n T

echn

ique

Rap

port

de C

RE

Rapport périodique d'Avancement au Client

RAMS and Q.A. Reports

Review Reports, Recoms status,...

Technical Specifications, Drawings,...

Realisation and Installation Plannings

Industrial FilesDID, DIC,DIX

part

ie F

inan

cièr

e

Procurement Plan + C.B.S.

O.V.P.

Changes, Waivers, NCR

R

appo

rt d

e C

RE

/QT

R

appo

rt d

e C

RE

/QO






VG-SM-200091-C-0003-CNES

Page : 19/260 Iss.: 2 Rev.: 1 Date :31/03/03

5.4. PHASING OF INDUSTRIAL ACTIVITIES INCLUDING SOFTWARE

The general sequencing of the main milestones of BCV development, system milestones and software milestones, is specified in chapter 6 of DA19.

The diagram below describes this sequencing of software and system reviews and acceptance.

The software acquisition, development and integration rationale is specified in DA11. The documents required at each software development milestone are indicated in the DRL and in document DS-IT-SE-51 referred to in DA11. The « SW ADR » is also referred to as « Software Preliminary Design Review » in the applicable documents and in DA11.

IPDR ICDR

SRR SW ADR SW DDR

IQR BCV HW+SW

BCV SW






VG-SM-200091-C-0003-CNES

Page : 20/260 Iss.: 2 Rev.: 1 Date :31/03/03

6. MANAGEMENT REQUIREMENTS SPECIFIC TO THE CONTRACT

6.1. GENERAL

After placing the Project in its context, the aim is to define the requirements which Contractor « X » must meet and incorporate first in its proposal and subsequently in the Contract.

This chapter provides further information on the approach and defines additional requirements:

- general requirements (fully developed in chapter 7),

- additions to the general requirements (particular aspects to be considered, specific to the contract),

- the list of documents Required and Deliverable to the Customer (DRL),

- the appended Guideline Documents or Document Requirements Description sheets.

6.2. GENERAL PROGRESS MEETINGS (RGA)

These meetings address contractual aspects (organisation, technical issues, progress, etc.) and review the subcontractors' activities. The Industrial Contractor shall prepare the agenda, organise the meeting and produce the meeting reports. The SDS Project Co-ordinator and ESA/IPT shall be informed of the Agenda of the meeting, giving the prior notice defined in the table below. The SDS Technical Officer shall chair the meeting and ensure that the approved agenda is observed. The SDS engineers concerned may attend the meeting. Typically, these meetings shall be held once a month.

The ESA Contract Officer shall always attend the meeting when contractual issues are addressed. ESA/IPT and the SDS Co-ordinator can participate in these meetings in a capacity as observers.

Activity Requirement Frequency of general progress meetings (RGA) Monthly Place of RGA On the premises of the Industrial Contractor Notice and distribution of agenda 7 days at least before the RGA






VG-SM-200091-C-0003-CNES

Page : 21/260 Iss.: 2 Rev.: 1 Date :31/03/03

Distribution of activity report 7 days at least before the RGA Submission of report by Contractor 7 days after the RGA at latest

6.3. PROGRESS REPORTS (REPORTING)

The Progress Report produced by the Industrial Contractor shall contain updated information on the situation relating to each management and follow-up area (summary and detailed information). The provisional activity completion dates shall be compared with the progress objectives specified in the approved planning. Progress information on subcontractors' activities (technical summary to be produced by each subcontractor) shall be included in the status reports submitted.

The Progress Reports shall be transmitted by the Industrial Contractor 3 days at least before the RGA meeting. They shall be analysed by the Technical Officer for technical and organisational aspects, and by ESA for programmatic, contractual and financial aspects.






VG-SM-200091-C-0003-CNES

Page : 22/260 Iss.: 2 Rev.: 1 Date :31/03/03

6.4. PROJECT CONFIGURATION MANAGEMENT

The configuration management system implemented by the Industrial Contractor shall: - enable ESA/IPT, at Programme level, to manage the configuration of PCC products (controlled configuration products), - provide the ESA/IPT Customer with adequate visibility on System components definition, - enable SDS to control the definition of the elements supplied or developed, - provide SDS and ESA/IPT with adequate visibility on the effective physical configuration of the products delivered.

From design to integration, ESA/IPT or their industrial architect (ELV), may issue specific management requirements regarding the configuration of some elements (IPT-controlled Configuration Products).

The configuration management of Programme/Project interface products is subjected to a process specific to VEGA needs (circulation, examination and application of MPs), based on the System's Interface Specification (IS). The Industrial Contractor shall participate, for the part under its responsibility, in this process [production of Qualification Justification Dossier (DJQ)].

The configuration management requirements set forth in [D19] supplement the general requirements of Chapter 7 of this document, and give the conditions of their integration by the Contractor.

6.4.1. PRODUCT TREE

The products to be developed under the contract are identified in the following «product» tree:

Level Product Code Structure Code Product or Subsystem PCC

213091 213 BCV located at CDL (Launch Centre) yes

2130911 213 BCV equipment located at CDL yes

21309111 213 BCV electrical connections located at CDL yes

2130911X 213 Equipment unit X yes

2130912 213 BCV SW (Levels 1 & 2) located at CDL yes

2130912X 213 SW unit X yes

2130913 213 BCV application (Level 3) TBD






VG-SM-200091-C-0003-CNES

Page : 23/260 Iss.: 2 Rev.: 1 Date :31/03/03

213093 213 Calculation centre located at CDL No

2130931 213 Calculation centre equipment No

2130931X 213 Equipment unit X No

2130932 213 Calculation centre SW No

2130932X 213 SW unit X No

212091 212 BCV located at launch pad yes

2120911 212 BCV equipment located at launch pad yes

21209111 212 BCV electrical connections located at launch pad

yes


2120912 212 BCV SW located at launch pad yes


212095 212 Launch pad payload connections yes

210091 210 BCV Launch pad/CDL electrical connections yes

211091 211 BCV located in Service Tower yes

2110911 211 BCV equipment located in Service Tower yes

21109111 211 BCV electrical connections in service tower yes


2110912 211 BCV SW located in service tower yes


211095 211 Payload connections in service tower yes

The Product Tree (OP) codes for the BCPH (Control bench - top section) shall be defined at a later stage (TBD).






VG-SM-200091-C-0003-CNES

Page : 24/260 Iss.: 2 Rev.: 1 Date :31/03/03

The Industrial Contractor shall comply with the identification rules set forth in (DA1) and submit its proposal to the SDS Technical Officer before application.

The GS Project identifies a priori, among the facilities to be developed, Customer Controlled Configuration Products (PCC).

PCCs shall be imperatively covered by a Development Plan, a Technical Specification, a Justification Dossier, RCIs, and the results obtained shall be examined in a Qualification Board. Qualification certificates shall be issued and signed by ESA/IPT.

.






VG-SM-200091-C-0003-CNES

Page : 25/260 Iss.: 2 Rev.: 1 Date :31/03/03

6.4.2. PRODUCT CLASSIFICATION AND DEVELOPMENT RATIONALE

In order to optimise the development efforts and associated management activities, the VEGA GS Project has defined a product classification process. The classification is based on the level of criticality (functional, operational, security), on technical complexity (interfaces, technologies) and on the context (feedback from experience, risk containment). The classification determines the type of development rationale recommended and therefore the activities, milestones, documents and inspections required. See GD-101, Annex 3.

The components to be subjected to individual qualification are listed in the following table:

Product or subsystem Indiv. Qualif.

BCV X

Calculation Centre X

Application X

Payload connections X

Control Bench - Top section X

6.4.3. CONTRACT CONFIGURATION MANAGEMENT PLAN

The Industrial Contractor shall produce and maintain a Configuration Management Plan applicable to all development activities under its responsibility. The configuration management process described in this Plan shall meet the relevant requirements set forth in [DA19].

6.4.4. DOCUMENTS DESCRIBING THE PRODUCTS UNDER CONFIGURATION MANAGEMENT

The documents describing a product configuration shall at all times reflect the current status of the product. Their initial approval and subsequent changes are subjected to the rules set forth in the product configuration management plan.






VG-SM-200091-C-0003-CNES

Page : 26/260 Iss.: 2 Rev.: 1 Date :31/03/03

The applicability of a document (incorporated in the configuration managed) shall be confirmed by the approval of the Industria l Contractor «application authorised by:» of the authorised entity as defined in the rules of the relevant Documentation Management Plan. At each Industrial Review (iPDR, iCDR, IQR and IAR), SDS shall verify the availability and composition of the Industrial Design and Realization Dossiers submitted by the Industrial Contractor, prior to transferring them to ESA for approval.

6.4.5. APPROVAL OF DEVELOPED PRODUCT CONFIGURAT ION

The reviews are an opportunity to keep the parties involved properly informed of any configuration changes implemented since the previous review, so they can integrate such changes in their activities. However, for the systems and/or subsystems developed (non PCC), the critical design cannot be approved in a specific review. In this case, the approval process is ongoing, based on the documents submitted according to the Documentation management rules, as and when they are submitted.

As a rule, once the approval is confirmed by Project at the end of a review and after incorporation of the recommendations, the configuration is deemed "applicable". From then on, it is managed under a controlled change process.

6.4.6. PRODUCT CONFIGURATION CHANGE AND MANAGEMENT

Any modification request relating to a product described in an already approved document (CCR or MP) and formulated by the Industrial Contractor, shall comply with the rules set forth in (DA4) and follow the procedure defined in its Configuration Management Plan. SDS shall ensure, at System level, that any request for modification issued by the Industrial Contractor is classified correctly and that any impact on the products is clearly identified. The Industrial Contractor shall not incorporate a request for modification until the modification order is issued (DR).

6.4.7. MODIFICATION MANAGEMENT PROCESS

Configuration Control at Programme level imposes a modification management process; the following rules shall be implemented by the Industrial Contractor:

- assignment of modification classes and observance of decision levels depending on the class assigned,

- application of modification handling procedures (formats, circuits, boards),

- justification of Ground/Airborne interface modification processing.

See DRD-MAN-121.






VG-SM-200091-C-0003-CNES

Page : 27/260 Iss.: 2 Rev.: 1 Date :31/03/03

The Technical Officer shall manage the requests for technical modifications submitted by the Contractor (if they have an impact on the characteristics specified in the contract or in the documents approved by the Customer). He/she shall ensure that they are properly monitored by the Contractor (examination, study of impact, submission to boards, document update, validations).

NB: This paragraph only addresses "technical" modifications. "Contractual" modifications are handled in accordance with SOW provisions (DA0).

6.4.8. CONTRACT CONFIGURATION AUDITS

SDS shall conduct configuration audits throughout the period of the contract (for activities specific to the Industrial Contractor and subcontractors) as indicated in the Quality Assurance provisions (DR2 and DA19), to ensure that all provisions included in the Contract Management Plan (PMC) and the Configuration Management Plan are effectively implemented and meet ESA/IPT requirements. ESA may conduct at all times configuration audits of the Industrial Contractor's activities. SDS shall participate in any external audits initiated and conducted by ESA.

6.4.9. CONFIGURATION DOSSIERS

SDS shall ensure (through audits, inspections or report analyses) that the Configuration Dossiers produced by the Industrial Contractor guarantee satisfactory development of the Qualification Review (GSTKP).






VG-SM-200091-C-0003-CNES

Page : 28/260 Iss.: 2 Rev.: 1 Date :31/03/03

6.5. PLANNING MANAGEMENT

6.5.1. PLANNING OF PROJECT DEVELOPMENT AND INDUSTRIAL REALIZATIONS

Each industrial consultation shall be accompanied by a Target Schedule showing the deadlines imposed and the operational periods. The analysis of the reply from the Industrialists solicited shall enable SDS to issue a precise, consolidated Industrial Development Schedule.

The proposed schedule, accepted by the Customer, shall become the reference contractual schedule and shall reflect the commitment of the Industrial Contractor throughout the Development phase.

Scheduled tasks are industrial activities and tasks identified in the Work Breakdown Structure (DR4). They shall be updated on a monthly basis.

6.5.2. IDENTIFIED INDUSTRIAL TASKS (MAIN TASKS)

To date, only the task sheets of phase 1 are identified. The task sheets of phase 2 shall be specified at a later stage (TBD).

Task sheets accompanied by a WBS, to be submitted with the reply to the invitation to tender, shall conform with DRD-MAN-109.

The tasks are broken down into major families: calculation centre, BCV, option, spare parts, etc.

Options shall also be described in task sheets. The breakdown shall be detailed and similar to that proposed for the calculation centre. It must be self-explanatory, i.e. include technical co-ordination work packages, product assurance, documentation, etc., specific to each work package.

The breakdown shall include as a minimum the levels described in DA0.

The system level planning of the VEGA GS (General Realization Schedule) is produced by the Customer and based on the Task Sheets (created by the Industrial Contractor and showing the breakdown and description of the contractual work packages). These Sheets shall be sufficiently detailed so each key event (delivery of product or documentation) or interface event (between the contractual work packages, between structural items or subsystems or with other contracts) is shown as an input or output element of the activity identified.

The SDS Technical Officer shall analyse and comment for ESA/IPT the Realization Schedule of the Industrial Contractor (lead times and associated costs).

For any change to the lead times and milestones approved in the reference Schedule issued at the beginning of the Contract, the Contractor shall apply the procedure specified in (DA0).

6.5.3. MANAGEMENT OF CONTRACTUAL MILESTONES

All milestones specified by ESA shall be shown in the industrial schedules.






VG-SM-200091-C-0003-CNES

Page : 29/260 Iss.: 2 Rev.: 1 Date :31/03/03

If existing milestones are modified or additional milestones identified by ESA in the course of contract development, they shall be included in the Realization Schedule after discussion with the Industrial Contractor.

If necessary, the Customer may ask the Industrial Contractor to organise specific planning meetings.

6.5.4. PLANNING PROGRESS REPORT

Planning management by the Industrial Contractor in the course of work performance shall be reported periodically to the ESA Customer. The reports shall be based on:

- the update of the list of key events and contractual milestones, - the submission of schedules (General Realization Schedules and separate schedules for each

system/structure), - comments and analyses regarding actual progress, - any deviations and general trends with relation to each contractual milestone, - the analysis of sensitive issues and critical paths. NB: The Customer shall be able to consult, on request, the subcontractors' schedules for information. If a significant modification of the Contractor's activity schedule occurs between two progress reports, the Contractor shall inform the Customer within two days of such occurrence to analyse the situation without delay.

6.5.5. DOCUMENTS AND MEETINGS TO BE HELD

Documents to be supplied/Meetings to be held Yes/No Update frequency

Schedule management plan N If needed

Schedule progress meeting Y RGA (General Progress Meeting)

Procurement and manufacturing schedule Y 1 month

General Realization Schedule Y 1 month

Specific Planning meeting If needed 2 months

System/structure schedules Y 1 month

Working party schedule Y 1 week

Test/Validation schedule Y 1 month

Subcontractors' schedules (info) Y as applicable

6.6. COST MANAGEMENT

Please refer to Statement Of Work (DA0)






VG-SM-200091-C-0003-CNES

Page : 30/260 Iss.: 2 Rev.: 1 Date :31/03/03

6.7. RISK MANAGEMENT

6.7.1. OBJECTIVES

To meet general management requirements, a risk management policy shall be implemented by the Contractor.

The areas requiring risk analyses are as follows:

• technical or operational performance (delivered product not conforming with the specifications, refusal by Customer, Users),

• the financial resources and budgets (unavailability of resources or overcosts),

• programmatics (late deliveries with or without overcosts).

At contract commencement, the overall provisional costs and timeframe shall be defined on the basis of the specified product performance and the contractual environment of product development.

The contractual risks to be taken into account in the analyses and evaluations are as follows:

• Interface risks with and from Customer,

• Industrial team internal risks,

• Interface risks with and from subcontracted industrialists,

• Interface risks related to the operating sites.

To conduct this activity, the industrialist may refer to document (DR7).

6.7.2. PRINCIPLES

The risk management activity shall be subdivided into three parts:

• writing of the risk management plan describing how «contractual risks» shall be handled from identification to control, to ensure achievement of the contractual objectives,

• production of risk acceptability diagrams built up on the basis of the contractual requirements and used as a reference for residual risk acceptability,

• production of risk analysis on the basis of the elements described in the Risk Management Plan.

Activity reports shall be presented in Quarterly progress meetings.






VG-SM-200091-C-0003-CNES

Page : 31/260 Iss.: 2 Rev.: 1 Date :31/03/03

6.8. QUALITY ASSURANCE

Please refer to the Quality Assurance requirements [DA19] which specifies, as a supplement to the general requirements of chapter 7 herein, the conditions of integration by the Contractor.

6.9. RAMS

Please refer to the Quality Assurance requirements [DA19] which specifies, as a supplement to the general requirements of chapter 7 herein, the conditions of integration by the Contractor.

6.10. OPERATIONS SUPPORT

The integrated logistic support provisions shall be described by the Contractor in the contract Management Plan.

The Contractor shall build up, as the Project develops, an Operations Dossier to be submitted at the end of the work. This Dossier shall include

Dossier name Documents YES/NO or Observations

Operations .the implementation specifications (S.M.O*.) Yes

.the User Manuals (M.U.*) and associated procedures Yes

Maintenance .the maintenance concept Yes

.the maintenance plan (list and frequency of maintenance operations) Yes

.the maintenance procedures Yes

.the teams necessary for operations, number and level (certification) Yes

.the maintenance facilities and tools Yes

.the available management resources Yes

.the list of spare parts and initial parts. Yes

.the list of long delivery items

Training .the training plans Yes

.the training supports Yes

Inventory .Final inventory of priced Property As per DA0






VG-SM-200091-C-0003-CNES

Page : 32/260 Iss.: 2 Rev.: 1 Date :31/03/03

The Operations Dossier shall be submitted at the Technical Qualification Board (GSTKP) at the latest for Customer approval.

6.11. DOCUMENTATION MANAGEMENT

The function of Project Documentation Manager is fulfilled by the "Technical Office", Support and Management Division, General Resources Department, CNES/DLA/SDS/SG/MS/BT.

6.11.1. CONTRACT DOCUMENTATION MANAGEMENT PLAN

The Industrial Contractor shall produce and maintain a Documentation Management Plan applicable to all development activities. The documentation management process implemented by the Contractor shall be in line with the provisions described in its Configuration Management Plan (approval of documents issued, verification of incoming documents, distribution).

The documentation management system implemented by the Industrial Contractor shall: - Take into account document classification: - Specify the document coding and recording conditions, - Define rules for internal and external circulation of documents, - Define applicable models, formats and contents, - Indicate the validation and approval circuits, - Describe the document update methods, - Specify the document confidentiality rules and access rights.

6.11.2. IDENTIFICATION AND PRESENTATION OF DOCUMENTS

The coding to be applied by the Industrial Contractor is defined in (DA14).

The Project code (zone 1) assigned is: VG

The Family identifier (zone 4) to be used (throughout the Project) is: C

The issuing code assigned to the Industrial Contractor (by the Customer) is: (TBD for the contract)

6.11.3. LIST OF DOCUMENT TYPES SPECIFIC TO THE PROJECT

Code Heading Heading AO APPEL D’OFFRES - Request for Proposals MI MANUEL D’INSTALLATION - Installation Manual QA QUALITY ASSURANCE MM MANUEL DE MAINTENANCE - Maintenance Manual BI BILAN MASSE - Weight budget MR MANAGEMENT DES RISQUES - Risk Management BT BILAN TECHNIQUE - Test Readiness Review MU MANUEL UTILISATEUR - User Manual CC CERTIFICATE OF CONFORMANCE MV PLAN DE MAITRISE DE LA VALEUR - Value Control

Plan CD CR COMITE DIRECTEUR - Steering Committee Report NM NOMENCLATURE

CE CR ESSAI - Test report NO NOTE D’ORGANISATION - Organisation Note






VG-SM-200091-C-0003-CNES

Page : 33/260 Iss.: 2 Rev.: 1 Date :31/03/03

CF CAHIER DES CHARGES FONCTIONNEL - Functional Specification

NT NOTE TECHNIQUE - Technical Note

CM CR COMMISSION MODIFICATION - Change Board Report

OP ORGANIGRAMME PRODUIT - Product Tree

COD LISTING SOURCE (LOGICIEL) - Source List (SW) OT ORGANIGRAMME TECHNIQUE- Technical Work Breakdown Structure

CP CADRE DE PROCEDURES - Procedural set-up PC PLAN DE CONTRÔLE - Inspection Plan CQ CERTIFICAT DE QUALIFICATION - Qualification

Certificate PCT PLAN DE CONTRÔLE DES TRAVAUX - Work Inspection

Plan

CR COMPTE RENDU - Report PE PLAN D’ESSAIS - Test Plan CT CLAUSES TECHNIQUES - Technical Conditions PEQ PLAN D’ESSAIS DE QUALIFICATION - Qualification

Test Plan

DA DIRECTIVE D’APPLICATION - Application Directive PG PLANNING GENERAL - General Planning DC DOSSIER COUT - Cost Dossier PI PROCEDURE D’INSPECTION - Inspection Procedure DCD DOSSIER DE CONCEPTION DETAILLE - Critical Design

Dossier PK POINT CLE - Key Point

DCP DOSSIER DE CONCEPTION PRELIMINAIRE - Preliminary Design Dossier

PL PLAN

DE DOSSIER D’ESSAI - Test Dossier PLG PLAN DE GESTION - Management Plan DF DOSSIER FONCTIONNEL - Functional Dossier MP MODIFICATION PROPOSAL DFQ DOSSIER FIN ESSAIS QUALIFICATION - Qualification

Test Completion Dossier PMP PLAN DE MANAGEMENT PARTICULIER - Specific

Management Plan DI DOSSIER INDUSTRIEL - Industrial Dossier PO PROCEDURE/PLAN OPERATION - Operating procedure /

plan

DIC DOSSIER INDUSTRIEL CONTROLE - Industrial Control Dossier

POD PROCEDURE OPERATIONNELLE DEPANNAGE - Operational Troubleshooting procedure

DID DOSSIER INDUSTRIEL DEFINITION - Industrial Definition Dossier

POM PROCEDURE OPERATIONNELLE MAINTENANCE - Maintenance operational procedure

DIF DOSSIER INDUSTRIEL FABRICATION - Industrial Manufacturing Dossier

POR PROCEDURE OPERATIONNELLE. REVALIDATION - Revalidation operational procedure

DIR DOSSIER INDUSTRIEL REALISATION - Industrial Realization Dossier

PP PLANNING

DJ DOSSIER DE JUSTIFICATION - Justification Dossier PR PROCEDURE D’ESSAI - Test procedure DJI DOSSIER JUSTIFICATION INTERFACES - Interface

Justification Dossier PRQ PROCEDURE D’ESSAI QUALIFICATION - Qualification

test procedure DP DOSSIER DE PRESENTATION - Presentation Dossier PV PROCES-VERBAL - Report / minutes DPQ DOSSIER PRESENTATION QUALIFICATION -

Qualification Presentation Dossier PVE PLAN VERIFICATION EXIGENCES - Requirements

verification plan

DQ DOSSIER DE QUALIFICATION - Qualification Dossier RA RAPPORT D’ACTIVITE - Activity Report DSP DOSSIER SPECIFICATION DE PROCEDES - Process

Specification Dossier RC REGISTRE DE CONFIGURATION - Configuration

Register

DV PLAN DE DEVELOPPEMENT - Development Plan RCH RAPPORT DE CHOIX - Selection report EF DOCUMENTS D’EXIGENCES D’INTERFACES -

Interface requirement documents RCI REGISTRE CONTROLE INDIVIDUEL - End Item Data

Package (EIDP)

EP ETAT CONFIGURATION DES PRODUITS - Product Configuration Status

RE RAPPORT D’ESSAI - Test report

FA FICHE D’ANOMALIE - Anomaly sheet RF RAPPORT FINANCIER - Financial Report

FM FICHE DE MODIFICATION - Modification Sheet RLV REGISTRE LANCEMENT VEHICULE - LV launch Log GC GESTION DE CONFIGURATION - Configuration

Management RP REPERTOIRE DES PLANS - Plan Directory

GD GESTION DE DOCUMENTATION - Documentation Management

RR RAPPORT DE REVUE - Review Report

GR REGLEMENT GENERAL - General Regulations RS REGLEMENTATION & SAUVEGARDE - Regulations & Backup

IB Property Inventory RSI REGISTRE SUIVI D’INTEGRATION - Integration follow-up log

LA LISTE D’ACTIONS - Action Items List SA SPECIFICATION D’APPROVISIONNEMENT - Procurement specification

LC LISTE DES COMPOSANTS - Component Items List SC SPECIFICATION DE CONTRÔLE - Control Spec.






VG-SM-200091-C-0003-CNES

Page : 34/260 Iss.: 2 Rev.: 1 Date :31/03/03

LD LISTE DES DOCUMENTS - Document Items List SE SPECIFICATION D’ESSAI - Test Specification LFA LISTE DES FOURNISSEURS AUTORISES - List of

authorised Suppliers SF SURETE DE FONCTIONNEMENT - RAMS (Reliability,

Availability, Maintainability and Safety)

LI LISTE - List SG SPECIFICATION GENERALE - General Specification LM LISTE DES MATERIAUX - Materials List SI SPECIFICATION D’INTERFACE - Interface Spec. (IS) LP LISTE DES PROCEDES - Process List SM SPECIFICATION DE MANAGEMENT - Management

Specification

LR LISTE DES RECOMMANDATIONS - Recommendation Item List

SMO SPECIFICATION DE MISE EN ŒUVRE Implementation Specification

LS LIVRET SUIVEUR - Log book SP SPECIFICATION DE PROCEDE - Process Spec. LT LISTE DES TECHNOLOGIES - Technology list SR SPECIFICATION DE REALISATION - Realization

Specification

MC MATRICE DE CONFORMITE - Conformity Matrix ST SPECIFICATION TECHNIQUE - Technical Spec. MG PLAN DE MANAGEMENT - Management Plan SY SYNOPTIQUE - Synoptic diagram






VG-SM-200091-C-0003-CNES

Page : 35/260 Iss.: 2 Rev.: 1 Date :31/03/03

6.11.4. DOCUMENT RECORDING AND ACCESS

All physical documents (Paper, Dossiers, Plans) issued or received shall be recorded, classified and stored so as to enable easy and prompt retrieval. The Industrial Contractor's documentation manager shall have suitable premises for this purpose and reliable methods and tools to manage the technical documentation. The Industrial Contractor shall ensure that all documents in electronic format can be recorded, classified and stored in a system (EDM type) allowing easy and prompt retrieval by authorised persons.

6.11.5. DOCUMENT CIRCULATION AND DISTRIBUTION

All documents issued by the Industrial Contractor and subjected to Customer approval shall be transmitted in paper form to allow insertion of the approval stamp (see chapter 6.13 and requirements set forth in § 7.2). The list of documents to be transmitted by the Industrial Contractor in the course of Contract performance (namely those listed in the DRL) and the required conditions (frequency, formats) are specified in chapter 6.13 and in the requirements of § 7.2.

6.11.6. DOCUMENT DELIVERY FORMATS AND MEDIA:

Product software package Version/format

observations

Cover pages (provided by Customer) WORD 97 V2.74 Readable and modifiable

Text document WORD 97 Readable and modifiable

Text document PDF 1.4 Not modifiable

Text document HTML Readable and modifiable

Tables EXCEL 97 Readable and modifiable

Presentations POWERPOINT 97 Readable and modifiable

Images, photos (separate) Readable with pack office

Videos (separate) Readable with pack office

Plan, drawing (separate) AUTOCAD 2000 Readable and modifiable

Database ACCESS 97 Readable and modifiable






VG-SM-200091-C-0003-CNES

Page : 36/260 Iss.: 2 Rev.: 1 Date :31/03/03

Diagrams, synoptics DESIGNER 7 Readable and modifiable

Diagrams, synoptics VISIO Readable and modifiable

NB: The IT files delivered may be generated using more recent software versions than those specified, but they shall be entirely compatible (without loss of attributes) with the versions listed above.

Delivery on CD-ROM are permitted.

The number of copies of work documents and drawings is as follows:

- For drawings: (if control organisation and site office involved): 5 copies, otherwise 3 copies,

- For other documents: 1 « paper » copy + 1 copy in native file format.

6.11.7. DOCUMENT DELIVERY LIST (DDL)

The list of documents “delivered” to ESA by the Industrial Contractor is referred to as Document Delivery List (DDL). This list includes the "deliverable" documents mentioned in the DRL (see also DA0) and those included in the Configuration Item Data List (CIDL) of PCC products. The «final» documentation prepared by the Industrial Contractor for submission to the ESA Customer is structured according to DRL (Document Requirements List) recommendations. See chapter 6.13. The Contractor shall provide an updated list (at Customer request) bearing the following information:

Document ref. Dossier ref. Document title Iss./rev. GB Delivery date N° of dispatch note

The tables of chapter 6.13 show the contractual events at which the Dossiers shall be produced or submitted; the initials used have the following meanings:

P = Dossier «Initialisation», production and submission of a preliminary or partial version,

U = «Update» and submission of Updated Dossier for the event,

F = Dossier in «Final» format delivered at the end of the contract.






VG-SM-200091-C-0003-CNES

Page : 37/260 Iss.: 2 Rev.: 1 Date :31/03/03

The Industrial Contractor shall output periodically the list of documents "delivered", identifying the documents which are part of the DDL and those which are not. This list shall be updated and incorporated in the Contract Configuration Report.

The conformity of the documents supplied with the requirements of the DRD (Document Requirements Description) shall be indicated by the Industrial Contractor in the Conformity Matrix. See Annex 3.

The delivery supports, media and formats imposed are specified in (DA14).

6.12. WORK DOCUMENTS

See chapter 6.11.6.

6.13. DOCUMENT REQUIREMENTS LIST (DRL)

6.13.1. GENERAL

This list includes all Deliverable documents and corresponding Dossiers.

To meet the requirements expressed, the DRL refers to Document Requirements Description sheets (DRD) or Guideline Documents (GD) such as those presented in Annex 3, but also to CNES documents specific to Ground Segment installation projects.

The references of the DRDs and GDs are given in the second column of the tables below. All documents identified for delivery during the «Proposal» period are not approved by the Customer but shall be submitted to the ESA offer evaluation commission for examination and acceptance.

Throughout the contract, all documents identified by the code « U for Updated» in the tables below shall be submitted for approval to the Technical Officer (who shall seek comments from PA, CO and MP services).

All documents «deliverable» to ESA/IPT at the end of the contract shall be submitted for approval to the ESA/IPT Project Manager (who shall seek comments from PA, TO and CO services).

In the tables below, the «T0» date of the contract means the effective start of the industrial activities (which may give rise to an «Authorisation to Proceed»).

The language imposed for all documents is English.

The dossiers below may be grouped together:

DIR+DIC DQA+DSF.

In the tables below, the acronyms have the following meaning:






VG-SM-200091-C-0003-CNES

Page : 38/260 Iss.: 2 Rev.: 1 Date :31/03/03

P: Preliminary version of document to be submitted to the customer one week at the latest before the scheduled milestone, U: Complete version of document, possibly updated, to be submitted to the customer one week at the latest before the scheduled milestone, F: Final version of document to be submitted to the customer one week at the latest before the scheduled milestone, X: Current version of document. The "remarks" column of the tables below may contain references to documents of this specification or SOW DA0.

6.13.2. TABLES



Titre du document : TECHNICAL MANAGEMENT SPECIFICATION FOR



VG-SM-200091-C-0003-CNES

Page : 39/260 Ed.: 2 Rev.: 1 Date :15/04/03

Title of document or dossier DRD code proposal T0 T0+1 month

IPDR &

SRR

SW ADR

ICDR &

DDR IQR IAR TKP OR

R remarks frequency

Contract Organisation Dossier (DOC) DRD-MAN-102 P U U F

Management Plan (including Management Requirements Compliance Matrix) DRD-MAN-103 P U F

Directory of Acronyms and Abbreviations DRD-MAN-105 P U U U U F

Contract Directory DRD-MAN-106 P U U U U U U F May be included in MAN-103

Contract Risk Management Plan DRD-MAN-107 P F May be included in MAN-103

Contract Risk management register DRD-MAN-108 P U U F 3 months

Risk acceptability diagrams Free form P U U F May be included in MAN-103

Product Tree - Functional Tree DRD-ENG-110 P U U F

System and sub-system Planning DRD-MAN-115 P U U U F For every progress meeting

Configuration Management Plan (including conf. change procedure and forms) DRD-MAN-118 P F

SW Configuration Management Plan DRD-MAN-130 P U U U F May be included in MAN-118

Documents Management Plan DRD-MAN-126 P U F May be included in MAN-103

Contract Development Plan DRD-ENG-101 P U F

SW development / management Plan DRD-MAN-104 P U U F May be included in ENG-101

Industrial Review Organisation Notes DA2 F F

Industrial Review Reports DA2 F F

Industrial Acceptance Reports DRD-PA-115 F






VG-SM-200091-C-0003-CNES

Page : 40/260 Ed.: 2 Rev.: 1 Date :15/04/03

Acceptance Certificates (PVR) DRD-PA-127 F F

Contract Progress Report DRD-MAN-127 X X X X X X For every progress meeting






VG-SM-200091-C-0003-CNES

Page : 41/260 Ed.: 2 Rev.: 1 Date :15/04/03


IPDR &

SRR

SW ADR

ICDR &DDR IQR IAR TKP OR

R remarks frequency

Industrial Definition Dossier (DID) DRD-ENG-108 P U U U U U F

Product Baseline and Technical Specifications (TS) DRD-ENG-106 P U F

Systems Functional Analyses DRD-ENG-114 P U U F

SW detailed design document DRD-ENG-152 P F

SW Architectural design document DRD-ENG-153 P F See [DA11]

SW Technical specifications DRD-ENG-156 P F See [DA11]

Level 2 SW technical specification DRD-ENG-170 P F Only for BCV

SW reference manual (component list and description, data dictionary, …)

DRD-ENG-161 P F

For each Sub-System Design Definition File including

- Sub-system Definition (HW specification)

- Sub-system Design manufacturing (list of components, drawings ..)

Free form

P

F

P

F

Documentation and Drawing Tree DRD-ENG-112 P U F On request

SW Interfaces Specifications DRD-ENG-157 P F

SW internal and external interfaces design DRD-ENG-158 P U F

IS and Definition of Interfaces between subsystems DRD-ENG-103 P F

Design Justification Dossier (DJD) DRD-ENG-115 P P U U U U F

Justification Report DRD-ENG-117 P U U U F

Verification plan DRD-ENG-132 P U U F

Verification Reports DRD-ENG-134 P U U F






VG-SM-200091-C-0003-CNES

Page : 42/260 Ed.: 2 Rev.: 1 Date :15/04/03

Industrial Realization Dossier (DIR) DRD-ENG-116 P F

Realization Plans in TQC of each subsystem See [DA14] F

List of Plans of each subsystem Free form F

SW and HW Configuration status report DRD-MAN-125 P U U U F DA12

CIDL (Configuration Item Data List) DRD-GD-107 P U U U U F DA12 And at each

progress meeting


IPDR &

SRR ADR ICDR &

DDR IQR IAR TKP ORR remarks frequency

Industrial Control/Tests Dossier (DIC) DRD-ENG-135 P U U U F

Certificates of conformance (on order) DRD-PA-154 F

Test Plan and validation planning (in factory and on site) DRD-ENG-136 P U F

Test Procedures (in factory and on site) DRD-ENG-139 P F

HW and SW Inspection key-point report and Test Reports DRD-ENG-140

DRD-PA-109

Coming from QA activities

Anomaly Sheets (HW and SW problem reports) DRD-PA-107 X X X Coming from QA activities

Subsystems Test Readiness Review Reports (in factory and on site) See [DA19] F F Coming from QA

activities

Subsystems Test Review Board Reports See [DA19] F F Coming from QA activities

SW Verification and test Plans and procedures DRD-PA-155 P U U F

SW Verification and test Reports DRD-PA-156 U F

Operations and ILS Dossier (DIX) DRD-ENG-119 P U U F






VG-SM-200091-C-0003-CNES

Page : 43/260 Ed.: 2 Rev.: 1 Date :15/04/03

Hardware Installation Manual (Drawings, logic, tasks, controls) DRD-ENG-159 P U F

SW Installation Manual DRD-ENG-160 P U F

User Manual (UM) of System delivered DRD-ENG-123 P U F

SW user manual DRD-ENG-155 P U U U F

Contract Operations Training Plan (for HW & SW) including syllabus

DRD-ENG-126 P U U F

Contract Maintenance Plan (HW & SW) DRD-ENG-127 P U U F

Maintenance Manuals (HW & SW) DRD-ENG-154 P U U F DA11

List of Support Tools and Facilit ies DRD-ENG-129 P F May be grouped with ENG-154

Spare parts list Free form see req. 752 of RD6

P U U F May be grouped with ENG-154

Implementation Specification (HW & SW SMO) DRD-ENG-120 P F






VG-SM-200091-C-0003-CNES

Page : 44/260 Ed.: 2 Rev.: 1 Date :15/04/03

Title of document or dossier DRD code Proposal

T0 T0+ 1 month

IPDR & SRR

SW ADR

ICDR and DDR

IQR IAR TKP ORR

remarks frequency

QA Dossier (DQA) DRD-MAN-124 P U U U U F _

Quality assurance Plan DRD-PA-101 P U U F _

Software quality assurance plan DRD-PA-151 P U U F _ May be

grouped with PA101

Hardware Manufacturing inspection flow chart DRD-PA-129 P F _

Audit Report DRD-PA-106 _ For every audit

Quality Assurance progress report DRD-PA-103 X X X X X X _ May be

grouped with MAN-127

For every progress meeting

KIP and MIP report DRD-PA-109 X X _ For every KIP or MIP

PVRI or Factory Industrial Acceptance Report DRD-PA-113 F _

RCI (EIDP - End Item Data Package) DRD-PA-139 P F _

Test Readiness and test review board DRD-PA-104 and

DRD-PA-105 X X _

Non-conformity or anomaly Reports DRD-PA-107 U F _ on request

Contract configuration report (including )

-reference configuration status

-modification list ( by status)

DRD-MAN-120

DRD-MAN-121

X X X X X X For each progress meeting






VG-SM-200091-C-0003-CNES

Page : 45/260 Ed.: 2 Rev.: 1 Date :15/04/03

-Action items and pending points list (status)

-non conformities list (by status)

-waivers list and status (derogations)

DRD-MAN-128

DRD-PA-138

DRD-PA-123

Waiver Reports DRD-PA-108 P U U U F _ on request






VG-SM-200091-C-0003-CNES

Page : 46/260 Ed.: 2 Rev.: 1 Date :15/04/03


IPDR &

SRR

SW ADR

ICDR & DDR IQR IAR TKP OR

R remarks frequency

Industrial RAMS Dossier (DSF) DRD-PA-119 P U U U U U U U

RAMS analysis and assessment file:

Reliability analysis and assessment

Availability analysis

Maintainability analysis

Common mode failures

Single point failures

DRD-PA-120

DRD-PA-125

DRD-PA-126

DRD-PA-124

DRD-PA-133

P U F

RAMS analysis and assessment report file DRD-PA-110 P U U U U F

RAMS progress report DRD-PA-130 X X X X X X

DRD-PA-2 May be

grouped with MAN-127

At each progress meeting

Preliminary Hazard Analysis (PHA) DRD-PA-117 F

RAMS Apportionment DRD-PA-132 F

FMEA/FMECA DRD-PA-112 P U U F

Feared events list and CIL DRD-PA-111 P U U F May be

included in PA100

Safety analysis DRD-PA-118 P U F

Zone analysis DRD-PA-114 P F

RAMS plan DRD-PA-100 P U F _






VG-SM-200091-C-0003-CNES

Page : 47/260 Ed.: 2 Rev.: 1 Date :15/04/03


IPDR &SRR

SW ADR

ICDR &DDR IQR IAR TKP OR

R remarks frequency

Safety and Regulations Dossier (DSR) DRD-PA-121 F

Working Party Health & Safety Plan (PHSCT) DR11 P U F

Accident Declarations (in factory outside France) DRD-PA-122 as applicable

Approval, qualification certificates Format imposed F

Reports from Control Registered Offices DRD-PA-137 P F as applicable

SDS validated version





VG-SM-200091-C-0003-CNES

Page : 48/260 Ed.: 2 Rev.: 1 Date :15/04/03

7. GENERAL MANAGEMENT REQUIREMENTS Principle

The identification and selection of the management requirements applicable to the Contract are performed by means of an analysis of the roles (and of resulting identified risks) assigned by the Customer (ESA/LAU-IPT) to the Supplier (Industrial Contractor). The contents of the applicable requirements correspond to the activities, organisation, tools and methods to be implemented by the Industrial Contractor for the complete duration of the work.

Presentation

Chapter 7.2 of this document sets forth, in the form of detailed requirements, the activities to be conducted by the Industrial Contractor, indicating:

- The Contract phase in which the activity must begin, be carried out or finalised (M = Multi-phase),

- The identified input to be delivered by the Customer before the Contractor's activity begins,

- The expected output from the activity described,

- The referenced documents detailing the activity (procedure, table, diagram, etc.).

The requirements are grouped under management topics.

The required documents, referred to in the requirements, can be consulted in Annex 2.

The tables, diagrams, explanatory processes can be consulted in the Guideline Documents, Annex 3.

The meaning of acronyms and the terminology used are presented in Annexes 4 and 5 hereto.

7.1. REQUIREMENT REFERENCES

Each requirement is identified by a 3- to 4-digit code; the first digit corresponds to the generic chapter of the activity as follows:

- chapter 1: preliminary provisions and risk management

- chapter 2: organisations charts (WBS, tree structures)

- chapter 3: industrial organisation of the contract

- chapter 4: development rationale

SDS validated version





VG-SM-200091-C-0003-CNES

Page : 49/260 Ed.: 2 Rev.: 1 Date :15/04/03

- chapter 5: management of lead times and costs

- chapter 6: configuration management (see DA19)

- chapter 7: RAMS (see DA19)

- chapter 8: logistic and operational support

- chapter 9: Quality Assurance (see DA19)

- chapter 10: documentation and information management.

Example: Requirement N°304 refers to chapter 3 «industrial organisation of the contract».

The area of activity to which each requirement refers to is also indicated.

Example: Requirement N°318 refers to Reporting to Customer .

7.2. LIST OF APPLICABLE GENERAL MANAGEMENT REQUIREMENTS

The List presented in chapter 7.2 gives a detail of each Requirement to be taken into account. It is adapted (terminology, review names, acronyms and abbreviations, etc.) to suit the context of the VEGA Control Bench Project.

VEGA PROJECT MANAGEMENT REQUIREMENTS APPLICABLE TO THE CONTRACTOR

N° DOMAIN REQUIREMENT WARNING / COMMENT 100 MANAGEMENT

PLAN The contractor shall describe in a management plan how it intends to comply with each requirement specified in this document.

The Management Plan may be a single document whose structure follows that of this document, or refer to specific plans (Industrial Organisation, Quality, Documentation and Configuration Management, Integrated Logistic Support, etc.). It may be based on internal reference documents (Quality Manual, methods and procedures, etc.) which can be consulted by the Customer who shall be entitled to have a copy of it.

102 MANAGEMENT PLAN

The Contractor shall impose on its subcontractors the requirements of the management specification which it deems necessary.

106 CONFORMITY MATRIX

The contractor shall deliver with the reply to the solicitation a matrix showing the conformity with the management specifications.

108 APPLICABLE RULES & REGULATIONS

The Contractor shall comply with the rules and regulations, directives and standards specified in the Technical Conditions of the Contract (SOW DA0).

Remember to demonstrate compliance with the IS Security requirements if they are applicable


202 WORK BREAKDOWN STRUCTURE

The Contractor shall structure and subdivide (down to the appropriate management level) the activities under its responsibility into Tasks, with the following information:

-Task identification,

- description of activity,

- assignment to an accountable entity,

- results expected,

- duration expected,

- necessary input data or events.

The Task Sheets shall be included in the Contractor's Offer.

204 PRODUCT TREE The Contractor shall present a specific «Product Tree» document showing the tree structure.

The complete Product includes the items physically delivered by the Contractor to meet Customer needs. A Product may be an equipment, a system, a structure, a software.

The Product Tree is the tree structure representation of the products (including support system elements (see chapter 7) necessary to build up a Complete Product meeting Customer needs).

The Product Tree is characterised by:

- at the top, the Complete Product (level 0 of the tree structure) required under the contract,

- levels n, n+1 and so on, down to the lowest level of detail parts accessible by Maintenance.

206 PRODUCT TREE The codes of the first levels of the Product Tree are imposed by the Customer.

These codes are defined in § 6.4.1 of this document.


302 INDUSTRIAL ORGANISATION

In the Management Plan, the Contractor shall describe:

• the internal organisation implemented (name and contact data of the project manager and main actors),

• the precise role of each actor (project manager, quality manager, RAMS manager, planning manager, etc.),

• the proposed industrial organisation (subcontractors, suppliers),

• the precise scope of work of each actor (design, engineering, realization, installation, tests, acceptance, qualification),

• the information circulation rules defined to guarantee the consistency of the information delivered to each actor,

• the backup measures to be implemented if one member of the industrial organisation defaults.

During the term of the contract, if a new correspondent is appointed in the Contractor's team, this information shall be reported to the Customer.

The Provisioning Plan and the Procurement Plan may be grouped under a single document if the Customer explicitly accepts it.


The Contractor shall implement an industrial organisation consistent with the technical breakdown of the system required under the contract (actor organisation chart and affected tasks and products).

During the "technical" kick-off meeting, the Customer shall designate the unique Contractor's correspondents, i.e. one for administrative aspects and another for technical aspects.


The Contractor shall identify the project correspondents for each specialised area, then confirm its internal organisation that will be submitted to the Customer.

When replying to the request for proposals, the Contractor shall provide the "profiles" of the persons potentially involved in the project and their future roles within the project.


308 DEVELOPMENT PLAN

In the Development Plan, the Contractor shall describe the sequence of steps it intends to follow for successful project development. The Development Plan shall be delivered one month after the kick-off meeting.

After analysis and acceptance by the Customer, the Plan shall become a reference document. This acceptance shall not relieve the Contractor from its obligation to ensure successful project development, nor reduce its liability.

The Development Plan may be incorporated as a chapter of the Final Management Plan.

An updated version shall be delivered by the Contractor at the milestones defined in the DRL.

310 DEVELOPMENT PLAN

The Development Plan shall state the project objectives and address or define the following aspects:

• the design and justification rationale of the system defined,

• the realization and verification rationale of the system developed,

• the main steps (key points and reviews) of the project,

• the task performance schedule (with identification of critical paths based on the Work Breakdown Structure) which will be used to produce the reference planning,

• the dates of the main steps,

• the specific resources required (HW & SW) for all project phases.

• the delivery schedule of the documents required by the Customer,- the acquisition and operation schedule for the resources used.


312 PROGRESS MEETINGS

The progress meetings shall normally take place once a month on average, on the Contractor's premises.

The purpose of the progress meetings attended by the Customer and the Contractor is to examine the progress status of the studies and development work.


During the working party phase (on-site installation and acceptance), the meetings shall be held at the work location and the frequency may increase to up to one meeting per week.

Depending on the information exchanged in the meeting, the Customer and the Contractor shall specify the future areas of development. When the circumstances justify it, the Customer may request the Contractor to:

Hold a meeting on a particular topic (planning, technical issue, administrative issue), outside the normal progress meeting schedule; carry out verification work, with or without the Customer, on Customer or subcontractors' premises; write reports or explanatory notes.


The Contractor shall produce the report, to be signed by the two parties, at the end of the meeting.

The report shall state the list of actions decided, the actions incorporated in the management process since the previous meeting, and the list of actions closed since the previous progress meeting. It shall keep a trace of the decisions made.

318 PROGRESS REPORTS

Before each progress report, the Contractor shall deliver to the Customer a progress report describing the progress made since the last report, the problems experienced and solutions applied, the list of work items planned for the next month and proposals for action planning and management update. The measures taken with regard to product assurance shall also be included in this monthly report (processing of anomalies, non conformities, etc.).

320 PROGRESS REPORT

The progress report is transmitted by fax or E-Mail to the Customer at the latest three working days before the meeting. It is accompanied by an agenda proposal for the meeting. The report, which may be amended, shall be appended to the meeting report and circulated 3 working days at the latest after the meeting.


322 OPPORTUNITY ACTIONS

When the circumstances justify it, the Contractor shall:

- hold a meeting on a particular topic (planning, technical issue, administrative issue) outside the normal progress meeting schedule.

- perform verification work, with or without the Customer, on Customer or subcontractor's premises.

- Write reports or explanatory notes.

324 ACTION MANAGEMENT

As of the effective date of the contract, the Contractor shall update the list of all actions requested during the meetings and shall transmit it by normal postal means, by fax or by electronic mail.


Action management and sorting shall be performed using an IT tool (spreadsheet, recoverable file under EXCEL as a minimum). The file shall be updated periodically (opening, closing or modification of action deadline).



The database shall contain as a minimum the following information:

order number, date of issue, origin of action (meeting report, fax n°, etc.),

request originator (SDS, Contractor, etc.),

designation of action,

name of actionee,

target deadline,

closing justification (text or reference of document authorising action closing),

status of action (open, in progress, proposed for closing, closed),

closing date,

comments, namely initial target closing date if postponed.


A list of actions not closed extracted from the database shall be output and transmitted to the entities responsible at least before each progress meeting and for each review, key point, Test Readiness Review (BT), Test Review Board (CRE)



Action management is ensured by and under the supervision of the Contractor. The closing of an action shall be proposed by the actionee who shall provide all supporting elements to the Customer. The Customer shall authorise the closing after acceptance of the results. The Contractor shall keep (as a minimum) a paper record of the technical elements related to action closing.

Following factory acceptance, the Customer shall implement a central action management system on its own tools, in addition to the management ensured by the Contractor.

402 THE REVIEW PROCESS

The Contractor's Project group shall be responsible for review (or PK) organisation and for the preparation of dossiers to be examined and presented to the review (or PK) group.

404 REVIEWS The reviews or key points are formal meetings and a mandatory step to control, at each project phase, the organisation and technical tasks required for project development. Their objectives are as follows:

assist the Customer project manager in assessing the status of the definition submitted by the Contractor, by comparison with the contractual specifications,

assist in the release of the authorisation to proceed with the next phase,

detect possible risks or deviations related to the development,

implement corrective or preventive actions at the earliest.

The participants in the reviews are as follows:

- the Customer project group is responsible for the presentation of the business case and the dossiers,

- the review group, independent of the project, designated by the Customer and comprised of experts of the domain addressed, is in charge of the critical examination of the dossiers presented,

- the Steering Committee, comprised of Customer senior officers, is in charge of arbitration and choices on the basis of review group's recommendations which it makes enforceable .


Before the review: the Contractor shall transmit to the Customer the documentation to be reviewed 2 weeks before the meeting date.

analysis of the documentation submitted by the Customer project group (during the meeting) and comments as and when necessary.



The review organisation notice shall be written and transmitted by the Contractor, then validated by the review Chairman.

Customer Project distributes this notice (after validation) and thereby convenes the meeting.


During the review: the Contractor's project group shall present to the review group the documentation to be examined and the project progress status.

- issue by the review group of written questions.


The Customer Project Manager or Customer Technical Officer shall present the aspects related to the contractual framework, interfaces with existing resources, installation or operation constraints.


The review group shall use the Issue Examination Sheets (FEPS) to keep a trace of the questions raised and obtain the answers from the project group.


The Contractor's project group shall provide the answers to the questions raised during the reviews.

answers by the Contractor's project group or by the Customer project group for questions under the scope of their responsibility;

- analysis of answers to the FFEPS by the review group and, if required, definition of actions and/or recommendations.


The recommendations validated by the Steering Committee shall be applicable to the Contract (under conditions to be defined) or to Customer Project, depending on the entity formally responsible for their application.

After the review: - Presentation to the Steering Committee by the Chairman of the review group of the conclusions of the review and any related recommendations.

- The Steering Committee shall examine the recommendations and issue directives to Customer Project.

420 REVIEW DOSSIERS The documents to be delivered by the Contractor at each Review shall be grouped in "paper" files and distributed in the number required for the entities represented.

The documents issued "specifically" by the Contractor and its subcontractors shall also be delivered on CD-ROM. In this case, the CD-ROM version shall become the "Reference" version in case of uncertainty on the validity of the "paper" and IT file versions.


422 KEY POINT PROCESS

The Key Point (PK) is a meeting held between Customer Project and Contractor Project to confirm the validity of the definition proposed subject to the actions identified in the meeting, which the Contractor agrees to implement.

The PK shall be held in place of the PDR and shall be formalised by a meeting report.

424 KEY POINTS Before the PK: The Contractor shall transmit to the Customer the documentation to be examined one week at least before the date scheduled for the Key Point.

See chapter 6 for the composition of the dossiers to be examined. On receipt of the documentation, Customer Project shall give the participants confirmation of the date selected for the Key Point (invitation to attend, agenda, list of documentation to be examined).

426 KEY POINTS Before the PK: the Contractor's project group shall organise the Key Point and shall be responsible for preparing the dossiers and documents to be examined.

428 KEY POINTS During the PK: the Contractor's project group shall present the documents to the Customer project group, as well as the progress status of the activities.

431 KEY POINTS During the PK: the Contractor's project group shall answer verbally or in writing, using the same forms as those used in the review, the questions raised in session and keep a trace of the actions decided and respective actionees.

432 KEY POINTS After the PK: the Contractor shall produce a meeting report (including action item list), present it for validation to Customer project, then distribute it to the participants.


434 KICK-OFF MEETING The purpose of the technical kick-off meeting, held on the Contractor's premises, is as follows:

- introduction of the main Customer and Industrial participants in the project,

- definition of the application principles regarding management rules,

- assurance that all contractual specifications are correctly understood by all participants,

- identification and verification of any project "hard" points (technical, planning, etc.).

This phase, which begins after the detailed pre-project phase conducted by the Customer, involves organisation, specification and preparation activities. During the "technical" kick-off meeting, the Customer shall appoint a single correspondent in charge of relations with the Contractor.

436 PRELIMINARY DEFINITION

The Contractor shall initialise the Health, Safety and Protection provisions in compliance with the legislation in force.

For structures subjected to specific legislation.

(applicable on the installation site)


The product preliminary definition phase, conducted by the Contractor, may include:

• the performance of preliminary technical design studies to define the hardware and software architecture.

• Interface definition (hardware and software), Human-Machine Interfaces (HMI).

• The definition of the verification method to demonstrate that the system and each constituent element meet the requirements.

This phase, which begins after the detailed pre-project phase conducted by the Customer, involves organisation, specification and preparation activities.


The end of this phase shall be formalised by an industrial Preliminary Design Review (iPDR) organised on the Contractor or Customer's premises.

This must be specified at the beginning of the contract by the Customer's Business Officer.



After integration of the actions defined in the iPDR, the Contractor shall baseline the definition documentation and manage it in accordance with the documentation management rules.

444 CRITICAL DESIGN During this phase, the Contractor shall carry out activities aimed at defining in a detailed manner the complete system and each constituent element.

It shall begin after the iPDR (or PK), and incorporate any actions and decisions issued from the review.

The development phase is subdivided into four steps, as follows:

• Critical Design

• Manufacture / Realization

• Factory acceptance

• On-site integration and acceptance.

446 CRITICAL DESIGN The development phases of specific software products shall fit into the different phases of the complete Project (with relation to other constituent elements).

If specific software products are required under the contract.

450 CRITICAL DESIGN The end of this phase shall be formalised by an industrial Critical Design Review (iCDR) to be organised on the Contractor's premises.

In any event, the Contractor shall organise at least one formal review (preliminary design PK, then iCDR or iPDR, then critical design PK).

452 CRITICAL DESIGN After incorporation of the actions decided in the iCDR, the Contractor shall baseline the design and realization documentation and manage it in accordance with the documentation management rules.


456 FACTORY REALIZATION

During this period, the Contractor shall implement the procurement provisions regarding the components, materials and manufacturing means, and carry out any factory assembly or pre- integration tasks. Inspection activities corresponding to these operations shall be carried out according to the Validated Inspection Plan. In some cases, partial tests may be performed (test assemblies, static tests, etc.).

The verification PKs shall be organised by the Contractor according to the type of product developed, and shall be sufficiently representative to demonstrate achievement of the quality and performance levels expected.

This phase shall include:

Production resources and methods preparation activities,

• Procurement and quality/performance control activities related to the equipment and necessary catalogue and standard products,

• Non standard product manufacturing activities,

• Factory inspection and test activities specific to the Contractor (hardware and software),

• Definition of final hardware and software version nomenclature,

• Production of Industrial Realization Dossier,

Update of Industrial Operations Dossier (operating, installation, user, preventive and corrective maintenance manuals ).

458 TEST READINESS REVIEW (BT)

On completion of the realization stage, the Contractor shall invite the Customer to attend the Test Readiness Review (BT) prior to factory acceptance tests.

Purpose of Test Readiness Review (BT):

- confirm that the supply is ready to undergo Acceptance tests (realization completed),

- check that the necessary documentation is available (minutes, test and acceptance procedures, reports),

- ensure that the Customer approves the tests and that the necessary facilities are available.

460 FACTORY ACCEPTANCE

Factory acceptance: (subjected to Customer approval)

This phase shall be carried out in compliance with the acceptance procedure.

See DA19


462 ON-SITE REALIZATION

The performance of all installation, pre-acceptance and on-site acceptance tasks shall in no event disrupt the operational use of the facilities on the realization site.

Transport, on-site installation, integration and preliminary acceptance

This phase begins upon completion of the previous phase. It includes:

• Adequate packing according to the means of transport used.

• Transport and installation of the supply on the operations site: Guyana Space Centre (CSG) or other site.

• On-site working party kick-off meeting.

• If required, inspection and acceptance by the Contractor of Customer-supplied interfaces.

• Integration of supplies at mechanical, hydraulic and electrical interfaces (including connections to existing facilities) made available on site by the Customer.

• Contractor's pre-acceptance tests after on-site integration.

• Up update of industrial Realization Dossier.

464 ON-SITE ACCEPTANCE

On-site acceptance: This phase shall be compliant with the acceptance procedure described in DA8 and DA19.

To facilitate this activity, "part acceptance" processes may be implemented subject to Customer and Contractor agreement. In this case, "overall" acceptance shall be released on successful completion of all part acceptance processes.

502 SCHEDULE MANAGEMENT

The Contractor shall ensure the availability of the necessary hardware and software products and human resources at the dates agreed in the work schedule.

These resources shall be used to produce a reference schedule based on the Development Plan, describing the main tasks to be carried out and any interactions between them, and incorporating any external constraints. To be produced at kick-off meeting at latest.

506 SCHEDULES The Contractor shall analyse the impact of any modifications requested by the Customer and incorporate them, once approved, in the reference schedule.

508 SCHEDULES The realization schedule shall be produced by the Contractor on the basis of the Development Plan.

The realization schedule shall reflect and demonstrate the actual task progress and activities carried out, and highlight any deviations from the reference schedule.


510 SCHEDULES The realization schedules shall be organised so as to show the different project phases: engineering, procurement, manufacturing, integration, preliminary acceptance tests, factory acceptance tests, transport, installation, on-site acceptance tests, training, documentation.

The milestones imposed by the Customer shall be recorded.

The subcontractors' schedules shall be incorporated in the overall schedule produced by the Contractor.

512 SCHEDULES For each task, the beginning and end dates (earliest / latest) shall be indicated by the Contractor.

514 SCHEDULE In addition to the above dates, the realization schedule shall indicate the target dates for the performance of the following activities:

Reviews, key points and progress meetings with the Customer.

Preliminary acceptance and acceptance tests in factory and on site.

Dates of main meetings planned with the subcontractors.

Tasks whose performance is conditional upon external factors (for example, if the Contractor needs premises to carry out the work)

Dossiers and documents to be submitted (progress reports, installation procedures, acceptance test procedures, etc.).

This schedule should preferably follow the "PERT" planning process or any equivalent method, showing any task interactions, internal or external constraints, scheduling rationale and critical path.

516 LEAD TIME MANAGEMENT

The Contractor shall notify the Customer of any constraints associated with its work or that of its subcontractors.

Any constraints related to the environment, the interfaces and particularly those associated with the Customer, shall be identified.


The Contractor shall keep a constant check of the effective progress made, the tolerance with regard to task performance, critical paths, and transmit the relevant information to the Customer.

The Contractor shall highlight any deviations observed with relation to the reference schedule in force.


520 SCHEDULES At each progress meeting, an updated realization schedule shall be handed over to the Customer.

Based on this schedule, any organisation adjustments which may be necessary shall be decided by the Customer (integration of constraints, if any).


For the breakdown of technical or operational activities, the Contractor shall indicate their criticality (integration of any planning difficulties).


On-site installation and commissioning work shall be carried out under the sole responsibility of the Contractor.


Bearing in mind the operational nature of some of the facilities involved in the launch process, the scheduling of this work may have to be decided by the Customer.

528 SCHEDULES One month at least before the starting date of installation work, a detailed schedule of the activities associated with installation and acceptance work shall be presented by the Contractor, together with the associated activity description sheets.

Depending on the case, the installation may be subdivided into several phases:

new facility installation,

shift to new system.


The description and analysis of each task to be performed on site by the Contractor (and its subcontractors) shall be formalised by a Site Activity Sheet containing the necessary information.


802 PROPERTY INVENTORY

Each item of property supplied by the Contractor shall be individually recorded in the permanent inventory if it meets the following conditions:

it is financed by ESA,

it is not consumable,

- its value is higher than the ceiling in force on the date of the contract (5,000 French Francs in 1995).

An item of property is the elementary functional unit which is physically identifiable, personal or immovable.

The functional unit is part of a functional assembly, i.e. a group of property items assembled to fulfil a common main function. Each functional assembly must be broken down into as many levels as required by its complexity, so each constituent property item in the assembly can be taken as an individual management item.

The software products are also recorded in the inventory according to the same rules of functional breakdown.

NB:


Each property item recorded in the inventory shall be costed by the Contractor at its contractual acquisition value by the Customer at the time of its acceptance. The value is expressed in currency, at the economic conditions of the contractual stock.

The inventory is a set of information relating to the description and costing of property items included in the composition of the product delivered. It is a management instrument used for ongoing monitoring of the property items throughout their service life. It must contain as a minimum the information recorded in the appended sheet.


The Contractor shall transmit to the Customer the updated, costed inventory at the Site Test Readiness Review (BT) at the latest (recommended inventory initialisation from Factory Acceptance).

The costing method is left to Contractor's initiative but must be consistent with the terms of the contract, and particularly with the work package breakdown.

The information to be transmitted to the Customer may be entered by the Contractor on any computer system available. A floppy disk containing this information (in a format compatible with Microsoft EXCEL) shall be delivered by the Contractor.

808 INITIAL SPARE PARTS PACKAGE

The Contractor sha ll identify the equipment and supplies to be provisioned to ensure on site operation of the installations delivered in the first year of operation according to the specified MTTR.

On completion of the performance tests (CRE/QT), the Contractor shall define and deliver to the Customer this equipment referred to as "initial spare parts package".

Not to be confused with the spare parts stock.


810 SPARE PARTS STOCK

At the request of the Customer, the Contractor shall propose and price a "spare parts stock" suited to the maintenance concept selected by the operator.

To size the stock, the following must be taken into account: long delivery equipment, storage duration and life limited equipment, levels of interchangeability, skills and tools required, operational inspections, etc.

812 OPERATION At the request of the Customer, the Contractor shall issue a technical and commercial offer for the operation of the installations delivered after the Test Review Board (CRE) and QT and for the period specified.

1002 DOCUMENTATION MANAGEMENT

The Contractor shall implement a document management process defined by its own services and its subcontractors, and shall keep a record of all documents received from the Customer.

The Contractor shall ensure compliance with the presentation, identification, validation and distribution rules described in the requirements below.

A distinction must be made between the work documentation (produced for development needs) and the Deliverable documentation (delivered to the Customer at specific formal stages of the contract).

NB: The different document, sheet, report models referred to in this document are available in electronic format (Word 97).

1003 CODING Each plan or document produced by the Contractor (or its subcontractors) shall be identified uniquely by a specific code.

Word processing type documents:

The structure of this code is indicated for the Project concerned (applicable to all operators issuing documents).

Plans, drawings and synoptic diagrams:

The structure of this code is indicated for the Project concerned. This rule is applicable to all operators issuing plans according to the management rules specific to the end user.

Industrial Dossiers:

Each industrial dossier produced by the Contractor shall comply with the structure of this code which is indicated for the Project.


1005 DOCUMENT APPROVAL

The documents which are in their final "frozen" version (issue and revision) shall be controlled by the Contractor's Quality manager and signed by the Contractor's Project manager before release to the Customer (for acceptance or approval as applicable).

1006 DOCUMENT DISTRIBUTION

Whenever a document is released for distribution, the Contractor shall implement a configuration management of such document. It shall also manage the list of document addressees to transmit all document changes.

Each document (hardcopy or IT file) shall be deemed "delivered" only if accompanied by a dispatch notice filled in by the Contractor.

Documents to be delivered by the subcontractors shall be delivered to the Customer by the Contractor only.

1007.a

DOCUMENT PRESENTATION

Standard documents shall be delivered in folder or other appropriate binding means. They shall be listed in the CIDL.

1008 DOCUMENT PRESENTATION

Specific documents:

All specific documents produced by the Contractor shall include the following introduction pages (see introduction pages of this document):

• Header sheet

• A description sheet including

• A list of document changes with exact origin and date.

• A summary and the list of annexes.

Header sheet bearing the following information :

- the symbol of the Customer Project,

all information useful to identify the document (title, Customer Identification code, Contractor's original reference, version (issue and revision), date, author,

the signatures of the persons responsible for document approval,

d) the distribution list.

Description sheet:

Bearing the information necessary to incorporate the document in the Customer's technical library, and a brief abstract by the author.


At the beginning of each document produced by the Contractor and using abbreviations, symbols or acronyms, a glossary shall be appended, listing and explaining each item.

The Contractor may opt for issuing a glossary valid for all Project documents. In this case, the glossary will be referred to in all documents produced.



Any part of a document produced by the Contractor must be removable and replaceable without disruption, using the sole information of the identification heading.

All pages and all elements (drawings, diagrams, cover page of annexes) comprising a document have an identification box bearing as a minimum the following information:

the title,

the page number,

the document identification code,

the document version (issue, revision),

the issue date.


The readability of all information contained in a document issued or delivered by the Contractor shall be total.

The Contractor shall be particularly careful about the quality of any photocopies inserted in the documentation.

1013 DOCUMENTATION MANAGEMENT

Any change to a document issued by the Contractor shall imply a change of issue or revision index, as applicable (change of contents or form).

The paragraphs or sections modified must be identified by a vertical line in the left-hand margin and traced in the preliminary pages.

1014 NUMBER OF COPIES

On completion of Project work, the Contractor shall deliver the number of document copies specified in the contract.

Typically, 5 «paper» copies and 2 «electronic» copy are required by the Customer.

NB: For acceptance phases, only 2 "paper" copies are required (one for filing and one as a support to the acceptance process).

1016 DELIVERABLE DOCUMENTATION

Delivery of specific documents:

The documents shall be delivered:

- on paper in format A4, with the exception of diagrams, plans and drawings when it is not possible,

- on electronic media compatible or recoverable by the standard software packages used by the Customer.

The software and versions used by the Customer will be specified (annex 5)


1017 PAPER DELIVERABLE DOCUMENTATION

Delivery of standard documents:

The documents shall be delivered written in English preferably, otherwise in French.


The Contractor shall produce and deliver to the Customer as part of its proposal the provisional DDL.

This List of Deliverable Documents must mention for each document: the document type, the delivery events, the update frequency.

1020 ELECTRONIC DELIVERABLE DOCUMENTATION

The Contractor shall comply with the requirements regarding the delivery of electronic files (documents).

The documents may be delivered using three types of medium (Floppies, CD-Rs, DVD-Rs).

This requirement is not applicable to technical data and software required under the Contract.

Floppies: 3" 1/2, high density, labelled,

CD-Rs 650 Mb: preferably conditioned in plastic box with sleeve (contract n°, abstract of contents, issue date).


The electronic files delivered by the Contractor may:

- be in native format (Microsoft Pack Office 97) preferably,

- be digitised in PDF format, resolution mini 300 DPI,

- be under Autocad in multi- layer mode (DWG),

- in TIFF CCIT GR4 for separate images (B&W or colour)

The files delivered must be readable and modifiable by the Customer using its software packages. The images, tables, graphs, objects must be included in the files.

The format delivered must be recognised by the import filters installed on the Customer's Pack Office.


The files delivered by the Contractor shall be checked for virus infection before delivery of the media to the Customer.

The files on CD-R must not be delivered in compressed mode (require certificate of individual inspection regarding anti-virus control).



The Contractor shall deliver CD-Rs recorded in compliance with ISO 9660 (mode 1). Each CD-R shall contain:

- an ASCII file called VOLUME, identifying the CD (disk number/total number, creation date, project, comments),

- an ASCII file called CATALOG listing all references of the documents recorded.


The deliverable dossiers shall be assembled in rigid folders to European standard (4 D-shape rings spaced by 80 mm, plastic sleeve preferably).

For Industrial Operations, user and maintenance Dossiers, the thickness of the folders must be limited to 50 mm (70 mm for other dossier types).


The Contractor shall clearly indicate on the front cover and the back of each folder:

the Acronym of the Customer Project,

its name or that of the subcontractor responsible for contents production,

the dossier reference: coding and folder number when the dossier is comprised of several volumes.

The sheets of the folder must be perforated to European standard (4 holes centred, spaced by 80 mm).

The different chapters or documents assembled in a folder must be separated by rigid dividers, with tabs wider than the standard A4 format.


The list of document contained in the folder shall be inserted at the beginning of the folder documents. It shall recap the folder document titles and identification codes and the identifier corresponding to the relevant tab number.



If a dossier is comprised of several folders, a presentation sheet shall be inserted at the beginning of each folder.

The purpose of this sheet is to:

list the titles and identification codes of the documents comprising each folder of the dossier and identify them using the number of the respective tabs;

- identify each particular folder (e.g. using bold characters or framing the contents).


For specific documentation, the documents shall be written in the language(s) specified in the contract.

Generally French, then French or English

1030 DOCUMENTATION DIRECTORY

The Contractor shall maintain and deliver the directory of documents, i.e. the exhaustive list of documents comprising the industrial project reference, irrespective of the type of document (standard or specific).

The document directory is structured and sorted to enable easy identification of a document by its title, identification code, reference, dossier or classification.

It must contain all documents useful for the project, even if they are not part of the deliverables to the Customer. It must identify clearly the deliverable documents.

For each document, the directory must contain the following information:

document title

Customer identification code,

document reference for Contractor (or subcontractor),

applicable document version (issue, revision, date),

the dossier it belongs to (logic document classification by topic: project management, definition, acceptance, installation, operations, etc.);

- the physical classification of the document (folder and divider number, floppy/ directory/ file, … etc.).


1031 DOSSIER IDENTIFICATION

The documents to be managed by the Contractor under the contract are grouped under several dossiers which may be as follows:

The Contract Organisation Dossier (DOC),

The Configuration and Product Assurance Dossier (DPA),

The Industrial Definition Dossier (DID),

The Industrial Definition Justification Dossier (DJD),

The Industrial Realization Dossier (DIR),

The Industrial Control Dossier (DIC),

The Industrial Operations Dossier (DIX),

The RAMS Dossier (DSF),

The Safety and Regulations Dossier (DSR).

.

1032.a

CONTRACT ORGANISATION DOSSIER

The DOC structure is defined in the DRDs referenced in chapter 6.13 (DRL).

.

1060.a

INDUSTRIAL DESIGN DOSSIER

The DID structure is defined in the DRDs referenced in chapter 6.13 (DRL).

1071.a

DESIGN JUSTIFICATION DOSSIER

The DJD structure is defined in the DRDs referenced in chapter 6.13 (DRL).

1074.a

INDUSTRIAL REALIZATION DOSSIER

The DIR structure is defined in the DRDs referenced in chapter 6.13 (DRL).


1120 SAFETY & REGULATIONS DOSSIER

The DSR structure is defined in the DRDs referenced in chapter 6.13 (DRL).

SDS validated version page 75


Titre du document :

TECHNICAL MANAGEMENT SPECIFICATION FOR



VG-SM-200091-C-0003-CNES

Page : 75/260 Ed.: 2 Rév.: 1 Date :15/04/03

8. REPLY TO MANAGEMENT SPECIFICATION

The Industrial Contractor shall reply to this management specification by supplying with its offer the following documents:

- A preliminary version of the Contract Management Plan (PMC),

- all documents, annexes, forms and models that might help in assessing the quality of the offer.

- the Requirements Conformity Matrix of chapter 7.2

After acceptance of the offer by the ESA Customer, these documents (once updated and completed) shall become contractual, and shall constitute the Industrial Contractor's commitment for the full scope of its activities.

Contract Management Plan

All provisions to be implemented by the Industrial Contractor in reply to the Customer's requirements may be presented in the form of a document whose structure is shown in DRD-MAN-103.

The replies to each of the requirements may be presented:

- in table form as shown below:

Requirement No. Title Reply No. Title

- in text form (with numbered paragraphs and chapters) to facilitate location and searches.

Referenced documents, models

Any documents deemed useful for the assessment or understanding of the Industrial Contractor's reply may be appended. These may include internal procedures, forms, synoptic diagrams, etc.

These documents shall not constitute a proof of compliance with the Customer's requirements, but may be used to illustrate the properly controlled management processes already in use by the Industrial Contractor.



Titre du document :




VG-SM-200091-C-0003-CNES

Page : 76/260 Ed.: 2 Rév.: 1 Date :15/04/03

The coherence and completeness of the Industrial Contractor's reply to the requirements of this specification shall be verified by the ESA/IPT Customer using a Conformity Matrix. This must be completed by the Industrial Contractor.

The matrix model given in DRD-MAN-103 may be used by the Industrial Contractor to facilitate its reply.

The conformity of the replies provided must be presented in a table illustrating the equivalence of the provisions proposed, and any identified deviations shall be reported.

Non conformities (in part or in full) should be commented on, and if necessary supported by the addition of explanatory notes.



Titre du document :




VG-SM-200091-C-0003-CNES

Page : 77/260 Ed.: 2 Rév.: 1 Date :15/04/03

9. ANNEX 1 « LIST OF DOCUMENT REQUIREMENTS DESCRIPTION »

DRD Ref. Topic

MAN-102 Contract Organisation Dossier MAN-103 Contract Management Plan (P.M.C.) including Conformity Matrix

MAN-104 Software Management/Development Plan

MAN-105 Directory of Acronyms and Abbreviations

MAN-106 Contract Directory

MAN-107 Risk Management Plan

MAN-108 Risk register

MAN-115 Systems and Subsystems Schedules

MAN-118 Configuration Management Plan

MAN-121 Configuration Change Proposal

MAN-124 Configuration and Product Assurance Dossier

MAN-125 Contract Configuration Status Report

MAN-126 Documentation Management Plan

MAN-127 Periodic Activity Report to Customer

MAN-128 Contract Action Item List

MAN-130 Software Configuration Management Plan

ENG-101 Development Plan



Titre du document :




VG-SM-200091-C-0003-CNES

Page : 78/260 Ed.: 2 Rév.: 1 Date :15/04/03

ENG-103 Subsystems Interface Specifications

ENG-106 Technical Specification

ENG-108 Industrial Definition Dossier

ENG-110 Product Tree – Functional Organisation Chart

ENG-112 Documents and Drawings Tree ENG-114 Functional Analyses

ENG-115 Definition Justification Dossier (DJD)

ENG-117 Definition Justification Report

ENG-119 Operations Dossier

ENG-120 Implementation Specifications (SMO)

ENG-123 User Manual (U.M.)

ENG-126 Training Plan

ENG-127 Maintenance Plan

ENG-129 List of support tools and facilities

ENG-132 Requirements Verification Plan

ENG-135 Industrial Control Dossier

ENG-136 Test and Validation Schedule

ENG-139 Test Procedures

ENG-140 Tests Reports

ENG-152 Software Critical Design

ENG-153 Software Architecture

ENG-154 Maintenance Manuals (HW and SW)

ENG-155 SW User Manual



Titre du document :




VG-SM-200091-C-0003-CNES

Page : 79/260 Ed.: 2 Rév.: 1 Date :15/04/03

ENG-156 Software Technical Specification

ENG-157 Software Interfaces Specification

ENG-158 SW Internal and External Interfaces Design

ENG-159 Hardware Installation Manual

ENG-160 Software Installation Manual

ENG-161 Software Reference Manual

ENG-170 Level 2 Software Technical Specification

PA-100 RAMS Management Plan

PA-101 Quality Assurance Plan

PA-103 Quality Assurance Progress Report

PA-104 Subsystems Test Readiness Review Report

PA-105 Subsystems Test Review Board Report

PA-106 External Audit Plan

PA-107 Non Conformity and Anomaly Report

PA-108 Request for Waiver Report

PA-109 KIP and MIP Report

PA-110 RAMS Report Dossier

PA-111 List of Feared Events and CIL

PA-112 FMEA and FMECA

PA-113 Factory Industrial Acceptance Report (FIAR)

PA-114 Zone Analyses

PA-115 Acceptance Review Board Report (IAR Contract)

PA-116 Non Conformity and Anomaly List and Status



Titre du document :




VG-SM-200091-C-0003-CNES

Page : 80/260 Ed.: 2 Rév.: 1 Date :15/04/03

PA-117 Preliminary Hazard Analysis (ADR)

PA-118 Safety Analysis

PA-119 RAMS Dossier (DSF)

PA-120 Reliability Analysis and Assessment

PA-121 Safety and Regulations Dossier (DSR)

PA-122 Accident Declaration

PA-123 Waivers List and Status

PA-124 List of Common Mode Failures

PA-125 Availability Analyses

PA-126 Maintainability Analyses

PA-127 Acceptance Certificates (PVR)

PA-129 Hardware Quality Manufacturing Flow Chart

PA-130 RAMS Progress Report PA-132 Apportionment of RAMS Objectives to subsystems

PA-133 List of Single Pint Failures (PDU) PA-135 Spare Parts List PÄ-137 Reports from Control Registered Offices PA-139 Certificate of Conformance PA-151 Software Quality Assurance Plan



Titre du document :




VG-SM-200091-C-0003-CNES

Page : 81/260 Ed.: 2 Rév.: 1 Date :15/04/03

10. ANNEX 2 DOCUMENT REQUIREMENTS DESCRIPTION (DRD)


DRD-MAN-102 CONTRACT ORGANISATION DOSSIER

The Contractor shall produce and manage a Contract Organisation Dossier (DOC).

This Dossier shall contain the documents listed in the DRL, namely:

- The Customer Requirements Conformity Matrix (if the Contractor decides to present this separately).

- The Contract Management Plan (which may include the Customer Requirements Conformity Matrix),

- The Procurement Plan,

- The Directory of Acronyms and Abbreviations,

- The Contract Directory (Contractor's Project team),

- The Risk Management Plan (if required),

- The Risk Register (if required),

- The Risk acceptability diagrams,

- The Work Breakdown Structure with completed Task sheets,

- The Product Tree for the complete Contract,

- Overall Planning and Systems Schedules as required under the contract,

- The Basic structure of Periodic Progress Report to Customer,

- The Hardware Configuration Management Plan,

- The Software Configuration Management Plan (if required),

- The Documentation Management Plan,

- The End of Project and Experience Feedback report,

- The Product Assurance Management Plan (QA and RAMS)

- The Developed Software Management Plan (if required),

- The Hardware Development Plan,

- The Specific Software Development Plan (if required),

- The Organisation notes for Industrial Reviews carried out,

- The Industrial Review Reports

- The Acceptance reports for Delivered Products (PVR)


DRD-MAN 103 CONTRACT MANAGEMENT PLAN

The Contract Management Plan (PMC) describes the specific provisions implemented by the Industrial Contractor to ensure successful Project Development (description of internal management operations, of general roles, of tasks and identification of players), while complying with the Management Specification rules imposed by the Customer.

The Contract Management Plan is a document that will evolve. It will be presented with the Industrial Contractor's offer for Customer approval, in its preliminary version for the "Proposal", then completed for ESA Customer approval at T0+1 month.

TYPICAL CONTENTS

The document may be structured according to the typical contents below:

- preliminary provisions,

- organisation charts,

- project organisation,

- development rationale,

- management of lead times and costs,

- configuration management,

- RAMS,

- operational and logistic support,

- Quality Assurance,

- documentation and information management,

- Customer requirements conformity matrix.

This document shall be based on the processes and procedures in use within the Contractor's organisation whenever a requirement of the ESA Customer is not in conflict with the proposed provision.


DRD-MAN 103 (Cont'd)

This table shall present a summary of the replies provided by the Contractor to the requirements of this specification. They constitute a commitment to comply (at the time of proposal or later during the contract period) with the stated requirements. Any declared Non Conformities (full or partial) will then be analysed by the Customer, in the light of comments or supporting evidence provided by the Contractor.

This matrix may be included in the Contract Management Plan (PMC).

The "conformity" column shall be completed using the following information:

Key: C = full conformity, PC = partial conformity, NC = non conformity (see comment)

Requirement N°

Topic heading Reply N° Comments / Document references Conformity


DRD-MAN-104 SOFTWARE MANAGEMENT/DEVELOPMENT PLAN

The software development plan shall include:

1 – INTRODUCTION

2 – APPLICABLE AND REFERENCE DOCUMENTS

3 – GENERAL CHARACTERISTICS

3.1 – Links with the Work Breakdown Structure

3.2 – Survey of facilities required

3.3 – Identification of constraints

4 – DRAFTING OF DEVELOPMENT PLAN

4.1 – Time scale creation and management

4.2 – Table construction

4.3 – DEVELOPMENT PLAN UPDATING

Note:

If another structure is selected, it is the responsibility of the Contractor to attach a detailed matrix for comparison with the content of the structure proposed in this appendix, to its development plan.

DESCRIPTION OF THE SOFTWARE DEVELOPMENT PLAN

1 – INTRODUCTION Indicate the purpose of the development plan and its applicability.

2 – APPLICABLE AND REFERENCE DOCUMENTS

Indicate the applicable or reference documents to which the software development plan refers or which it completes (e.g. software technical specification, OT, OP, contract, etc.).

3 – GENERAL CHARACTERISTICS 3.1 – LINKS WITH THE WORK BREAKDOWN STRUCTURE

As a minimum, an identifier and WBS code shall be assigned to each work package. A WBS sheet is raised for each work package.

3.2 – SURVEY OF FACILITIES REQUIRED

The objective is to establish a list of the facilities and technologies required for the software development process. These facilities can be:

- human resources,

- technical design, execution, integration, validation, production and maintenance (hardware and software) facilities, with identification (reference and version) of tools and their suppliers,


- delivery facilities.

Any facilities made available by CNES shall be identified.

3.3 – IDENTIFICATION OF CONSTRAINTS

This section identifies the constraints to be taken into account in the development process.

These constraints are linked to project organisation, and include availability of facilities, compliance with safety and confidentiality rules and sub-contracting.

These constraints are also linked to planning aspects, including effective quality assurance, and compliance with cost and completion date limits.

The functional categories and classes of the software and its components are also identified.

4 – DRAFTING OF THE DEVELOPMENT PLAN 4.1 – TIME SCALE CREATION AND MANAGEMENT

Application of the time scale requires estimation of completion dates for the software developed, and procurement lead times for standard or off- the-shelf software.

This also requires determination of "at latest" dates, and dates for reviews, key points, progress meetings and acceptance operations.

4.2 – TABLE CONSTRUCTION

The development plan can be submitted in PERT or table form. For each work package included in the work breakdown structure, this table sha ll contain all information required for its management in time:

- task descriptions and codes,

- task chaining,

- persons responsible and contacts (customer and contractor),

- meeting dates (progress meetings, reviews and key points),

- supplies,

- facilities and resources required, etc.

4.3 – DEVELOPMENT PLAN UPDATING

This section indicates the major events which could involve changes to the development plan and scheduled update procedures.

This plan refers to ENG-103.


MAN 105 DIRECTORY OF ACRONYMS

Acronyms used by the Industrial Contractor in his offer (general documents, organisation documents, procedures, etc.) shall be defined in a glossary that may be presented as follows:

Acronym; Meaning Acronym; Meaning

Acronyms specific to a document (technical equipment or sub-system acronyms, etc.) may be defined in the document that uses them (specifications, notes, diagrams etc.), usually in chapter 4.

General acronyms used in the context of the contract which apply to all domains (management, technical, finance, etc.) shall be grouped in a document called "list of contract acronyms and abbreviations".

This document should preferably be presented in the form of tables that can be recovered under Microsoft Word, to facilitate its consultation and use.

The glossary shall be updated and enhanced by the Contractor, and submitted for information to the ESA Customer at every event indicated in the DRL (reviews and boards).


DRD-MAN 106 CONTRACT DIRECTORY

All personnel in the Industrial Contractor's team that may come into contact with the Customer's personnel or with SDS engineering support in the context of the contract shall be identified and their details provided in a table, which can take the following form:

Entity Role in Contract Full Name Acronym Contact address

The contact addresses provided will allow the persons indicated to be contacted (by telephone, fax, e-mail, postal address if this differs from that shown on the contract).

The directory should preferably be established in the form of a Table (Microsoft EXCEL type) to facilitate its use.

At any change (of address or personnel), the Industrial Contractor shall update this directory and transmit it for information to the ESA Customer.


DRD-MAN-107 RISK MANAGEMENT PLAN

The plan shall be compliant with the general principles of the DR10 and requirements in chapter 6.7.

The document shall include the following chapters:

q Programmatic risk implementation Plan

q Risk Categorisation

q Risk identification and prioritisation

q Risk analysis and management ( risk control datasheet)

q Risk monitor and report

q Organisation and responsibilities

This document refers to the MAN-103.


DRD-MAN-108 RISK REGISTER

The following fields shall be included :

q Control Work Package Code

q Contract Code (as in Contract Structure)

q Risk Identification Number

q Description

q Reasons for criticality

q Classification

q Severity

q Magnitude of Consequences

q Probability of occurrence

q The preferred solution

q Alternative solutions and contingencies

q Current status

q Compound Risk Code

Example Classifications

q Loss of life

q Loss of mission

q Pollution of the environment

q Degradation of mission objectives or performances

q Cost increase

q Schedule delay

q User dissatisfaction

Example Severity

q Catastrophic

q Serious


q Major

q Significant

q Negligible Magnitude of Consequences

q Schedule delay in days

q Cost Increase in Euro

Example Probabilities

q Frequent (>0.2)

q Reasonably probable (0.10 - 0.2)

q Occasional (0.01 - 0.10)

q Remote (0.001 - 0.01)

q Extremely Unlikely (<0.001)

The plan shall be compliant with the general principles of DR10 and requirements in chapter 6.7.

The register shall be complaint in particular with Annex A of DR10.


DRD-MAN-115 PLANNING


Industrial realization planning

Tasks planned during this phase are mainly industrial tasks identified during the production of the tasks tree structure for the contract.

SCHEDULING LOGIC AND ASSOCIATED SUPPORTS

CustomerProject Level

Developement Schedule (target schedule) GANTT diagram General Principles

Summary schedules extract from development schedule and general Manufacturing Schedule with specific details

General Manufacturing Schedule (System schedule) Tests and Validation

schedule

Construction schedulessystem schedule

Interactions and analyses

Type 2 to 5 Test Schedule produced by Test/Validation Team

Detailed schedule Field schedule

Industrialists

Call for tender versionContractual version

c o n t r a c t o r 1 s c h e d u l e

Subcontractor xsubsystem schedule

Factory Site

Reference schedule (contractual baseline)

transmission of 'informations

transmission of documents

Exchange of Computer DatasEDI

Detailed schedule

Field schedule

Call for tender versionContractual version

c o n t r a c t o r 2 s c h e d u l e

Factory Site

Subcontractor ysubconstruction schedule

Discrepancy analysis (trends)


System Planning (General Realization Planning) is produced on the basis of Task Sheets created by the Contractor, and which represent the breakdown of the contractual work packages. These sheets must be sufficiently detailed to allow every key event (delivery of product or documentation) or interfacing (between contractual work packages, between structures, sub-systems or other contracts) to be shown as an input or output of the activity thus identified.

The activity duration stated in the Task sheet should preferably be in line with the frequency of schedule updates, so that satisfactory progress is achieved.

The activity duration stated in the Task sheet should preferably be in line with the frequency of schedule updates (theoretically monthly), so that satisfactory progress is achieved.

Lead time monitoring plans are normally required, and must be produced in PERT format (with logical links), except for summaries (in GANTT format).

Deliverable document formats must use the following models:


LIST OF KEY EVENTS

ORIGINATOR

PROJECT

LIST OF KEY EVENTS

Ref.:

Page:

Issue:

Date:

Contract N° CONTRACTOR:

SUBJECT

ZONE: ---------------------------

STRUCTURE --------------------------- sub-structure: -------------------

PERT Reference:

SYSTEM: --------------------------- subsystem: ------------------- CONTRACTOR: --------------------

Contract WP N°

WP Resp

Evt N°

Designation Initial date Current date Comments


MAN115- ON-SITE OPERATION, INSTALLATION AND TEST SHEETS

The Contractor shall take into account any constraints imposed by the Customer when preparing and updating its installation schedule. The status of this schedule is examined during working party meetings.

For the systems to be developed that interface with an existing site carrying out operational activities, the Contractor is required to issue Operation Sheets. These sheets, which have the format shown below, must allow operations to be identified and their intrinsic characteristics specified, so that their potential or actual impact on the operating site can be fully assessed. They must be linked to and correlate with the installation and test schedule.

Originator: OPERATION SHEET N° Project:

Date: Title:

WBS reference: Installation Planning ref.:

MP reference:

DEFINITION OF OPERATION:

PURPOSE:

SITE CONCERNED:

Initial Conditions

Previous operations

PERSONNEL:

HARDWARE:

PROCEDURES:

DOCUMENTATION:


EXTERNAL RESOURCES:

CRITICALITY OF ACTIVITY:

OPERATION PROCESS:

Start date:

Envisaged duration:

Hours:

Possibility of interruption:

Possibility of exchange:

INTERFACES:

Environmental risks:

Incident feedback procedure:

END OF WORK CONDITIONS:

(If necessary, append supporting documents) Documents appended: Yes No

SITE PLANNING ADVICE:

PROJECT ADVICE:

NB: sheet to be filled in if necessary


DRD-MAN--118 CONFIGURATION MANAGEMENT PLAN

The Configuration management Plan shall :

q Include a milestone chart, which depicts the configuration management activities and their relationship to the major overall project milestones.

q Define the Configuration identification and associated documents

q Include the configuration audit plan

q Describe the configuration management organisation :

o Describe the organisation, authority and responsibility of the Configuration Control Board (CCB).

o Describe the methods for documents, physical items, and software identification with a reference to the SW Configuration management Plan.

o Describe how the identification of the hardware, software items and documents is compliant with the product tree.

o Identify requirements for the standardisation, preparation, submission and subsequent release of configuration documents and controlled documents .

o Describe procedures for identifying both formal and internal (contractor) configuration baselines. All documents required to establish each baseline shall be listed as well as the procedure to be utilised for the control of such documents.

o Plan the level of the configuration items, e.g. electronic device or board.

o Define procedures for processing of changes and waivers.

o Outline the recording, storing, handling, verifying, validating and presenting of configuration status information.

o Define configuration accounting procedures

o Define configuration auditing procedures

o Requirements imposed on subcontractors and vendors.

This document refers to MAN-103.


DRD-MAN-120 CONTRACT CONFIGURATION BASELINES LIST

The managed baselines of reference shall include at least : q Sub-systems Specifications (TS, IS ,SMO etc) and Definition file (DID, DJD, Product Tree

etc) since iPDR, q Sub-systems Realization file : Sub-systems control File (DIC), Safety and Regulations

File (DSF, DSR), Exploitation File (DIX), since GSTKP, including the complete set of Industrial files.

The list of configured file types is contained in the DRL. At industrial level, the baselines shall include :

q Industrial Definition File (plans, diagrams, architecture, wire-type diagrams, interfaces, product tree etc) since iPDR,

q Industrial Realization file (Installation plans, descriptions etc and Industrial configuration file) since IQR.

The Contractor shall describe the number, timing and composition of Contract Configuration Baselines to be established . Normally at each review of the system or subsystem development, a new baseline shall be enacted. The agreed baselines shall include :

q Preliminary System definition baseline at IPDR, q Industrial preliminary definition baseline at iPDR, q Industrial definition baseline at iCDR, q Industrial qualification baseline at IQR, q Qualification baseline at GSQR.

The list shall be drawn up and maintained taking inspiration from the Configuration Management Principles stated in chapter 4 of the DR12 and shall be compliant to the requirements imposed in chapter 5 of the DR12. The SOW DA0 imposed requirement for Configuration Control take precedence over the DR12 in case of discordance.


DRD-MAN-121 CONFIGURATION CHANGE REQUEST AND PROPOSAL LIST

The list of all change requests and change proposals shall include at least the following fields :

- date of the request or proposal,

- writer,

- reference of the request or proposal,

- title of the request or proposal,

- code in the product tree of the impacted items,

- status of the request, e.g. approved or rejected,

- comments on the progress of the change.


DRD-MAN-124 : QA Documentation file

This file shall contain the documents that are defined in the DRL section 6.13.


DRD-MAN-125 HW AND SW CONFIGURATION STATUS REPORT

The HW and SW CONFIGURATION STATUS REPORT shall include at least the following fields for all the HW and SW items to be delivered to the customer :

Ø Configuration Item reference

Ø Configuration Item Title

Ø Product Tree Code

Ø WBS Code

Ø Contractor Code

Ø Contract Code

Ø Serial number for HW

Ø Part Number for HW

Ø Model or brand for HW

For the SW, see the AD11.

This document shall be compliant with the MAN-118 and the MAN-130.


DRD-MAN-126 DOCUMENT MANAGEMENT PLAN

The document shall be compliant to what stated in DA0, chapter 6.5 of DR3 with this order of precedence. The Fundamentals of documentation management stated in chapter 4 of DR3 shall be taken into account.

The general documentation requirements of DA0 and of chapter 6 of DR3 shall be verified with this order of precedence.

The document shall include as a minimum :

q Objectives of documentation management

q Documents identification plan

o Drawings

o Documents other than drawings

q Preparation rules for physical documents

o Drawings

o Documents other than drawings

q Document numbering rules

q Formation of the document identification code

q Document approval rules

q Document change rules

q Document storage, translation and dispatch rules


This document refers to the MAN-103.


DRD-MAN 127 PERIODIC ACTIVITY REPORT TO CUSTOMER

To provide evidence for the assessment of the progress status of contractual activities, before every General Progress Meeting the Contractor shall prepare and deliver to the Customer a Report presenting, for each area, evidence of progress being made and difficulties experienced. This Report shall be drawn up on the basis of the model contents below. Depending on the context, some items may still require studying, justifying or supporting as deemed necessary for proper visualisation of the situation.

Typical composition of Report according to contract phases: Phase Conditions

List of Recommendations and Actions arising from Industrial Reviews, C/D Systematic

List of Actions arising from Contract Progress Meetings C/D Systematic

List of Documentation (to be approved) produced and received by the Contractor

C/D Systematic

List of management, inspection, individual qualification, test Plans, C/D Systematic

List of Contract level key Planning events, C/D Systematic

List of provisioning and Factory manufactur ing, C Systematic

List of planned or completed inspections, C Systematic

List of suppliers and subcontractors assessments and audits, C On request

List of personnel and operatives on site**, D Systematic

List of shipment and transport of equipment**, C/D Systematic

List of RAMS critical items, On request

List of industrial reserves and actions C/D Systematic

List of system level modifications (associated products and documents), C/D Systematic

List of waivers and major anomalies, C/D On request

List of planned or completed industrial acceptance activities (Test Readiness Review and Test Review Board),

D Systematic

List of Deliverable Dossiers transmitted to Customer (DDL), D Systematic

List of installations available, D On request

List of inventories of property. D On request

** Free format for these Lists (to be filled in using verifiable and quantified information)


Depending on the steps of the Project, some Lists (not applicable at this stage) may not be produced or presented. It is recommended that the topics addressed be placed in the order of the agenda of the Progress Meeting.

The different formats of each of the topics shall be presented in table form, or extracted from databases managed by the Contractor, and shall include information on sub-contractor activities.

The report shall also contain the SCHEDULE PROGRESS REPORT, based on the following model:


Originator: PROJECT:

Contract N° :

Report N° :.........................................Period of:.......................to :..................... (day and month)

Schedule reference :.....................................index:....................

1 - ACTIVITIES COMPLETED :

- Task designation or number:

- Effective end date:

2 - ACTIVITIES STARTED :


- Effective start date:

- Target end date:

3 - ACTIVITIES IN PROGRESS:

- Task designation or number

- Effective end date:

4 - CHANGE OF DURATION :


- New estimation and reminder of initial duration (e.g. 4 weeks instead of 3):


5 - CHANGE OF RATIONALE:


- Cancellation of activities or constraints:

- Creation of activities or constraints:

- Change of task contents, i.e. designation:

6 - KEY EVENTS:

- Events carried out with effective end date:

- Events deferred , proposal of new date and reason(s) for deferral:

- New events proposed:

7 - COMMENTS:

Justify recommended rework methods for activities not carried out according to schedule.


DRD-MAN-128 CONTRACT ACTIONS ITEM LIST

Contract actions will normally originate from :

- meetings held between the Agency and the Contractor,

- meetings held within the Contractor's Project Team,

- reviews (iPDR, iCDR) or inspections key-points,

- IQR, IAR, (BT or CRE),

- Non-conformance report or anomaly report…

All actions shall be managed by Contractor in single process in accordance with the DA10.

The Action Item Status List shall include the following fields :

q Meeting or review or key point Identifier

q Action Number

q Action Item Title

q Issue Date

q Action Due Date

q Originating Organisation

q Originator

q Related Subsystem/Task

q Actionee Organisation

q Actionee

q Status *

q Closing Date

q Closing Reference

* Open, Closed, Withdrawn, Pending.


Actions placed upon the Agency will only be accepted following agreement of the Agency's Project Manager or duly authorised representative (Technical Officer).

This document may be merged with the PA-123 and the PA-138,e.g. in a 'CONTRACT CONFIGURATION STATUS REPORT'.


DRD-MAN-130 - SOFTWARE CONFIGURATION MANAGEMENT PLAN

The Software Configuration Management Plan shall define :

field of application

Software concerned

Phases concerned

Sites concerned

links with others configurations

Links with system configuration management

Links with other configuration management

Links with subcontractors

Links with suppliers

SW configuration management

Main activities

Repartition of activities by sites

Responsibilities

identification control

configuration baseline

configuration items (viewed by the Prime Contractor)

configuration objects (viewed by the contract holder)

links between configuration objects

baselines

qualification baseline constitution

use baseline constitution

configuration identification and marketing

identifiers

rules for use and evolution of identifiers

marketing

responsibilities


identification control

changes management and control

internal change procedure

contractual change procedure

changes control

configuration administration

media manufacturing procedure

delivery procedure

objects protection

archive procedures

back-up procedures

configuration status accounting

communication with the system configuration management

supplier control

configuration control

end of phase control

delivery control

SW configuration audit

coherence control with other configuration management

control of the use of tools

indicators

facilities and tools

computer

tools

storage facilities

specific configuration control directory (coding, validation, qualification, delivery)

relations with subcontractors

This plan refers to the MAN-104.


DRD-ENG-101 DEVELOPMENT PLAN

The Contract Development Plan shall be the top- level technical plan covering the complete activities for development and qualification. It shall cover the analysis, design, manufacturing and procurement, assembly, integration, verification and testing. Separate plans might be prepared by Industrial Contractor for a more detailed description. In this case a reference shall be presented in the main Development Plan.

The Development Plan shall include at least :

1. Overall logic of activities required to achieve the scopes, schedule and deliveries for the project milestones.

2. Overall schedule, top level bar charts and associated milestones and review activities. 3. Description of the composition and overall function of the System, both hardware and

software, sufficient to understand the scope of the products. 4. The analysis approach, providing descriptions of the type of analyses to be performed, the

resources required, the responsibility allocations and the logic flow for trades and analyses. 5. An overview of the software activities, showing the links between the different

developments (see DRD-ENG-152). 6. The inter-relations between software and hardware development, test and qualification (for

Launcher interfaced ground items). 7. The design definition approach, showing the inter-relationship to analyses, breadboarding,

mock-up,. 8. Overall verification approach, covering tests, analyses, inspections, reviews of design

aspects and their control. 9. The logic and approach for accepting, receiving and integrating equipment from lower level

contractors (hardware and software). 10. Manufacturing and procurement, assembly and integration approach, providing a clear

hardware and software flow showing how verification configurations are achieved and the type of tests to be performed on the various configurations. Facilities, responsibilities and test windows shall be shown.

11. All project reviews and the major documents issued and base lined before and after each review.

12. The product assurance and safety approach and its role in all the activities above, both in terms of direct contribution and in terms of its assurance functions.

13. The plan of audits. This plan contains a list of the sub-contractors and procurement sources to be audited by the industrial contractor together with the scheduled dates for the audits. This plan as well contains information on the audit baseline, current status and periodicity, if needed. The configuration audits may be defined in the MAN-118.

The Development Plan shall include a section addressing the external interface aspects, identifying all hardware and software items needed to support the interface verification process and its intended utilisation. This section shall be sufficiently self-contained to permit efficient review of interface aspects by an interfacing contract.


The Development Plan shall also contain a summary of the internal interface management plan.

(see DRD-ENG-141)


DRD-ENG-103 - INTERFACE SPECIFICATION AND DEFINITION OF INTERFACES BETWEEN SUBSYSTEMS

At System level, the document shall specify the interfaces. Reference to subsystem interface requirement documents may be made whenever the interface requirements are verified at system/sub-system/equipment level. The document shall identify the interface requirements for which a verification at System/Subsystem level is required.

List of Contents

1 PURPOSE

2. APPLICABLE DOCUMENTATION

3 REQUIREMENTS AND CONSTRAINTS

3.3. Definition of the VEGA Ground segment systems

3.1.1 system missions

3.1.3 Functions at the interface

3.1.4 Interface configuration

3.4. Functional Requirements

3.2.1 Performance requirements

3.2.2 Physical requirements

3.2.2.1 Requirement on mechanical interfaces

3.2.2.1.Cleanliness and contamination

3.2.3 Electrical functional requirements

3.3 Operational requirements

3.4 Requirements on interfaces with others elements

3.5 Operational constraints

3.5.1 Natural environments thermal, noise, vibrations…)

3.6 Design and manufacturing constraints

3.6.1 Main design constraints

3.6.1.1 Mechanical interfaces

3.6.1.2 Electrical and pyrotechnic interfaces

3.6.1.3 Radio electrical interfaces


3.6.1.4 Fluid connection interfaces

3.6.1.5 Accessibility and assembly interfaces

3.6.2 Design specifications and standards

3.6.2.1 mechanical design

3.6.2.2 electrical design

3.6.2.3 fluids design

3.6.3 Main manufacturing constraints

3.7 Logistic constraints

4 Check of requirements


DRD-ENG-106 - TECHNICAL SPECIFICATION

The Subsystem/Equipment Specification shall define the requirements applicable to the Subsystems of the VEGA Ground Segment. A Technical Specification shall be issued for each Subsystem and/or equipment.

The Subsystem/Equipment Specification shall define the key equipment and lower level characteristics to the extent necessary for further sharing into lower level components and for the validation of the requirements.

The Subsystem/Equipment Specification shall identify for each requirement the verification method (analysis, test, review of design etc.) and the verification level (subsystem, stage/assembly, equipment).

The requirement numbering shall allow tracing the sub-system requirements to the higher and lower lever requirements.

The contents and format of the system or sub-system Technical Specifications shall be in accordance with the requirements defined by the Agency. The requirement numbering shall allow tracing the Ground Segment system requirements to the customer and lower lever requirements.

When the system or sub-system Technical Specifications are generated consideration shall be given to the system’s functional objectives, its characteristics and interfaces, the environmental conditions under which it will perform, the quality and operational factors, the necessary support and the verification aspects, this providing operational, functional and physical views of the system and its constituents.

This document should include :

q Purpose of the document

q Applicable and reference documents

q Abbreviation-glossary

q General description

q Functional requirements

q Dimensioning and performance requirement

q Interface requirement

q Design and implementation constraints


q Rams

q Environmental, installation and transport constraints

q Verification and tests required

A compliance matrix to the upper technical requirements, e.g. the DR8, shall be annexed to this specification. This matrix is compliant with the PVE ENG-132. This compliance matrix to the DR8 must be included in the first issue for the proposal, see the section 6.13.


DRD-ENG-108 INDUSTRIAL DEFINITION DOSSIER

This dossier is that from which product manufacture, production or realization is made possible since it contains all the documents and drawings that "specify" the "definition" of the product(s) to be supplied or developed.

The exact list of the dossier documents for this contract is given in the DRL.


DRD-ENG-110 PRODUCT TREE - FUNCTIONAL TREE

1 PRODUCT TREE

The product is a physical item supplied by the Industrialist to meet Customer requirements. The product may be an item of equipment, a service, a system, a structure, an industrial process (process, software, etc.) or a combination of these.

The Product Tree is a representation of the composition (known beforehand, or acquired in the course of contract performance) in terms of elements, prepared by the Contractor in order to develop a final product that meets the requirements expressed by the Customer. The "product" is the smallest integral entity in the tree structure (deemed significant by the Customer; in general, this corresponds to the level of interchangeability on site).

The development of a tree element may be limited to the development of sub-elements, and so on, down to the single element level.

This breakdown into single elements is based on the principle of relationships. For any element identified at level "n" of the tree, all the sub-elements of which it is made up will appear at level "n+1"

The Contractor's Product Tree is characterised by:

- an apex, the complete Product (classified as level zero), to be delivered under the contract.

- levels "n", "n+1" and so on down to the final level of detail parts accessible to the operator for his operational and maintenance activities.

The Product Tree shall show the sub-products that comprise the system and/or sub-system in completed phases. The minimum Products that should appear in the Tree are therefore:

- products whose configuration is controlled by the Customer (P.C.C or Configuration Items),

- the products described in the Industrial Definition Dossier (D.I.D*)

- all products described in Technical Requirement Specifications (TRS),

- all associated means, including support elements.

- the main standard components described in a Technical Procurement Specification (STA).

The "Product Tree" document, which shall be presented in its preliminary version with the Contractor's Management Plan (PMC).

NB: If required by the Customer, the Product Tree code may include (in position 5 of the 7 authorised characters) a number relating to the "activity" associated with the development of the product.


This enables searches to be carried out for documents by "technical specialisms" (document searches, production of dossiers, etc.).

Product Tree Code (OP): positions 1 to 4 indicate the geographical location of the Product, positions 6 and 7 specify, if required, the function, element or equipment.

*

With* = 0 for general items

With* = 1 for Civil engineering (earthworks, foundations, road works, services etc.)

With* = 2 for Infrastructure (heavy work and light work) and metal structures

With* = 3 for Power (high currents)

With* = 4 for Air Conditioning

With* = 5 for Safety, access control

With* = 6 for RTMO (low currents)

With* = 7 for Lifting and Handling

With* = for Fluids

With* = 9 for Command and Control, remote control, signal processing etc.


2 FUNCTIONAL TREE

The functional tree is the tree structure resulting from functional analysis. It allows the identification, characterisation and hierarchical organisation of all functions (internal or otherwise) that are defined to meet the product, system and sub-system requirements without making a priori assumptions about the product to be developed. It may be produced in phase B and should be frozen for phase C1.


DRD-ENG 112 DOCUMENTS ET DRAWINGS TREE

All Documents and Drawings produced by the Contractor should be readily accessible and traceable by the Customer and the future Operator. The recording of document and drawing references must therefore take into account the relative position of each of them in the complete list of documents produced. To achieve this, the Contractor shall build up tree structures and cascades allowing any item to be located using a systematic approach.

The tree structure may be presented in graphic form or in the form of successive hierarchic cascade directories, the organisation of which shall be presented in an explanatory document.

The selected approach may be geographic, functional or based on product break-down.

The Contractor may base its approach on the Product Tree breakdown.

Useful information that should be included is:

- the document or drawing reference,

- the name of the structure involved,

- the name of the system involved,

- the title of the document or drawing,

- the product tree code.


DRD-ENG-114 FUNCTIONAL ANALYSES

The resulting architecture of the VEGA Ground Segment shall show the evidence of the fulfilment of subsystems to answer to the corresponding functions.

At the system and sub-system level, a functional decomposition (FT, Functional matrix, Functional Block diagram,…) shall be provided.

Functional analysis (FA) is the technique of identifying and describing all functions ( Intended effect of a system, s/s, product or part ) of a system, in presence of possible constraints ( characteristic, result or design feature which is made compulsory or has been prohibited for any reason).

Functional analysis shall be performed as part of the overall design development process to establish the system functions and to control the distribution and maintenance of these functions in a systematic and useful manner. Three techniques:

- function tree, - functional matrix

- functional block diagram

are usually used, although it is recognised that other representations can also prove suitable. See the DR14 for further details on these structures.

As minimum, at the start of preliminary definition phase the Contractor shall define a Functional Tree or other equivalent functional tree, which constitutes his basis for developing the Product Tree. The Functional Tree's links to the Specification Tree shall be identified. At the end of the preliminary design ( iPDR) a functional architecture shall also identified.

Based on the FMECA and Functional Analyses the Contractor shall determine the effect of the loss of the functions constituting the system and sub-systems concerned by the contract.

The document shall:

- Categorise the functions/products as identified by the different dependability and safety analysis;

- Provide input to the Design and Development Plan and Verification Plan,

- Provide means for a proper follow-up.

The Functional Analyses shall comply with the ENG-110.


DRD-ENG-115 DESIGN JUSTIFICATION DOSSIER (DJD)

The Contractor shall generate and maintain the justification of design through a system Design Justification Dossier (DJD).

The actual list of documents to be inserted in this DJD is given in the DRL.


DRD-ENG-116 INDUSTRIAL REALIZATION DOSSIER (DIR)

The Contractor shall generate and maintain the realization of the products through a system INDUSTRIAL REALIZATION DOSSIER (DIR).

The actual list of documents to be inserted in this DIR is given in the DRL section 6.13.


DRD-ENG-117 JUSTIFICATION REPORT

To justify the system tools, methods, architecture and design of the VEGA Ground Segment.

A justification shall be provided for every design option taken and here described. This justification can be trade-off’s, analyses, simulation results, test results etc. The historical background shall also be presented whenever necessary. Due reference shall be made to the lower level documentation where details on the analyses performed can be found.

Justification reports shall be established in the form of an assembly of justification evidence at a given time to prove that the tools, development and the design are optimised for all requirements expressed in the Technical Specifications and Management Specifications. The report shall identify acceptable risks, in order to ensure that the objectives achieved fulfil the target requirements and assemble information intended to justify design option selection.

The justification report contains the technical justification of the system architectural concept and components choices and associated calculation notes.

References to the tools utilised for manufacturing, engineering and coding shall be included, with associated performances, procedures, processes, CAD models and drawings.

The set of these reports and notes shall be referenced in justification report.

All the COTS and reused software shall be justified in this document, see the DA11.


DRD-ENG-119 OPERATIONS AND ILS DOSSIER (DIX)

This Dossier is intended for the use of the future operators of the products supplied by the Contractor. It shall enable them to carry out all the plant hand-over activities. With this aim in view, it shall include:

- installation procedures,

- commissioning procedures,

- the Operating Manual

- Training Manuals and Plan,

- the Maintenance Plan,

- Maintenance Manuals,

- The list of recommended spare parts,

- The list of tools recommended for maintenance,

- An inventory of delivered products and costing (see SOW DA0).

The exact contents of the DIX is given in the DRL.

The format of any document included in the DIX is a matter of choice, except for inventories.

The documents shall, however, meet the coding and presentation requirements given in DA14.


DRD-ENG-120 SMO - IMPLEMENTATION SPECIFICATIONS

The contractor shall support the Agency in analysing and defining all activities planned to be performed at the launch site fo r the exploitation phase, through the GS System Operational Specifications ( Spécifications de mise en oeuvre Système- SMO).

Those activities should start from the reception of sub-assemblies in Kourou up to the mission completion operations and preparation of the post flight analysis. Those activities should cover nominal operations and all other non nominal operations (unit replacement, launch postponement, launch abort,...) that should be defined and checked (when appropriate) in the frame of the development contract and qualification of the Launcher system.

In particular the contractor shall support the Agency to define the ground processing operational reference to reflect the launcher and CSG infrastructure design definition status and to complete and detail the processing flow description and time estimates, the allocation to launch site processing facilities, the concept for performing all required operations, and the sequence of task execution per facility.

The contractor shall identify all the dependencies in the operations flow, in order to leave as much flexibility as possible, for the scheduling of operations when no driving constraint has been identified. He shall segregate as far as possible the main operations from secondary operations and shall refer to the sub-systems SMO whenever appropriate.

The contractor shall specify and define specifications for operations in the following areas :

Assessment of the final check out and count down timeline control and management from the Vega Control Centre with a flight functionally representative data base

Support to LV and payload AIT operations

Acceptance of P80

Final check out and count down execution monitoring and control

Mission Control via Real time data flight monitoring (Quick look TLM or CVI)

Early and late post flight analysis ( CVD-Contrôle visuel differé)

Site Servicing, meteo and telecom services

All fuelling/pressurisation/battery charging

All on-site transport for P80, stages and payload


The Operational Specification (SMO) shall present all the requirements and constrains to be taken into account for the definition of the operation plan and procedure of the VEGA Ground Segment system and/or its elements.

The Operational Specification shall present :

General Conditions and environmental constrains,

Operations to be conducted.

Each phase will include an overall diagram of the operation to be performed; a list of means and facilities required to perform the operations; a list of detailed SMO files.


The typical content of a detailed SMO file could be as follows :

Objectives

Initial Configuration.

Final Configuration

Procedure requirements (if applicable)

Means (all the resources needed for the operation)

Clearance constrains (all constrains imposed by the dimensions of the elements involved in the operation)

Sequence constrains (operation to be performed before )

Environmental constrains (wind limits ……)

Safety constrains

Operation sequence: configurations

Operation sequence: test configuration

Checks to be performed (parameters to be verified and measured, min/max values……)

Exploitation (data to be gathered for the exploitation of the operation)

Degraded modes (actions to be taken to return to a safe mode in case of failure)

Each SMO file shall also contain :

Annex A : Justification and additional comments

Annex B : Risk identification


DRD-ENG-123 USER MANUAL

The document (U.M.) shall include a description of the Ground Segment systems such as :

Ø System/Subsystem Functional description

Ø System mission timeline and Payload mission phases

Ø System level operations, planning and operational constraints;

Ø System performance (Limitations, launch constrains relevant to GS etc.);

Ø environmental conditions (mechanical, thermal, ventilation, radio and electromagnetic environment);

Ø mechanical interfaces;

Ø electrical interfaces

Ø radio electrical interfaces;

Ø dimensioning requirements;

Ø Payload compatibility tests;

Ø Safety prescriptions

The UM shall contain the following information :

Ø a complete description of the different mission phases and the associated activities (operations) to be performed;

Ø a description at system level;

Ø a complete description of the LV-to-ground interfaces;

Ø operating modes at the system level;

Ø a detailed design description of each subsystem;

Ø detailed requirements for ground mission-specific processes needed during operations;

Ø Monitor and Control list and data base required for ground processing of commands and status information's;

Ø procedures for both nominal and contingency operations.

The UM is based on :


Ø the operations plan (GOP) which includes timelines or schedules for the different mission phases and procedures for all nominal and contingency operations;

Ø the operational databases which contain the characteristics and processing information for the monitor and control;

Ø the operational specifications

Ø The document shall be written in such a way for being used as training support.

Ø It could be issued also as a contribution to the overall System UM.

This manual can refer to the ENG-155.


DRD-ENG 125 HANDLING, STORAGE & TRANSPORT PLAN

The Contractor shall describe in a specific Plan:

- the provisions relating to the packaging of equipment, supplies and materials delivered,

- precautions relating to equipment handling and lifting,

- the arrangements to be made to guarantee that products are stored under appropriate conditions (for supplies, factory or site manufacturing, protection pending installation or use),

- the provisions relating to the organisation, monitoring and delivery of products and materials using maritime or air transport.

This Plan may refer to internal procedures or standards in use for these activities. Inspection operations shall be included and Key Points carefully scheduled to guarantee proper implementation of the preventive measures specified.

The Plan shall be defined and validated by the Contractor before implementation of factory storage provisions or before products are shipped to the installation site, whichever occurs first.


DRD-ENG-126 TRAINING PLAN

The System Operation Training Plan shall define the necessary means (documentation, test participation,…) to be implemented for guarantying the training of the exploitation phase user of VEGA Ground Segment.

The supplier shall establish an initial and recurring training plan for the operation and maintenance personnel for all systems under his responsibility.

The aim of the document is to ensure up–to–date personnel skills.

The training plan shall notably address technical and personnel resources to carry out the recurring training throughout the utilisation phase . The plan shall also cover the training for personnel operating the test campaigns.

It shall make reference to and use of System and GS User Manuals.

This plan shall include the training procedures, syllabus and the slides.


DRD-ENG-127 MAINTENANCE PLAN

The System Maintenance Plan shall define the necessary means to be implemented for ensuring of the maintenance of VEGA Ground Segment systems.

The supplier shall define the support elements required for the performance of each maintenance task for the operation of the Supported System in its environment of use.

For each task, the following shall be defined :

- an overview and a reminder of :

- the nature and type of the task,

- the frequency (or periodicity),

- the allotted duration for the task,

- the quantified resources requirements, regarding the logistic needs in terms of :

- support equipment (tools, test equipment, ...),

- Packaging, Handling, Storage and Transport (PHST),

- personnel skills and manpower,

- training ( if not included in a dedicated document),

- software support,

- support facilities,

- provisioning of spares and consumables,

- documentation material (operation, maintenance, re-provisioning data and procedures),

- technical events data feedback,

- list of spare parts and consumables.

The Spare parts and consumables items list consists, as a minimum, of summary delivery schedule.

It covers the spares and consumables and provides the following information :

- Item nomenclature;

- Part number and lot number or serial number;

- Deliverable quantity;


- Certificate of Conformance / Certificate of Acceptance number;

- Expected delivery date;

- Related loose items: nomenclature, P/N, quantity etc.


DRD-ENG-129 LIST OF TOOLS AND FACILITIES

As part of the logistic file, the list of all tools necessary for support the operations in E phase and testing phase shall be detailed. The support facilities shall be also listed. In this analysis, the Contractor shall maximise the re-use of existing or development equipment. The Contractor shall specify the support element to be used and or re-used such as Software Configuration control, or common facilities (CSG, BLA). The document shall contain :

- a description of the support tools and facilities required in support of the AIT operations and Integrated Tests.

- a description of the support tools and facilities utilisation with sufficient detail and justification allowing the number of items required, the compatibility with production and operational requirements.

- a support tools and facilities utilisation concept, including a summary of the resulting support tools and facilities items characterised by :

o Its name, o Operation phase/scenario affected, o Interface to Flight and Ground segment, o Quantity of items, o Specific information, such as storage, maintenance, lifetime, transport storage (whenever

applicable). The document may be a part of GS System Maintenance Plan.


DRD-ENG-132 VERIFICATION PLAN

As required by DR13, this document is the master plan for the system verification process and demonstrates how the requirements will be verified by a coherent implementation approach. This plan includes a reference to the assembly, integration and test planning and integrated test plan.

The Verification Plan ( or AIV plan) may be a detailed sub-plan of the relevant Design and Development Plan.

It contains the overall verification approach, the model philosophy, the hardware matrix, the verification strategies for each requirement category, the analysis/review of design/inspection programme, the assembly integration and test programme, the AIV activity sheets and the relevant planning, the selected test facilities, the verification tools, the verification control methodology, the involved documentation, the verification management and organisation.

Its principal use is to provide the customer a basis for review and evaluation of the effectiveness of the AIV programme and its proposed elements.

AIV plan provides a basis for review and evaluation of the effectiveness of the AIV programme and its proposed elements. An AIV Plan is prepared for the different verification levels covering in detail the integration activity at that level and outlining the lower level aspects.

It is originated on the basis of the applicable specifications and associated verification matrices, taking into account the development philosophy, the general test standards defined in the test requirement specification, programmatic constraints and availability of tools and facilities.

The Verification Plan shall cover all aspects of the verification tasks, i.e.:

- test,

- analysis,

- inspection,

- review of design.

The Verification Plan shall be constructed hierarchically to cover all levels of verification, i.e. from the Ground Segment to subsystems and equipment. It shall include the verification management and control methods, such as :

1. the Verification Control Board (formal approving authority with respect to the closure of the verification activities concerning requirements),

2. the documentation system,


3. the Verification Control Document maintenance, 4. external interface verification approach, 5. traceability with the verification system and to the requirement and specifications via VCRM 6. the overall schedules of analyses and tests involved in the verification effort, 7. the facility utilisation planning, in particular for planned use of the European Co-ordinated Test

Facilities, 8. the contractor/sub-contractor responsible for each identified verification task.

Reference shall be made to Industrial verification Plans for lower level verification.

To ensure that the requirements of each GS Technical Specification (DR8) have been properly integrated, a Requirements Verification Plan (PVE) shall be produced by the Contractor and included in the Verification Plan (at least for PCC products) and presented in the offer in its preliminary version.

The Verification Plan shall include control matrices listing all identified requirements, and shall propose for each requirement the control methods and principles envisaged depending on the Project phase or step. The control matrices shall be presented as shown below.

Project :

VEGA Ground Segment TECHNICAL REQUIREMENTS CONTROL MATRIX

Ref :

Date :

Ed/Rev :

Technical Specification Ref :

Requirement Project Phase

Requ.N° Designation A B C1 C2 D1 D2 D3 Remarks Sheet Ref :

1 Functional or performance test 2 Study or computer analysis 3 Document examination 4 Conformance control 5 Demo for availability 6 Mock up, functional simulator 7 Environmental qualification

A Verification matrix shall be attached.

In its «offer» the Industrialist shall include a basic requirements verification and traceability matrix which will be supplemented subsequently at each Industrial Review (iPDR and iCDR).

The verification matrix defines the verification strategy for each product requirement in terms of methods/levels/stages. It is used by the customer in association with the applicable requirement to define


the required verification; when discussed and mutually agreed it represents the verification implementation approach proposed by the supplier.

A matrix is prepared for each product specification at the chosen verification levels and may be incorporated in the relevant product specification. In this case the content of the document could be simplified.

Customer Requirement

Performance or characteristic proposed Comment

It is input to the preparation of the AIV plan and of the VCD into which it is incorporated as soon as frozen.

This verification matrix is used by the applicable requirement contractual authority to define the required verification. After a mutual agreement it shall become the starting point for the relevant VCD.

The Matrix shall list, in relationship to each requirement the selected verification method(s), at the proper verification level(s), in the relevant verification stage(s).

The verification entries may be presented in a dedicated format table which could be associated to the relevant specification.

1. Requirement traceability links

2. Verification stages

3. Verification methods at different levels for several requirements

4. Requirement number, title and text

Aim of the table is to list, in relationship to each requirement the selected verification method(s), at the proper verification level(s), in the relevant verification stage(s). DR13 annex c is recalled for further details.


DRD-ENG-134 VERIFICATION REPORTS

The verification report describes the execution and the results of a specific verification activity carried out with multiple methods. It contains the description of the verification approach, the results of the different combined activities and the conclusions.

The principal use of this document is to demonstrate to the Customer that the required verification activities have been carried out before allocating the closed status to the relevant requirement verification.

The document is produced for the different verification levels as necessary when verification with more than one method is involved. If just one method of verification is envisaged, the report shall be replaced by another describing the method used (test, analysis, design review and inspection ) as per document DR13.

This document covers all verification reports other than those relating to tests, for which separate documents must be produced, as described in this DRL.

The contents are in line with the provisions of document DR13, Annex L.

The verification report may cover the verification of several requirements providing that the relevant verification events are the same (for example an environmental test and the associated analysis cover the same set of requirements).

It is prepared on the basis of the verification matrix and the associated AIV plan, and takes into account the results of the relevant test, analysis, design review and inspection reports (see document DR13, Annex H/DRL, Annex I, Annex J and Annex K).

It shall list the requirements to be verified (in correlation with the VCD) and summarise the verification results, the comparison with the requirements and the verification closing acceptance.

Requirement closing may be summarised in a separate table to be produced for each requirement or group of requirements.

These reports shall refer to ENG-136 and ENG-139.

These report may refer to PA-155 and PA-156.

.


DRD-ENG-135 INDUSTRIAL CONTROL DOSSIER (DIC)

The Industrial Control Dossier shall demonstrate the industrial control status of the VEGA Ground Segment at System, Subsystems and Equipment levels, through a series of dossiers.

It shall include an index and the reference of the design documentation. The exact list is given in the DRL.


DRD-ENG-136 TEST PLANNING AND VALIDATION

The Tests validation plan (TVP) constitutes the formal definition of how the final technical verifications for the ground system or sub-system are achieved for the contract.

The Tests validation plan defines the objectives, schedules and rules for the performance of tests for the individual technical validation, then systems integrated tests validation in preliminary to the operational validation of the ground systems.

The purpose of tests validation is to demonstrate (to each system or sub-system) all technical performances for the compliance with the contractual requirements.

TVP objectives, schedule and success evaluation shall include :

o a statement of the TVP objectives;

o a presentation of the overall structure, organisation and schedule for the TVP, including major milestones;

o identification of any constraints or mission-specific considerations;

o identification of the mechanisms and criteria to be used for measuring and evaluating the success of the TVP.

The ground segment test plan shall include for each individual test the test timetable (start time, duration), the test configuration including, for instance, the identification of all ground segment entities to be used (e.g. hardware, software and database versions), initialisation requirements, any applicable test constraints, manpower resources, and the test procedures to be used (cross-reference may be made to other documents where appropriate).

The same general principles of AIT test plan apply.


DRD-ENG-139 TEST PROCEDURES

A Test Procedure document shall be generated for each test (or package of tests on an individual test article). The document shall be prepared also according to the “PA and Safety Requirements for the contract x” and shall present all the steps to be followed for the verification tests.

The Test Procedure shall be generated in such a manner that each individual step can be checked and monitored by the Quality Assurance Inspectors.

The document shall be written such that the test results shall be entered in the document itself and space shall be available for the Quality Assurance buy-off notification.

The first step for each test shall be to ensure the test readiness, i.e.:

- The test article and the test set-up (including the associated documentation) has been released by the Review Board;

- All support equipment is within calibration for the foreseen duration of the test or that re-calibration is required by the procedure prior to invalidation;

- All protective equipment, for both the test article (e.g. connector saver) and for the test personnel, is in place;

- The test procedure has been approved and is available;

- The necessary personnel, including the quality insurance and the IPT observers, if required, are in place and are suitably qualified and/or certified,

- Constrains from previous tests are removed.

This document provides detailed step-by-step instructions for conducting test activities in accordance with the relevant test requirements.

The test procedure states objectives of the activity, the applicable documents, the references to the relevant test specification, the participants required, the article and tools configuration list, and the step-by-step test procedure.

The test procedure gives directions for conducting a test activity in terms of description, resources, constraints and step-by-step procedure.

The document is used and filled-in as appropriate during the execution and becomes the as-run procedure.


The document is prepared for each test to be conducted at each verification level.

The same procedure may be used in case of recurring tests.

It incorporates the requirements of the test specification and uses detailed information contained in other project documentation (e.g. drawings, ICDs).

Several procedures often originate from a single test specification. In certain circumstances several test procedures may be combined in an overall integrated test procedure.

The as-run procedure becomes part of the relevant test report.

Each Test Procedure document shall be approved by the Test Review Board prior to the test.

These documents must refer to ENG-132.


DRD-ENG-140 INSPECTION KEY-POINT REPORTS AND TEST REPORTS

See DS-MP-AQ-05 referred to in DA19.


DRD-ENG-152: SOFTWARE DETAILED DESIGN

The software detailed design document shall be structured as follows:

1- Introduction

2- Applicable documents

3- Scope of document

4- Project standards, convention and procedures

Design standard

Documentation standard

Naming convention (including files, programs, modules, etc.) 5- System context

6- Technical architecture

7- Component design specifications

N [component identifier]

Identifier

Type

Purpose

Function

Subordinates

Dependencies

Interfaces

Resources

References

Processing

Data

8- Validation

9- Annexes


If the design is object-oriented, the form of this DRD shall be adapted accordingly.


DRD-ENG-153 SW ARCHITECTURAL DESIGN DOCUMENT

The Architectural Design Document should contain :

1- Introduction

2- Applicable documents

3- Scope of document

4- System context

5- System design

Design Method

Breakdown description

6- General presentation of the design

Functional architecture

Task breakdown if applicable

Communication concept model

Data concept model

General processing organisation

HMI synoptics

Constraints description

Errors handling and take over

Degraded mode and take over procedures

7- Validation

Annexes Traceability matrix with SW technical specification, ENG-156.


DRD-ENG-154 MAINTENANCE MANUAL

The maintenance instructions shall provide all technical description and operating information required in order to:

- ensure preventive and corrective maintenance of the installations delivered,

- perform a study of all equipment items at the level of detail required by the maintenance concept selected by the Customer (namely, according to the operational levels defined).

The Maintenance Manual (as per NFX 60-212) shall include documents such as:

- maintenance or servicing guides,

- repair manuals,

- spare parts catalogues.

Maintenance or servicing guides

The operating directives shall be presented accurately, in the logical sequence of the required operations. The interchangeable component verification, assembly and removal operations shall be presented at the appropriate level of detail.

A detailed description of operations involving no specific technical difficulty is not necessary.

However, it is important to highlight the specific characteristics of some tasks: accident hazard, risk of damage, fire, explosion, precautionary measures to be implemented, required accuracy, tolerance to be observed, possible consequences of defective work, etc.

The Maintenance operations shall refer to the catalogue or list of spare parts and/or interchangeable parts.

Repair Manual

This document shall identify the operating conditions of the repair operations (on site or local workshop, or return to factory), describe the tools (standard and specific) necessary, the skills required from the personnel, and indicate the task duration and the inspections (recommended or mandatory) to be carried out after repair completion.

Spare parts catalogue

This document shall be designed and used to illustrate the relations between the constituent elements of a reusable item of equipment, represented in the form of a product tree structure.


Each interchangeable part shall be identified by a manufacturer reference or a reference specific to the project as applicable.

Typical contents of a Maintenance Manual

General

Description and Operation

Operation normal conditions

Operation in particular conditions (if required)

Breakdown of maintenance operations into maintenance levels

Tools and equipment (standard and specific)

Operating processes

Preventive maintenance operations (frequency, ingredients, accesses)

Troubleshooting (diagnostics and repairs)

Installation/removal procedures (text and illustrations)

Inspections and tests (operations, values to be obtained, measuring instrumentation)

Packaging of items repaired or to be repaired.

This manual may include the Spare parts list and document ENG-129.


DRD-ENG-155 SOFTWARE USER MANUAL

The document shall provide as a minimum the following information :

• Purpose of the S/W • Operations environment

- Hardware configuration - Software configuration - Operation constraints

• Operation basics and fundamentals • Operations control procedures and instructions

- Set-up and initialisation - Getting started - Mode selection and control - Normal operations - Normal termination - Error conditions, known deficiencies - Recovery runs - House keeping

• Installation procedures - Reference to the ENG-160 SOFTWARE INSTALLATION MANUAL

• S/W reference description - Description and examples - Help method - Screen definitions and operations - Operators commands and operations - Messages


DRD-ENG-156 SW TECHNICAL SPECIFICATION

The software technical specification should contains the following :

1 – DEFINITION RULES

2 – SOFTWARE TECHNICAL SPECIFICATION CONTENTS

3 – DETAILED CONTENT OF SPECIFICATION SECTIONS

3.1 - Purpose

3.2 – Applicable and reference documents - symbols

3.3 – Required characteristics

3.3.1 – Definition and missions

3.3.2 – Functions or objects

3.3.3 – Operational requirements

3.3.4 – Design and execution constraints

3.4 – Verification and qualification

DESCRIPTION

1 – DEFINITION RULES

a) As a general rule, the specification must express needs in terms of requirements as opposed to solutions or resources, except in exceptional cases. The specification indicates WHAT the software must do, and NOT HOW this is to be done (this rule must be modulated according to the software breakdown level).

A specification only establishes the limits of a solution space for the problem addressed. These limits correspond to the properties and constraints which can be used to test the selected solution during the development phase.

Where a functional specification or technical requirement specification exists, e.g. ENG-106, the STL must refer to the requirements expressed in the functional specification.

b) It is of fundamental importance that the specification language stays close to natural language. However, a formal or semi-formal description is associated wherever possible in order to avoid natural language hazards (ambiguity, lack of precision, contradiction or incompleteness).


With this approach, the functional part of the software technical specification comprises:

- natural language part,

- part using a formalism (pseudo- language, standardised graphics, Petri networks, PLCs, decision tables, timing diagrams, etc.).

c) Section layout and numbering remains broadly the same, although the content of certain sections can be limited to "not applicable".

d) Sections which cannot be informed at the time of drafting the initial version of the STL are designated "TBD", indicating the target date for key project events (reviews, key points, etc.) and the reason for temporary non-definition.

2 – SOFTWARE TECHNICAL SPECIFICATION CONTENTS

The software technical specification must cover the following:

1 – Purpose

2 – Applicable and reference documents – symbols

3 – Required characteristics

3.1 – Definition and missions

3.2 – Functional requirements

3.3 – Operational requirements

3.4 – Design and execution constraints

4 – Verification and qualification

3 – DETAILED CONTENT OF SPECIFICATION SECTIONS

3.1 - PURPOSE

This explanatory section must include:

- generic software name,

- software objectives and anticipated users,

- name(s) of hardware and software products in which the software will be integrated,

- utilisation to be emphasised,

- software level and functional category.


3.2 – APPLICABLE AND REFERENCE DOCUMENTS - SYMBOLS

This section must indicate:

- list of applicable and reference documents (higher level technical specification, standards, etc.), and identification of applicable chapters or sections of documents which are not applicable in their totality, where necessary,

- symbols and abbreviations used in the technical specification, giving the terminology reference and symbols used in the project where necessary.

3.3 – REQUIRED CHARACTERISTICS

This section must describe accurately the required software characteristics, which must be met to comply with the utilisation for which the software is intended.

The characteristics expressed in the sections of this chapter must be indicated in terms of need, and in no case in terms of solution or execution.

Each requirement must be referenced.

3.3.1 - Definition and missions

This section enlarges on section 3.1 above in more detail, indicating the software mission, its various utilisation modes (nominal, limit and accidental situation), and the various utilisation states which the software can assume throughout its life cycle. An inventory of all functions or purposes must be established for the various software utilisation states and modes.

3.3.2 – Functions or objects

3.3.2.1 – Functional requirements or objects

a) Chaining and execution

An execution diagram is prepared indicating chaining criteria such as:

- event definition,

- absolute value event appearance time,

- time constraints between successive events,

- degrees of precision corresponding to these different times,

- global software duration constraints,

- constraints imposed for the superimposition of a number of independent time counts

to specify the dynamic links between the functions or purposes, so as to clarify parallelism, sequencing or


alternative-related constraints.

b) Processing (generation of results and error processing)

The following are described from a functional point of view:

- rules for output generation,

- required performance (time and size),

- errors to be detected and their treatment mode (internal or delegated),

- incidents in course of execution of the software and their processing mode (internal or delegated).

3.3.2.2 – Description of data and performance by function on the basis of the software mission profile

a) Processing (generation of results and error processing)

The following are described from the functional point of view:

- rules for generation of output from input (algorithms, mathematical models or expressions, etc.),

- required characteristics for the data to be generated,

- required performance: processing time, size and memory space, etc.,

- errors to be detected and their processing mode (internal or delegated),

- incidents during execution and their processing mode (internal or delegated),

- results to be recorded (e.g. acquisition, rerun point, etc.).

b) Input data

Establishment of a list of software input data, indicating in each case:

- data origin,

- nature and associated characteristics (precision, change domain, format, etc.),

- inter-data relations where necessary.

The dialogue is described where the program includes a conversational part.

c) Output data

Identification of software output data indicating:

- nature of data generated and associated characteristics,

- destination of output data (user, storage, etc.),

- inter-data relations where necessary.

d) Performance in regard to the software mission profile


Time, size, etc.

3.3.3 – Operational requirements

This section describes all requirements relating to the implementation and operation of the software for its various utilisation modes and states.

a) Environment

A description of the hardware and software environment with which the software will come into contact must be described.

If this information is already given in other parts of the document, this section is used to group precise definitions.

1) Hardware environment

The description of this environment includes:

- list of hardware elements employed and/or interfacing (computer and application-dedicated),

- chaining, nature, media and representation of information exchanged,

- performance constraints imposed by hardware characteristics,

- utilisation limits for peripherals,

- accidental configuration cases.

2) Software environment

The description of this environment covers:

- description of interfaces in terms of service provided or constraints imposed (by the sender or the software concerned),

- nature, media and representation (or applicable document reference) of information exchanged, and the chaining of this information.

b) User interface (where necessary)

This interface described:

- operator dialogue (commands, messages, etc.) and screen organisation and content (analog measurements, reports, etc.),

- form of anticipated results: hard copy, interrogation screen, etc.,

- imposed performance constraints (response times, etc.),

- user interface standards.

c) Activation conditions

This section indicates:


- required configuration state (hardware and software),

- combination of events triggering execution,

- state in which the software must leave the hardware and interfacing software after execution.

3.3.4 – Design and execution constraints

This section addresses design and execution requirements other than those induced by functional and operational requirements, and which result from the fact:

- that the software is inserted in a larger system, in turn inducing constraints relating to:

. harmonisation,

. resource sharing,

. utilisation of joint solutions and techniques,

. development (between contractors);

- that the software functions, operating environment and utilisation states can change according to its life cycle, and that it is necessary to plan resources to cope with this situation;

- that certain software components are imposed (standard or existing software).

This section consequently covers the following points:

a) Design constraint (system)

1) Sharing of computer resources

The following are stipulated:

- sharing of processor(s),

- allocated memory size,

- sharing of peripherals.

2) Performance

The following are stipulated where necessary:

- information flow-rates between input and output,

- input data integration rates,

- output result availability rates,

- imposed response times,

- time-related precision for processing, commands, etc.

3) Computer organisation

This section describes the rules to be taken into account for internal software design.


Examples:

- component "re-entrance" property,

- master/slave mode execution, etc.

b) Execution constraint (project)

1) Applicable rules, standards and specifications

This section must indicate the particularities introduced by application of the various general documents.

2) Language

Precise definition of the language(s) imposed for execution of the program covered by the specification.

c) RAMS constraint

This concerns the inherent RAMS function of the software, and program execution security in regard to its hardware and software environment.

Specific actions to be implemented shall be defined according to the functional category of the software. These actions can involved implementation of techniques and mechanisms of an internal nature, or delegated operations in regard to the other levels.

d) Confidentiality constraint

Examples:

- data to be protected,

- access authorisations (read, write and execution),

- user restrictions.

e) Miscellaneous constraints

1) Program medium

Indication of the following, for example:

- type(s) of medium to be used (magnetic tape, magnetic disks, EPROM, floppy disks, etc.), taking account in particular of the various sites and utilisation modes fo r the software,

- identification for marking.

2) Installation and maintenance

Technical requirements shall be indicated regarding:

- installation,

- commissioning,

- archiving,

- user aid.


3.4 - VERIFICATION AND QUALIFICATION


DRD-ENG-157 SW Interfaces Specifications

This document shall provide the requirements and specification of the software interfaces to and from external entities, e.g. software applications, operating system, telecommunication software. This document shall specify any interface requirement imposed on and by the system. Requirements related to the following (as applicable) shall be listed: - identification of the interfaced SW component by its name and product tree code

- Communication interfaces specification - Software interfaces specification, including the performances

- HCI interactions.

The SW Interfaces Specifications can be justified in the justification report ENG-117.


DRD-ENG-158 SW internal and external interfaces design

This document shall define the design of the SW internal and external interfaces of the product.

Representation of interfaces shall be made utilising interface diagrams.

This document shall contain :

- Interface Identification. Interface diagrams can be used to identify the external interfaces of the software item.

- Interface description

For each identified interface this section shall be organised as follows:

Ø Data Elements

For each data element the following information shall be provided:

? Name

? Unique identifier

? Description

? Source item

? Destination item

? Unit of measure

? Limit/range

? Accuracy

? Precision

? Frequency

? Rate

? Legality checks

? Data type

? Data representation


? Priority

Ø Message Description

This section shall describe the messages transmitted across the interface by name and unique identifier and shall describe the assignment of data elements to each message.

Ø Communication Protocol

This section shall describe the protocol applicable to the interface or make reference to applicable documentation.


DRD-ENG-159 HARDWARE INSTALLATION MANUAL

This hardware installation manual shall contain, at least : - the identification of the equipment to be installed, including its code in the product tree, - the installation logic, - the duration of the installation and the duration of each long step, more than 1 min, - the installation environment, including the needed tools,

- the installation procedures, including the definition of each step of the installation and the drawings, - the installation checks, - the ‘uninstallation’ procedures. Each step of the installation and the ‘uninstallation’ must be referenced.


DRD-ENG-160 SOFTWARE INSTALLATION MANUAL

A software Installation Manual must contain the following information:

- prerequisites, including the necessary hardware and software configuration in particular, - the duration of the installation and the duration of each long step, more than 1 min,

- archiving or storage procedures and de-archiving or restoration procedures where necessary,

- local or remote (downloading) installation procedures,

- system initialisation procedures,

- software partial modification procedures if necessary, - software installation checks, e.g. checksums,

- software version change procedure,

- software ‘uninstallation’ procedures.

Each step of the installation and the ‘uninstallation’ must be referenced. See also the DA11, in particular about the checks and the installation metrics.


DRD-ENG-170 LEVEL 2 SOFTWARE TECHNICAL SPECIFICATION

A Level 2 software technical specification shall include as a minimum, for each tool, the following information:

Ø Tool designation

Ø Input and output parameters

Ø Tool accessibility (application software, manual)

Ø Description of tool functions

Ø Functional description of parameters

Ø Reports

Ø …..

The preliminary list of software tools is provided in DR8.


DRD-ENG-161 Software Reference Manual

The table of content of this manual is :

1 Introduction 1.1 purpose 1.2 scope

1.3 document structure 2 Documents

2.1 Applicable documents

2.2 Reference documents

3 Overview

3.1 introduction

3.2 context

3.3 definitions

3.4 Package overview

3.5 process or component identification

4 process or component description

5 Software Package information

5.1 Introduction 5.2 Package definition

5.3 Package descriptions

6 Data bases (TBC)


DRD-PA-100 : RAMS PLAN

This document must explain how the RAMS requirements shall be taken into account and applied. It may be included in a PA plan.

It shall contain :

Ø Contractor organisation for this contract and specially RAMS organisation

Ø Description of RAMS tasks in design, purchase, manufacturing, installation and acceptance operations

Ø Configuration management

Ø Documentation management

Ø Sub-contractors management : RAMS evaluation


DRD-PA-101 : QUALITY ASSURANCE PLAN

This document must explain how the quality assurance requirements shall be taken into account and applied . It may be included in a Product Assurance Plan.

The SW Quality Assurance Plan must be an applicable document in this plan, see the AD19.

Quality Assurance Plan shall contain, at least :

Ø Contractor organisation for this contract and specially assurance quality organisation

Ø Personnel Training and certification

Ø Description of quality tasks in design, purchase, manufacturing, installation an acceptance operations

Ø Configuration management quality checks

Ø Documentation management quality checks

Ø Actions / pending points management

Ø Non-conformities, anomalies and waivers management

Ø Sub-contractors management, e.g. quality evalua tion and checks

Ø Checks and tests means management

The contractor may reference in-house existing documentation.


DRD-PA-103 : QUALITY ASSURANCE REPORTS

These reports are required to provide visibility on product assurance aspects. They may be included in PA reports.

This report is required to provide visibility on product assurance aspects

The report shall include, at least, the following information :

♦ Overall assessment :

Ø PA manager's assessment,

Ø Key problems list,

Ø Open action items requiring specia l attention,

Ø Comments on schedule impacts.

♦ Detailed status

Ø Status of actions and recommendations,

Ø Status of anomalies, non-conformances and waivers,

Ø Status of audits, MIP/KIPs and reviews,

Ø Verification and qualification status list : reference shall be made to the relevant reports issued,

Ø QA graphic indicators, such as :

- number of tests successfully - unsuccessfully completed / number of tests expected at issue date,

- number of KIP/MIP performed / expected planned number at issue date,

- number of open critical items,

- number of open NCRs,

- number of change requests issued in the reporting period

Ø Quality performed task: e.g. the check of the software source code and the check of the documentation

Ø SW quality report, including the metrics, see the AD11


DRD-PA-104 : TEST READINESS REVIEW REPORT

Test readiness review (TRR) must be hold before the beginning of the tests. At the end of TRR, the customer takes the decision to begin or not the tests.

The TRR report shall contain, see AD8 :

Ø General information about the system to be tested, including the contract reference

Ø TRR Participants list

Ø System and interfaces description and progress status

Ø Applicable documentation

Ø Safety, Reliability, Availability, Maintainability aspects

Ø System quality status, e.g. : NCR, Waivers, Action items, pending points

Ø Configuration status of the documentation, hardware and software

Ø Test plan and procedures examination, e.g. : test objectives, procedures status

Ø Checks, tests and measurement means status, e.g. : availability, calibration, software tools

Ø Checks and tests performed before TRR status

Ø Tests schedule

Ø List of non closed actions items and pending points before TRR

Ø List of non closed actions items and pending points issued from TRR

Ø Decision to begin tests or not


DRD-PA-105 : TESTS REVIEW BOARD REPORT

Tests review board (TRB) must be hold when tests have been completed. The tests results are analysed in order to authorise next phase or acceptance.

TRB report shall contain, see AD8 :

Ø General information about the system, inc luding the contract reference



Ø Applicable documentation

Ø NCR and waivers status


Ø Checks, tests and measurement means status

Ø Checks and tests performed before TRB status, e.g. : performed tests, not performed tests, used procedures list, tests report list

Ø Test results analysis

Ø List of non closed actions items and pending points before the TRB

Ø List of actions items and pending points issued from the TRB list

Ø Decision to continue to next phase or to go to the acceptance


DRD-PA-106 AUDIT REPORT

The audit report shall contain:

q composition of the audit team

q definition of the topic of the audit, e.g. the quality process, configuration

q short presentation of the audited company : location, size, organisation chart, annual turnover, quality certification –if any-, as a minimum

q description of its activity in the project

q audit assessment baseline

q audit activity summary

q identified areas of non-compliance

q recommendations

q overall conclusion

All the auditors shall sign the audit report.


DRD-PA-107 : NON CONFORMITY OR ANOMALY REPORT

The NCR shall contain, see the AD9 :

:

Ø information about the system or components where appears NC or anomaly

Ø occurrence phase, date, hour and place (with maximum accuracy)

Ø name of person who detected NC or anomaly

Ø precise description of NC or anomaly (with attached documents if necessary)

Ø analysis giving proved, probable or possible causes and actual or/and potential effects (with attached documents if necessary)

Ø classification : major or minor

Ø decided corrective actions

Ø closure with justification and evidence, with attached documents if necessary


DRD-PA-108 : REQUEST FOR WAIVER REPORT

The Request for Waiver report shall contain, see AD9 :

Ø Program and project identifications

Ø Industrial contractor or sub-contractor identification

Ø Waiver identification number

Ø System or component identification

Ø WBS identification

Ø Problem description

Ø Waiver origin : NCR identification

Ø Impacted items

Ø Use limit

Ø Industrial contractor technical and quality assurance managers opinion

Ø Customer quality assurance manager opinion

Ø Customer technical manager decision

Ø Closure decision by waiver review board (CTTD)


DRD-PA-109 : KIP AND MIP REPORT

KIP and MIP report shall contain :

Ø Project identification

Ø Quality control plan identification

Ø Industrial contractor and/or sub-contractor identification


Ø KIP or MIP reference

Ø KIP or MIP title

Ø Industrial contractor and/or sub-contractor test or/and check certificates identification

Ø Possible NCR or waiver identification

Ø Decided corrective actions

Ø KIP or MIP acceptance decision

Ø Industrial sub-contractor and/or contractor signatures

Ø Customer technical and/or quality assurance managers signatures

In each MIP report, a RAMS progress report for the considered period shall be delivered with : o The objectives of the MIP,

o The compliance with the RAMS rules to check out this point in the manufacturing process or installation process.


DRD-PA-110 : RAMS analysis and assessment report file

The RAMS report shall be subdivided into 5 sections:

a) Safety report

The safety report shall include:

• A remind of availability objectives

• hazards analysis input data (e.g. design and operational data, either by document reference and issue or the document copy);

• hazards analyses;

• supporting analyses and safety studies that are performed in support of hazard identification and evaluation.

• technical safety requirements file;

• hazard and risk acceptance support documentation (e.g. analyses, qualification test procedures or drawings), either by document reference and issue or the document copy);

• safety reviews and safety audit reports;

• safety related non-compliance (including waivers) and failure documentation;

• document review tracking data;

• accident and incident data;

• safety requirements conformance data; • safety problem data

b) Availability report

The availability report shall include:


• a description of the hypothesis used to build the availability models

• a description of the availability model ( e.g. block diagrams )

• the list of quantitative data ( together with their sources ) which are used in the predictions

• the availability results


• the identification of the main contributors to the unavailability and recommendations on how to reduce their impact

c) reliability report

The reliability report shall include:


• a description of the hypothesis used to build the reliability models

• a description of the reliability model ( e.g. block diagrams )

• the list of quantitative data ( together with their sources) which are used in the predictions

• the reliability results

• the identification of the main contributors to the unreliability and recommendations on how to reduce their impact

• the results of the sensitivity analysis on the main parameters influencing the reliability results

d) maintainability report

• A remind of maintainability objectives

• the maintainability results from maintainability analysis .

a) Synthesis report

Compliance with RAMS GS VEGA requirements.

This document can be merged with the PA-118, PA-120, PA-125 and PA-126.


DRD-PA-111 : FEARED EVENTS LIST AND CIL

The list and the CIL are detailed in appendix A5 of the AD19 (TBC)

This document can be merged with the PA-124 and PA-133, e.g. in a 'Critical item file'.


DRD-PA-112 : FMEA/FMECA

The AD20 shall be used as guideline.

The FMECA shall be performed either according to the functional approach or to the hardware approach and shall include considerations on the processes.

It shall include a Functional Analysis establishing the relative criticality of each function and/or functional path in the concept under study in order to establish the reliability requirements, including those for failure tolerance and the software criticality classes. The FA shall be used to support the reliability modelling and the Reliability and Safety Analyses.

The FMECA shall make use of the following inputs:

• the mission requirements and the mission profile;

• the product specification (e.g. system/subsystem specification and performance specification);

• the current hierarchical decomposition of the system functions; The function decomposition is generally derived from the functional analysis;

• the design of the product architecture (e.g. design description, drawings, interfaces description);

• available information from the product safety analyses relevant to hazard causes and controls;

• when available, FMECAs performed at lower integration level;

• item failure rates.

The output of the FMECA is: • list of dependability and safety requirements to be allocated to the product and lower

levels for implementing the prevention and compensation methods and for avoiding the single point failures;

• the effect of the H/W faults on S/W and the opposite

• input to safety analyses: identification of hazardous consequences due to failures at lower levels and relevant identified prevention and compensation methods;

• input to Software Criticality Analysis, e.g. identification of function failure consequences to be used as support in defining the effects of functional software failures;

• input to the Critical Function List / Critical Item List • input for the demonstration of the Failure Detection Isolation

Recovery (FDIR) capability.


DRD-PA-113 : FACTORY INDUSTRIAL ACCEPTANCE REPORT (FIAR)

Factory Industrial Acceptance Report shall contain , see the AD8 :

Ø Project identification

Ø System or component identification and location

Ø Components list with reference

Ø Discrepancies : NCR, anomalies, waivers status

Ø Modifications status

Ø Tests and checks status with certificates reference and test means status

Ø Action items and due points list

Ø Sub-contractor and/or contractor technical and quality managers signatures

Ø Customer technical and/or quality managers signatures


DRD-PA-114 : ZONE ANALYSIS

The analysis report shall contain the following:

• Identification of the perimeter of the study (system and RAMS rules to check)

• List of feared events in entries which are studies.

• List of identified effects on the sub system

• List of actions


DRD-PA-115 : ACCEPTANCE REVIEW BOARD REPORT

Acceptance Review Board (ARB) must be hold for acceptance in case of satisfactory TRB results.

ARB report shall contain, see AD8 :

Ø General information about system tested



Ø Safety, Availability, Maintainability aspects

Ø System quality status : NCR, Waivers, Action items, pending points,…


Ø TRB results

Ø Non closed actions items and pending points before TRB list

Ø Actions items and pending points issued from TRB list

Ø Decision to acceptance


DRD-PA-117 : PRELIMINARY HAZARD ANALYSIS

The AD20 shall be used as guideline.

The PHA results shall be documented using hazard analysis report sheets providing at least the following information: • Identification of the affected item • Operational phase • Hazard • Description of the undesirable events and consequences • Consequences category • Possible causes • Applicable safety requirements • Description of the hazard reduction process • Recommendations • Verification methods • Rationale for retention • Inclusion in the safety critical item list • Closure/approval status


DRD-PA-118 : SAFETY ANALYSIS

The safety analysis shall be performed according to AD20 that shall be used as guideline.



DRD-PA-119 : Industrial RAMS Dossier This file shall contain, at least, the following documents: v RAMS plan,

v RAMS report file,

v RAMS progress report,

v Preliminary Hazard Analysis,

v RAMS apportionment,

v FMEA/FMECA,

v Feared events list and CIL,

v RAMS actions items,

v Reliability analysis and assessment,

v Availability analysis,

v Maintainability analysis and spare parts list,

v Safety analysis,

v Common mode failures,

v Single points failures,

v Zone analysis


DRD-PA-120 : RELIABILITY ANALYSIS AND ASSESSMENT

The reliability analysis shall be performed according to the AD20, which shall be used as guideline.



DRD-PA-121 : SAFETY AND REGULATIONS DOSSIER (DSR)

The exact list of the dossier documents is given in DRL, chapter 6.13.


DRD-PA-123 : Waivers list and status

Waiver list and status shall contain, for each waiver (see AD9):

Ø Industrial contractor or sub-contractor identification


Ø Waiver identification number

Ø Opening date

Ø Impacted items

Ø Effects on system and operations

Ø Agreement date or denial date

Ø Closure date

This document may be merged with the MAN-128 and the PA-138,e.g. in a 'CONTRACT CONFIGURATION STATUS REPORT'.


DRD-PA-124 : COMMON MODE FAILURES

Two common mode failures must be considered:

Common Cause failures are failures of more than one item as the result of an external influence.

Common Mode failures are failures of more than one identical item as the result of a failure initiating condition which is a common characteristic of the item.

The analysis shall contain the following: • identification of the applicable configuration and interfaces; • identification of the applicable functional diagram • identification of the considered design status • identification of the operational phases • identification of the operational modes • an ordered list of all configuration items in the system.

For each configuration item the analysis shall provide: • configuration identification • descriptive name • identification of each failure mode/failure cause respective hazard and hazard cause.

For each failure mode/failure cause and respective hazard/hazard cause the analysis shall provide:

• the configuration items which share the same mode/cause • failure or hazard severity category • preventive measures taken • other measures taken to reduce the consequences of the failure.

This document can be merged with the PA-111 and PA-133, e.g. in a 'Critical item file'.


DRD-PA-125 : AVAILABILITY ANALYSIS

The maintainability analysis shall be performed according to the AD20 that shall be used as guideline

A Human Dependability Analysis shall be performed when the RAMS analyses identify the possibility of functional failures through human interaction. The analysis shall be performed at system level, in support to the FMECA and the Hazard Analysis, and in support of the subsequent risk reduction approach.



DRD-PA-126 : MAINTAINABILITY ANALYSIS

The maintainability analysis shall be performed according to AD20 that shall be used as guideline

From availability and reliability objectives the analysis shall:

• identify the preventive and credible corrective maintenance actions, including the corresponding maximum time to repair, for ground operations and on the launch pad;

• identify emergency restoration or repair activities necessary to sustain system capabilities crucial to launch readiness;

• identify those items that cannot be checked after integration, those require late servicing, access or replacement, and limited- life items or consumables.



DRD-PA-127 : ACCEPTANCE CERTIFICATE

This certificate is the official item for property transfer of supply from industrial contractor to customer.

This certificate shall contain :

Ø Certificate identification

Ø Date

Ø Contract designation and identification

Ø Acceptance subject

Ø Acceptance review board report identification

Ø Industrial contractor name

Ø Signatures of :

§ Industrial contractor technical and QA managers

§ Technical officer and QA infrastructure manager or PA GS manager

§ VEGA GS manager and VEGA PA manager

Ø Attachment with pending points list

A REFERENCE TO THE RCI, DRD-PA-138, CAN BE INCLUDED IN THIS CERTIFICATE.


DRD-PA-129 : HARDWARE QUALITY MANUFACTURING FLOW CHART

The Hardware Quality manufacturing flow chart must give checks and tests points foreseen on hardware technical devices and activities in order to ensure final product quality, see the AD7, including factory and on site acceptances, see the AD8.

It shall contain :

ØForeseen purchased items checks

ØForeseen manufacturing checks and tests, e.g. : dimensional checks, temperature measurement.

ØForeseen factory acceptance checks and tests

ØForeseen on site installation checks and tests

ØForeseen final acceptance checks and tests

ØMIP/KIP plan

For each check or test must be given :

Ø applicable requirements and expected results

Ø test or check procedure

Ø used checks and tests means with their validity date

When a check or test step is complete, it must be indicated, on this document, if the result is compliant and give the reference of check or test report.


DRD-PA-130 : RAMS PROGRESS REPORT

This progress report shall provide all RAMS programmed activities in progress relatively to previous schedule.

• Identification

• Date

• Supporting analysis and justification

• Actions in progress

• Evidence of acceptance or rejection by management.

For accepted recommendations:

• For recommendations related to specifications, provide evidence of implementation into the relevant applicable documentation.

• For other recommendations, provide evidence of implementation

This progress report may be included in a Product Assurance report.


DRD-PA-132 : RAMS APPORTIONMENT

The RAMS objectives apportionment shall be performed for each sub system and function and every class of risk. The logic of apportionment shall be clearly described. The detailed objectives shall be collected in a specific document.


DRD-PA-133 SINGLE POINTS FAILURE

See AD19. This document can be merged with the PA-111 and PA-124, e.g. in a 'Critical item file'.


DRD-PA-138 : NON CONFORMITIES AND ANOMALIES LIST AND STATUS

Non conformities and anomalies list and status must contain for each NC or anomaly :

Ø Occurrence date

Ø Summary description of NC or anomaly

Ø Effects (actual or/and potential)

Ø Proved cause when it has been found, if not, probable or possible causes

Ø Classification : major or minor

Ø Decided corrective actions

Ø Actually implemented corrective actions

Ø Status : opened or closed

See AD19.

This document may be merged with MAN-128 and PA-138,e.g. in a 'CONTRACT CONFIGURATION STATUS REPORT'.


DRD-PA-139 Acceptance configuration Register (RCI)

The Acceptance configuration Register shall be produced on the basis of the following model form:


Acceptance configuration Register

INDUSTRIAL LOGO Customer

Technical Flow diagram reference:

|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|

RCI reference: Page

/

ACCEPTANCE CONFIGURATION REGISTER

STRUCTURE OR SYSTEM : _______________________________

CONTRACT N° : _______________________________

UPDATE TABLE

ISSUE MODIFIED

PAGES OPERATION

ORDER N° ABSTRACT OF MODIFICATION REASON INITIAL REFERENCE


Any page modified shall be given the new issue allocated to the document at the time of page modification.

Date:

Iss. Initials

Signature


ACCEPTANCE CONFIGURATION REGISTER Customer

ORIGINATOR'S INDUSTRIAL LOGO ASSEMBLY :


|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|

SUBASSEMBLY : RCI reference: Page

/

TABLE OF MAIN CONSTITUENT ITEMS LIST OF ACCEPTANCE CERTIFICATES

PLAN DESIGNATION SUPPLIER MANUFACT. SERIAL N° ACCEPTANCE CERTIFICATE TYPE OF CONFORMITY

EXPIRY DATE

ID AND NUMBER REFERENCE NAME and/or WP N° ORIGINATOR

NUMBER ISSUE DATE DOCUMENT OR REMARKS


CCPU, CC, PVRI Log Book

Date:

Iss. Initials

Signature





|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|


/

STATUS OF DOCUMENTATION DOCUMENTS

DOCUMENT REFERENCE ISSUE TITLE

DOCUMENT

REFERENCE

ISSUE TITLE