ECSS-Q-70-01A:Cleanliness and Contamination Control

The objective of the new Q-70-01A Standard is to ensure a successful mission by the definition ofacceptable contamination levels for space-system elements, their achievement, and maintenance.

This standard has been prepared by a dedicated Working Group, composed of specialists from thespace agencies and industry, involved in the development of a wide range of products, from smallequipment items to large systems, from electro-optical precision hardware to habitablepressurised cabins. This has ensured the availability of a huge amount of experience andinformation.

Contamination control cannot be applied without knowledge of the “enemy” and how to copewith it. For this reason a lot of informative elements are provided in the standard.They cover thedescription of the main contaminants, their sources and their detrimental effects.

Additionally, “standard” definitions of cleanliness levels both for surfaces andenvironments and at both molecular and particulate levels are provided,including a description of the common methods for cleanlinessmonitoring.

Finally, known methods for contamination removal (cleaning) forthe most common contaminants and some elements ofcontamination modelling methods are also included.

Contents:

ECSS-Q-70-01A: Cleanliness and Contamination Control 1

ECSS E-40B and Q-80B: Software Standards 3

ECSS-Q-70-71: Data for Selection of Space Materials and Processes 9

ECSS and the International Aerospace Quality Group (IAQG) 10

Tell Us What You Think about ECSS! 11

Newly Published ECSS Standards 12

No.8 , April 2005

The actual cleanliness and contamination control programme has then been defined and articulated,in order to cover all the development phases, starting from the design phase, budgeting ofcontamination, control during manufacturing, assembly, integration and test, verification,transportation, storage, launch and mission.

The general space system cleanliness control flow is shown in the above figure. A description of thecontamination-control activities related to each phase of the flow is provided and the relevantrequirements, to be tailored to the specific programme, are detailed in the standard.

Requirements provided in this standard are addressed to standardise the cleanliness andcontamination control process and hence define elements mandatory for the achievement of thegiven objectives.

Annex F of Q-70-01A provides specific requirements for clean rooms, which are derived from currentinternational standards.

The cleanliness and contamination control programme is managed through two essential documents:

• the Cleanliness Requirements Specification (CRS), and

• the Cleanliness and Contamination Control Plan (C&CCP).

Q-70-01A also contains the Document Requirements Definitions (DRDs) for these two documents (seeAnnexes G and H).

2

No. 8

8. Product assurance plan

10. Procurement

15. Bakeout

17. Purging

1. Performance requirements and operational modes

2. Cleanliness oriented design

3. Cleanliness requirements specification

4. Cleanliness and Contami- nation Control Plan

9. Materials, processes and components selection

11. Intermediate cleaning

13. Final cleaning

14. Assembling

16. Integration

18. Tests

19. Launch preparation

24. Launch

25. Mission

5. Cleanliness predictions or modelling

6. Cleanling procedures

7. Cleanliness monitoring procedures

12. Manufacturing process

20. Packing, containerization, transport

21. Packing, containerization, transport

22. Packing, containerization, transport

23. Packing, containerization, transport

ECSS E-40B and Q-80B: SoftwareStandards

European Space SoftwareThe core business is the execution of space programmes including the space segments(spacecraft, launchers and payloads) and the ground segments, comprising all the groundfacilities needed to operate each mission. Software is pervasive throughout the whole “producttree” of any space programme. The space segment has onboard computers, data-handlingsystems and attitude and orbit systems, all of which contain software. The ground segment hasmission-control systems, simulators, flight-dynamics systems, mission-analysis tools, ground-station data systems such as telemetry and telecommand processors and communicationsnetworks, all of which contain software frequently of considerable complexity. In addition, manysimulation, design and testing software tools are used to engineer the segments. Developing andmaintaining this software in a disciplined way is a key to the success of any space mission. Failure todo so can result in expensive delays and, in the worst case, in catastrophic failures. Following propersoftware standards is one of the ways of keeping software development under control and ensuringadequate quality.

The ECSS family of standards includes several documents related to software:

• Two level-2 (branch-specific) documents: “ECSS-E-40B Space engineering – Software” and “ECSS-Q-80B Space product assurance – Software product assurance” have been written by the sameteam and complement each other to cover all the software aspects and make the necessary linksto the relevant standards in their respective branch.

