astrium GmbH Change Record - European Space Agencyemits.sso.esa.int/emits-doc/ESTEC/6_CS-RS-DOR-PA-0001_5.pdf · 2010-01-13 · AD14 PSS-01-201 Contamination and cleanliness control

astrium GmbH Change Record CryoSat

Doc. No: CS-RS-DOR-PA-0001 Sheet A-IIssue: Issue 5Date: 17.01.02 File: CS-RS-DOR-PA-0001_5 (PA Req for SUBs).doc

Issue Date Chapter Description of Change Release

Draft 26.05.00 all First draft issue

1 12.10.00 all First issue

2 17.11.00 3.1 "scheduled Peer reviews" replaced by "Peer review"3.6.2 BEO deleted3.6.4 General statement and additional materials added3.6.6 "TML" (Total Mass Loss) replaced by "RML" (Recovery Mass

Loss")3.6.9 Availability of coupon samples modified

3 draft 30.03.01 3.1 "Off-the-shelf" definition added3.4.1 Comments concerning the FMECA added3.5.1 - "Off -the-shelf" definition transferred to 3.1

- reference to proposal evaluation deleted- wording modified

3.5.2.1 Wording adjusted3.5.2.6 Relife criteria modified3.5.3 DCL content modified3.5.4 "Indication of radiation susceptibility shall be ..... " added3.5.4.1 Shielding condition added3.5.6.1 Wording modified3.6 - Reference to ECSS-Q-70 and PSS-01-7xx added

- Wording modified3.6.1 Some materials transferred to 3.6.23.6.2 Materials added from 3.6.13.9.2 - NCR notification modified

- GSE NCR reporting added- Incremental SW NC reporting added

4.2.2.1 - Output from SR phase: "Trace from SW technical spec..." added- SQA Inspection reports shall cover: "traceability of higherlevel requirements" added

4.3.2 SQA Inspection reports shall cover: "branch coverage" &"statistic analysis" added.

4.4.5 Chapter reference changed from 4.3.1.5 to 4.3.4

3 26.06.01 3.5.2.4 New chapter "Wires and Cables" added3.6.4 Ag plating of Cu wires added4 SDR RID-PA-048 incorporated into the S/W PA Requirements

4 11.12.01 2.1 [AD37] MIL-HDBK-217F added (DCM RID-PA-016); Issue Badded to ECSS-Q-80

3.4 MIL-HDBK-217F added for Reliability calculation (DCM RID-PA-016)

3.4.1 "Loss of complete connector" deleted from non-credible failure

astrium GmbH CryoSat

Doc. No: CS-RS-DOR-PA-0001 Page B-IIssue: 5Date: 17.01.02 File: CS-RS-DOR-PA-0001_5 (PA Req for SUBs).doc

1 SCOPE ................................................................................................................. 3

2 DOCUMENTS....................................................................................................... 4

2.1 Applicable Documents........................................................................................................................... 4

2.2 Reference Documents ............................................................................................................................ 5

3 PRODUCT ASSURANCE REQUIREMENTS....................................................... 6

3.1 General Approach ................................................................................................................................. 6

3.2 PA Documentation................................................................................................................................. 7

3.3 Product Assurance Organisation ......................................................................................................... 7

3.4 Design Assurance................................................................................................................................... 83.4.1 Design for Fault Tolerance .............................................................................................................. 83.4.2 Peer Reviews ................................................................................................................................... 93.4.3 EEE Parts Derating........................................................................................................................ 103.4.4 Worst Case Analysis ...................................................................................................................... 11

3.5 EEE Parts ............................................................................................................................................. 113.5.1 General Aspects ............................................................................................................................. 113.5.2 EEE Parts Selection and Quality.................................................................................................... 11

3.5.2.1 Standard Parts ............................................................................................................................ 113.5.2.2 Non-standard Parts / Parts with lower Quality level .................................................................. 123.5.2.3 Parts Approval Document (PAD) .............................................................................................. 123.5.2.4 Wires and Cables ....................................................................................................................... 123.5.2.5 Components requiring specific authorisation............................................................................. 123.5.2.6 Destructive Physical Analysis (DPA) ........................................................................................ 133.5.2.7 Stock Parts ................................................................................................................................. 133.5.2.8 Lot Acceptance Tests (LAT) ..................................................................................................... 143.5.2.9 Pre-cap Inspection ..................................................................................................................... 143.5.2.10 Special Parts Requirements ...................................................................................................... 14

3.5.3 Declared Component List (DCL)................................................................................................... 143.5.4 Radiation Tolerance....................................................................................................................... 15

3.5.4.1 Total Dose ................................................................................................................................. 153.5.4.2 Displacement Damage ............................................................................................................... 153.5.4.3 Single Event Effects (SEE)........................................................................................................ 16

3.5.4.3.1 Single Event Upset (SEU) ................................................................................................... 163.5.4.3.2 Single Event Latch-Up (SEL) .............................................................................................. 173.5.4.3.3 Single Event Burnout (SEB) & Single Event Gate Rupture (SEGR)................................... 17

3.5.5 GIDEP and ESA Alerts ................................................................................................................. 173.5.6 EEE Parts Procurement.................................................................................................................. 17

3.5.6.1 Parts Attrition ............................................................................................................................ 183.5.6.2 Spare Parts ................................................................................................................................. 18


Doc. No: CS-RS-DOR-PA-0001 Page B-IIIssue: 5Date: 17.01.02 File: CS-RS-DOR-PA-0001_5 (PA Req for SUBs).doc

3.5.6.3 Procurement Status Reporting ................................................................................................... 18

3.6 Materials Selection and Processes Controls ...................................................................................... 183.6.1 Prohibited Materials ...................................................................................................................... 193.6.2 Materials Restrictions .................................................................................................................... 193.6.3 Magnetic Materials ........................................................................................................................ 203.6.4 Plating / Corrosion......................................................................................................................... 203.6.5 Radiation Sensitive Materials ........................................................................................................ 203.6.6 Outgassing ..................................................................................................................................... 203.6.7 Limited Life ................................................................................................................................... 203.6.8 ATOX Vulnerable Materials ......................................................................................................... 203.6.9 PCB Coupon Testing ..................................................................................................................... 213.6.10 Certification and Traceability ........................................................................................................ 213.6.11 Procurement of Materials and Mechanical Parts ........................................................................... 21

3.7 Processes Selection............................................................................................................................... 213.7.1 Surface Mounting Technology (SMT)........................................................................................... 213.7.2 Declared Materials and Processes Lists ......................................................................................... 22

3.8 Safety Assurance.................................................................................................................................. 223.8.1 Policy and Management................................................................................................................. 223.8.2 Program Content............................................................................................................................ 22

3.8.2.1 Hazard Analysis......................................................................................................................... 233.8.2.2 Safety Trade-Off Studies / Hazard Reduction............................................................................ 233.8.2.3 Safety Testing ............................................................................................................................ 243.8.2.4 Safety Documentation................................................................................................................ 243.8.2.5 Training ..................................................................................................................................... 243.8.2.6 Accident/Incident Reporting...................................................................................................... 24

3.9 Non Conformances Handling and Reporting.................................................................................... 253.9.1 Non Conformance Reporting Process............................................................................................ 253.9.2 Notification.................................................................................................................................... 253.9.3 Failure Analysis Requirements ...................................................................................................... 263.9.4 Corrective Action Verification ...................................................................................................... 26

3.10 Critical Items Control ......................................................................................................................... 26

3.11 Hardware Quality Assurance ............................................................................................................. 27

3.12 Subcontractor QA Programs and Processes ..................................................................................... 27

3.13 Workmanship....................................................................................................................................... 27

3.14 Contamination Control, Mechanical and Electrical Equipment ..................................................... 27

3.15 Contamination Control, Optical Equipment..................................................................................... 28

3.16 Inspection, Testing and Controls........................................................................................................ 283.16.1 Planning......................................................................................................................................... 28


Doc. No: CS-RS-DOR-PA-0001 Page B-IIIIssue: 5Date: 17.01.02 File: CS-RS-DOR-PA-0001_5 (PA Req for SUBs).doc

3.16.2 Test Facility Control ...................................................................................................................... 293.16.3 Post Test Hardware Inspection ...................................................................................................... 293.16.4 Non-conforming Material Control ................................................................................................. 293.16.6 Hardware Delivery Reviews .......................................................................................................... 293.16.7 Acceptance Data Package (ADP) .................................................................................................. 29

3.17 Handling and Transportation............................................................................................................. 29

3.18 Ground Support Equipment............................................................................................................... 303.18.1 Transport Boxes and Packing Material.......................................................................................... 303.18.2 GSE Acceptance Data Package (ADP).......................................................................................... 30

4 ONBOARD SOFTWARE PRODUCT ASSURANCE REQUIREMENTS ............ 31

4.1 General ................................................................................................................................................. 314.1.1 Applicability .................................................................................................................................. 314.1.2 Interfaces with Other Disciplines................................................................................................... 314.1.3 Responsibilities.............................................................................................................................. 31

4.2 Requirements on Management and Framework............................................................................... 314.2.1 Organisation and Responsibility .................................................................................................... 31

4.2.1.1 Responsibility and Authority ..................................................................................................... 324.2.1.2 Resources................................................................................................................................... 324.2.1.3 Software Product Assurance Management................................................................................. 32

4.2.2 Software Product Assurance Planning and Control ....................................................................... 324.2.2.1 Software Product Assurance Reporting ..................................................................................... 334.2.2.2 Audits......................................................................................................................................... 334.2.2.3 Non-Conformances .................................................................................................................... 334.2.2.4 Software Problems..................................................................................................................... 33

4.2.3 Risk Assessment and Critical Item Control ................................................................................... 334.2.3.1 Risk Assessment ........................................................................................................................ 334.2.3.2 Critical Items Control ................................................................................................................ 34

4.2.4 Subcontractor Control.................................................................................................................... 34

4.3 Requirements on Life–Cycle Activities and Processes...................................................................... 344.3.1 Software Requirement Engineering Process .................................................................................. 344.3.2 Design Engineering Process .......................................................................................................... 364.3.3 SW Validation and Acceptance Process ........................................................................................ 374.3.4 Operations and Maintenance Process ............................................................................................ 384.3.5 Incremental / early SW delivery .................................................................................................... 39

4.4 Requirements Applicable to All Life–Cycle Processes ..................................................................... 394.4.1 Process Documentation.................................................................................................................. 394.4.2 Software Dependability for Critical Functions .............................................................................. 404.4.3 Non - critical Software................................................................................................................... 404.4.4 Software Configuration and Documentation Management ............................................................ 41

4.4.4.1 Change Control .......................................................................................................................... 414.4.4.2 Software configuration management tool .................................................................................. 41


Doc. No: CS-RS-DOR-PA-0001 PageB-IVIssue: 5Date: 17.01.02 File: CS-RS-DOR-PA-0001_5 (PA Req for SUBs).doc

4.4.4.3 Control of documents................................................................................................................. 414.4.4.4 Protection and marking.............................................................................................................. 42

4.4.5 Re–used Software .......................................................................................................................... 424.4.6 Regression testing.......................................................................................................................... 43

4.5 Requirements on Product Quality...................................................................................................... 434.5.1 Product Quality Objectives and Metrication................................................................................. 43

4.5.1.1 Product and process quality objectives ...................................................................................... 434.5.1.2 Software Product Metrics .......................................................................................................... 444.5.1.3 Software Process Metrics .................................................................................................................. 444.5.1.4 Numerical accuracy ................................................................................................................... 44

4.5.2 Supporting Documentation ............................................................................................................ 444.5.3 Purchased Software ....................................................................................................................... 45

4.6 QUALITY ASSURANCE FOR GROUND SUPPORT EQUIPMENT........................................... 45

5 PA DOCUMENT REQUIREMENT LIST ............................................................. 47


Doc. No: CS-RS-DOR-PA-0001 Page 2Issue: 5Date: 17.01.02 File: CS-RS-DOR-PA-0001_5 (PA Req for SUBs).doc



1 SCOPE

The Product Assurance Requirements for Subcontractor defines the (PA) policy objectives,principles and rules for the implementation of a PA program for the CryoSat spacecraft and relatedGround Support Equipment covering design, development, production and operations.

The PA discipline covers: PA management, Quality Assurance, Safety Assurance, ReliabilityAssurance, Software Product Assurance, EEE Components, Materials, Mechanical Parts andProcesses. It defines their respective objectives, policies, requirements and implementationstandards to achieve the stated overall PA objectives throughout the complete life cycle of theproducts.

These requirements are based on the ESA CryoSat PA Requirements CS-RS-ESA-PA-0007 issue1.

In general the requirements explicitly specified in this document have to be met by thesubcontractor, on which he shall base his compliance matrix. The documents listed in chapter 2.1"Applicable Documents" provide rules for activities, which shall be used as guideline in case notspecified in the CryoSat PA requirements for subcontractor, or if referenced in the individualchapters of this document.



2 Documents

2.1 Applicable Documents

This Document incorporates by dated or undated reference, provisions from the other publications.These normative references are listed hereafter. For undated references the latest edition of thepublication referred to apply.

AD01 CS-LI-DOR-SY-0015 CryoSat general supporting information

AD02 CS-RS-DOR-PM-0001 Subcontractor Management Requirements for Phase C/D

AD03 ECSS-Q-00 Policy and principals

AD04 ECSS-Q-20 Quality assurance (as tailored herein)

AD05 ECSS-Q-20-09 Non-conformance control system (as tailored herein)

AD06 ECSS-Q-40 Safety (as tailored herein)

AD07 ECSS-Q-30 Dependability (as tailored herein)

AD08 ECSS-Q-30-02 Failure Modes, Effects and Criticality Analysis

AD09 ECSS-Q-60 EEE Components (as tailored herein)

AD10 ECSS-Q-70 Materials, mechanical parts and processes (as tailoredherein)

AD11 ECSS-Q-70-36 Materials selection for controlling stress corrosioncracking

AD12 ECSS-Q-70-37 Determination of susceptibility of metals to stresscorrosion cracking

AD13 ECSS-Q-80B Software quality assurance (as tailored herein)

AD14 PSS-01-201 Contamination and cleanliness control

AD15 PSS-01-202 Preservation, storage, handling and transportation of ESAspacecraft hardware.

AD16 PSS-01-203 Quality assurance of test houses for ESA spacecraft andassociated hardware

AD17 PSS-01-204 Particulate contamination control in clean rooms byparticle fall-out measurement.

AD18 PSS-01-301 Derating Requirements

AD19 PSS-01-403 Hazard analysis requirements and methods

AD20 PSS-01-608 Generic Specification for Hybrid Microcircuits(or MIL-PRF-38534)

AD21 PSS-01-700 The technical reporting and procedures for materials andprocesses.



AD22 PSS-01-701 Data for selection of space materials

AD23 PSS-01-702 A thermal vacuum test for the screening of spacematerials

AD24 PSS-01-706 The particle and ultraviolet (UV) radiation testing of spacematerials

AD25 PSS-01-708 The manual soldering of high reliability electricalconnections.

AD26 PSS-01-710 The qualification and procurement of two-sided printedcircuit boards (fused tin-lead or gold –plated finish)

AD27 PSS-01-726 The crimping of high reliability electrical connections

AD28 PSS-01-728 The repair and modification of printed circuit boards andsolder joints for space use.

AD29 PSS-01-738 High reliability soldering for surface-mount and mixedtechnology printed circuit boards.

AD30 MIL-HDBK-5 Metallic materials and elements for aerospace vehiclestructures.

AD31 ISO 9001 Quality Systems: Model for Quality Assurance inDesign/Development, Production, Installation andServicing

AD32 ISO 9002 Quality Systems: Model for Quality Assurance inProduction and Installation

AD33 ISO 9003 Quality Systems: Model for Quality Assurance in FinalInspection and Test

AD34 CS-LI-DOR-SY-0014 Document Requirement Description

AD35 ECSS-E-40 Space Engineering - Software

AD36 CS-TN-GMV-SY-002 CryoSat Radiation Environment Analysis

AD37 MIL-HDBK-217F Reliability prediction of Electronic Equipment

2.2 Reference Documents

RD01 ISO 9126 "Information technology - software product evaluation -quality characteristics and guidelines for their use"



3 Product Assurance Requirements

3.1 General Approach

The Product Assurance (PA) approach for the CryoSat Project is ‘tailored-to-cost’.It is well understood that reducing formality to the essential extent shall result in significant costsavings without jeopardising the high level of quality and reliability of CryoSat.

PA activities shall be performed in accordance with the following rules:

• The subcontractor PA manager shall perform formal control and supervision of the CryoSat PAtasks. As an independent member of the CryoSat project team, the PA manager shall provide asingle point of contact and shall be responsible for all PA tasks in the frame of the CryoSatcontract.

• The PA manager shall perform the PA tasks in close co-operation with the customer’s ProjectManager and PA Manager.

• Each CryoSat subcontractor shall be responsible for the timely and adequate execution of thePA tasks. He shall clearly demonstrate to the PA Manager and /or the supporting AstriumGmbH PA engineers that the system or unit conforms to the applicable PA/QA requirements.This demonstration shall be given during the “Peer Review".

• All deliverable documents and all additional PA relevant (e.g. analyses, NCR's, waivers,inspection reports, etc.) shall be signed by the subcontractor engineering, the subcontractor PAManager and the subcontractor Project Manager.

• Personnel from the Product Assurance Department shall be involved for tasks which requiremore detailed or specific knowledge (for example parts, materials and workmanshipexpertise).This involvement shall be initiated and co-ordinated by the Project PA Manager orthe Project Manager

• Existing PA management policies, forms, processes and procedures as available through theISO 9001 quality management system shall be utilised, whenever commensurate with the ESAECSS system and the CryoSat project constraints.

• Communication and database tools, commonly available to all involved parties, shall be used toan extent commensurate with the CryoSat needs and constraints. Transmission of documentson paper shall be restricted to those that require the approval of the prime contractor.

• The CryoSat team members from ASTRIUM GmbH and ESA shall have access tosubcontractor manufacturing facilities where project work is being performed on hardware orsoftware for the CryoSat project.

• Audits of PA/QA processes, procedures, records and analyses shall be conducted atsubcontractor facilities as deemed necessary by ASTRIUM GmbH PA, or as requested by ESA.



The term "Off-the-shelf" (OTS) is used in this document in the sense, that the design of anequipment including S/W is existing and this design has already been built and qualified for otherspace programs (Category A acc. SOW).

3.2 PA Documentation

PA documentation is necessary to:

• control product design, procurement, storage, manufacturing, inspection, test, packaging anddelivery.

• audit the effectiveness of the PA programme• ensure that sufficient evidence is provided to demonstrate that the product conforms to the

system requirements

Subcontractor design and manufacturing standards and procedures as well as the relevant PAdocumentation (see Document Requirement List § 5) will be accepted, if the specific CryoSatproject requirements are met.

Each subcontractor shall provide a compliance matrix (DRD-PA-01) to this CryoSat PArequirements for subcontractor document. All non-compliance's shall be identified and described indetail.

3.3 Product Assurance Organisation

In order to ensure effective product assurance management for the CryoSat project, a ProjectProduct Assurance Manager has to be appointed from the PA Department and he shall report tothe Project Manager as a member of the Project Management Team and in parallel to theCompany Product Assurance Manager.

The Project Product Assurance Manager shall be directly supported in his tasks by a team ofnominated engineers in each of the functional disciplines of Product Assurance. The engineersshall be authorised by the PA manager to manage their activity in assuring that the particularcontractual requirements are met.

The subcontractor project team organisation shall clearly identify the reporting channels by whichthe PA responsible has unimpeded access to levels of management above that of the projectmanager.



3.4 Design Assurance

Reliability engineering and analysis shall be provided by the appropriate engineers in close co-operation with PA specialists. This proceeding shall ensure that reliability is built into the flighthardware design and that it is consistent with the equipment requirements and objectives.Reliability is assured by design and proven by early analysis of this design as specified hereafterand qualification testing of the manufactured hardware. Reliability of electronic andelectromechanical components shall be proven during peer reviews. The reliability calculation shallbe based on MIL-HDBK-217F.

3.4.1 Design for Fault Tolerance

The CryoSat H/W and S/W shall be designed to be tolerant against one credible failure. This hasto be analysed by the FMECA (DRD-PA-05). The following failures are considered as non-credible, that need not to be analysed:

• Fracture/Detaching of structure elements• Rupture of tubing and pressure vessels• Harness failures• Short circuit of metal film and metal oxide film resistors• Short circuit of fixed wire wound resistors• Permanent short circuit of metallized plastic foil capacitors (MKTS)

Connector failure shall be analysed only, where nominal and redundant functions are on the sameconnector.

The failure events shall be classified on the basis of the severity of their consequences, accordingto the following scale:

Catastrophic:

• Loss of life, life threatening or permanent disabling• Occupational illness• Loss of launch site facility/launcher/spacecraft• Loss of ground systems/facilities• Loss of private or public property• Long term detrimental environmental effects

Critical:

• Temporarily disabling (not life threatening injury)• Temporarily occupational illness• Major damage to launch site facility/launcher/spacecraft• Major damage to ground systems/facilities• Major damage to private or public property• Short term detrimental environmental effects• Degradation of mission performance

Major:



• Degradation of mission performance

Minor:

• Other

For the failure "degradation of mission" the acceptable failure tolerance has to be agreed on acase-by-case basis depending on the severity of the degradation.

All equipment shall be designed to ensure full operability upon power up. Internally redundant unitsshall be cross-strapped within the onboard data handling subsystem and the interconnecting databus. Failure propagation shall be limited to the affected module. Inputs and outputs shall be shortcircuit resp. overcurrent and overvoltage protected. No spacecraft redundant functions shall belocated in the same part cavity. If redundant functions are located in the same box, failurepropagation to the redundant function shall be avoided e.g. by excessive thermal stress. Ifredundant signals or power are routed via the same connector, at least one either grounded orunused pin shall separate both lines. Utmost care shall be taken in case of necessary separatepowering/unpowering of circuit sections embedded in a CMOS environment. In such cases it ismandatory to switch on/off all signal lines, too, in order to avoid powering via the CMOS internalprotection devices.

3.4.2 Peer Reviews

Peer Reviews will be performed to reduce the effort of formal issuing and maintenance of designanalysis documents. The intention is to investigate the design of electrical and mechanical unitswith respect to parts stress, parts derating, worst case circuit margins, radiation effects (TotalDose, Single Event Effects), failure tolerance, design margins, critical items etc by means of asingle “expert working meeting”. The review board shall consist of disciplines dedicated PA andengineering experts from the subcontractor and ASTRIUM GmbH. In order to accelerate theconclusions and common agreement process on such reviews, ESA shall be asked to participateand help with their expertise.

Although the FMECA, the Critical Items List and the Hazard Analysis shall be subjects of the peerreview, it is mandatory to formally issue the FMECA and the Residual Hazard Sheets, becausethis documentation shall be used at system level throughout the project. The FMECA may also benecessary for failure recovery during in-orbit operation of CryoSat.

All remaining analysis work, discussed and commonly agreed in such a Peer Review, shall bereported in form of MOMs. Any action items resulting from these reviews have to be closed beforedelivery of the units to ASTRIUM GmbH.

• Peer reviews shall be performed at the supplier’s site.• Peer reviews shall be held as soon as the design is established and not later than 3 months

prior to units delivery to ASTRIUM GmbH (For SIRAL: during SIRAL CDR).• Advance copies of background documentation shall be delivered to ASTRIUM GmbH and ESA

no later than one week prior to the peer review.

The subcontractor shall provide suitable data in order to justify his design. The review shall focuson critical areas. Circuit diagrams, detailed drawings etc. shall be used for discussion, but are



considered proprietary information and are not deliverable except to ESA as a non-commercialagency, upon request. In such cases ESA shall undertake not to disclose the information to anythird party, i.a.w. the ESA general clause and condition.

Unit design engineering and PA shall support the peer reviews by providing:

• Documentation of the methodology, applicable databases, guidelines and results of allrequired analyses

• A list of Single Point Failures and rationales for their retention• A Critical Items List providing rationales and means for compensation• EEE-Parts derating verification• Worst Case Analysis results (if requested by ASTRIUM GmbH to perform this analysis)• Current Schematics/Drawings• Parts List /Materials/Processes List• Documentation of heritage and a list of changes to the heritage design or the design

requirements.• In addition for OTS equipment the qualification programme plan and qualification test reports

During this peer review the subcontractor shall demonstrate to ASTRIUM GmbH and ESA PeerReviewers that the unit design meets the relevant unit requirements.

All review members shall be prepared to:

• Show compliance with parts derating standards by discussing EEE Parts Stress.• Demonstrate, if so requested, adequate circuit design margins by discussing Worst-case

Circuit Performance or the results of Margin Testing / Simulation (accounting for worst caseoperating and environmental conditions, and failure conditions under which the circuit isrequired to operate).

• Show compliance with the fault tolerance requirements.• Show compliance with the requirement to operate successfully in the radiation environment

that shall be experienced by the CryoSat spacecraft by discussing Radiation Effects Analysis(Total Dose, Single Event Effects, etc,)

• Show compliance with the EEE Parts quality level requirements• Demonstrate successful control of critical items• Demonstrate for mechanical equipment adequate design margins, use of qualified materials

and application of suitable processes.• Demonstrate elimination or effective control of hazards

3.4.3 EEE Parts Derating

Derating Requirements and Application Rules for Electronic Components (ESA PSS-01-301 orother space standards e.g. MIL-STD-1547) shall be followed in the design of CryoSat Subsystems.If for OTS equipment, other derating rules (e.g. in-house standards) have been followed, theserules shall be checked against the minimum requirements of ESA-PSS-01-301 or MIL-STD 1547for compliance. Any deviations are subject to approval by ASTRIUM GmbH.

For new equipment it shall be planned to implement derating during computer aided design andcircuit simulation activities. Therefore Derating Analysis results shall be available in implicit



electronic form and may be reviewed by ASTRIUM GmbH specialists during the Peer Reviews. Itis not intended to require the detailed Derating Analysis as a deliverable document. However, anevaluation report shall be issued, summarising the results and demonstrating that derating hasbeen implemented in compliance with a.m. rules.

3.4.4 Worst Case Analysis

In parallel to new design and development activities a worst case analysis (DRD-PA-06) shall beperformed, if deemed necessary by ASTRIUM GmbH PA, for critical electronic equipment. It shalltake into account worst case conditions for EEE parts parameter changes due to environmentalinfluences such as radiation exposure and parameter degradation due to drift during storage andoperational life time of those parts.

The parameter changes specified in PSS-01-301 shall be taken as guideline. Manufacturer’s datamay be used instead, if appropriate.

3.5 EEE Parts

This section defines the CryoSat Project Parts requirements and implementation plan.

3.5.1 General Aspects

ASTRIUM GmbH PA will perform an intensive control function on the subcontractor w.r.t. EEEparts quality and suitability. Intermediate supervision will be done by ASTRIUM GmbH duringreviews.

3.5.2 EEE Parts Selection and Quality

All EEE Parts, whether inherited or new, shall be selected in accordance with the criteria describedin this section. Where possible, preference shall be given to existing (heritage) parts as long asthese parts satisfy the requirements identified in this document.

3.5.2.1 Standard Parts

Parts used in the design of the CryoSat spacecraft shall preferably be taken from a valid QualifiedParts List (QPL) or Preferred Parts List (PPL) such as from ESA, NASA, MIL, or CNES.

The minimum quality requirements for EEE Parts shall be:

� Integrated Circuits MIL-PRF-38535, class Q or ESA-SCC 9000, level C� Hybrids MIL PRF-38534, class H or ESA PSS-01-608� Discrete MIL-PRF-19500-JAN TXV or ESA SCC 5000, level C� Passive ER-MIL, failure rate M (exponential law), or failure

rate B (Weibull law) or CECC generic spec class B� Relays MIL-R-39016 or ESA-SCC level B



� Connectors MIL-C-xxxxxx or ESA-SCC level B� Printed Circuit Boards MIL-PRF-55110, MIL-P-50884, or ESA PSS-01-710

Parts taken from a valid QPL or PPL and screened compliant to the above requirements areconsidered “standard parts” and need no further parts quality evaluation activities.

3.5.2.2 Non-standard Parts / Parts with lower Quality level

If, e.g. for OTS equipment, functional, performance or schedule reasons, it is not possible to meeta.m. parts quality requirements, lower quality level parts may be used or parts may be selectedfrom a source, different from those listed in chapter 3.5.2.1. Such parts require a specialevaluation program covering the following:

� construction analysis� manufacturer and manufacturing line validation� part characterisation� radiation characterisation on flight lot basis

The use of such parts shall be identified in the DCL supplied to ASTRIUM GmbH and ESA. Suchparts or parts families shall be traced under critical items control until a successful completion ofthe unit qualification test. For non-standard parts the unit subcontractor has to provide a PartsApproval Document (see chapter 3.5.2.3)

3.5.2.3 Parts Approval Document (PAD)

Parts Approval Document (DRD-PA-09) shall not be issued for standard parts as defined inchapter 3.5.2.1. For non-standard parts, a PAD sheet has to be issued by the subcontractor andsent to ASTRIUM GmbH and ESA for approval. The suitability of non-standard parts will bechecked in a joint effort between unit supplier, ASTRIUM GmbH and ESA preferably during thepeer review, but latest before EEE parts ordering. Alternative part types or additional screeningmay be required if a non-standard part is considered unsuitable and / or unreliable w.r.t. theCryoSat needs.

3.5.2.4 Wires and Cables

For unit internal and external harness, only space qualified wires and cables shall be used. Copperwires shall have a minimum of 2µm silver plating.

3.5.2.5 Components requiring specific authorisation

Use of components with the following characteristics shall be prohibited except where specificallyagreed on case–by–case basis:

a. Limited lifeb. Known instabilityc. May cause a safety hazardd. May create a reliability risk



EXAMPLE:

- Plastic encapsulated semiconductors- Components containing the following materials:

Beryllium oxide (except if the health and safety hazardsare identified in the specification)CadmiumLithiumMagnesiumRadioactive materialPure tin (electroplated or fused)

- Hollow core resistors- Potentiometers- Non–metallurgically bonded diodes- Non–solid tantalum capacitors with silver case- Dice with no glassivation- Unpassivated power transistors- Wet slug tantalum capacitors (except for CLR79 construction

using double seals and a tantalum case)- Any component whose internal construction uses metallurgic bonding with a melting

temperature not compatible with the end–application mounting conditions- Wire link fuses

3.5.2.6 Destructive Physical Analysis (DPA)

A DPA is generally not required for standard parts. For non-standard parts a DPA may berequested on a case by case basis by ASTRIUM GmbH / ESA pending e.g. on the construction,complexity etc of the part. This shall be identified in the relevant PAD sheet.

3.5.2.7 Stock Parts

EEE parts from stock to be used for CryoSat shall have been stored under controlled conditionsduring the entire storage period. Such parts, having a lot date code that is older than 6 years thefollowing inspections/tests have to be performed:

- visual inspection on sample basis (AQL 0,65, level II)- 100% electrical test on ageing sensitive parameters as defined in ESA PSS-01-301 or

MIL-STD-1547 (AQL 0,65, level II)- hermeticity test for cavity parts (AQL 0,65, level II)



3.5.2.8 Lot Acceptance Tests (LAT)

LAT/QCI is not required for standard parts, unless specifically required by the procurementspecification. For all non-standard parts the LAT/QCI requirement will be defined on a case-by-case decision during the parts approval process. The LAT/QCI requirement shall be identified onthe relevant PAD.

3.5.2.9 Pre-cap Inspection

Pre-cap inspection is not required for CryoSat

3.5.2.10 Special Parts Requirements

• Connector Saver shall be procured according to the same or equivalent quality standard asapplied for the connector for which the saver will be used.

• Traceability of Hybrid add-on parts shall be provided (type & manufacturer). The add-on partsshall have the same or better quality level as specified for the hybrid.

3.5.3 Declared Component List (DCL)

All EEE parts needed for the flight equipment shall be listed in the DCL. ASTRIUM GmbH willreview this list in order to identify any parts, which do not comply with the CryoSat requirements.Each subcontractor shall maintain this DCL up-to-date. ASTRIUM GmbH and ESA approval isrequired. The list shall contain the following information:

0) Family Code acc. ESA Standard1) Part Name / Type / Value2) Part Manufacturer3) Description4) Package5) Quantity per board/equipment (optional)6) Procurement Specification (include. issue/revision)7) Quality level8) Reference to qualification/heritage (ESA/SCC, MIL, other successful program)9) Up-screening requirements10) Comments11) Radiation hardness (Total Dose, SEU, SEL, SEGR)12) PAD reference for non-standard parts



