S2-ASU-RS-1034 EADS LEA Pathfinder ASTRIUM Page I - European Space Agencyemits.sso.esa.int/emits-doc/ASTRIUMLIM/LISA_MGA/S2.ASU... · 2010-01-13 · the project configuration management

S2-ASU-RS-1034 Issue 02

Page 1 of 24 L E A Pathfinder -i

EADS ASTRIUM

I I I

CADM Requirements for Subcontractors

CI CODE: 124000

UK EXPORT CONTROL RATING: Not Listed Rated By: R. A. Wilson

Prepared by:

Checked by:

Approved by:

Authorised by:

R. Wilson

LL .......................................

Date: ............... CSL J‘,P.\ .P4 . . . .

Date: b ( 1 “(0 4’ ..................................

N.Dunbar

Date: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

A. &ones / G.Adarns

&fJ-L M ckler

Date: ....................

0 EADS Astrium Limited 2004

€ADS Astrium Ltd owns the copyright of this document which is supplied in confidence and which shall not be used for any purpose other than that for which it is supplied and shall not in whole or in part be reproduced, copied, or

communicated to any person without written permission from the owner.

EADS Astrium Limited, Registered in England and Wales No. 2449259 Registered Office: Gunnels Wood Road, Stevenage, Hertfordshire, SGl 2AS, England

Document Autogenerated lrom DOORS Module : ILiSA PathlinderlLevel3ICADM Requirements ~2.a5u.rs.1034il .doc

WILSON_R

LISA Pathfinder

S2-ASU-RS-1034Issue 02

Page 2 of 24

EADS Astrium Ltd owns the copyright of this document which is supplied in confidence and which shall not be used for any purpose other than that for which it is supplied and shall not in whole or in part be reproduced, copied, or communicated to any person without written permission from the owner.

s2.asu.rs.1034i1.doc

INTENTIONALLY BLANK

LISA Pathfinder


Page 3 of 24



CONTENTS

1. INTRODUCTION AND SCOPE.....................................................................................................................6 1.1 Introduction.............................................................................................................................................6 1.2 Scope And Applicability..........................................................................................................................6

2. DOCUMENTS................................................................................................................................................7 2.1 Applicable Documents............................................................................................................................7 2.2 Reference Documents............................................................................................................................7 2.3 Terminology............................................................................................................................................7

3. PURPOSE .....................................................................................................................................................8

4. BASIC REQUIREMENTS..............................................................................................................................9 4.1 Configuration managament System.......................................................................................................9 4.2 Organisation ...........................................................................................................................................9 4.3 Configuration Managment Plan..............................................................................................................9 4.4 Lower Tier Monitoring.............................................................................................................................9 4.5 Progress Reporting.................................................................................................................................9

5. CONFIGURATION IDENTIFICATION.........................................................................................................10 5.1 Configuration Item Selection ................................................................................................................10 5.2 Configuration Identification Documentation .........................................................................................10

6. CONFIGURATION CONTROL....................................................................................................................11 6.1 Configuration Control Board.................................................................................................................11 6.2 Change Documentation........................................................................................................................11 6.3 Review and Approval of Changes ........................................................................................................12 6.4 Incorporation of Changes into Documents...........................................................................................12 6.5 Implementation of Changes on Deliverable Items ..............................................................................12 6.6 Interface Control ...................................................................................................................................12

7. CONGIFURATION STATUC ACCOUNTING..............................................................................................13

8. CONFIGURATION VERIFICATION ............................................................................................................14 8.1 Reviews ................................................................................................................................................14 8.2 Configuration Reconciliation.................................................................................................................14

9. SPECIFIC DISPOSTIONS FOR SOFTWARE. ...........................................................................................15 9.1 Software CI Defintions..........................................................................................................................15 9.2 Software CI Identification .....................................................................................................................15 9.3 Storage .................................................................................................................................................15

9.3.1 Media..........................................................................................................................................15 9.3.2 Library ........................................................................................................................................15

9.4 Change Control ....................................................................................................................................15 9.5 Releases...............................................................................................................................................16

10. DOCUMENTATION MANAGEMENT........................................................................................................17 10.1 Basic Requirements ...........................................................................................................................17 10.2 Documents Numbering.......................................................................................................................17

LISA Pathfinder


Page 4 of 24



10.2.1 Document Reference System ..................................................................................................17 10.3 Documents Updating..........................................................................................................................19 10.4 Release System .................................................................................................................................19 10.5 Documents Despatching ....................................................................................................................20

Annex 1 Change Form Data Requirements ……………………………………………………………………….21 Annex 2 Deviation Form Data Requirements ……………………………………………………………………..22 Annex 3 Deviation Form …………………………………………………………………………………………….23

LISA Pathfinder


Page 5 of 24



INTENTIONALLY BLANK

LISA Pathfinder


Page 6 of 24



1. INTRODUCTION AND SCOPE

1.1 Introduction LISA Pathfinder (LPF) is the second of the Small Missions for Advanced Research and Technology (SMART), an element of the European Space Agency’s “Cosmic Vision” plan for scientific projects. The purpose of the LPF mission is to flight test key technologies critical for the future space cornerstone mission LISA. Among these technologies, the demonstrations of the LISA Technology Package (LTP) and the µPropulsion Technologies have been identified as mandatory. Additionally the mission will enable the in-flight demonstration of the NASA provided DRS (Disturbance Reduction System). The LPF spacecraft will demonstrate both electric and cold gas micro-thrusters during its 1 year mission.

1.2 Scope And Applicability This document defines the Configuration and Data Management requirements placed by EADS Astrium on subcontractors, lower tier subcontractors and suppliers who have responsibilities for Systems & equipments contractually delivered to EADS Astrium including their related software, EGSE and MGSE, and any item that requires verification. The requirements are based on ECSS series documents, or in ESA specific documents when no equivalent ECSS is available.

LISA Pathfinder


Page 7 of 24



2. DOCUMENTS

2.1 Applicable Documents The following publications form a part of this document to the extent specified herein. Unless an issue is quoted for a document, the current issue is deemed to apply. When an issue is quoted, that issue and no other must be used. �� Applicable documents defined in the contract or the project Statement of Work

2.2 Reference Documents The publications listed below were used in the preparation of this document, and contain background information relating to the subjects addressed.

RD 1 ECSS-M-40A Space Project Management: Configuration Management RD 2 ECSS-M-50A Space Project Management: Information/ Documentation

Management RD 3 S2.EST.PR.1001 Project References RD 4 S2.ASU.RS.1005 PA Requirements for Subcontractors RD 5 S2.ASU.RS.1023 Subcontractor Project Management Requirements and Tasks

2.3 Terminology ABCL As Built Configuration List CADM Configuration And Data Management CCB Configuration Control Board CD Change Directive CI Configuration Item CIDL Configuration Item Data List CM Configuration Management CR Change Request CP Change Proposal CSR Change Status Report DBL Development Baseline DSR Deviation Status Report EIDP End Item Data Package FBL Functional Baseline ICD Interface Control Document LPF LISA Pathfinder NCR Non Conformance Report PBL Production Baseline RFD Request For Deviation QBL Qualification Baseline SW Software TBD To be defined TRR Test Readiness Review

LISA Pathfinder


Page 8 of 24



3. PURPOSE The purpose of these requirements is to state and establish an uniform approach for all companies (all EADS Astrium subcontractors/suppliers), enabling the application of disciplines and procedures to achieve effective control over the design and built status of all contractual deliverables from the initial definition throughout entire life cycle of the project.

LISA Pathfinder


Page 9 of 24



4. BASIC REQUIREMENTS

4.1 Configuration managament System EADS Astrium subcontractors and suppliers shall establish and operate a project configuration management system with procedures to: �� Identify items under their configuration control (Configuration Items) and document their functional and physical characteristics by means of at least specifications, functional diagram, drawings, parts lists, procedures, plans, interfaces documents. �� Control and document changes to those characteristics and operate an effective Configuration Control Board (CCB), �� Record and report configuration status of each C.I for which the contractor is responsible for, �� Verify achievement of conformity of requirements within the delivered product as set forth in its technical documentation, and monitor configuration data received from their lower tier subcontractors.

4.2 Organisation Subcontractors shall appoint a person to be responsible for the implementation, operation and monitoring of the project configuration management system. This person shall act as a single point of contact throughout the project for all configuration and data management matters.

4.3 Configuration Managment Plan The system and the procedures used to comply with the EADS Astrium requirements shall be described by the subcontractor in a CADM plan. A statement of compliance against these EADS Astrium requirements shall be provided. The plan shall be submitted for EADS Astrium approval, according to the contractual schedule. If necessary, EADS Astrium shall have the right to conduct audits to confirm the subcontractor's ability to comply with these requirements. EADS Astrium's customer ESA shall be permitted to attend such audits.

4.4 Lower Tier Monitoring EADS Astrium subcontractor shall ensure that lower tier subcontractors, suppliers and vendors also comply to these requirements and shall initiate procedures as necessary. Planned configuration audits conducted by the subcontractor on lower tier subcontractors shall be notified in due time to EADS Astrium. EADS Astrium and its customer ESA shall be permitted to attend such audits. Related audit reports shall be made available to EADS Astrium.

4.5 Progress Reporting The subcontractor shall provide a configuration status report to EADS Astrium as part of the required Project progress report and as defined in the Project Management Requirements Specification (S2.ASU.RS.1023). It shall include: �� A report on the Configuration Management tasks achieved during the reporting period, �� Identification of problems encoutered and solutions proposed, �� A Documents issued during reporting period listing, A Contract Change Notice (CCN) status list, (See Project Management RS S2.ASU.RS.1023). �� A Waivers/Deviations status list. (See Project Management RS S2.ASU.RS.1023). The report shall include all configuration activities and data related to lower tier subcontractors. It is recommended that data are presented in relation to the identified subcontractor CI's.

LISA Pathfinder


Page 10 of 24



5. CONFIGURATION IDENTIFICATION This function consists of the identification and selection of items to be placed under configuration management control. This includes the documentation and data that specify and describe their functional and physical characteristics, as well as processes, manufacturing, test and operation requirements to achieve these characteristics.

5.1 Configuration Item Selection The C.I selection process is the separating of a system into individual portions for the purpose of controlling their development, production, qualification, delivery and usage. CIs at the highest level are identified by EADS Astrium and as identified with the Product Tree document (S2.ASU.PT.1001). At the lower system levels (i.e at levels under the top CI of the subcontractor), CIs selection by the subcontractor shall be approved by EADS Astrium. The subcontractor selection must be done with defined criteria. A documented system shall be established and implemented for the numbering of CIs. The item number shall be an alphanumeric number. The numbering of the top CI will be provided by EADS Astrium. In case of interchangeability break, the subcontractor shall make sure to clearly identify the different versions.

5.2 Configuration Identification Documentation The documents necessary for Configuration identification are presented for approval at key milestones, and, when approved, form the Configuration baselines. Configuration baselines are the fundamental concept of Configuration Management (CM) which allows control of what has been agreed to between a customer and his supplier for the product characteristics. The Configuration Identification is developed and maintained through four distinct evolutionary (increasing) levels of detail, each one used for establishing a specific baseline: Functional Configuration Baseline which includes the overall performances, interfaces and design requirements, and the verification testing of these requirements, placed by EADS Astrium on the subcontractor, Development Configuration Baseline, which includes the technical specifications written by the subcontractor for his top level and lower levels CIs to satisfy the Functional Baseline requirements, Design Configuration Baseline, which includes the detailed design documentation presented at the CDR, to be authorized for qualification models or protoflight production. Product Configuration Baseline, which includes the set of documents containing all the detailed performance and design attributes required for production, acceptance, operation, support and disposal. The Product Configuration Baseline is the approved qualified design for serial production. Approved changes modify a baseline, but do not re-establish the baseline nor create a new one. Baselines, plus approved changes from those baselines, constitute the current approved Configuration Identification.

LISA Pathfinder


Page 11 of 24



6. CONFIGURATION CONTROL The subcontractor shall establish and operate an efficient system by which any change or limited departure to the configuration identification of a CI after formal establishment of its baselines will be identified, documented, evaluated, classified, justified, approved and implemented, or rejected. All configuration control shall be applied at the CI level. All changes (or departure) against non CI components will be addressed to the next upper CI. The system shall include procedures for review and approval of CI documentation to be baselined.

6.1 Configuration Control Board Any change between EADS Astrium and his subcontractors shall be classified into 2 classes. Class A and Class B are defined within Article 10 of the contract: �� Class A (except for the cancellation of work or hardware) are changes which impact on the contractual/technical agreement reached between EADS Astrium and the subcontractor, in particular one of the following: - Functions, processes, performances, weight as defined in EADS ASTRIUM requirements - Safety, reliability, maintenability, - Approved interface data, - Interchangeability, - Established configuration baselines, - Costs and schedules, - Delivered spare or product (if necessary to retrofit), - Qualified product

�� Class A changes shall be submitted to EADS Astrium for review and approval before implementation. EADS Astrium will request his customer approval, through the appropriate procedure, when necesserary regarding his own commitments. �� Class B are changes outside the Class A definition, but necessary to meet technical/contractual requirements and provisions. They may be implemented after subcontractor CCB approval, but shall be copied to EADS Astrium for information and possible over classifying.

6.2 Change Documentation Any party may at any time initiate the change procedure, with the following change documents: �� Change Request (CR): the formal document issued by EADS Astrium to the subcontractors in order to explore impacts of a change in the requirements of the functional baseline. �� Subcontractors shall be obliged to evaluate and answer to EADS Astrium CR. �� Contract Change Notice (CCN): the formal document raised by the subcontractor, either in response to a CR or on its own initiative, to propose a change in the current approved configuration identification. �� Class A CCNs may be raised on subcontractor form, which shall include at least the data defined in Annex 1. In addition to the CCN form, the Class A change package shall contain all informations, drawings, justifications necessary for the EADS Astrium CCB to decide on the change feasibility and acceptability. In particular, the package shall include mark-ups or sketches of impacted baselined documents. �� Deviation (RFD) : The formal document raised by the subcontractor to request a departure against a requirement of the functional baseline. The RFD may be raised on subcontractors form or the attached format see annex 3, the form shall include at least the data defined in annex 2. The RFD package shall contain all the information & justification necessary for the EADS Astrium CCB to decide on the RFD acceptability. Approved deviations will be incorporated within the Functional Baseline. �� Waiver (RFW) : see definition and approval procedure in P.A Requirements

LISA Pathfinder


Page 12 of 24



6.3 Review and Approval of Changes Signature of class A CCN form by EADS Astrium CCB chairman (Project Manager or his delegated representative) constitutes approval of the change and renders it enforceable. If necessary, a Change Directive (CD) will be issued to document and forward EADS Astrium CCB dispositions. The CD will stipulate any contractual actions in relation to the change, funding limitations, schedule constraints, or will give reasons for deferral or disapproval if that is the CCB decision.

6.4 Incorporation of Changes into Documents Incorporation of changes into documents shall be carried out by the organization responsible of the generation of the document. Any changed document shall clearly identify the change numbers used for its updating.

6.5 Implementation of Changes on Deliverable Items Implementation of approved changes on procured item shall be verified by EADS Astrium procurement engineers through key inspection points and progress meeting at subcontractor site.

6.6 Interface Control Each subcontractor controlling a CI design shall provide to EADS Astrium Interface Control Documents (ICD) comprising at a minimum the following interface data: �� Mechanical characteristics : geometry, dimensions, fixings, weight, inertia, and position of centre of gravity, �� Electrical characteristics : power supply, 0 volt diagram, primary/secondary switching diagrams, protection characteristics of each function…, �� Interconnecting data : connectors list of the item and electrical characteristics of the signals on each pin of each connector, �� Telecommand and telemetry characteristics : telemetry and telecommand points, type, mnemonics, transfert function, bits and status meaning,…, �� Thermal characteristics : heating surface, ..., �� Specific constraints : laying out, mounting, operation, ..., �� Software data flow and control flow. When approved by EADS Astrium, these ICDs are gathered into EADS Astrium System Interface Data Handbooks and become a EADS Astrium requirement for the subcontractor. Subsequently, any change to approved interface parameters shall be processed as class A change. At lower levels, any subcontractor having design authority over both sides of an interface between two CIs shall be responsible for the management of that interface, and will be required to establish Interface Control Drawings or Documents (ICD).

LISA Pathfinder


Page 13 of 24



7. CONGIFURATION STATUC ACCOUNTING The preparation and maintenance of the configuration status accounting for each CI is the responsibility of the relevant subcontractor. The major elements to be provided shall be: �� The Configuration Item Data List (CIDL) including: - the baselined documents of the Functional Baseline (FBL). - the baselined documents of the Development Design (DBL). - the baselined documents of the Design Baseline, then of the Product Baseline (PBL). Each entry on the CIDL will show the current issue of the document applicable to the CI, with the approved changes applicable but not yet incorporated into the document. The CIDL shall be delivered for project Reviews to establish new baselines and within the EIDP of each delivered CI unit. �� An As Built Configuration List (ABCL) for each delivered CI unit, showing its definitive built statement. The ABCL will refer to the relevant applicable CIDL, will list the approved waivers/NCR versus this baseline, and will establish the actual composition of the CI unit by part and assembly serial numbers. The ABCL shall be provided at the Test Review Board of the unit, and shall be delivered within the EIDP of the relevant unit. �� A Change Status List (CSL) and Deviation Status List (DSL) which identify the current status of changes & deviations. The DSL (normally part of the CIDL) and the CSL shall be provided as part of the project progress reports, for project Reviews and within the EIDP of each delivered CI unit.

LISA Pathfinder


Page 14 of 24



8. CONFIGURATION VERIFICATION Configuration verification of a CI is performed during Project Reviews to verify the current configuration status and conclude with the establishment of Configuration Baselines, and by Reconciliation of its “as-built” configuration to its “as-designed” configuration for each manufactured CI unit.

8.1 Reviews Reviews are key milestones to assess subcontractor's technical progress, review configuration documentation and establish configuration identification baselines. Establishment of the Configuration Baselines shall be defined in the CADM Plan Typically : The Functional Baseline is established at the C/D phase kick-off meeting. It includes all the requirements placed upon the subcontractor by EADS Astrium. The Development Baseline is established at the Preliminary Design Review of the CI. It includes all the technical and performance specifications written by the subcontractor for its top level and lower levels CIs. The Design Baseline is established at the Critical Design Review of the CI. It includes all the detailed design necessary to produce and test the CI qualification model/protoflight model. The Product Baseline is established at the Qualification Review of the CI. It is an update of the Design Baseline, takes into account of qualification tests results and contains all the detailed performance and design attributes (including the CI operation support documents) required for serial production.

8.2 Configuration Reconciliation The configuration reconciliation allows the subcontractor to certify that the manufactured CI unit conforms to the approved configuration identification, has functioned correctly during tests to the prescribed requirements and is of an acceptable standard for the stated application. The subcontractor shall be responsible for the configuration reconciliation of each deliverable CI unit, that is the comparison between the approved design standard and the achieved built status, and the reconciliation of any differences by means of approved waivers or change proposals. The configuration reconciliation shall take place at the Test Readiness Review (TRR) of the CI unit.

LISA Pathfinder


Page 15 of 24



9. SPECIFIC DISPOSTIONS FOR SOFTWARE. All the previous rules are applicable to the software (SW), but the following are SW specific.

9.1 Software CI Defintions A software CI can be: �� The end SW product or a part source, the smallest part being a SW independant compileable piece �� Executable code �� Test SW �� Software development component The breakdown of a software CI into components shall be described in the Architectural Design Document. An identification number shall be assigned from the lowest controlled level onwards and shall be an integral part of the header of the program code For firmware software, each loaded PROM or EPROM shall be managed following configuration management applicable rules.

9.2 Software CI Identification Each software CI shall have an identifier. This identifier shall contain following information: �� Name identifying the CI function �� Extension representative of language or type of file �� Version and release number �� Checksum to be calculated for each CI The checksum shall be calculated according to an algorithm defined in the subcontractor's CADM plan.

9.3 Storage

9.3.1 Media Each storage media shall be clearly and uniquely identified and controlled by configuration management. Its label will at least contain the following information: �� Project name and subsystem �� CI identifier �� Date �� Content description �� Company of manufacturer

9.3.2 Library To ensure security and control of the SW, the following SW libraries shall be implemented, as a minimum: �� development library used by development engineers with write access �� configuration library, under configuration management control only Regular backups of these libraries shall be performed. All deliveries of software shall be copies of the codes residing in the configuration library.

9.4 Change Control All changes of a SW CI shall be documented in the Header : �� Unit name �� Version/release number �� Title of change �� Change number

LISA Pathfinder


Page 16 of 24



�� Change date �� Author name

9.5 Releases For each SW release, the following shall be provided: �� A SW configuration status list containing the following information for each CI: name and extension, version/release number, history of changes (title, number) and checksum �� A release note which will list the incorporated changes in the current release (except the initial release) Modified SW shall be verified and tested before release. A report of these activities shall be provided.

LISA Pathfinder


Page 17 of 24



10. DOCUMENTATION MANAGEMENT This section defines the requirements applicable to all data and documentation produced for the project, which must be either available to EADS Astrium at the subcontractor's site or delivered to EADS Astrium. The list of the data and documentation to be provided by the subcontractor is given in the Statement of Work.

10.1 Basic Requirements Each subcontractor shall establish and operate a centralized documentation system which shall encompass rules for identification numbering, recording, release, distribution, maintenance, care, and storage of all documentation and changes released for the project. All deliverable documentation: �� Shall be written in the English language. �� Shall be in a searchable PDF format were possible. The documentation system shall be described in the subcontractor CADM plan and must remain the same for the entire duration of the project. The system shall be able to: �� Maintain a data bank for all documents produced under the contract, �� Verify that all documents required in the statement of work are produced and delivered, �� Number the documents following the numbering system of codification defined hereunder, �� Periodically inform on received and issued documents �� Fully approve changes before introduction in the baselined documents �� Set up a receipt, recording, and despatch system for all technical and project managment data.

10.2 Documents Numbering LPF project requires all mission participants to adhere to the following references for documents, change control and correspondence. The reference system will allow flexibilty to accommodate reference and registration systems already in place by the subcontractors. Definitions: �� Documents are narratives and / or descriptives (including Technical Notes, Reports, Minutes of Meetings ect.) that describethe formal status of a project element within the LPF project. �� Correspondence covers communication and exchange of information via Fax, Mail (Letters / Memos) or E-Mail. Only written corresponence that carries the signature of an authorised person will be considered as committing. As a consequence, E-Mail and electronic exchange are considered as informal and non-committing.

10.2.1 Document Reference System To identify each document the following code is to be adhered to by all subcontractors: �� Project Identifier �� Originating Company �� Document Code �� Project Element �� Numbering System Example: XX.XXX.XX.X XXX

10.2.1.1 Project Identifier The Project identification code for LISA Pathfinder is S2 Example: S2.XXX.XX.X XXX

LISA Pathfinder


Page 18 of 24



10.2.1.2 Originating Company A two or three letter code is assigned for the originator of the document. For example the following codes have been allocated. EST - for documents issued by ESTEC ESC - for documents issued by ESOC ASD - for documents issued by Astrium GmbH ADU - for documents issued by Astrium Ltd SYS - for documents issued by Science System Ltd Example: S2.EST.XX.X XXX

10.2.1.3 Document Code The document identification characters (two or three) clarify the purpose and the objective of the document. The following codes have been allocated, additional codes can be allocate if required. ADD - Architectural Design Document BR - Budget Report CH - Schedule, Network, Chart CON - Contract CE - Certificate CCN - Contract Change Notice CP - Change Proposal CR - Change Request CS - Configuration Status List DDD - Detailed Design Document DVP - Development and Verification Plan DRL - Document Requirement List DRW - Drawing/Diagram DP - Data Package DS - Design Specification ECP - Engineering Change Proposal EID - Experiment interface Document HAD - H/W Architectural Design Document ICD - Interface Control Document INF - Information Item (Q & A, statements ect.) IRD - Interface Requirement Document ITT - Invitation to Tender LI - List MA - Manual MN - Minutes of Meeting MR - Management Requirements NCR - Non-Conformance Report PL - Plan PMM - Project Managers Meeting Report PR - Procedure PRR - Progress Report PRS - Presentation / Handbook PT - Product Tree PTL - Parts List or Document List RCD - Rquirement Control Document RFD - Request for Deviation RFQ - Request for Quotation RFW - Request for Waiver RP - Report

LISA Pathfinder


Page 19 of 24



RS - Requirement Specification SOW - Statement of Work SRD - S/W Requirement Document TN - Technical Note TP - Test Procedure TR - Test Report TS - Test Specification VCD - Verification Control Document WBS - Work Breakdown Structure WPD - Work Package Description Example: S2.EST.PRR.X XXX

10.2.1.4 Project Element The first of the four digits document number refers to the respective project element as shown below. 1 XXX - Management 2 XXX - Spacecraft 3 XXX - Lisa Technology Package (LTP) 4 XXX - Launcher 5 XXX - Ground Segment, Mission Analysis 6 XXX - Disturbance Reduction System (DRS) Example: S2.EST.PRR.2 XXX

10.2.1.5 Number System For each type of Document Code 999 document numbers can be asigned. The reference number (last three digits '001') is sequential for each Document Code (PRR). Each Originator (EST, ESC, ASU ect.) will create there own sequential reference numbers. The sequential reference number is independent from the project element ('2'). Example: S2.EST.PRR.2001

10.3 Documents Updating Documents will be updated either by revision or a new issue. Revisions will be made for minor additions, deletions or changes of information. New issues or re-issues will be made when major changes in scope or in text occur. Changes (deletions, modifications and additions) in the text of the document between issues and revisions shall be identified in the margin by a vertical dash. The issue number of the pages shall be the same as the document issue number. A change record sheet shall be included in the document and shall list the different issues with their dates, information about the reason of change or the number of incorporated changes.

10.4 Release System The release of engineering documentation, i.e drawings and associated lists, specifications, tests procedures, manufacturing and inspection documentation, etc... will be in accordance with subcontractor internal procedures, to describe within the CADM plan. �� Procedures shall be established for: �� Obtaining approval and authorizing release of documentation, �� Controlling distribution, �� Storage and protection of original masters against damage and unauthorized withdrawal, �� Maintaining release records. The data to be recorded shall include the identification number, title

LISA Pathfinder


Page 20 of 24



and issue status, the identification of the relevant product and the release date.

10.5 Documents Despatching No formal document shall leave the subcontractor firm without signature of the project manager (or of his duly designated representative). Every document despatched to EADS Astrium shall be addressed to the EADS Astrium LPF project CADM department. Similarly, any despatch to the subcontractor shall be addressed by EADS Astrium to a single point of contact to be identified in the subcontractor CADM plan.

LISA Pathfinder


Page 21 of 24



Annex 1 - Change Form Data Requirements

DATA DESCRIPTION Company Identification of the change originating organisation Change Number Unique identification and register number Issue Numerical identification of updated issues Date Issue date of the change Project Project under which the changed item will be supplied Change Request reference

Reference to EADS ASTRIUM change request if any

Title Title or short description of the change Classification Class 1 or 2, according to the contractual agreement and the

subcontractor CCB decision Effectivity Recommended introduction point and identification of the application

range of the change Change description Description of the change Affected Item Identification of the CI (name and number) to which the change applies. Affected document Identification of the document(s) (number and issue, paragraph / design

data) affected by the change. Change Reason Reason for Change; Describe the rational for the change approval. Related Factors Indication on related factors of the change:

performances, interfaces, interchangeability, qualification, reliability, maintainability, safety, electrical/mechanical parameters, material or processes, parts, testing, Ground segment, GSE and tooling, user documentation, cost, schedule.

Influences Estimated influences on contract provisions Price Detailed cost identification and overall summary price of the change Schedule effects Impact on schedule Limitation of use Regarding the intended use (if any) Subcontractor Approval

Names, date and signatures of the relevant subcontractor's authorities

LISA Pathfinder


Page 22 of 24



Annex 2 - Deviation Form Data Requirements

DATA DESCRIPTION Company Identification of the RFD originating organisation RFD N° Unique identification and register number Issue Identification of updated issues Issue Date Issue date of the RFD Project Project under which the nonconforming item will be supplied Contract Contract identification under which the nonconforming item will be

supplied Order Order n° under which the nonconforming item will be supplied Originator site Location of the supplier of the RFD Item designation Identification of the nonconforming item per name and number,

according to its CIDL Model Nonconforming models of the item Affected requirement document

Identification of the requirement specification (number and issue) to which the item does not conform

Short description Title or short description of the deviation Detailed description Description of the deviation against the relevant requirement Reason for request Reason why the proposed deviation can be accepted Adversely affects Item characteristics affected by the deviation Classification Major or Minor as per relevant level CCB decision Signatures Name, date and signature of the relevant level CCB members

LISA Pathfinder


Page 23 of 24



Annex 3 - Deviation Form

Doc. No. /

Request for Deviation Issue:

Project: Date: LISA Pathfinder Sheet: Title: Product Tree Identifier Other systems/configuration items affected

Recurring Deviation Designation

( ) yes ( ) no ( ) yes ( ) no Model (s) : Serial No.: Controlled Documents/Drawings Affected Spec./Drawing Number Issue/Rev. Date Title Appl. para. Effect on Cost/Price Effect on Delivery Schedule Quantity Effect on if approved: Interface, Performance if disapproved: Description Interface Involvement Avionics Payload AIV Justification/Reason Originator: Company/Name Signature: Approval need date: Subcontr. Engineering Date: � a

� d � c

Prod. Assurance Date: � approved �disapproved � cond. appr.

� a � d � c

CMO Date: � a � d � c

Project Manager Date: � approved �disapproved � cond. appr.

� a � d � c

EADS Ast Prod Assurance Date: � a � d � c

EADS Ast Project Manager Date: � approved �disapproved � cond. appr.

� a � d � c

ESA Prod Assurance Date: � a � d � c

ESA Project Manager Date: � approved �disapproved � cond. appr.

� a � d � c

LISA Pathfinder


Page 24 of 24



DOCUMENT CHANGE DETAILS

ISSUE CHANGE AUTHORITY CLASS RELEVANT INFORMATION/INSTRUCTIONS

01 - - Initial Issue

02 S2ca030 Up-issued with minor changes following ITT comments

DISTRIBUTION LIST

INTERNAL

EXTERNAL

Configuration Management