• Three level-3 (technical domain specific) engineering documents: “ECSS-E-40-01 Space segmentsoftware”, “ECSS-E-40-03 Ground segment software”, “ECSS-E-40-04 Software life-cycle”.

• Four level-3 product assurance documents:“ECSS-Q-80-01, Reuse of existing software”,“ECSS-Q-80-02 Software process assessment and improvement”, “ECSS-Q-80-03 Softwaredependability and safety methods and techniques”, “ECSS-Q-80-04 Software metricationprogramme definition and implementation”.

These standards will be available in the near future.They will provide guidance on howto implement a software product-assurance programme compliant with ECSS-Q-80requirements on these specific issues.

The processes applied in space-software development are identified by ECSS-E-40, whose primary input is ISO 12207, which has been instantiated throughECSS-E-40, ECSS-Q-80 and other ECSS standards (e.g. ECSS-M-40 forconfiguration management) for the space domain. ECSS-E-40 definesrequirements for the engineering activities associated with thedifferent software development processes. ECSS-Q-80 containsproduct-assurance requirements relevant to the individualsoftware-engineering processes, as well as to the overallsoftware development. Furthermore, ECSS-Q-80requirements are aimed at ensuring the quality ofboth the development processes and thefinal software products.

3

ECSS-Q-80 and ECSS-E-40 are based on the ECSS customer-supplier concept. This concept may beapplied recursively - as would typically be the case for space projects - with a main customer at the toplevel (typically a space agency, such as ESA, CNES, etc.) and a chain of customer-supplier relationshipsextending downwards, corresponding to the prime contractor and then to the lower levels ofsubcontractors.

Overview of ECSS-E-40BISO 12207 and ECSS-E-40 are based on a defined set of processes. They define requirements on thoseprocesses, including a breakdown into component activities, and their expected inputs and outputs.They are in effect “standards for making standards”. This permits suppliers to use their own standards,provided that they conform to the requirements of ECSS-E-40, or some tailoring of it, defined by thecustomer. This is particularly useful in the European environment where suppliers work for both ESAand national agencies, the ECSS standards providing a common backbone.

At technical level, the reviews are the main interaction points between the customer and the supplier.They complete or synchronize the processes. They have the same name as the satellite reviews, butneed to be synchronized with the system (satellite and ground segment) review in a mannerappropriate for each project (System Requirement Review, Preliminary Design Review, Detailed DesignReview, Critical Design Review, Test Readiness Review, Qualification Review and Acceptance Review).

The following short summary of ECSS-E-40B outlines the required processes, reviews and documentation.

System engineering:This is carried out by the customer and involves activities such as system requirements engineering,system integration, and system validation. It sees the software as part of a system that putsrequirements on it – the surrounding system could be onboard hardware and other software systemsand need not necessarily include a human user. This process is actually the same as the ECSS-E-10(System engineering) process, ensuring a better transition between system and software. It finisheswith the software System Requirement Review.

Software requirements and architecture engineering:This is carried out by the supplier and in essence involves software requirements analysis and softwarearchitectural design. It finishes with the Preliminary Design Review.

Software design and implementation engineering:This is also carried out by the supplier and involves design of software items, coding, unit testing, andintegration testing. It finishes with the Critical Design Review, but may include an intermediate DetailedDesign Review to review the design.

Software validation process:Carried out by the supplier, this includes writing the validation plan for the Preliminary Design Review,validation with respect to the technical specification for the Critical Design Review, and validation withrespect to the requirements baseline for the Qualification Review, carried out in the supplier’senvironment (sometimes referred to as Factory Acceptance Test). A Test Readiness Review mayauthorize each test campaign.

Software verification process:carried out by the supplier, this includes writing the verification plan for the Preliminary Design Review,and carrying the various verification activities throughout the life cycle.

Software delivery and acceptance:This comprises the software delivery and installation by the supplier for Qualification Review andAcceptance Review and the software acceptance for Acceptance Review, carried out in the operational

4

No. 8

environment by the customer. This is sometimes referred to as the Site AcceptanceTest (SAT) and may be preceded by a Preliminary Site Acceptance Test (PSAT).

Software management process:This is an activity of the supplier, who writes the software development plan. In particular,it documents the software life cycle that defines the sequencing and dependency of theprocesses. No particular life-cycle model is imposed, but the selection of the life-cyclemodel is an essential management activity.