3.5.4 Radiation Tolerance

The CryoSat orbit is at an altitude of approximately 720 km. This orbit will expose the spacecraft tothe geomagnetic field and charged particles, consisting mostly of electrons.In addition, the spacecraft will pass through the South Atlantic Anomaly, where high fluxes ofprotons are present. All electronic parts shall be assessed for their suitability w.r.t the radiationenvironment. The radiation environment is given in the respective tables of the CryoSat RadiationEnvironment Analysis [AD36]. Indication of radiation susceptibility shall be given in the parts list.

3.5.4.1 Total Dose

The estimated worst case total dose accumulated on electronic components inside the spacecraftis 20 krad (Si) including a safety factor of 2. This assumes an equivalent aluminium shielding of3.0 mm (1 mm spacecraft, 2 mm box). For units where this shielding condition is guaranteed, thefollowing rules for the selection of EEE parts shall be applied:

� All EEE parts to be used for CryoSat shall withstand a total dose of 20 Krad (Si) as a minimum.

� Parts, which are susceptible to less than 20 Krad (Si), are subject to ASTRIUM GmbHauthorisation. A justification for the use of such parts and a detailed analysis has to beperformed. Spot shielding may be required.

� If the part’s radiation tolerance is between 20 Krad (Si) and 30 Krad (Si), radiation tests shallbe performed on a lot by lot basis.

� Parts, which are radiation tolerant above 30 Krad (Si), shall not be submitted to radiationtesting but radiation test data must be available.

� Parts which are radiation hard above 100 Krad (Si) are accepted without radiation lotverification if used inside closed boxes with a minimum box shielding of 1 mm Al equivalent.

For units which provide less then 3,0 mm equivalent aluminium shielding (1 mm spacecraft, 2 mmbox), a radiation sectoring analysis has be provided by the subcontractor in order to define therequired total dose level of the EEE parts. The safety factor of two must be guaranteed.

3.5.4.2 Displacement Damage

Protons and electrons, which are both present in the natural space environment, causedisplacement damage in addition to ionisation damage. The most sensitive parts are linearintegrated circuits, optocouplers, some types of optical sources, and optical detectors.

All flight parts shall be intrinsically tolerant to a displacement damage at a radiation level asspecified in the respective tables of the CryoSat Radiation Environment Analysis.Exceptions shall be permitted in those cases where additional shielding lowers the radiationenvironment such that the part’s intrinsic radiation-tolerance is at least twice the radiation at thepart location (i.e. the radiation design margin RDM >= 2). Total integral fluence of particles externalto the spacecraft is given in the respective tables of the CryoSat Radiation Environment Analysis[AD36].



3.5.4.3 Single Event Effects (SEE)