Software operations engineering:This comprises preparation of software operations procedures, preparation of plans foroperational testing (i.e. of new releases coming from the maintenance process), softwareoperations proper, and user support – including, for example, a user help desk – what is usuallycalled “first-line support”.

Software maintenance:This comprises writing the maintenance plan, software problem analysis, software problemcorrection (software modification), re-acceptance (i.e. validation of corrections), softwaremigration, and software retirement.The ECSS software maintenance process places emphasis onmigration and retirement and separates first-line maintenance into software operations.

Overview of ECSS-Q-80ECSS-Q-80 belongs to the Product Assurance (“Q”) branch of the ECSS Standards series. The mainobjective of product assurance is to ensure that the space products accomplish their definedmission objectives, and more specifically that they are safe, available and reliable [ECSS-Q-00]. ECSS-Q-80 defines the product-assurance requirements applicable to the development of software forspace systems and applications.

The ECSS-Q-80 structure is based on three main principles, reflected in clauses 5, 6 and 7 of theStandard, summarized below.

Software product-assurance programme implementationRequirements are defined in ECSS-Q-80 for the establishment of a comprehensive and solidproduct-assurance programme for the projects to which the standard is made applicable.This includes:

• identification of resources and responsibilities for the organization in charge of softwareproduct assurance;

• adequate product-assurance planning, control and reporting;

• selection and management of next-level suppliers;

• procurement process;

• selection of development methods and tools.

Requirements are also defined for continuous processassessment and improvement, to be performed by thesupplier, spanning the different projects in whichsoftware development is involved.

5

Software process assuranceIt is largely recognized that a bad process is very unlikely to produce a good product.Therefore, ECSS-Q-80defines requirements applicable to the software development processes.

Product-assurance activities are required to ensure that the software life cycle, selected according to theECSS-E-40 requirements, is suitable for the characteristics of the product to be developed and is thoroughlydefined, including resources,milestones,phase inputs and outputs and consideration of quality objectives.Requirements are set for the timely definition of project plans and procedures, covering, for example,development, configuration management, and verification and validation.

Special emphasis is placed on software dependability (reliability, availability and maintainability) andsafety. The relationships between system- and software-level dependability and safety analyses areidentified, to ensure that the software is duly classified according to its criticality and that this is reflectedin the overall system design.Then, requirements are set for the definition of measures for handling criticalsoftware components.

Other requirements encompassing several development processes concern software configurationmanagement (in addition to the ones defined in ECSS-M-40),process metrics,verification activities,and softwarereuse,the last of which is becoming more and more a matter of concern in space-applications development.

The remainder of subclause 6 of the standard is devoted to the definition of product-assurancerequirements applicable to the individual development processes, such as requirements analysis, design,coding, testing and validation, acceptance, operation and maintenance.

Software product quality assuranceEven if development processes are accurately planned, performed and monitored, the quality of the finalsoftware products has to be defined and evaluated, to ensure that it meets the customer’s requirementsand expectations. ECSS-Q-80 includes a set of requirements specific to the assurance of software productquality, i.e. program code and associated documentation.

The identification of a quality model,consisting of a set of characteristics - such as functionality,reliability andmaintainability - and the relationships between them, is the basis of software product quality assurance.Since the goal characteristics of a quality model often cannot be directly measured, sub-characteristics arederived from them and then measurable quality objectives are set for these sub-characteristics, accordingto the overall system quality requirements.Suitable metrics and a timely metrication programme have to bedefined to support the verification of the achievement of quality objectives.

Software documentationThe ECSS-E-40 and ECSS-Q-80 documentation is arranged in folders in which the various outputdocuments are aggregated. The main folders are: the Requirements Baseline (RB), the TechnicalSpecification (TS), the Design Definition File (DDF), the Design Justification File (DJF), and the ProductAssurance File (PAF). Most of the output of the software product-assurance activities required by ECSS-Q-80 is allocated to the PAF.This includes the Software Product Assurance Plan (SPAP).

The majority of the ECSS-E-40 and ECSS-Q-80 sub-clauses define Expected Output. The sub-clause thenspecifies the destination folders and the milestone review. The expected content of the folders by eachmilestone review is collected in ECSS-E-40, Annex A. Practically, the Expected Outputs are organised intodocuments,and the documents end up in the folders.The structure of the main documents to be includedin these folders is specified in the DRDs (ECSS-E-40 Part 2B, Documents Requirements Definitions). Thecontents of these folders are built up in the course of the project. Part 2B also includes an exhaustiveDocument Requirement List (DRL).