Any single particle strike in electronics devices may induce a measurable effect on the componentfunction. SEEs can be induced by heavy ions (solar events and galactic cosmic rays), protons(trapped and solar events) and neutrons (generated by protons interacting with spacecraftshielding or the atmosphere).

Single event effects for the CryoSat mission may occur predominately in two regions. In the SAAdue to trapped protons and during passes over the poles due to heavy ions in the galactic cosmicray background and particles from solar events. The CryoSat orbit will experience only intermittentgeomagnetic shielding from interplanetary radiation. Peak and geomagnetically shielded (orbital-averaged) particle fluxes are as specified in the CryoSat Radiation Environment Analysis [AD36].

The spacecraft shall be designed to tolerate proton and heavy ion induced SEEs. Parts subject toSEE shall be analysed and/or tested for latchup and/or SEU. Where EEE parts are not compliantwith the radiation requirements specified in this section, the design must compensate for ortolerate the effects. Compensation may include changes to further radiation hardness orautonomous software recovery methods.

If a device is not immune to SEEs, analysis for SEE rates and effects shall be performed based onLETth of the candidate devices as follows:

Device Threshold Environment to be AssessedLETth < 12 MeV*cm2/mg Cosmic Ray Heavy Ions, Trapped

Protons, Solar Proton EventsLETth = 12-100 MeV*cm2/mg Galactic Cosmic Ray Heavy Ions,

Solar Heavy IonsLETth > 100 MeV*cm2/mg No analysis required

Table 3.4.6: Analysis Classification for devices vulnerable by SEEs

3.5.4.3.1 Single Event Upset (SEU)

An energetic particle such as a cosmic ray or proton induced in a device may change the state ora transient. This may occur in digital, analog, and optical components or may have effects insurrounding interface circuitry. These are soft errors in that a reset or rewriting of the devicecauses normal device behaviour thereafter.

The EEE parts shall be evaluated to withstand a LET of 30 MeVcm2/mg. Where this requirementcan not be met, the sensitive EEE parts shall be able to self-recover autonomously from a SEU.The equipment manufacturer shall demonstrate the improvement of the SEU tolerance.



3.5.4.3.2 Single Event Latch-Up (SEL)

A single event latch-up causes loss of device functionality due to a single event, induced highcurrent state. A SEL may or may not cause permanent device damage, but requires overcurrentsensoring and power strobing of the device to resume normal device operations.Microcircuits containing CMOS technologies shall be procured/evaluated to withstand aLET of 60 MeVcm2/mg without latchup.

3.5.4.3.3 Single Event Burnout (SEB) & Single Event Gate Rupture (SEGR)

Single Event Burnout can cause device destruction due to a high current state in a transistor.A single ion induced in MOSFETs may result in the formation of a permanent conducting path inthe gate oxide (SEGR). All MOSFETs shall be evaluated for SEB and SEGR vulnerability. A LETthreshold of 20 MeVcm2/mg for SEB and SEGR shall be considered insensitive. For SEB andSEGR vulnerability, further radiation hardness assurance shall be achieved by derating to lessthan 75% of the voltage at which the SEB/SEGR occurred at 20 MeVcm2/mg.

3.5.5 GIDEP and ESA Alerts

All Government Industry Data Exchange Program (GIDEP) and ESA Alerts/Problem notificationsavailable to subcontractor shall be dispositioned by the subcontractor w.r.t. applicability for theCryoSat project. This applies to all electronic parts as well as materials and processes. ASTRIUMGmbH shall be informed about such applicable alerts. The subcontractor shall take care that thenecessary steps are taken to overcome the situation. Applicable alerts shall be tracked via theCritical Items Control Process.

3.5.6 EEE Parts Procurement

ASTRIUM GmbH will not perform any co-ordinated procurement. The EEE parts procurement forall CryoSat units shall be a user self-procurement. The timely and adequate procurement is underfull responsibility of each subcontractor. Each subcontractor shall prepare a Long Lead Items Listand a DCL as a selection criteria for early assessment by ASTRIUM GmbH.

Post programming B/I for PROMs is not generally required. However PROMs may be subjected toa post programming burn-in process, if explicitly required by the subcontractor standards forPROM programming.

Any failure during this B/I programme shall be reported by NCR according chapter 3.9



3.5.6.1 Parts Attrition

The attrition quantity shall be calculated by the subcontractor on the basis of units underconsideration of the following rules:

qty per unit attrition [%]1 - 4 1005 - 10 5011 - 30 3031 - 100 20> 100 15

The above shall be considered as minimum requirements. In case that more than one unit will bemanufactured by the subcontractor, the attrition rate for common part types may be calculatedfrom the total number of needed items per type.

3.5.6.2 Spare Parts

If no spare unit will be delivered, the subcontractor shall have sufficient parts or already populatedand tested boards available in order to meet the repair requirement as defined in the SOW.

In case that PROMs are used in the design, as minimum two complete set of un-programmedspare PROMs shall be procured and hold on store for any potential late flight S/W update. Onlyone spare set is required for PROMs used for boot software

3.5.6.3 Procurement Status Reporting

The actual EEE parts procurement status reporting is not required for each individual part type,however, all identified problem areas w.r.t. schedule and quality shall be reported as part of thenominal progress reports.

3.6 Materials Selection and Processes Controls

All materials and processes to be used for CryoSat flight hardware design, development andmanufacturing shall be compatible with CryoSat on-ground and in-orbit environment and missionduration. Baseline for the selection of materials and processes shall be ECSS-Q-70 and the PSS-01-7xx series. If the selection is not performed according those documents, a justification shall beprovided.

Where feasible, materials shall be selected from valid ESA or NASA databases, and/or sources ofsimilar, previously flown or qualified space hardware, and thus already be qualified for flight use.

For not yet space qualified materials, or materials unproven in the CryoSat environment,testing and analysis shall be performed prior to selecting. Early notification of new or unprovenmaterials shall be provided to ASTRIUM GmbH and ESA.



3.6.1 Prohibited Materials

The following materials are strictly prohibited for use in flight hardware:

• Zinc and Zinc platings• Mercury (liquid or gaseous)• Polyvinylchloride (PVC)• Barium and its compounds• Asbestos

3.6.2 Materials Restrictions

• Aluminium, magnesium and ferrous alloys susceptible to stress corrosion cracking shall not beused for primary structures or primary support brackets.

• Molybdenum shall not be used for relay contacts and in alloys in excess of 0.5 % for fluid andgas systems for hydrazine and amine based propellants.

• Beryllium and beryllium alloys containing more than 4% beryllium shall be used in coatedcondition only.

• Low alloy steels shall not be used.• Copper-zinc-alloys used for solder connections shall be plated with a barrier layer of copper.• Shatterable materials shall not be used except for solar cells, cover glasses and optical

equipment.• Chlorinated cleaning agents shall not be used unless they can be completely removed from the

final product.• Solithane coating should be avoided• Carcinogens (with the exception of propellant / oxidizer and pyrotechnic charges)• Magnesium (except specifically agreed on case-by-case basis for components, see chapter

3.5.2.4)• Cadmium and Cadmium platings (except specifically agreed on case-by-case basis for

components, see chapter 3.5.2.4)• Lithium (except specifically agreed on case-by-case basis for components, see chapter

3.5.2.4)• Radioactive sources (except specifically agreed on case-by-case basis for components, see

chapter 3.5.2.4)

If usage of a.m. materials/processes cannot be avoided they shall be marked in the DML/DPL andshall be brought to the attention of ASTRIUM GmbH and ESA through Request for Waiver.



3.6.3 Magnetic Materials

Use of magnetic material should be minimised, because of possible magnetometer measurementdisturbance. If not avoidable, magnetic materials shall be used only in fixed positions to allow forcompensation. Soft magnetic materials shall be used only for electromagnetic purposes wherehigh frequency flux reversals prevent permanent polarisation by the earth’s magnetic field.Amounts of soft magnetic materials within valves and relays shall be kept at a minimum.

3.6.4 Plating / Corrosion

Generally all materials and mechanical parts shall be protected against corrosion. Materials andmechanical parts made of stainless steel shall be passivated. Titanium alloys shall be anodized.Copper alloys containing zinc must be plated to prevent sublimation or vaporisation. Copper wiresshall be plated with 2µm silver.

3.6.5 Radiation Sensitive Materials

Polytetrafluoretylene (PTFE) must not be used in a radiation environment exceeding 30 Krad (Si)total dose during specified in-orbit duration.

3.6.6 Outgassing

Outgassing rates of materials shall be less than 1% of TML and 0.1% CVCM. Exceptions up toTML < 5% are allowable for hygroscopic materials like CFRP structures and thermal foilsconsisting of kapton, mylar, trevira, vespel and very small amounts of glue for attachment. Furtherexceptions shall be subject of approval by ASTRIUM GmbH and ESA. Outgassing parameters areto be identified in the DML.

3.6.7 Limited Life

Limited life items planned for use in flight hardware shall be identified and listed in the CriticalItems List to be provided to ASTRIUM GmbH and ESA.

3.6.8 ATOX Vulnerable Materials

The atomic oxygen environment has been analysed in the CryoSat Radiation EnvironmentAnalysis [AD36]. All materials exposed to free space shall be compatible to the ATOX flux asexpected during mission.



3.6.9 PCB Coupon Testing

Coupon samples for all multi-layer Printed Circuit Boards (PCBs) shall be available at thesubcontractor for evaluation by ASTRIUM GMBH or ESA on request. The inspection shall be inaccordance with the PCB quality level. Procurement specifications for PCBs are secified in chapter3.5.2.1.