6

No. 8

Applying ECSS software standards to projectsECSS-E-40A introduced the concepts of processes, reviews and folders. An intermediate Draft Bversion of June 2000 mainly added missing activities.The final B version (June 2003), which has beensuccessfully subjected to a public review, is now published. It does not add any activities, butorganizes them in a way that simplifies the access to ECSS-E-40 and its tailoring.

ECSS-Q-80A was published in 1996. After the release of ECSS-E-40A, in 1999, a major effort wasdevoted to moving engineering requirements from ECSS-Q-80 to ECSS-E-40 and to defining theexpected outputs of ECSS-Q-80 requirements. This led to an intermediate Draft B, dated 3 April2000, which was made applicable to several ESA projects. ECSS-Q-80B Draft 1, 22 May 2002, hasbeen successfully subjected to public review. No major changes to the draft standard werenecessary, and ECSS-Q-80B was published on 10 October 2003.

Since 1996, ECSS-E-40 and ECSS-Q-80, in their A version or draft B version, have beensuccessfully applied in a large number of space projects, ranging from full-size satelliteprojects (space science, Earth observation, GalileoSat) and ground-segment projectsat ESOC and ESRIN, to smaller R&D activities, including onboard software, electricalground-support equipment (EGSE), analysis tools (mechanical, thermal, spaceenvironment), and prototypes.

The success in applying ECSS software standards relies on two keyactivities:

• Training the engineers involved: The customer has tounderstand the benefits of the standard and theimplication of the requirements that he imposes onthe supplier. Industry needs to understand the

7

vocabulary and the principles of the ECSS standards, so that they can relate them to their currentpractices and transition in a better way.

• Tailoring the standards to the needs of each project: The full application of the standards can be eitherinappropriate (the project organization does not exactly fit with the process model) or overkill (somerequirements can consume resources without bringing the corresponding added value to the particularproject’s scope and goals).Tailoring is and remains a customer responsibility, to be carried out accordingto the requirements specified in ECSS-M-00-02.

These two key activities for success have been implemented in the following way:

• Training material has been prepared on ECSS-E-40 and ECSS-Q-80.Training has been given to some smalland medium enterprises (SMEs), to Portuguese companies, and it is in the training plan for ESA staff.Furthermore, training has been given to ESOC staff.Training is also offered on a commercial basis by thecompanies that developed the training material.