(NOTE: Sample coupons from PCB's used in new designed CryoSat flight hardware may berequested by ESA for cross-checking quality standards.

3.6.10 Certification and Traceability

Traceability shall be maintained to the manufacturer lot and date code for PCBs, mechanismscomposite materials, adhesives, coating materials, as a minimum. Certificates of compliance shallbe filed at the subcontractor and be available on request of ASTRIUM GmbH or ESA.

3.6.11 Procurement of Materials and Mechanical Parts

All items shall be procured from an approved supplier where possible. Maximum use of Europeanmechanical parts and materials shall be made. In general the following specifications shall beused:

• European national or international specifications used in space projects.• US Federal or Military specifications

3.7 Processes Selection

Standard space proven manufacturing processes shall be selected wherever possible. Priorityshall be given to the use of ESA published specifications and to processes previously used forspace applications. The identification, qualification and approval status shall be provided in theDeclared Processes List. Each process and its application shall be considered separately. If aprocess specification does not conform to project requirements it shall be updated accordingly.The processes shall be selected during design on the basis of their ability to satisfy the designrequirements.

3.7.1 Surface Mounting Technology (SMT)

All surface mounting technology shall have passed successfully the process qualification acc. ESAPSS-01-738 [AD29].

If for any equipment this qualification cannot be demonstrated, a verification test according ESAPSS-738 shall be performed. No verification is required, if recurring unit elements are alreadyqualified and accepted by ESA, CNES or NASA for other space programmes with comparablevibration and temperature levels.



3.7.2 Declared Materials and Processes Lists

Each subcontractor shall provide lists of materials and processes being used on subsystem andequipment level.The results of materials and processes evaluation and selection shall be listed and described in:

• Declared Materials List ( which includes mechanical parts ), (DRD-PA-03)• Declared Processes List (DRD-PA-04)

The lists shall be updated reflecting design changes, type reductions and other changes in theprogramme.

These lists will be reviewed and approved by ASTRIUM GmbH for technical compliance withapplicable specifications and for compliance with the CryoSat PA requirements. The Materials andProcesses Lists will be submitted to ESA for review and approval in acc. with the procedures ofPSS-01-700. Only items specified on this approved list shall be used for manufacturing of flighthardware.

3.8 Safety Assurance

3.8.1 Policy and Management

Safety assurance methods shall be established to prevent personnel injury as well as damage toflight hardware, equipment, facilities and environment. Subcontractors shall use their existingsafety policies and procedures for operations at their own facilities. At all times local, state, andnational safety requirements shall be applicable, including specific safety requirements imposed atthe “User Site” location.

3.8.2 Program Content

Each subcontractor shall be the responsibility for the safety of personnel at their facility. Writtenprocedures shall be identified for dealing with all hazards:

• all procedures, containing hazardous operations shall be marked and identified accordingly,• hazards shall be clearly identified in these procedures,• preventive measures, required infrastructure or environment etc. controlling or eliminating

these hazards shall be defined in specific sections of these documents.

Equipment Protection Documentation shall exist at subcontractor facilities to ensure that theequipment is protected from damage due to: fire, flood, lightning, mis-mating or cross-mating,accidental overstress, ESD vulnerability, handling, shipping & storage, assembly, test andinspection environment. In order to ensure and to demonstrate that the requirements of the relateddocuments are entirely met, the following methods of analysis shall be applied.



3.8.2.1 Hazard Analysis

The design shall be analysed considering also associated support equipment and groundoperations, to identify inherent hazards, which may result in loss of life, personal injury, damage toother equipment or the environment. For the classification of hazard severity, the subcontractorshall use the categories as defined below:

Catastrophic Hazard when the following consequences are credible:

• Loss of life• Life threatening or permanently disabling injury• Occupational illness• Loss of launch site facility/ launcher/ spacecraft• Loss of ground systems / facilities• Loss of public or private property• Long term detrimental environmental effects

Critical Hazard when the following consequences are credible:

• Temporarily disabling (not life threatening injury)• Temporary occupational illness• Major damage to launch site facility / launcher / spacecraft• Major damage to ground systems / facilities• Major damage to public or private property• Short term detrimental environmental effects

No single failure or operator error shall lead to a critical or catastrophic hazard. No combination oftwo failures, two operator errors or one failure and one operator error shall lead to a catastrophichazard. All identified hazards, which are not controlled by compliance to failure tolerance, shall becontrolled by compliance to "design to minimum risk".

The analysis shall result in recommendations for possible elimination or adequate control of theidentified hazards. It shall take new hazards into consideration, which may come up during the on-ground project activities. With the periodic refinement of the analysis during all on-ground phases,those hazards that are associated with manufacturing, testing, transportation, integration,handling, storage and launch operations shall be included. The hazard analysis shall be performedusing PSS-01-403 as guideline.

3.8.2.2 Safety Trade-Off Studies / Hazard Reduction

Based on the results of the hazard analyses, design trade-offs and means of hazard reductionshall be investigated to reduce the hazards to the lowest possible categories. Reduction ofhazards shall follow the sequence defined in Para 7.1.1.2 of ECSS-Q-40.Possible hazards shall be closed by meeting the following conditions:

• elimination of the hazard by design or change of proceeding, and verification thereof• reduction of the hazard to an acceptable level, where normal operating procedures, test

programmes or analyses have demonstrated its acceptability



• assessment of the risk has shown an acceptably low level.

3.8.2.3 Safety Testing

It is envisaged to implement, where this is deemed appropriate, adequate validation tests onsafety critical items to determine or demonstrate the margin of safety or degree of hazard.

Testing of safety critical items shall be assessed for adequacy of hazard control prior to test andmonitor for correct implementation during test. Systematic and periodic proofload or pressuretesting of Ground Support equipment shall be implemented.

3.8.2.4 Safety Documentation

The following documentation shall be provided to ASTRIUM GmbH for approval:

• A Hazard Identification Sheet (DRD-PA-07) showing in form of a matrix for each subsystemall identified, credible hazards

• For each identified Hazard a Residual Hazard Sheet (DRD-PA-08) shall be issued with atleast the following information :

� Unambiguous Hazard Sheet Identification number� Related subsystem, equipment� Responsible subcontractor� Type of hazard� Criticality category� Description of hazard source and potential consequences of the hazard� Applicable safety requirements� Possible hazard reduction / hazard control measures� Rationale for acceptance of the hazard� Approval status

The current approval status shall be part of progress reports.

3.8.2.5 Training

Training of personnel for hazardous operations shall be implemented in a systematic timelyfashion.

3.8.2.6 Accident/Incident Reporting

All accidents / incidents occurring during hardware manufacturing, assembly, integration and testsshall be reported by NCR to ASTRIUM GmbH and ESA.



3.9 Non Conformances Handling and Reporting

The problem reports written at the subcontractor facilities shall be the primary means fordocumenting and tracking spacecraft hardware and software anomaly investigation.

3.9.1 Non Conformance Reporting Process

An electronic non-conformance log (DRD-PA-12) shall be kept to document all problems,anomalies and failures. Major and Minor NCR ratings shall be identified in this log acc. to thedefinition given below.

• Major NCR's are those which can have an impact on customer requirements in the followingareas:- safety of people or equipment- operational, functional or any technical requirements- reliability, maintainability or availability- lifetime- functional or dimensional interchangeability- interfaces with hardware or software- deviation to the approved qualification or acceptance procedure- EEE parts if the procurer proposes to use a rejected lot or batch- EEE parts which do not conform to form, fit and function requirements

• Minor NCR's are those which by definition are not classified as major

3.9.2 Notification

Each subcontractor shall inform ASTRIUM GmbH and ESA in parallel about major NCRs within 5working days. Minor NCRs shall only be reported to Astrium GmbH in form of a summary list aspart of the progress reports. Minor NCRs may be reviewed by higher level during meetings (e.g.progress meeting, TRB, etc.) or MIP. Major NCR shall be written in English language.

Anyone witnessing an anomaly has the responsibility and authority to report a problem andgenerate a NCR. Requirements for reporting problems/failures for CryoSat commence as follows:

� EEE Parts: Starting with FM procurement

� FM or FS Equipment− Electronics : Starting with FM/FS unit assembly− Mechanical Devices : Starting with FM/FS unit assembly− Support Equipment : When first mated with spacecraft hardware

� Software− Delivered with the H/W : Starting with final verification tests− Onboard S/W : Starting with S/W validation and acceptance phase

� GSE: Starting with acceptance testing



For incremental software the NC process shall start with the first delivery of the first SW version toAstrium GmbH Reporting requirements continue during all subsequent phases of integration andtesting.

3.9.3 Failure Analysis Requirements

Failure analyses including electrical and mechanical stress analyses, if needed, shall beconducted to adequately determine and characterise the failure, as well as to understand thecause of the problem and possible implications on all elements of the subsystem or system.Failed parts and related NCR's shall be delivered to ESA on request. Destructive Physical Analysis(DPA) of the failed parts may be performed at the discretion of ESA. This analysis may beconducted at ASTRIUM GmbH or a vendor facility, if requested by ESA.

3.9.4 Corrective Action Verification

Verification of corrective action shall involve the appropriate analysis and/or re-testing if necessaryto ensure that the correction has been accomplished. The unit corrected must perform correctlywhen subjected to the same conditions and shall pass the gate where the failure occurred.

3.10 Critical Items Control

Critical Items Control shall be performed on all constituents of CryoSat. Each subcontractor shallevaluate the design he is responsible for w.r.t. all PA/QA related critical items. Critical items whichare not PA/QA related (e.g. project or AIT program or schedule) shall not be addressed. All criticalitems identified shall be listed and traced in a Critical Items List (CIL, DRD-PA-10). All items,whether open or closed shall remain listed. Following items shall be addressed in all CILs:

� Single point Failures( Code : SPF )

� Safety critical items categorised “catastrophic” or “hazardous”( Code : SAF )

� Items without previous flight experience or without previous flight qualification( Code : QUA )

� Technology critical items ( Code : TEC )

� Performance critical items ( Code : PER )

� Life limited items ( Code : LIF )

� EEE Long Lead Items ( Code : LLI )

All CILs shall be prepared using a commonly agreed format and tool. The following informationshall be given:

� Unit, subsystem concerned

� unambiguous, permanent item number

� description of the critical item

� code as given above



� reference to supporting documentation (FMECA, Residual Hazard Sheet etc)

� description of the nature of criticality and it’s consequence

� recommendation to eliminate or control the criticality

� close-out status and rationale for close-out or retention ( ref. to test reports, analysis resultsetc.)

3.11 Hardware Quality Assurance

Hardware quality assurance includes the approach, policies, requirements and activities to beimplemented during the design, manufacturing, assembly and test of the equipment, as specifiedhereafter.

3.12 Subcontractor QA Programs and Processes

The existing QA programs and practices of the CryoSat subcontractors shall be utilised. Audits ofthe subcontractor’s Quality Assurance operation will be co-ordinated with the subcontractor andASTRIUM GmbH QA manager, in advance of the intended visit. No formal documentation isrequired, however, some recommended items for inclusions in subcontractor’s, QA programs, inaddition to other requirements specified herein, are given below:

• Use of space qualified hardware, processes and procedures• Use of certified personnel• Procedures for handling, shipping, storage of hardware• Inspections (source, receiving, workmanship, etc.)• Calibration of support equipment• Process control• Quality certification

3.13 Workmanship

All components shall be manufactured and finished in a thorough manner with establishedaerospace industry standards. Workmanship of manufactured hardware shall be verified duringMIPs with ASTRIUM GmbH and ESA invitation.

3.14 Contamination Control, Mechanical and Electrical Equipment

Cleanliness control shall be carried out to prevent potential degradation of CryoSat spacecraft’sand its optical instrument’s performance on ground or in orbit. Main areas are during development,manufacturing, handling, testing, integration, transportation and storage.

All flight hardware of the CryoSat Spacecraft shall be maintained in a Class 100,000 environmentas a minimum, in order to maintain a cleanliness level that is appropriate for non-contamination



critical flight hardware. Materials shall be characterised for outgassing to ensure effects areminimised. Verification of this requirement shall be made via history log and facility cleanlinesscontrol log.

3.15 Contamination Control, Optical Equipment

Handling, transportation integration and test of optical equipment requires a level 100 000environment as a minimum with all optical surfaces and critical cavities being suitably protected.Testing of integrated optical equipment can be performed in cleanliness level100 000 area, however, it is required to protect the optical equipment immediately after testcompletion. Verification of these requirements shall be made via history log, facility cleanlinesscontrol log and cleanliness verification on H/W for both particle and molecular contaminationbefore delivery.

3.16 Inspection, Testing and Controls

Inspections/evaluations shall be performed at the level necessary to assure compliance with thefollowing:

� Interface Requirements� Electrostatic Discharge Protective Measures� Acceptable Workmanship and Process Conditions� Cleanliness requirements� Configuration Requirements� Training and Certification Requirements� Inspection/Verification required by Safety

3.16.1 Planning

Early planning of all manufacturing, integration, test and inspection tasks shall be performed bythe subcontractors in close co-operation with their PA responsible.

Written procedures shall be used for hardware fabrication and assembly and test. Specificassembly instructions, inspection operations and tests, including criteria and techniques shall bedefined in these procedures.

These procedures shall be available for review by ASTRIUM GmbH and ESA on request.



3.16.2 Test Facility Control

The test area shall be controlled to the extent necessary to protect the test article from damage ordegradation due to handling, storage, environmental conditions etc. Requirements governingsafety, handling and storage, calibration, cleanliness and environmental controls shall be in effect.Fixtures shall be acceptable for intended use as evidenced by documentation. All test equipmentshall be checked for valid calibration and/or certification. Cleanliness logs, environment controllogs, calibration certificates, safety certifications of handling, hoisting and lifting devices shall bemaintained.

3.16.3 Post Test Hardware Inspection

The subcontractor shall inspect each flight hardware after completion of a functional orenvironmental test.

3.16.4 Non-conforming Material Control

When an article or material does not conform to applicable design documentation it shall beidentified as non-conforming, segregated from work operations (to the practicable degree), heldfor further actions and the non-conformance documentation.

3.16.6 Hardware Delivery Reviews

Hardware delivery reviews shall be conducted as part of the Delivery Review Board (DRB) to anydelivery of flight hardware to ASTRIUM GmbH.

3.16.7 Acceptance Data Package (ADP)

The ADP shall contain all documentation, which provides visibility over the fabrication, assemblyand test operations performed on the equipment to be delivered to the customer.The ADP shall be prepared as defined in DRD-PA-11. The Original ADP shall remain with theequipment at all time. Complete paper copies of the ADP plus 1 CD ROM containing the ADP filesshall be submitted to ASTRIUM GmbH (1 copy) and ESA (1 copy).

3.17 Handling and Transportation

Flight hardware and associated equipment shall be handled, stored, packed and transported insuch a manner, that all relevant precautions as detailed in the ESA PSS-01-202 [AD15] arecomplied with.



3.18 Ground Support Equipment

All GSE shall comply with the applicable and legal European Standards and shall be certified. Nocertification is required for unit transport boxes.

The GSE shall be designed taking into account the specific spacecraft related safetyrequirements as outlined in chapter 3.8. The GSE interface compatibility shall be proven beforeuse on flight or flight spare hardware. In addition the following has to be considered:

• All GSE parts and materials interfacing with the flight hardware shall be non-corrosive.

• All GSE parts and materials shall not cause degradation or contamination of the flighthardware

• GSE on wheels shall have locking brake devices.

• Fail-safe-design shall be built in

• Components requiring scheduled maintenance shall be identified and easily accessible

3.18.1 Transport Boxes and Packing Material

Transport boxes and packing material shall be suitable to protect the flight equipment againstenvironmental factors in accordance to ESA PSS-01-202 [AD15]. In no way the used material shalldegrade or contaminate the flight hardware.

3.18.2 GSE Acceptance Data Package (ADP)

An ADP similar to the format provided for flight hardware (DRD-PA-11) shall be compiled anddelivered with the GSE H/W.



4 Onboard Software Product Assurance Requirements

4.1 General

The following Software Product Assurance (SPA) Requirements are based on the ESA ECSS-Q-80B Standard and reflect the tailoring approach for the CryoSat Project (see also § 3.1). Thetailoring have been performed with respect to required level of quality, reliability and size ofCryoSat.

4.1.1 Applicability

These SW PA Requirements are applicable to every Onboard Software used in the CryoSatProject and verification and supporting software used for Onboard SW verification.

For new developed Software the requirements have to be applied. For re-used SW chapter 4.4.5(Re–used Software) and chapter 4.3.4 (Operations and Maintenance Phase) are applicable.The applicable requirements for EGSE SW are described in chapter 4.6

4.1.2 Interfaces with Other Disciplines

Where requirements are adequately covered in other documents they are not repeated hereexcept if necessary for clarity but are explicitly made applicable. See chapter 2 of this in-hand PArequirements for applicable documents.

4.1.3 Responsibilities

The Software Product Assurance (SPA) is responsible for the tasks, which are described in thefollowing chapters.

4.2 Requirements on Management and Framework

4.2.1 Organisation and Responsibility

The supplier shall ensure that an organisational structure is defined for software development, andthat individuals have defined tasks and responsibilities.



4.2.1.1 Responsibility and Authority

The supplier shall define the responsibility, the authority of the SPA personal and the interfaces toother organisation within the SPA Plan or in the SPA Section of the PA-Plan.

The SPA shall report to the project manager via the Product Assurance Manager.

4.2.1.2 Resources

The supplier shall provide adequate resources to perform the required SPA tasks.

4.2.1.3 Software Product Assurance Management

The supplier shall

- appoint one person for Software Product Assurance.- prepare and implement a Software Product Assurance Plan (can be part of general PA-Plan)- maintain the SPA-Plan throughout the project life cycle

SPA shall liase with the software engineers and dependability and safety engineers.

4.2.2 Software Product Assurance Planning and Control

The subcontractor SPA Plan shall be developed to cover the SPA requirements as laid down inthis document. The software product assurance plan shall be updated if necessary, at each S/Wlifecycle milestone in such a way that the activities to be undertaken in the following phase are fullydefined.

The software product assurance plan shall specify or reference the following items:

• quality objectives, expressed in measurable terms for critical SW;

• the software development life cycle, the related milestones and the input and output criteriafor each development phase;

• types of verification and validation activities (including tests) to be carried out;

• specific responsibilities for quality activities such as reviews and tests, configurationmanagement and change control, non-conformance control and corrective action;

• methods, tools and rules to be applied;• the procedures for determine the criticality category of SW functions, objects, packages,

modules, files (according to the design methodology adapted);

The software product assurance plan shall identify the plans to be used and producedThe SPA plan shall provide a compliance matrix documenting the extent of compliance with therequirements laid down in this document.



4.2.2.1 Software Product Assurance Reporting

The supplier shall periodically prepare and submit to the Customer reports on the status andprogress of the SPA programme, as part of the overall PA reporting. In addition a SPA report shallbe presented in each formal review as defined in the SW life cycle.

The software product assurance report shall include an assessment of the current quality of theproduct and shall put special emphasis on critical SW with respect to verifications undertaken,problems detected and problems resolved.

4.2.2.2 Audits

The Supplier shall perform audits when necessary to overcome failure, consistent poor quality, orother problems or requested by the customer. An audit questionnaire shall be used and submittedin advanced to all involved parties

4.2.2.3 Non-Conformances

Non-conformance handling as described in chapter 3.9 of this PA requirements is applicable Thenon-conformance Review Board shall include a representative from the software productassurance and the software engineering organisations for SW related topics. The supplier shalldefine and establish non conformance procedures to allow effective and transparent NC control.

4.2.2.4 Software Problems

The SPA shall define and implement procedures for the logging, analysis and correction of allsoftware problems encountered during software development. The procedures for softwareproblems shall define the interface with the non-conformance system as described in chapter 3.9of these PA requirements. The SPA shall ensure the correct application of problem reportingprocedures

4.2.3 Risk Assessment and Critical Item Control

4.2.3.1 Risk Assessment

The SPA shall ensure that risk assessment will be performed during the SW Lifecycle with respectto

- Design margins- Dependability and safety- Quality degradation as result of cost and schedule constraints imposed on the project



4.2.3.2 Critical Items Control

For critical item control ECSS-Q20 clause 2.8 is applicable and reflected in chapter 3.10 of this PArequirements.

4.2.4 Subcontractor Control

If the supplier has subcontracted any SW development the requirements laid down in this planshall be made applicable to the subcontractors. An appropriate subcontractor controlling shall bedefined in the SPA Plan

4.3 Requirements on Life–Cycle Activities and Processes

In order to ensure effective assurance, software development shall be broken down intosuccessive phases from the statement of requirements to the entry of the software into service.These phases, and the milestones marking the transitions between them, constitute the softwaredevelopment life cycle.

The supplier shall define a software development cycle based on the life cycle defined in ECSS-E-40. The development life cycle shall define the required inputs and outputs for each developmentphase. The Outputs of each phase shall include documents, in outline or complete versions, andthe results of verification activities on the phase technical outputs. The documents shall contributeto the ECSS-E-40A baseline documents RB, TS, DJF and DDF.

The software life cycle for CryoSat shall at least comprise the following phases

- Software Requirement Engineering Phase- Software Design Engineering Phase- Software Qualification and Acceptance Phase- Operation and Maintenance Phase

4.3.1 Software Requirement Engineering Process

The Software Requirement Engineering Process comprises two main activities

• Definition of Software Requirements based on the Requirements Baseline (RB)• Definition of the SW top level design

At beginning of the software requirement-engineering process (SR Process) the requirementswhich shall be covered by software shall be defined. Furthermore additional software requirementswhich are necessary to fulfil the user requirements (requirement baseline) shall be defined. Eachrequirement shall have a unique identifier to support the verification and validation activities.Requirements shall be stated sufficiently precisely to allow verification and validation. For eachrequirement the method for verification/validation shall be specified.



The SW requirement definition activity shall be terminated by a Software System RequirementsReview (SW-SRR) The SW-SRR shall show that the requirements are clearly identified andsummarised in a requirement matrix and that the documentation is complete.

After successfully SW-SRR the definition of the top-level design shall be performed. Thetop-level design shall cover all SW requirements defined in the Technical Specification (TS) andshall define all software internal and external interfaces. During this part of the SR Phase theverification and validation approach of the SW requirements shall be outlined in a softwareverification and validation plan and a preliminary version of the operations manual shall beestablished.The top-level design activities are terminated by a Software Preliminary Design Review (SW-PDR).

Inputs to the SR Process are the

- agreed requirements baseline (user requirements)- first issue of the SPA Plan- first issue of the project development plan- first issue of the configuration management plan

Outputs from the SR Process are the- formal issue of Software Technical Specification (TS)- first issue of the top-level design- formal issue of Software Verification Plan and Software Validation Plan (can be part of DJF)- first issue of SW Budged Document- preliminary operations manual- updated project Plans, if necessary- internal SPA Inspection reports (for consultation at the SW-PDR)- trace from Software Technical Specification to higher level requirements

During this process the following SPA tasks shall be performed:

- internal review of the TS- internal review of top-level design- internal review of Software Verification Plan and Software Validation Plan- internal review of the SW Budged Document

The results shall be reported in an SQA Inspection report and shall cover the following mainitems:

• correctness• completeness• consistency• testability• criticality of SW• traceability of higher level requirements

for the top-level design the following items shall be covered:

• decomposition of the SW



• completeness of requirements• traceability of software requirements to design• function definition• data flow definition

- define the SQA activities for upcoming processes, if necessary- participation in formal SW-SRR and SW-PDR

4.3.2 Design Engineering Process

The Design Engineering Process (DD-Process) comprises the design/detailing of the SW items,the coding, testing and the integration of the Software items. During this process the necessarytest cases, test procedures and related test plans shall be established. The process shall beterminated by a SW Critical Design Review (SW-CDR)

The SW-CDR shall identify:

- the completeness of the documentation and its contents- the correctness of the design and the implementation of the software- the SW decomposition concerning control-flow, data-flow and function definitions- the traceability from code to requirement

Inputs to the DD-Process are

- Software Technical Specification (TS)- top-level design- Software Verification Plan and Software Validation Plan- SW Budged Document- Operations Manual- updated project Plans, if necessary

Outputs from the DD Process are the

- formal issue of the Design Definition Document, including source code- test and integration reports- first issue of the SW User Manual- updated of Software Verification Plan and Software Validation Plan- updated SW Budged Document, if necessary- updated issue of TS, if necessary- updated issue of Acceptance Test Plan, if necessary- updated project Plans, if necessary- internal SPA Inspection reports (for consultation at the SW-CDR)

During this process the following SPA tasks shall perform internal reviews of documentsgenerated and updated during this process and shall participate in the SW-CDR.

The results shall be reported in an SQA Inspection report and shall cover the following main items:



• decomposition of the SW• completeness of requirements• traceability of software requirements to software functions• function definition• data flow definition• correctness• conformance to coding standards• recording and documentation of test results• branch coverage• static analysisThe acceptance and proceeding criteria shall be defined

4.3.3 SW Validation and Acceptance Process

In this process the subcontractor shall perform the validation to ensure that the software productconforms to its technical specification. This process shall be performed in a flight representativeenvironment.

The objectives of this process are:

- defining the Acceptance Test cases and procedures- finalising the software user manual- finalising the Operations Manual- performing Acceptance Tests

The supplier shall perform the Acceptance Test activities to demonstrate that all customerrequirements are properly met and verified. The qualification test activities shall be terminated byan Acceptance Review. After successful AR the SW shall be either implemented into the real unitor be delivered to the customer where the SW will be installed, tested and used in its operationalenvironment.

Inputs to this Process are the

- Integration tested SW- Software User Manual (SUM)- Acceptance Test Plan- Acceptance Test procedures

Outputs of this Process are the

- Final Software; including executable load module, source code, data memory link maps anddata memory image

- Software development tools and related procedures- Test reports of performed AR- updated Documents from earlier phases, if necessary- SPA Summary Report

During this process the following SPA tasks shall be performed



- internal review of Acceptance Test cases and procedure- internal review of SUM- participation in internal and formal test activities- preparing a SW PA summary report

to ensure that

- the AR is performed in accordance to the test plans- test results are recorded and documented- tests are reproducible- the trace from user requirements to AR documentation is correctly performed-

4.3.4 Operations and Maintenance Process

The Operation and Maintenance Process starts after successfully performed Acceptance Reviewand takes until end of Contract.Inputs to the Process are the

- Accepted SW- AR Report

Outputs from this Process are the

- Maintenance plans and procedures

The organisation responsible for maintenance shall establish and maintain plans and proceduresfor performing maintenance activities and support of the operation of the software product. Themaintenance organisation shall specify the assurance, verification and validation activitiesapplicable to maintenance interventions.

The maintenance plans and procedures shall include the following:

• scope of maintenance;• identification of the initial status of the software product;• support organisation;• maintenance activities;• maintenance records and reports.

Maintenance records shall include the following information

• list of requests for assistance or problem reports that have been received and the currentstatus of each;

• organisation responsible for responding to requests for assistance or implementing theappropriate corrective actions;

• priorities that have been assigned to the corrective actions;• results of the corrective actions;• statistical data on failure occurrences and maintenance activities.

SPA shall ensure that

- plans and procedures are verified against specified requirements for maintenance of thesoftware product.



- All changes to the software product will be documented in accordance with the procedures fordocument control and configuration management

4.3.5 Incremental / early SW delivery

In case that an incremental / early software delivery is part of the contract, the subcontractor shallreflect that in the Project Development Plan, SPA Plan, CM Plan and Test Plans.

For each incremental / early delivery the following documents shall be delivered

• an adequate Software User Manual• Test Specification• Test reports• Software Configuration Item Data List (SCIDL)

SPA shall perform the following tasks

- internal review of Test cases and procedure- internal review of SUM- internal review of SCIDL- participation in test activities- preparing a SW PA summary report- ensure that test results are recorded and documented- tests are reproducible

4.4 Requirements Applicable to All Life–Cycle Processes

4.4.1 Process Documentation

PlansThe following activities shall be covered in project plans:

• development;• specification, design and user documents to be produced;• configuration and documentation management;• verification and validation activities (including testing);• maintenance.

All plans shall be finalised before the phase for which they are applicable is started.All plans shall be updated for each milestone to reflect any changes during development.

Procedures and standards

The following activities shall be covered by development procedures and project standards:

• configuration management of all products and documentation;• classification of software product according to its functional criticality;• use of program design language, if it is used in the detailed design;



• use of coding languages.

Procedures and project standards shall include provision for all classes of onboard softwareincluded in the project. All procedures and project standards shall be finalised before the phase forwhich they are applicable is started.

4.4.2 Software Dependability for Critical Functions

The following dependability and safety requirements concern software products involved infulfilling critical functions, as defined in the relevant section of the user requirements (UR). TheSPA shall endeavour to design critical software components as simply as possible, to facilitatedependability and safety analysis and software testing.

A functional analysis at system level as presented in the UR shall be used to identify the criticalsoftware modules. The Hardware Software Interaction Analysis (HSIA) as part of the FMECA shalltake into account the interaction of the software with its environment (system hardware, humanintervention, etc.) jointly with the system level.

The list of critical modules for software shall be verified for continuing validity at each developmentmilestone. The list of critical modules shall be part of the critical item list.The functional analysis shall, if necessary, be updated for each development milestone.The SPA shall define measures to assure the reliability of critical modules.These measures shall include:

• use of software design or methods, which have performed successfully in a similarapplication;

• defensive programming techniques, such as input verification and consistency checks;• prohibiting the use of language commands and features which are known to be unpredictable

or difficult to program;• use of formal design language for formal proof and/or automatic code generation;• full inspection of source code;• 100% branch coverage and justification in case it is not possible to reach 100%;• full regression testing after any change on critical modules.• independent verification of critical software.

4.4.3 Non - critical Software

The SPA shall ensure that failure of non-critical software, which is not subject to the above statedassurance measures, will not cause failure of critical software.



4.4.4 Software Configuration and Documentation Management

The requirements for Software Configuration Management are described in the standard ECSS-M-40, and this clause contains requirements on product assurance of Software ConfigurationManagement which are complementary to the ECSS-M-40 requirements.

The Configuration Management implementation document should explicitly address the CM ofsoftware, with respect to all of the requirements of ECSS-M-40. The software configuration shallstart for each SW product, including documents, with the delivery to third parties.

The management of source code configuration shall be described in the configurationmanagement plan. The SW CM shall be based on different areas, e.g. development area, releasearea. The responsibilities and access rights of the different areas shall be described.

The software CM system shall allow any reference version to be re-generated from backups. Thesoftware configuration item data list shall be submitted to the customer for approval at acceptancetesting. The software configuration item data list shall also be available and up to date for eachproject milestone.

In case of incremental/early delivery the delivered Version and its related documentation has to beput under configuration control and the SW change control has to be started.

4.4.4.1 Change Control

The SPA shall ensure that all authorised changes are implemented according to the requirementsof the Software Configuration Management plan. The SW CM can be part of the overallConfiguration Management Plan. The SPA shall ensure that only appropriately authorisedchanges are made.

4.4.4.2 Software configuration management tool

The use of a computer-based configuration management tool is recommended.The configuration management tool shall be identified in the configuration managementimplementation document.

4.4.4.3 Control of documents

All SW documents produced or used within the CryoSat Project shall be subject of formalConfiguration Control as described in Configuration Management Plan



4.4.4.4 Protection and marking

The SPA shall ensure that a mechanism will be applied to protect all supplied software (source,executable, data,...) against corruption. For all software products in operational use, the SPA orConfiguration Control shall use a checksum calculation and checking software (each executablebinary or each file considered to be a supply). The checksum value shall be specified in thesoftware configuration file.

The identification key shall be used:

• prior to each delivery;• at reception to check identification.

If the protection mechanism used is based on a SPA- or CM- specific tool, this tool shall besupplied to the customer along with the delivered software products. The software mediadeliverable to the customer shall be marked during the preparation of each delivery, indicating thefollowing minimum information:

• the software name;• the version number;• the reference to the software configuration file.

4.4.5 Re–used Software

Re-used software includes software from previous developments, which is intended to be used forthe project development as it is, or with adaptation. It also includes software supplied by thecustomer for use in the project development. During SR -Phase the re-used items shall beidentified and an Software Re-used Document shall be provided containing

• a qualitative summary review of the re-used components and an assessment of thepossible level of re-use;

• a description of the assumptions and the method of calculating the level of re-use;• planned corrective actions regarding the re-used component design, coding,

tests/regression tests shall be described• a compliance matrix to the in-hand SPA requirements

The identification process shall be finalised at the SW-PDR. The choice of re-used software shalltake into account:

• the assessment of the product with respect to requirements;• the acceptance and warranty conditions (demonstration of correct operation);• the conditions of installation, preparation, training and use;• the identification and registration by configuration management;• the maintenance conditions, including the possibilities of changes;• the copyright constraints (licence, modification rights);• the criticality of the function provided.

SPA shall analyse the re-used software to check for each re-used component:

- its validation level or operational behaviour,



- its documentation status,- its quality status, i.e. residual non conformances, complexity analyses, waiver, etc.

4.4.6 Regression testing

Areas affected by any modifications shall be identified and re-tested (regression testing).In case of re-testing all test related documentation (test case specifications, procedures, reports)shall be updated accordingly.

4.5 Requirements on Product Quality

4.5.1 Product Quality Objectives and Metrication

The subcontractor shall define metrication depending on the criticality of the Softwarecomponents.

4.5.1.1 Product and process quality objectives

The SPA shall define assurance activities to ensure that the product meets the quality objectivesas specified in the contract.

The software quality objectives shall be derived from the reliability, safety, maintainability andquality requirements of the system.

Quality models shall be used to specify the required quality objectives. This can be done byreference to a quality model such as MacCall or ISO 9126. The following subjects should beconsidered at least:

Characteristics Quality propertiesCompletenessCorrectness

Functionality

EfficiencyRobustnessIntegrity

Reliability

MaturityChangeabilityVerifiabilityModularity

Maintainability

AnalysabilityRequirement qualityDocumentation QualityCompleteness

The subcontractors shall apply rules on design, code and documentation and define a metricationprogramme to verify and prove that the objectives are reached.



The Software Process quality approach is essentially based on the monitoring of Processmetrics.SPA activity:

The SPA shall define relevant metrics, and the means to obtain them, to predict /assess /estimatethe actual characteristics of the product. These measurements shall be performed throughout thedevelopment and the results obtained used to define corrective actions when necessary. Theresults shall be used to provide the customer with an insight into the level of quality obtainedthrough software product assurance reports.

4.5.1.2 Software Product Metrics

The following basic product metrics shall be considered for use:

• size (design, code);• complexity (design, code);• test coverage;• number of failures.

4.5.1.3 Software Process Metrics

The following list of software process metrics shall be considered for use:

• Number of open and close non conformances, per month,

• Number of open and close change requests, per month,

• Number of open and close requests for waiver , per month,

• Number of open and close actions, per month (including actions initiated by software productassurance and reviews actions).

All these metrics, requested to Subcontractors by ECSS-Q-80, will be analysed at Astrium level.

4.5.1.4 Numerical accuracy

For software in which numerical accuracy has a functional importance (e.g. for an attitude andorbit control subsystem) specific rules on design and code shall be defined to ensure that theappropriate level of accuracy will be obtained. Numerical errors will be estimated and checkedfrom the design phase to the end of development.

4.5.2 Supporting Documentation

The following requirements are applicable for test documentation:

• Detailed test planning documentation (designs, case specifications, procedures, expectedresults, etc.) shall be consistent with the strategy defined in the test plan.

• The test documentation shall cover the test environment, tools and test software, personnelrequired and associated training requirements.

• The criteria for the completion of the test and any contingency steps shall be specified.



• Test cases, procedures and expected results shall be specified.• The hardware and software configuration shall be identified and documented as part of the test

documentation.• Test results shall be recorded and documented in reports as defined in the applicable project

standards.• For any requirements not covered by testing a verification report shall be drawn up

documenting or referring to the verification activities performed

4.5.3 Purchased Software

The choice of purchased software (commercial off the shelf software) shall take into accountconstraints associated with development and future use.

The following aspects shall be considered:• the assessment of the product with respect to quality requirements and objectives;• the available support documentation;• the acceptance and warranty conditions;• the conditions of installation, preparation,• the maintenance conditions, including possibility of evolutions (portability by example);• copyright constraints.

The choice of purchased software shall be described and submitted for customer acceptance inthe form of a software component list. The software component list shall include specification of, atleast:

• ordering criteria (versions, options, extensions, etc.);• arrangements for maintenance and upgrades to new releases;• back-up solutions if the product becomes unavailable;• contractual arrangements for the development and maintenance phases;• receiving inspection criteria.

All the purchased software, which will be used in the operational system, shall beidentified and registered by configuration management.

The SPA shall subject the purchased software to a planned receiving inspection against pre-defined criteria before its acceptance.A receiving inspection report (including identification of detected problems) shall be generated.

4.6 QUALITY ASSURANCE FOR GROUND SUPPORT EQUIPMENT

The following chapters of this document are applicable to SQ QA for EGSE:

4.2.2 SPA Planning and Control, where the main focus will be on verification and validationactivities, traceability of requirements and participation in acceptance tests.

4.2.2.1 SPA reporting

4.2.2.2 Audit



4.2.2.3 Non-Conformances

4.3 Requirements on Life-Cycle Activities and Processes, SW audits, SRR, ADR, Review oftest procedures and test plans, witnessing of test and delivery review

4.4.4 SW Configuration and Documentation Management

4.4.5 Re-used Software (if foreseen)

4.5.2 Supporting Documentation, as specified in the SOW

4.5.3 Purchased Software



5 PA Document Requirement List

Responsible 2)DRD-