• ECSS-E-40 tailoring support is organized within ESA’s Software Engineering and Standardisation Section(D-TEC/SWE) for all project managers or industry staff facing their first application of the ECSS-E-40standard. More than 100 tailorings have been performed to date. Guidelines for ESA Technical Officershave been prepared. A supporting tool to guide the tailoring for “small” projects is used at ESTEC(http://www.estec.esa.nl/wmwww/EME/ecss/ecss.htm). Generic tailorings for families of softwareproducts are also in preparation (simulators, thermal tools), in particular at ESOC where other tailoringhas been performed with Excel. The initially often conservative project managers now recognize theusefulness of the exercise.They generally modify their Statement of Work to complement missing tasksor improve the overall vision of their software project.

• There are several drivers for the tailoring of ECSS-Q-80,such as dependability and safety aspects,softwaredevelopment constraints, product quality objectives and business objectives. In addition, the tailoringperformed on ECSS-E-40 for a specific project directly impacts on the application of ECSS-Q-80 to thatproject: if a software process, for instance, is tailored, the product-assurance requirements of ECSS-Q-80relevant to that process become automatically not applicable.

• In addition, for ESOC, where much of ESA’s mission-control software has been developed, the ESA Boardfor Software Standardisation and Control (BSSC) has written the ESA Ground Segment SoftwareEngineering and Management Standard (ESA GS SEMS) to ease the transition from PSS-05.The GS SEMSdocument provides ECSS compliance in the form of a set of practices, and it covers all relevant ECSSstandards in a single (multi-volume) document.This document is currently under review to become thetailoring of ECSS for ESOC’s software development.

ConclusionsThe above has outlined the ECSS-E-40 and ECSS-Q-80 software standards as the result of a major effortperformed by ESA, the national space agencies and Eurospace, with the aim of providing the Europeanspace community with a consistent and comprehensive framework to ensure the quality of softwareproducts for space applications. Also, an intense set of activities within the agencies ensures their smoothintroduction into the procurement of software for both the space segment and the ground segment.Many projects are already using the new standards, and early indications are that the careful preparationof the transition, comprehensive training and systematic tailoring have helped make this transition asmooth one.

8

No. 8

ECSS-Q-70-71: Data for Selection ofSpace Materials and Processes

The purpose of this standard is to assist spacecraft and space-payload designers in theirpreliminary selection and application of both materials and fabrication processes. Lists of well-known materials that are currently available and have been used successfully in past spacecraftprogrammes are provided,together with their general properties and properties relevant to spaceuse such as outgassing-under-vacuum data, UV and particle effects, and, for manned spacestations, their flammability, offgassing and toxicity.

The standard is described as a short guide to a vast subject. It describes the tests that are requiredby ESA for the approval of materials and processes related to the manufacture of spacecraftstructures and their payloads.Spacecraft subsystems must always be electrically grounded to thestructure and this requires that metal-to-metal and metal-to-conductive fibre reinforcedmaterials need to be specially selected to avoid galvanic corrosion (particularly important aslaunch sites such as ESA’s Centre Spatial Guyanais and NASA’s Kennedy Space Center, bothlocated on the coast,are exposed to heavily salt-laden prevailing winds).Similarly,structuralalloys need to possess a high resistance to stress corrosion.During launch,these materialsneed to survive exposure to acoustic noise, vibration and pyrotechnic shocks. Thisstandard then describes all the details,such as optical glasses needing to be assessedfor their resistance to ionising radiation, particles and UV radiation; how lubricantsshould be selected, and how coatings can be degraded by the atomic oxygenthat is present in low Earth orbits (i.e. at altitudes between 200 and 700 km),as shown in the accompanying figures.

An electronic version of this 222-page publication is available free ofcharge from the ECSS web site at: http://www.ecss.nl/standardsafter registration of your name and organisation. Alternatively,hard copies can be requested from ESA PublicationsDivision, ESTEC, 2200 AG Noordwijk, The Netherlandsfor a price of € 30.00.

Scanning Electron Micrographs of silver solar-cell interconnectors returned from active operation in low Earthorbit. These pictures illustrate how atomic oxygen has oxidised the pure silver surface and converted it to silveroxide. The oxide has a lower density than metallic silver and this causes it to continually spall off, so thinning theinterconnector. Eventually this will result in an electrical open circuit.

9

ECSS and the International Aerospace QualityGroup (IAQG)

The ECSS has recently adopted a policy relating to the certification of Quality Management Systems(QMS). This article presents some background to the creation of the policy and the reasoning behindit.

ECSS develops and publishes standards, which define requirements at product/project level. Theserequirements are imposed through the contractual chain on a case-by-case basis, and as such are notthe subject of certification; ECSS does not regard itself in any way as a certification authority. However,Quality Management Systems are developed and implemented to improve the effectiveness andefficiency of organisations, and many companies have already invested in being certified to theinternationally recognised ISO 9001 standard. ECSS recognised the need to reconcile the project-basednature of ECSS standards with the “cross-cutting” character of the QMS approach and established theECSS Audit and Certification Working Group in 1997.

This Working Group proposed a policy in 1998 aimed at recognising the role of the QMS in the spacebusiness, particularly with the opportunity to minimise auditing costs, for the mutual benefit of bothcustomers and suppliers. To fully realise this potential, a special ECSS Working Group was set up toidentify any space-specific supplementary requirements to ISO 9001, which was considered to be toogeneric.The Working Group delivered its recommended ECSS space supplements in 1999, at about thesame time the aerospace industry was developing, through the International Aerospace Quality Group(IAQG), an International Aerospace Quality Standard 9100 by the addition of specific aerospacerequirements to ISO 9001. The recommendations were proposed to AECMA, the body responsible forthe European version of the standard, EN 9100, but were considered too late for publication.

It had been recognised from the outset that the proposed 9100 standard was a suitable basis for thecertification of space companies’ QMS, but it did not reflect adequately the specific spacerequirements, particularly in the areas of dependability, risk management and project management.Representation was made through ISO TC20/SC14 to correct this and IAQG agreed to set up a joint taskforce to develop the relevant requirements. The ECSS created the International Aerospace QualityLiaison (IAQL) Working Group with the objectives of:

• Proposing the ECSS space supplements to AS/EN9100.

• Investigating other quality standards developed by IAQG.

• Possible cooperation on QMS certification.

The space supplements were proposed to the joint task force in 2002, but despite strongrepresentation to have them agreed and adopted, the chairman of the task force made a unilateraldecision that a space addendum was not necessary. However, the process of consultation anddiscussion had raised awareness within IAQG of the need to consider the space sector and a SpaceForum was set up chaired by Roberto Ciaschi of ESA, who also chairs the IAQL WG. In turn, to show itscommitment, the ECSS undertook to recommend AS/EN 9100 as a suitable standard for its membersonce the space supplements were added. This is reflected in the ECSS Policy.

10

No. 8

In November 2003, the IAQL submitted an Evaluation Report which:

• Proposed that a policy established around two main principles:

- endorse 9100 as a suitable QMS standard for organisations running space projects- encourage the achievement and recognition of QMS certification in accordance with

9100.

• Recommended to continue the interaction with IAQG.

These recommendations were accepted and incorporated into the Policy.

The current situation is that a set of space supplements exists and is agreed as suitable forconsideration in the next issue of AS/EN 9100, which might not occur before 2008. However,the team that develops the requirements for the standard have learned a valuable lesson fromthe ECSS and have adopted our proposal on how these requirements should be captured andevaluated, including consideration of some to be proposed for an ISO 9001 update. AllEuropean primes are, or are in the process of becoming, registered to EN 9100.The Space Forumis developing its mission and objectives and the IAQL is in the process of proposing acooperation agreement with the European Aerospace Quality Group (EAQG), the Europeansector of IAQG

In summary, although the space sector has yet to achieve the necessary changes to AS/EN 9100,good working relationships with IAQG and EAQG have been established and the global spacesector has established an excellent forum for the progressing of the space requirements as wellas the exchange of good practice – all initiated by ECSS and its ideal of strengthening the spacesector through active cooperation with all interested parties. For more information on IAQG,AECMA/ASD and IAQL, please refer to the following web sites:http://www.iaqg.sae.org/iaqg/index.htmhttp://www.aecma.org/http://www.asd-europe.org/http://www.ecss.nl/

Tell Us What You Think about ECSS!

ECSS has now reached a stage of maturity and we would like to hear from youabout your experiences with ECSS Standards.

Your feedback will help us to improve the quality of our Standards andprovide a better service to our users. So please send us any comments orsuggestions you have – don't keep it to yourself but tell us.

Use the user-friendly discussion forum on the ECSS website –http://www.ecss.nl/forums/ecss/dispatch.cgi/discussions – toprovide us with your comments (e.g. what's wrong, what'smissing, what's usable or what's not), or to participatein ongoing discussions.

We look forward to your input.

11

Newly Published ECSS StandardsIn addition to the list of Standards published in the last ECSS Newsletter, the followingare now available to be downloaded in PDF format from the ECSS website(www.ecss.nl), or in hardcopy from ESA Publications Division:

P-001B ECSS - Glossary of terms

E-10 Part 1B Space engineering - System engineering - Part 1: Requirementsand process

E-50 Part 1A Space engineering - Communications - Part 1: Principles andrequirements

E-10 Part 6A Space engineering - System engineering - Part 6: Functionaland technical specifications

E-10 Part 7A Space engineering - System engineering - Part 7: Product dataexchange

E-20-08A Space engineering - Photovoltaic assemblies and components

E-40 Part 1B Space engineering - Software

E-60A Space engineering - Control engineering

Q-60-11A Space product assurance - Derating and end-of-life parameterdrifts - EEE components

Q-70-45A Space product assurance - Standard methods for mechanicaltesting of metallic materials

Q-70-09A Space product assurance - Measurement of thermo-opticalproperties of thermal control materials

Q-80B Space product assurance - Software product assurance

Q-70-46A Space product assurance - Requirements for manufacturingand procurement of threaded fasteners

Q-70-71A rev.1 Space product assurance - Data for selection of space materialsand processes

12

No. 8

Published by:ESA Publications Divisionc/o ESTEC, PO Box 2992200 AG NoordwijkThe Netherlands

Editors: Joel Asquier & Bruce BattrickDesign & Layout: Jules Perel