No 1)

Title Reference tochapter

ASTR

IUM

Gm

bH

ESA SUB

Submittal Remarks

PA-01 PA Compliance Matrix 3.2 R R X according SOW

PA-02 Declared Component List(DCL)

3.5.3 A A X according SOW

PA-03 Declared Mechanical Partsand Material list (DML)

3.7.2 A A X according SOW

PA-04 Declared Process List (DPL) 3.7.2 A A X according SOW

PA-05 Failure Mode Effects andCriticality Analysis (FMECA)

3.4.1

3.4.2

R R X according SOW

PA-06 Worst Case Analysis (WCA) 3.4.4 R R X according SOW

PA-07 Hazard Identification sheet 3.8.2.4 A A X according SOW

PA-08 Residual Hazard sheet 3.8.2.4 A A X according SOW

PA-09 Parts Approval Document(PAD)

3.5.2.2

3.5.2.3

A A X Prior EEE partsprocurement

for non-standardparts only

PA-10 Critical Item List (CIL) 3.10 R R X draft with proposal,periodic update inC/D

PA-11 Acceptance data package(ADP)

3.16.7 R R X 10 days prior DRB

PA-12 NCR's -major

- minor

3.9 A

I 3)

A

I 3)

X

X

5 working days formajor

progress reporting,reviews

only major NCR'sto Astrium & ESA

Notes: 1) DRD = Document Requirement Description as per CS-LI-DOR-SY-0014 2) Responsible: X = responsible for document preparation

A = Document to be approved R = Document to be reviewed I = Document for information

3) Summary listing only