ECSS E HB 10 02A (17december2010)

ECSS-E-HB-10-02A
17 December 2010
Space engineering
Verification guidelines
ECSS Secretariat ESA-ESTEC Requirements & Standards Division Noordwijk, The Netherlands
ECSSEHB1002A 17December2010
Foreword ThisHandbookisonedocumentoftheseriesofECSSDocumentsintendedtobeusedassupporting material for ECSS Standards in space projects and applications. ECSS is a cooperative effort of the EuropeanSpaceAgency,nationalspaceagenciesandEuropeanindustryassociationsforthepurpose ofdevelopingandmaintainingcommonstandards. The material in this Handbook is defined in terms of description and recommendation how to organizeandperformtheworkofverificationofaspacesystemproduct,asspecifiedintheECSSST 1002. This handbook has been prepared by the ECSSEHB1002 Working Group, reviewed by the ECSS ExecutiveSecretariatandapprovedbytheECSSTechnicalAuthority.
Disclaimer ECSSdoesnotprovideanywarrantywhatsoever,whetherexpressed,implied,orstatutory,including, butnotlimitedto,anywarrantyofmerchantabilityorfitnessforaparticularpurposeoranywarranty that the contents of the item are errorfree. In no respect shall ECSS incur any liability for any damages,including,butnotlimitedto,direct,indirect,special,orconsequentialdamagesarisingout of,resultingfrom,orinanywayconnectedtotheuseofthisdocument,whetherornotbasedupon warranty,businessagreement,tort,orotherwise;whetherornotinjurywassustainedbypersonsor propertyorotherwise;andwhetherornotlosswassustainedfrom,oraroseoutof,theresultsof,the item,oranyservicesthatmaybeprovidedbyECSS.
Publishedby: Copyright:
ESARequirementsandStandardsDivision ESTEC,P.O.Box299, 2200AGNoordwijk TheNetherlands 2010bytheEuropeanSpaceAgencyforthemembersofECSS
Table of contents
1 Scope.......................................................................................................................6 2 References ..............................................................................................................7 3 Terms, definitions and abbreviated terms............................................................8
3.1 3.2 3.3 Terms from other documents .....................................................................................8 Terms specific to the present handbook .................................................................... 8 Abbreviated terms ......................................................................................................9
4 Verification principles ..........................................................................................12

4.1 4.2 4.3 4.4 Introduction...............................................................................................................12 Verification versus Validation ...................................................................................12 Applicability to all engineering domains ................................................................... 13 Development ............................................................................................................13
5 Verification guidelines .........................................................................................14

5.1 5.2 Verification process ..................................................................................................14 Verification planning .................................................................................................14 5.2.1 5.2.2 5.2.3 5.2.4 5.2.5 5.2.6 5.2.7 5.3 5.3.1 5.3.2 5.4 5.4.1 5.4.2 5.4.3 Verification approach..................................................................................14 Verification methods ................................................................................... 19 Verification levels........................................................................................23 Verification stages ......................................................................................24 Models and Models Description ................................................................. 27 Verification tools .........................................................................................42 Verification process phasing.......................................................................44 General.......................................................................................................51 Example of verification team responsibility and interfaces ......................... 51 General.......................................................................................................53 Verification control board (VCB) .................................................................54 Re-verification.............................................................................................54
Verification execution and reporting .........................................................................51
Verification control and close-out ............................................................................. 53
6 Verification documentation .................................................................................56

6.1 6.2 Introduction...............................................................................................................56 Verification planning documents ..............................................................................58 6.2.1 6.2.2 6.2.3 6.3 6.3.1 6.3.2 6.3.3 6.3.4 6.3.5 6.3.6 6.3.7 6.3.8 Verification plan (VP).................................................................................. 58 Verification control document (VCD) .......................................................... 65 Other verification planning Documents....................................................... 68 Test report (TRPT) .....................................................................................69 Analysis report (ARPT)...............................................................................71 Review-of-design report (RRPT) ................................................................ 72 Inspection report (IRPT) ............................................................................. 74 Verification report (VRPT) ..........................................................................76 VRPT DRD explanation.............................................................................. 77 Other verification execution and reporting Document ................................ 78 Other close-out documents ........................................................................ 80
Verification execution and reporting documentation ................................................ 69
Annex A Verification documents delivery per review ..........................................81 Annex B Verification Standard Tailoring ...............................................................82
Figures
Figure 5-1: Basic verification approach ..................................................................................16 Figure 5-2: Parameters for Model Philosophy definition ........................................................ 34 Figure 5-3: Example of Unmanned project model philosophy................................................ 36 Figure 5-4: Example of Manned project model philosophy .................................................... 37 Figure 5-5: Example of Protoflight model philosophy............................................................. 38 Figure 5-6: Example of Hybrid model philosophy................................................................... 40 Figure 5-7: Example of verification process phasing with the project life cycle...................... 45 Figure 5-8: Verification activities flow (Phases A/B)............................................................... 48 Figure 5-9: Verification activities flow (Phases C/D) .............................................................. 49 Figure 5-10: Verification activities flow (Phases E/F) ............................................................. 50 Figure 6-1: Verification documentation...................................................................................57 Figure 6-2: Example of Verification Strategies per Group/level ............................................. 60 Figure 6-3: Example of verification strategy for a single Requirement Group........................ 61 Figure 6-4: Example of verification planning .......................................................................... 62 Figure 6-5: Example of activity sheet for analysis programme............................................... 63 Figure 6-6: Example of Activity Sheet for Integration and Test Programme .......................... 64 Figure 6-7: Example of the close-out status table ................................................................. 67
ECSSEHB1002A 17December2010 Figure 6-8: Example of VCD sheet.........................................................................................68 Figure 6-9: Example of test report sheet ................................................................................ 71 Figure 6-10: Example of an analysis report sheet..................................................................72 Figure 6-11: Example of review-of-design report sheet ......................................................... 74 Figure 6-12: Example of an inspection report sheet............................................................... 76 Figure 6-13: Example of verification report sheet................................................................... 78
Tables
Table 5-1: Product categories according to heritage.............................................................. 25 Table 5-2 : Summary model definitions.................................................................................. 32 Table 5-3 : Example of a product matrix as viewed with a satellite perspective .................... 41 Table B-1 : Tailoring guidelines and some examples per product type.................................. 83
1 Scope
ThishandbookprovidesadditionalinformationfortheapplicationoftheverificationstandardECSS EST1002Ctoaspacesystemproduct. This handbook does not contain requirements and therefore cannot be made applicable. In case of conflictbetweenthestandardandthishandbook,thestandardprevails. This handbook is relevant for both the customer and the supplier of the product during all project phases. To facilitate the crossreference, this handbook follows as much as is practical, the structure of the standard and quotes the requirements, to make it self standing and easier to read (the text from the standardisinitalic). AstheStandardappliestodifferentproductsatdifferentproductlevelsfromsingleequipmenttothe overall system (including space segment hardware and software, launchers and Transportation Systems, ground segment, Verification tools, and GSE) several examples of tailoring, to match the specificityofeachapplication,areproposedinAnnexB. Specific discipline related verification aspects are covered in other dedicated standards and handbooks.InparticularthedetailedaspectsforTestingarecoveredintheECSSEST1003andinits correspondinghandbookECSSEHB1003. The application of the requirements of the standard to a particular project is intended to result in effectiveproductverificationandconsequentlytoahighconfidenceinachievingsuccessfulproduct operations for the intended use, in this respect this handbook has the goal to help reaching these objectives.
2 References
ThisdocumentisthehandbookcorrespondingtotheVerificationstandardECSSEST1002C. Thefollowingdocumentsarereferencedinthistextorprovideadditionalinformationusefulforthe reader. ECSSSST0001 ECSSEST10 ECSSEST1002 ECSSEST1003 ECSSEST40 ECSSEST50 ECSSEST70 ECSSEHB1003 ECSSETM1021 ECSSMST10 ECSSQST1009 ECSSQST20 ECSSQ2007 ECSSQST40 ECSSQST60 ECSSQST70 ECSSsystemGlossaryofterms SpaceengineeringSystemengineeringgeneralrequirements SpaceengineeringVerification SpaceengineeringTesting SpaceengineeringSoftware SpaceengineeringCommunications SpaceengineeringGroundsystemsandoperations SpaceengineeringTestingguidelines SpaceengineeringSystemmodellingandsimulation Space project management implementation. Project planning and
SpaceproductassuranceNonconformancecontrolsystem. SpaceproductassuranceQualityassurance. SpaceproductassuranceQualityassurancefortestcentres. SpaceproductassuranceSafety. Space product assurance Electrical, electronic and electromechanical(EEE)components. Space product assurance Materials, mechanical parts and processes.
3 Terms, definitions and abbreviated terms

3.1 Terms from other documents
validation verification
Forthepurposeofthisdocument,thetermsanddefinitionsfromECSSST0001apply,inparticular forthefollowingterms:
3.2
3.2.1
Terms specific to the present handbook

acceptance stage
verificationstagewiththeobjectiveofdemonstratingthattheproductisfreeofworkmanshipdefects,
isinaccordancewiththequalifieddesignandisreadyforitsintendeduse
3.2.2
analysis
verificationmethodperformingatheoreticalorempiricalevaluationusingtechniquesagreedwiththe customer NOTE Theselectedtechniquescantypicallyincludestatistics,qualitative designanalysis,modellingandcomputersimulation.
3.2.3
commissioning
verification and validation activities conducted after the launch and before the entry in operational serviceeitheronthespaceelementsonlyorontheoverallsystem(includingthegroundelements)
3.2.4
in-orbit stage
verification stage valid for projects for which inorbit verification is performed, including the commissioningandverificationactivitieswhicharedelayedbecausetheactivationofaspaceelement isperformedlaterduringthemission(e.g.forInterplanetarymission,lander).
3.2.5
inspection
NOTE1 Product characteristics include constructional features, hardware conformancetodocumentdrawingorworkmanshiprequirements, physical conditions, software source code conformance with codingstandards NOTE2 SeealsoECSSST0001.
verificationmethodbyvisualdeterminationofphysicalcharacteristics
ECSSEHB1002A 17December2010 3.2.6 model philosophy
definition of the optimum number and the characteristics of physical models required to achieve confidenceintheproductverificationwiththeshortestplanningandasuitableweighingofcostsand risks
3.2.7
post-landing stage
verification stage valid for projects for which postlanding verification is performed (e.g. for Multimissionprojects)
3.2.8
pre-launch stage
verification stage with the objective toverify that the flightarticle is properlyconfigured for launch andcapableoffunctioningasplannedforlaunch
3.2.9
qualification stage
verificationstagewiththeobjectivetodemonstratethatthedesignfulfilstheapplicablerequirements includingpropermargins
3.2.10
review-of-design
verification method using approved records or evidence that unambiguously show that the requirementismet(e.g.usingdesigndocuments,designreports,technicaldescriptions,engineering drawings)
3.2.11
test
verification method by measurement of product performance and functions under representative simulatedenvironments NOTE SeealsoECSSST0001.
3.2.12
Verification Control Board (VCB)
aboardcomposedofcustomerandsupplierrepresentativesthatmonitorstheverificationprocessand formallyassessestherequirementsverificationcloseout.
3.2.13
verification level
productarchitecturallevelatwhichtherelevantverificationisperformed
3.3
Abbreviated terms
Thefollowingabbreviatedtermsareusedwithinthisdocument:
Abbreviation Meaning AIT AITP AIV AIVP AOCS assembly,integrationandtest assembly,integrationandtestplan assembly,integrationandverification assembly,integrationandverificationplan attitudeandorbitcontrolsystem
Abbreviation Meaning AR ARPT BB CDR CRR CP DM DRD ECSS EEE EIDP ELR EM EMC EOL EQM FM FMECA FRR FS GPS GSE H/W HFE I/F IM IRPT ISO LRR LTM MU NCR NRB OBDH acceptancereview analysisreport Breadboard criticaldesignreview commissioningresultreview commissioningplan developmentmodel documentrequirementsdefinition EuropeanCooperationforSpaceStandardization electronicelectricalandelectromechanical enditemdatapackage EndofLifeReview engineeringmodel electromagneticcompatibility endoflife engineeringqualificationmodel flightmodel failuremodeeffectsandcriticalityanalysis flightreadinessreview flightspare globalpositioningsystem groundsupportequipment Hardware humanfactorsengineering Interface integrationmodel inspectionreport InternationalOrganisationforStandardisation launchreadinessreview LifeTestModel mockup Nonconformancereport Nonconformancereviewboard onboarddatahandling
10
Abbreviation Meaning ORR P/L PDR PFM PRR PTR QA QM QR RCS RF RFW ROD RRPT S/C S/W SM SRR SS STM SVF TCL ThM TPRO TRR TRPT TSPE TT&C VCB VCD VP VRPT OperationsReadinessReview Payload preliminarydesignreview protoflightmodel preliminaryrequirementreview posttestreview qualityassurance qualificationmodel qualificationreview reactioncontrolsystem radiofrequency requestforwaiver reviewofdesign reviewofdesignreport spacecraft software structuralmodel systemrequirementsreview subsystem structuralthermalmodel softwarevalidationfacility testconfigurationlist thermalmodel TestProcedure testreadinessreview testreport TestSpecification telemetry,trackingandcommand verificationcontrolboard verificationcontroldocument verificationplan verificationreport
11
4 Verification principles
4.1
Introduction
ECSSEST10statesthatverificationdemonstrates,throughadedicatedprocess,thatthedeliverable system meets the specified requirements andis capable of sustaining its operational roleduring the projectlifecycle. ECSSEST1002 establishes the requirements for the verification of a space system product. It specifiesthefundamentalconceptsoftheverificationprocess,thecriteriafordefiningtheverification strategyandtherequirementsfortheimplementationoftheverificationprogramme.Itisintendedto applytodifferentproductsatdifferentlevels,fromsingleequipmenttotheoverallsystem(including space segment hardware and software, ground segment, launchers and transportation systems, VerificationtoolsandGSE). Concerning the scope of the standard, it is useful to address at this point some frequently asked questionsposedbyusers,inordertoemphasizecertainconceptsanddefinitionsimposedbyhigher levelstandardsandbytheacceptedEuropeanpracticesenshrinedwithinthestandard.
4.2
Verification versus Validation
A question often posed is why, within European space projects, we mandate a verification programme as opposed to a verification and validation programme, as practiced in other engineeringdisciplines(e.g.software,groundsegment). In general terms verification addresses whether a product satisfies the requirements placed upon it, whilstvalidationaddresseswhetheraproductwillsatisfytheneedsofitsusers,orasisoftenmore simplysaid, Verificationprovestheproductisright. Validationprovesitistherightproduct. TheVerificationStandarddoesnotmandatetheneedforaseparateprogrammeofvalidationofspace products, since product verificationisperformed against a set ofrequirements thatalsoaddress the suitability of the product to fulfil the needs of its intended use. However, the standard does not preventtheexecutionofaseparatevalidationactivityifthisisconsideredappropriate,asispracticed forexample,intheoperationorgroundsegmentdomains.Essentiallytheprocesstobefollowedisthe same,althoughitaddressesmainlytheuseoftheproduct.
12
4.3
Applicability to all engineering domains
The verification standard is applicable to all engineering domains where space products are developedandassuchitisviewedasanumbrellaunderwhichalldomainsarecovered. Inordertousethestandardinaspecificengineeringdomainitisnecessarytotailorthestandardfor that domain and where necessary, to make applicable the standards that define the verification requirements of that domain. A clear example is the verification of the ground segment and operations, whereby its verification is addressed specifically in ECSSEST70 (Ground systems and operations), by mandating specific verification (and validation) requirements and processes for the ground segment. The fact that ECSSEST1002C addresses in detail the space segment does not precludetheuseofthestandardinotherdomains,subjecttocorrecttailoring.
4.4
Development
The ECSS glossary defines development as the process by which the capability to adequately implementatechnologyordesignisestablishedbeforemanufactureandthatthisprocesscaninclude the buildingof various partial or complete models of the products in order toassessamongst other things,theirperformance. Whilstitisobviousthattestingandanalysisactivitiesoccurduringtheproductdevelopmentprocess, theyarenotaddressedbythestandardbecausetheyarenotformalrequirementverificationactivities inthesenseofthecustomersupplierrelationshipandconsequentlydonotfallwithinthemandateof ECSSverificationstandard.
13
5 Verification guidelines
5.1
Verification process
a. Theverificationprocessshalldemonstratethatthedeliverableproductmeetsthespecified customerrequirementsandiscapableofsustainingitsoperationalrolethrough: 1. Verification planning; 2. Verification execution and reporting; 3. Verification control and close-out.
ECSSEST1002Cclause5.1specifiesthat:
ThedetailedobjectivesoftheVerificationprocessareasfollows: a. b. c. to demonstrate the qualification of design and performance, as meeting the specified requirementsatthespecifiedlevels; toensurethattheproductisinagreementwiththequalifieddesign,isfreefromworkmanship defectsandacceptableforuse; to confirm product integrity and performance at particular steps of the project life cycle (e.g. launch,commissioning,missioneventsandlanding).
While this process looks sequential in nature, it is in fact more complex because the verification process of a multi level product is conducted in a top down approach for the planning, while the executionandreportingisconductedbottomup.Inaddition,theverificationcontrolandcloseoutis conductedinparalleltotheentireprocess. The verification process activities are incrementally performed at various levels and in different stages,andutilizingacombinationofthedifferentverificationmethodsasdescribedinthefollowing clause5.2.
5.2
5.2.1
5.2.1.1
Verification planning
Verification approach
General
ECSSEST1002Cclause5.2.1specifiesthat: a. Thecustomershalldefinetheprojectrequirements,verificationobjectivesandconstraints affectingthesupplierverificationprocess. Note: For example, ground segment characteristics, launch service, envisaged end to end tests involving several suppliers. The usual general objectives are listed in clause 4.1.1 Verification objectives.
14
b. c. Therequirementsspecifiedin5.2.2.1ashallalwaysincludethoseofthetechnical specification Thesuppliershalldefinetheverificationapproachbyconductingthefollowingsteps: 1. Identify and agree with the customer the set of requirements to be subject of the verification process; 2. Select the methods and levels of verification, associated model philosophy and verification tools; 3. Identify the stages and events in which the verification is implemented. TheverificationapproachshallbedefinedbythesupplierintheVerificationPlan(VP)for approvalbythecustomerpriortoimplementation. Foreachrequirementtobeverified,theverificationstrategyshallbedefinedintermsofthe combinationoftheselectedverificationmethodsforthedifferentverificationlevelsatthe applicableverificationstagesintheinitialissueoftheVerificationControlDocument (VCDalsocalledverificationmatrix(seeAnnexB),forapprovalbythecustomer.
d. e.
ToreachtheverificationobjectivesaverificationapproachisdefinedinphasesAandBoftheproject byanalyzingtherequirementstobeverified,takingintoaccount: a. b. c. d. e. f. designpeculiaritiesandconstraints, qualificationstatusofcandidatesolutions(productcategory), availabilityandmaturityofverificationtools, verification(includingtest)methodologies, programmaticconstraints,and costandschedule.
The requirement criticality, in terms of technical and programmatic impacts on the verification implementation, should be assessed by the involvement of the verification team in the requirement definitionprocessduringphasesAandB,sinceitdrivestheverificationstrategy. Theverificationapproachshouldallow: a. b. c. d. e. f. g. h. i. j. Toensurethedefinitionofcorrectverificationcriteriaforeachrequirementbyparticipatingin thepreparationofproductspecifications. To assess the impact that verification has on the design (e.g. modularity, testability, and accessibility). To ensure a coherent approach to verification implementation throughout the various levels avoidingduplicationofactivities. Toensureearlyverificationofcriticalitemstoreducetherisksoflatefailureidentification. Toensurethecoverageoftheinterfaceverification. To optimize the design and use of ground support equipment, simulators, test tools and test software(e.g.reusebetweenlevels,stagesandmodels). Tooptimizetheuseoftestfacilities. Toplanforfeedbacktotheverificationactivityfromthecommissioningresultsincaseofmulti missionprojectsorrecurringproducts. Toconsiderinnovativesolutionsthatcanreduceoverallverificationcosts. Toprovidevisibilityandobjectiveevidenceofverificationsperformed.
The use of requirement categories andrequirementtraceability helps to ensure consistency between verificationactivities,andtoavoidduplicationsorgapsintheentireverification.
15
In generating the verification approach, the supplier conducts the following verification steps (see Figure51)whileensuringcoherencyacrossallverificationlevels a. b. c. IdentifyWhataretheproductsandrequirementssubjectoftheverificationprocess; IdentifyHowtoverifythembyaselectedmethodofverificationatacertainlevelonthebasis ofadeterminedmodelphilosophyduringtheprojectimplementationphases; Identify When to implement the verification steps through selected stages and events all alongtheprojectlifecycle.
What?
How ?
When ?
Identify the consistent set of verifiable project requirements to be subject of the verification process
Select methods and levels of verification and associated model philosophy
Identify the phases and events in which the verification is implemented
Reiterations for technical - cost - schedule reasons
Figure51:Basicverificationapproach
5.2.1.2 What
Requirementsmaybegroupedinhomogeneouscategoryatthisstepifitfacilitatessubsequentwork. The requirements applicable to a particular product are usually all contained in technical specifications(includinginterfacerequirements).Asubsetofsomestandardsmaybepartoftheset. Inordertofacilitatetheverificationimplementation,theprojectrequirementshouldbe: a. b. c. d. e. f. traceable, uniqueandassociatedtoaproperidentifier(preferablyauniquerequirementID,initsabsence adocumentandsubclausenumber, singleandnotacombinationofseveralrequirements, verifiableusingoneormoreapprovedverificationmethods, unambiguous, referenced as necessary to other requirements (with applicable document and sub clause identification),
Some requirements are obvious in their verification execution (example: requirements to issue test procedures/reports). To limit the documentation and tracking effort these requirements should be identifiedandinagreementwiththecustomermarkedasnottobetrackedintheVCD.Thismeans
16
that these requirements are still applicable requirements but no formal verification report is issued andtrackedintheVCD. In other words a successful verification starts with a satisfactory set of requirements. Each requirement is seen as both the origin and the conclusion of the verification process, and treated as fundamentaltechnicalinformationratherthanaconstituentofaverbosetext. 5.2.1.3 How Overview
5.2.1.3.1
Then the supplier defines the verification approach in steps, generally conducted in an iterative processbasedontechnical,costandscheduleconsiderations. Theverificationplanningactivityshouldtakeintoaccountthefollowingelements: a. b. c. d. e. f. g. h. i. theproductandspecificationtrees; theapplicablemodels; theestimateddurationofprocurement,designandmanufacturingofeachmodel; theutilizationofmodels(inlinewiththemodelphilosophy); theestimateddurationoftheintegrationofmodels; the selected test programme and sequences at different levels with estimated time and resources; theanalysis,reviewofdesignandinspectionactivitiescombinedonthebasisoftheverification strategiesandestimatedtimeandresources; theactivitiesandtimeassociatedwiththeprocurementoftheverificationtoolstobeused; theprojectmilestonesandtheverificationoutput. Step 1 method, level, model philosophy and verification tool.
5.2.1.3.2
After identification of the requirements to be verified the potential verification methods and alternatives in each particular case are assessed in the context of the overall flow, the testing techniques,andtheanalyticaltoolsavailable. The verification levels are selected, taking into account as a minimum the programmatic aspects specifiedbelow: a. b. c. d. standardizedproductlevels(e.g.servicemodules); makeorbuydecisions(e.g.offtheshelfproducts); reductionofoverheadcosts(e.g.deletionofsubsystemlevel); responsibility.
Additionally to the aspects associated with a specific requirement (category), the following rules applytotheselectionoflevelsofverification: a. Inordertohaveanearlyfeedbackintheprogramme,verificationofcriticalrequirements(for instancerelatedtonewtechnologies)shouldbeachievedatthelowestlevelofintegrationofthe producttowhichthecriticalrequirementapplies. Allphysicalorfunctionalrequirementsforagivenproductshouldbeverifiedonthatproduct level.
b.
17
c. d. e. f. Specialattentionshouldbegiventotheselectionoflevelsofverificationofexternalinterfaces duetothepotentialimpactsontheverificationprogram. In the case of verification by test, the use of actual interfaces is preferable to the use of simulators. Duplicationofverificationactivitiesondifferentlevelsshouldbeavoided. In addition to the combination of the verification activities between the different levels, the verification of complex functional chains (e.g. operational performances and mechanisms actuation)shouldincludeintegratedendtoendtesting.
Modelsareselectedbydefiningtheoptimumnumberandtypeofphysicalmodelstoachieveahigh confidenceintheproductverification,withtheshortestscheduleandasuitablebalanceofcostsand risks. Model philosophy should be defined and frozen in project Phase A or B. Examples of model philosophies are prototype, protoflight or a mix of both, called hybrid model philosophy. This is further discussed in clause 5.2.5. The number of models is minimized and their reuse between different levels maximized to reduce costs. Parallelmodelsare utilized in order to suitably separate thetestactivitiesfromeachotherandconsequentlytoreducerisksofscheduleslippage. The Design verification (qualification main objective) is carried out on the product which is representative of the end product configuration (e.g. prototype models, flight models in case of protoflightorhybridapproach). The Workmanship verification (acceptance main objective) is carried out on the final products (e.g. flightmodels,andspares). Customerapprovalisnecessarywhendesignparameters,areverifiedusingdevelopmentmodels.
5.2.1.3.3
Step 2 - facilities
Selectionofthefacilitiesaccordingtotheirtechnicalcharacteristics,location,availabilityandcost.
5.2.1.3.4
Step 3 - resources
Identificationoftheresourcesrequired. 5.2.1.4 When (stage and event)
Theverificationstagesareselectedtakingintoaccount: a. b. c. theprojectcharacteristics, theassociatedlifecycle theadoptedmodelphilosophy
Additionally to the aspects associated with a specific requirement (category), the following rules applytotheselectionofstagesofverification: a. Whenduetothemissioncharacteristicsverificationincludesinflightactivities,theverification does not rely only on inflight activities. Requirements are verified prior to the flight to the extent compatible with the acceptable risks and with the physical possibilities (e.g. microgravity). All verifications associated with any stage should be completed prior to the start of the next stage.Inparticular,qualificationisfinishedbeforethestartofacceptance.
b.
18
5.2.2
5.2.2.1
Verification methods
General
ECSSEST1002Cclause5.2.2.1specifiesthat: a. Verificationshallbeaccomplishedbyoneormoreofthefollowingsverificationmethods: 1. test (including demonstration); 2. analysis (including similarity); 3. review-of-design; 4. inspection. Allsafetycriticalfunctionsshallbeverifiedbytest. Verificationofsoftwareshallincludetestinginthetargethardwareenvironment. Foreachrequirementverifiedonlybyanalysisorreviewofdesign,ariskassessment(part oftheVP)shallbeconductedtodeterminethelevel(major/minor)oftheimpactofthis requirementonthemission. Iftheimpactoftherequirementismajor,ariskmitigationplan(partoftheVP)shallbe definedwhichincludesacrosscheckbasedontwoindependentanalyses(intermsofmodel usedandsuppliers).
b. c. d.
e.
Test is the preferred verification method as it provides generally a higher confidence in the verificationofaproductsperformanceanddesign.Ifarepresentativetestcannotbeconducted,then ananalysissubstitutesorcomplementsit. Inselectingtheverificationmethod/levels/stagesthefollowingguidelinesareconsidered: a. b. c. d. Theselectedmethoddoesnotproduceriskstopersonnel,flighthardwareandfacilities; Theselectedmethodisfeasibleandtherequiredfacilitiesexistasfaraspossible. Theselectionofthemethodsconsidersthelevelofconfidencethatcanbeachievedwithagiven fidelity,accuracy,andvalidity; Analysis is used when flight conditions cannot be accurately simulated on the ground and/or whenitisnoteconomicallyfeasibletotesttheentirespectrumofflightconditions.Analysisand testmethodsareveryoftencomplementary. Ifseveralverificationmethodsarepossiblewiththesamelevelofconfidenceontheverification results,theselectionisorientedtominimizetherequiredeffort(impactoncostandschedule) Verification of critical requirements (for instance related to new technologies) should be achieved as soon as possible (e.g. at the lowest suitable level) to have early feedback on the programme. To bypass difficulties of testing (i.e. size of facilities, test representativeness) in presence of complex systems or to minimize expensive system testing a combined approach could be selectedincludingtestcampaignatlowerlevelandanalysisathigherlevel. Inparticularifenvironmentaltestingathigherlevelisimpracticableortoocostly,lowerlevel testing should be carried out, completed by analysis, to demonstrate compliance with higher levelrequirements. Whenmissioncharacteristicsrequireinflightverification,theverificationdoesnotrelyonon orbitactivitiesonly;requirementsareverifiedwithpropermethodspriortothefirstflight. Internalandexternalinterfaceverificationiscarriedoutattheappropriateresponsibilitylevel. Incaseoftestingtheuseofactualinterfacesispreferabletotheuseofsimulators. Thelowerlevelverificationshouldbecompletedpriortotheassociatedhigherlevelone.
e. f.
g.
h.
i. j. k.
19
l. m. n. o. Duplicationofverificationactivitiesondifferentlevelsshouldbeavoided. The verification in any stage should be completed prior of the start of the next stage, in particularqualificationshouldbefinishedbeforeacceptancestart. Finalverificationofsoftwareisperformedbytestinthetargethardwareenvironment. the verification of complex functional chains (typically operational performances and mechanisms actuation) should plan for an integrated endtoend testing, in addition to the verificationactivitiesperformedatlowerlevels Allphysicalorfunctionalrequirementsforagivenproductshouldbeverifiedonthatparticular productleveltothemaximumextentfeasibleandreasonable. Attention should be paid to avoid overtesting, since parts and equipment are being tested at parts,equipment,subsystemandsystemlevel. Verification by similarity is an exceptional process, which can be applied only if all the conditions mentioned in Clause 5.2.2.3.b are met. It cannot be considered as a standard verificationmethod.
p. q. r.
The four verification methods are not necessarily applicable or efficient for all stages (and all the stagesarenotapplicabletoalltheproducts).Thefollowingtableprovidesasynthesisofthefollowing requirementswhileaddingsomeexample. Method Qualificationstage Acceptancestage prelaunchstage inorbitstage (includingcommissioning) postlandingstage (1)Forexamplebudgets(e.g.link,power,mass). (2) In this case limited to the software change process for inflight software or ground segment software. (3)Formannedspacecraftorforgroundsegment. 5.2.2.2
Test X X X X
Analysis X
ReviewofDesign X
Inspection X X X
X(1)
X(2)
X(3)
Test
ECSSEST1002Cclause5.2.2.2specifiesthat: a. b. c. d. Verificationbytestshallconsistofmeasuringproductperformanceandfunctionsunder representativesimulatedenvironments. Theanalysisofdataderivedfromtestingshallbeanintegralpartofthetestandtheresults includedinthetestreport. Whenthetestobjectivesincludethedemonstrationofqualitativeoperationalperformance, theexecutionshallbeobservedandresultsrecorded. Atestprogrammeshallbepreparedforeachproductincompliancewithtestrequirements specifiedinECSSEST1003.
20
e. f. Thetestprogrammeshallbecoordinatedwiththeintegrationflow. Testsperformedaspartoftheintegrationflowtocheckqualityandstatusoftheinprogress configuration(includinginterfaces),havingaformalverificationpurpose,shallbeincluded inthetestprogramme. ThetestprogrammeshallbedefinedintheAssembly,IntegrationandTestplan(AITP)).
g.
AlthoughthedetailedrequirementsconcerningtestingarecapturedintheteststandardECSSEST 1003,theverificationstandardprovideshighlevelrequirementsforallverificationmethodsinorder tohaveacoherentverificationapproach Indefiningthetestprogrammethefollowingguidelinesareconsidered: a. b. c. d. e. f. g. CriticalproductsandinterfacesaretestedearlyinphaseC/Doftheprogramme. Testflowandsequencearebasedonthepossibilitytodetectpotentialfailuresanddefectsearly inthetestprogramme. Thebalanceofcostsandrisksistakenintoaccount. Workaroundplansandcontingenciesaretakenintoaccount. Reintegrationtesting(alsocalledregressiontesting)shouldbeavoided. TestfeasibilityshouldbeconfirmedinphaseAorBoftheprogramme. Thereuseofmodels,simulatorsandsupportequipmentshouldbeconsidered.
Tests are selected based on their effectiveness in verifying the specified requirements considering lessons learned, statistical data from past projects and state of the art test methods. The lessons learned and the statistical data (combining information on ground testing failures and flight anomalies)areusefultodeterminetesteffectiveness.Failuresnotdetectedduringgroundtestingcan endupasearlyflightfailures. The impacts of the deintegration and reintegration tests (also called regression tests) on the verificationprogramareassessed.Deintegrationandreintegrationareperformedforvariousreasons e.g.faultfindings,duringpostlandingphaseinthecaseofmultimissionortocarryoutmodifications orrepairs. Starting from the initial VCD, test matrices are established showing the correlation of requirements (categories)withthetesttobeperformedatthedifferentlevelsinthevariousverificationstages.They identifythetestverificationeventstobeusedforplanningpurposes. TestisfurtheraddressedintheTesthandbook. 5.2.2.3
Analysis
ECSSEST1002Cclause5.2.2.3specifiesthat: a. Verificationbyanalysisshallconsistofperformingtheoreticalorempiricalevaluation usingtechniquesagreedwiththeCustomer. Note: b. c. Techniques comprise systematic, statistical and qualitative design analysis, modelling and computational simulation.
Verificationbysimilarityshallbepartoftheverificationbyanalysis. Similarityanalysisshallprovideevidencethatanalreadyqualifiedproductfulfilsthe followingcriteria: 1. The already qualified product was not qualified by similarity. 2. The product to be verified belongs to category A or to category B (defined in Table 5-1) but no testing is required to achieve qualification. Note: Implicitly the product to be verified cannot belong to categories C and D equipment (defined in Table 5-1).
21
d. e. f. Similarityanalysisshalldefineanydifferencethatcandictatecomplementaryverification activities. AnanalysisprogrammeshallbedefinedintheVerificationPlan(VP). Ananalysisprogrammeshallbeapplicabletoqualificationandinorbitstagesonly.
Ananalysisprogrammecompatiblewiththeselectedverificationapproachisdefinedonthebasisof the verification strategies for the various requirements (categories). In defining the analysis programmethefollowingguidelinesareconsidered: a. b. c. d. e. f. g. h. i. j. k. l. m. Theanalyticaltechniqueisvalidated.Theverificationbyanalysisisdependantonthequalityof theanalyticaltechniquesandontheexperiencegainedinusingthem. Mathematical model used to perform the analysis should be verified, as far as possible, with laboratorydataorinflightdata. Whenanalysisissupportedbytestdata,testingisperformedonarepresentativemodel. Themodellingsystemusedisdescribed,anditsusagejustified. Theproductconfiguration,towhichtheanalysisapplies,isidentified. Allboundaryconditionsarestated. Allassumptionsusedintheanalysisarestated. Thefieldofinvestigationandtherangeofvalidityoftheresultsaredefined. The analytical uncertainty is taken into account such that specified performance is demonstratedwithadefinedmargin. Analysiscoversboththenominalandtheworstcaseconditions. Analysisforverificationmayuseexistinganalysispreparedforotherpurposes(e.g.designor requirementallocation) Analysiscanbeusedinsupportoftestorviceversa. Analysismaybeusedatallverificationlevels.
Starting from the initial VCD, analysis matrices are established showing the correlation of the requirements (categories) with the analyses to be performed at the different levels. These matrices identifytheanalysisverificationeventstobeusedforplanningpurposes. Sometimetheexpressionsqualificationbysimilarity,orverificationbysimilarityareusedinan improper way. Verification by similarity is not an additional verification method on top of the 4 defined in the standard. A similarity analysis can be conducted on a product in order to provide evidencethatitbelongstocategoryA(asdefinedinTable51).Ifitisachieved,thenthenewproduct isconsideredqualified(bysimilarity)asspecifiedinclause5.2.4.2.Ifthesimilarityanalysisshowsthat theproductbelongstocategoryB,thenthesimilarityanalysisshouldprovidesufficientinformationto allowdeterminingtherequireddeltaqualificationprogramme. 5.2.2.4

Review-of-design (ROD)
ECSSEST1002Cclause5.2.2.4specifiesthat: a. VerificationbyReviewofdesign(ROD)shallconsistofusingapprovedrecordsorevidence (e.g.designdocumentsandreports,technicaldescriptions,engineeringdrawings)that unambiguouslyshowthattherequirementismet. Note: b. Examples of such approved records are design documents and reports, technical descriptions, and engineering drawings
AreviewofdesignprogrammeshallbedefinedintheVerificationPlan(VP).
22
c. Areviewofdesignprogrammeshallonlybeapplicableinthequalificationstageorinthe inorbitstage
Areviewofdesignprogramme,compatiblewiththeselectedverificationapproach,isdefinedonthe basisoftheverificationstrategiesforthedifferentrequirement(categories).Indefiningthereviewof designprogramme,thefollowingguidelinesareconsidered: a. b. Theactivityshouldbecarriedoutsimultaneouslywiththeproductdesignreviews. Theactivitymayincludethereviewoflowerlevelrecords(e.g.requirementverifiedbytestata lowerlevel).
Verificationbyreviewofdesignmaybeusedatallverificationlevels. StartingfromtheinitialVCD,reviewofdesignmatricesareestablishedshowingthecorrelationofthe requirement categories with the reviewofdesign activities to be performed at the different levels. Thesematricesidentifythereviewofdesignverificationeventstobeusedforplanningpurposes. ReviewofdesignintheinorbitstageislimitedtothesoftwarechangeprocessSeeECSSEST40for moredetails. 5.2.2.5
Inspection
ECSSEST1002Cclause5.2.2.5specifiesthat: a. Verificationbyinspectionshallconsistofvisualdeterminationofphysicalcharacteristics. Note: Physical characteristics include constructional features, hardware conformance to document drawing or workmanship requirements, physical conditions, software source code conformance with coding standards.
b.
AninspectionprogrammeshallbedefinedintheVerificationPlan(VP).
Inspectioncanbecomplementarytoreviewofdesign. Aninspectionprogrammecompatiblewiththeselectedverificationapproachandmodelphilosophy is defined on the basis of the verification strategies for the different (categories of) requirement. In definingtheinspectionprogrammethefollowingguidelinesareconsidered: a. b. c. The activity should be carried out together with quality assurance tasks during the manufacturingorintegrationprocess. Theactivitymaybeperformedbythecrewduringtheinorbitverification. Inspectioncanbecomplementarytothereviewofdesign.
Verificationbyinspectionmaybeusedinallstagesandallverificationlevels. Starting from the initial VCD, inspection matrices are established showing the correlation of the requirement categories with the inspections to be performed at the different levels in the applicable verificationstages.Thesematricesidentifytheinspectionverificationeventstobeusedforplanning purposes.
5.2.3
Verification levels
a. b. Verificationshallbeaccomplishedthroughtheselectedverificationlevels. Note: Usual levels are defined in 4.2.3 Whenarequirementisfullyverifiedatlowerlevel,thetraceabilitytolowerlevel verificationevidenceshallbeidentified.
ECSSEST1002Cclause5.2.3.1specifiesthat:
23
c. Formalcloseoutofqualificationandacceptanceatlowerlevelsshallbeperformedpriorto closeoutathigherlevel.
The number and type of verification levels depends upon the complexity of the project and on its characteristics (levels are generally derived from product and specification trees). The usual verificationlevelsforaspaceprojectare: a. b. c. d. Equipment(e.g.valves,batteriesandindividualelectronicboxes); Subsystem(e.g.electricalpower,attitudecontrol,structure,thermalcontrolandsoftware); Element(e.g.launcher,satellite,groundsegment); Overallsystem(e.g.combinedspaceandgroundsegments,mannedinfrastructuresystem).
Below the equipment level there is the parts and materials level. The general requirements for the evaluation,approvalandprocurementofpartsandmaterialsaredefinedinECSSQST60andECSS QST70. The identification of the verification levels is driven by technical and programmatic considerations (e.g.functionalarchitectureandoverheadcost)havinginmindthatverificationiscarriedoutagainst theapplicablerequirementsundertheresponsibilityoftheorganizationuponwhichtherequirements areplaced.
5.2.4
5.2.4.1
Verification stages
General
ECSSEST1002Cclause5.2.4.1specifiesthat: a. Verificationshallbeaccomplishedthroughtheselectionoftheappropriatestagesonthe basisofprojectspecificityfromthefollowing: 1. qualification, 2. acceptance, 3. pre-launch, 4. in-orbit (including commissioning), 5. post-landing. Qualification,acceptanceandprelaunchstagesshallbecompletedbeforelaunch. Whentheverificationprogrammeincludesaninorbitstage,theverificationshallnotrely onlyoninorbitactivities. Whentheverificationprogrammeincludesapostlandingstage,theverificationshallnot relyonlyoninorbitactivitiesorpostlandingactivities.
b. c. d.
Eveniftheverificationprogrammeincludesaninorbitstageorapostlandingstage,theverification isconductedalsobeforelaunch(thisisshownwiththeentriesintheVerificationstagesoftheVCD relevanttoprelaunchongroundverificatione.g.qualification,acceptance). 5.2.4.2
Qualification
ECSSEST1002Cclause5.2.4.2specifiesthat: a. b. c. Inthequalificationstagetheverificationshalldemonstratethatthedesign,including margins,meetstheapplicablerequirements. Qualificationshallbecarriedoutonhardwareandsoftwarewhichisrepresentativeofthe productconfigurationintermsofdesign,materials,toolingandmethods. Thequalificationprogrammeshallbepreparedconsideringtheproductcategoryaccording toheritageasdefinedinTable51.
24
Table51:Productcategoriesaccordingtoheritage
(Table51ofECSSEST1002)
Category
Description
Qualificationprogramme
Offtheshelfproductwithoutmodifications and
subjectedtoaqualificationtestprogrammeat least as severe as that imposed by the actual project specifications including environment and produced by the same manufacturer or supplier and using the same tools and manufacturingprocessesandprocedures
None
Offtheshelfproductwithoutmodifications. Deltaqualificationprogramme, However: decidedonacasebycasebasis.

It has been subjected to a qualification test programme less severe or different to that imposed by the actual project specifications (includingenvironment).
Offtheshelfproductwithdesign modifications Modificationincludeschangestodesign, parts,materials,tools,processes, procedures,supplier,ormanufacturer Newlydesignedanddevelopedproduct.
Deltaorfullqualification programme(includingtesting), decidedonacasebycasebasis dependingontheimpactofthe modification.. Fullqualificationprogramme.
Duringthisstage,verificationactivitiesareexecutedwiththeobjectivetodemonstratethatthedesign being qualified and therefore that the flight product will fulfil the requirements in the expected environment. To cover the uncertainties in measurement and environment, margins are applied. Discipline specific margins (e.g. power, frequency, data rate, processor loading) are defined in the disciplinespecificstandards.TestmarginsandtolerancesaredefinedinthetestingstandardECSSE ST1003.Thesemarginshavealsotocovertheaspectthattheflightproducthastosurvivetheflight levels/stressesaswellastheacceptancetests. The qualification programme for Cat B product has mainly to cover the differences in the requirements,includingtheenvironment. Incaseofadifferentsupplier,changedprocessesordifferentparts,italsodemonstratesthatthefinal product still fulfils the requirements. The delta qualification programme therefore concentrates on theseaspects. Cat C products have design modifications with respect to the originally qualified design. The delta qualificationprogrammeinthiscaseconcentratesontheimpactofthesechangesonthequalification. Incaseofmajormodificationsafullqualificationprogrammeisperformed.
25
5.2.4.3
Acceptance
ECSSEST1002Cclause5.2.4.3.1specifiesthat: a. b.
Intheacceptancestagetheverificationshalldemonstratethattheproductisfreeof workmanshiperrorsandisreadyforsubsequentoperationaluse. Acceptanceshallbecarriedoutonthefinalhardwareandsoftware.
ECSSEST1002Cclause5.2.4.3.2specifiesthat: a. b. Theacceptancearticleshallbemanufacturedinagreementwiththequalifieddesign. Theacceptancearticleshallperformasthequalifiedproduct.
During this stage, verification activities are executed with the objective to demonstrate that the productunderacceptance: a. b. c. conformstoitsrelevantqualifieddesign, isnotaffectedbydefectsthatcouldbeintroducedduringmanufacturingorassembly,eitherby workmanshiporbyinadequateprocess, isabletofullyprovideitsrequiredfunctionsandperformances,asspecifiedforflight.
Thisverificationprocessappliesonhardwareandsoftwareintheirfullflightconfiguration. 5.2.4.4
Pre-launch
ECSSEST1002Cclause5.2.4.4specifiesthat: a. b. Intheprelaunchstagetheverificationshalldemonstratethattheproductisproperly configuredforlaunchactivitiesandearlyoperations. Intheprelaunchstagetheverificationshallconfirmthattheproductiscapableof functioningasplannedduringlaunchandearlyoperations.
A number of activities are usually accomplished during the prelaunch stage. These activities are needed to demonstrate that the transportation to the launch site or any storage condition have not damagedtheproduct,toputtheflightproductinitsspecificlaunchconfiguration,andtointegrateit withthelaunchervehiclewhereapplicable,dependingontheproductlevel. Test and inspection techniques are applied at thisstage. They complement the verification activities completed at acceptance, where the real flight products and interfaces now replace the use of the simulators. 5.2.4.5
In-orbit
ECSSEST1002Cclause5.2.4.5specifiesthat: a. b. Intheinorbitstagetheverificationshallensurenodegradationoccurredduringthe launch,earlyorbitphase,atperiodicalintervalsandbeforespecificoperationaluse. Intheinorbitstagetheverificationshallsupplement/confirmgroundverificationby providingoperatingconditionswhichcannotbefullyorcosteffectivelyduplicatedor simulatedonground. Intheinorbitstagetheverificationshallcharacterizethesystemunderoperational conditionsespeciallyfortheaspectsthatcannotbedeterminedbeforethelaunch. Intheinorbitstagetheverificationshallconfirmthatthespaceandgroundelementsare compatiblewitheachother. Intheinorbitstagetheverificationshallperformcalibrationandtuningactivitiesspecific tothemissionpayload. Note: The working arrangement between the elements suppliers (e.g. satellite, ground segment) and the final customer defines the share of responsibilities
c. d. e.
26
for preparing, conducting and reporting the in orbit - commissioning activities. The completion of this stage allows declaring readiness for routine operations (Phase E2-exploitation). The inorbit stage is valid for projects where, due to their characteristics (e.g. mission or inorbit operations),inorbitverificationisperformed. Thespaceelementsuppliershouldupdateitsanalysesandmathematicalmodelsusinginorbit experienceandthetelemetrymadeavailablebytheCustomer(e.g.thermal,power,aerothermal behaviourduringreentry,RFlinkbudget). Verificationatperiodicalintervalsconcernsgenerallyhealthcheck.Theperiodicityismission dependentandagreedwiththecustomer. ForGEOandLEOsatellites,thisverificationduringinorbitstageisdoneduringthecommissioning shortlyafterthelaunch. Forothermissions(e.g.moon,planets,comets,interplanetary),thisverificationmaybedelayed untilreachingthetargetedlocation(s)andenvironment(s). 5.2.4.6
Post-landing
ECSSEST1002Cclause5.2.4.6specifiesthat: a. b. Theverificationinthepostlandingstageshalladdresstheproductintegrityand performanceafterthemission. Incasetheproductisintendedtoberelaunchedtheverificationshalladdress: 1. health check, at periodical intervals agreed with the customer, during storage periods; 2. the product performance after modification, repair or replacement; 3. the readiness for reuse.
The postlanding stage is valid for projects that, due to their characteristics (e.g. multimission projects),postlandingverificationisperformed. Many projects are actually facing a return to earth or a multimission scenario (e.g. reentry demonstrators,NASASTS,theLogisticsModulesfortheISS)andinthenextfuture,itisexpectedthat the reusable launchers or the advanced crew transportation systems, including associated reentry demonstrators,willseesimilarperspectives. In this context the classical verification stages, completed with the inorbit activities, are complemented by additional postlanding verification. In the case of a simple reentry, it covers at leasttheproductintegrityandperformanceafterthemission. In case of subsequent mission, it covers at least the health checks during storage, the product performanceaftermodification,repairorreplacementandthereadinessforreuse.Forproductstobe relaunched, the verification programme is updated taking into account the previous flight verification programme and inorbit experience. This program is established by reviewing and assessing existing documentation, on the basis of the requirements for the new flight and by inspectingthehardwareandsoftwaretobereflown.
5.2.5
5.2.5.1
Models and Models Description

Introduction
ECSSEST1002Cclause5.2.5specifiesthat: a. Themodelphilosophyshallbedefinedaspartoftheoverallverificationplanning.
During the development and verification process of a product various models are used. The model philosophy defines the optimum number and the characteristics of physical models required to
27
achieveconfidenceintheproductverificationwiththeshortestplanningandasuitableweighingof costsandrisks. Thefollowingguidelines,relevantmainlytoflightelements,areintendedtohelpthedefinitionofthe modelsinvolvedintheverificationprocessandtheselectionoftheassociatedmodelphilosophy.This section starts with a description of the models (build status and use) involved in the verification process,thencriteriaareestablishedhowtoselectamodelphilosophyandexamplesoftypicalmodel philosophiesareprovided. Clause5.2.5.2describesthevariousmodels;theECSSGlossaryECSSST0001Csection3.3givesthe definitionofthemainones. 5.2.5.2 Models description General
5.2.5.2.1
Various types of models can be employed according to verification requirements. These models can either be hardware models, virtual models (software simulators and analytical models) or a combination of both (hybrid models). A short description of the major models used is given. These modelsaremaintainedunderconfigurationcontrol(exceptmodelsusedfordevelopmentpurposes). The Table 52 provides a schematic summary of the models with related objectives, representativity andapplicability.Therepresentativityofthemodelsdependsfromtheirintendeduse.
5.2.5.2.2
Mock-Up (MU)
MockUps are used in support of design definition for overall architecture analyses, configuration designandassessment,interfacecontrolanddefinition,humanfactorsandhumancomputerinterface (HCI)assessment,operationalproceduresevaluationandlayoutoptimization. Accordingtotheirrepresentativity,mockupsareclassifiedas: a. Lowfidelity:tobeusedintheinitialverificationphases(generally,mockupsforhumanfactors engineering requirement development activities or for validation of software HCI requirements). High fidelity: under configuration control in all areas where interface control and flight hardware manufacturing support is provided (e.g. area of utility routing, connector brackets andattachpoints).
b.
The MockUps can be incremental tools, i.e. they are progressively upgraded to reflect a final configuration. MockUps intended for human factors evaluation are also used in test campaigns such as parabolic flights, buoyancy and swimming pool tests. Their representativity depends on the type of test to be performed.
5.2.5.2.3
Development Model (DM)
In general the Development Models are used in the development areas of new design or where substantial redesign is performed. They are applicable to every type of product (e.g. electronic box, mechanisms, structural parts and thermal equipment) and can be subjected to functional and/or environmental testing. Development Models of subsystems are also envisaged such as: thermal control active control loop breadboards, attitude & orbit control system and guidance & navigation controlbenches.TheDMissometimesalsocalledBreadBoardmodel(BB)
28
ECSSEHB1002A 17December2010 5.2.5.2.4

Structural Model (SM)
The Structural Model is fully representative of the end product for structural aspects. It is used for qualificationofthestructuraldesignandformathematicalmodelscorrelation.Generally,thesystem Structural Model consists of a representative structure, with structural dummies of the flight equipment.Italsoincludesrepresentativemechanicalpartsofothersubsystems(e.g.mechanismsand solarpanels).TheSMisalsousedforafinalvalidationoftestfacilities,GSE,andrelatedprocedures.
5.2.5.2.5
Thermal Model (ThM)
TheThermalModelisfullyrepresentativeofthethermalpropertiesoftheendproduct.Itisusedfor thequalificationofthethermaldesignandforthecorrelationofmathematicalmodels.Generally,the system Thermal Model consists of a representative structure with thermal dummies of the flight equipment.Itincludesalsorepresentativethermalpartsofothersubsystems.
5.2.5.2.6
Structural-Thermal Model (STM)
TheStructuralThermalModelcombinestheobjectivesoftheStructuralModelandThermalModel.It consists,atsystemlevel,ofarepresentativestructureequippedwithdummiesofflightequipment.On theotherhand,theStructuralThermalModelcanalsobeaStructuralModelrefurbishedforthermal verificationpurposesafterstructuralqualification(providednopotentiallydestructivetestshavebeen performedontheStructuralModel).
5.2.5.2.7
Suitcase Model
TheSuitcaseModelisintendedtobeusedwiththegroundstationforverifyingcorrectTMreception, TC commanding and ranging. It is representative of the RF receiver and transmitter (including ranging) as well as the data handling part involved in the TM/TC protocol. This representativity is generally achieved with nonredundant EM equipment for the RF part and breadboard for the data handlingpartrunningtheflightsoftwarewiththecorrectspaceelementidentifier.SeealsoECSSE ST1003.
5.2.5.2.8
Electrical and Functional Model (EFM)
The Electrical and Functional models (sometimes called also integration models) are functionally representativeoftheendproductsinbothelectricalandsoftwareterms.Theyareusedforfunctional andinterfacetestsandforfailuremodeinvestigations.Somepartcanbesimulatedbysoftware;the restisusingcommercialparts.
5.2.5.2.9
Engineering Model (EM)
TheEngineeringModelisflightrepresentativeinform,fitandfunction,withouthighreliabilityparts and usually without full redundancy. The Engineering Model is used for functional qualification, failure survival demonstration (and parameter drift checking if military parts are used). The Engineering Model is also used for final validation of test facilities and GSE and the related procedures.
5.2.5.2.10
Engineering Qualification Model (EQM)
TheEngineeringQualificationModelfullyreflectsthedesignoftheendproductexceptfortheparts standard (military grade parts can be used instead of high reliability parts, provided they are procured from the same manufacturer). The Engineering Qualification Model is used for functional performance qualification (including verification of procedures for failure detection, isolation and recoveryandforredundancymanagement)andEMCtesting.Itmayalsobeusedforenvironmental testingiftheCustomeracceptstherisk,inthiscasetheQualificationModel(QM)rulesapplies.
29

Qualification Model (QM)
TheQualificationModelfullyreflectstheendproductdesigninallaspects.TheQualificationModelis usedforcompletefunctionalandenvironmentalqualificationtests.Itisusedonlyforequipmentand subsystemsnewlydesignedorwhenadeltaqualificationforadaptationtotheprojectisperformed. The QM sees qualification test levels and durations as specified in ECSSEST1003. Qualification Modelisnotintendedtobeusedforflight.
5.2.5.2.12
Life Test Model (LTM)
The Life Test Model is used to demonstrate by testing that the product can achieve the required lifetimeandperformtherequiredquantityofcycles.Forqualificationthetestsareperformedinthe environment specified for qualification. This model is required for mechanisms, if a protoflight approachisappliedandahighnumberofoperationcyclesarerequired.LifeTestModelscannotbe usedforflight.
5.2.5.2.13
Proto-Flight Model (PFM)
The ProtoFlight Model is the flight end product on which a partial or complete protoflight qualificationtestcampaignisperformedbeforeflight.Theprotoflightmodelsonlyseeacceptanceor protoflight test levels and durations as specified in ECSSEST1003. Limited life constraints, especiallywhenmechanismsarepresent,areevaluatedasforanyflightmodel.
5.2.5.2.14
Flight Model (FM)
The Flight Model is the flight end product. It is subjected to formal functional and environmental acceptancetesting.TheFMseesacceptancetestlevelsanddurationsasspecifiedinECSSEST1003.
5.2.5.2.15
Flight Spare (FS)
The Flight Spare is the spare end product for flight. It is subjected to formal acceptance testing. RefurbishedqualificationproductcanbeexceptionallyusedasFlightSpare.
5.2.5.2.16
Function oriented model
Thefunctionorientedmodelisdedicatedtothequalificationofparticularfunctionalrequirements.It reflectstheendproductdesignintheaspectssubjecttothequalification.Thedefinitionofthismodel depends on project characteristics and verification requirements. Examples of function oriented modelsare

aerodynamicmodels, roboticsandautomationmodels,and groundsegmentfunctionalmodels. Training model
5.2.5.2.17
The training model is dedicated to development and training of activities (including flight procedures). Therefore, it is usually a functional representative of the flight model modified to be capabletofunctionundernaturalgravity.Forexample,trainingmodelcanbeusedto:

trainflightcrewandgroundpersonnel, developandverifyprocedures, establishtrainingrecords,and performbaselinedatacollection.
30
For the ground segment, it means an environment with sufficient fidelity to allow achievement of objectives.
5.2.5.2.18
Virtual and hybrid models
Inthefunctionalandelectricaldomain,simulationmodelsareusedfordevelopmentandverification. Thesemodelsexisteitherinpuresoftwareconfiguration(simulators)orinacombinationofsoftware and hardware components. Their composition may change in course of the project life cycle. A particularcaseofsuchmodelistheSoftwareVerificationFacility(SVF)addressedinclause5.2.6.3.A detaileddefinitionisgiveninECSSETM1021A(SystemModellingandSimulation).
5.2.5.2.19
Human related models
Thesemodelsarededicatedtothequalificationofparticularhumanfactorsengineeringrequirements. Theirrepresentativityislimited,dependingonqualificationobjectives.
5.2.5.2.20
Ground segment specific models
Thesemodelsarededicatedforaparticularpurposeintheverificationprocessofthegroundsegment andoperations,forexample:
A model, composed of a subset of the ground segment plus a satellite simulator, to developandverifyprocedures,andtheHumanMachineInterface(HMI). A model to validate the telecommand (TC) and housekeeping telemetry (TM) data processing, as well as the associated procedures, on a representative TM/TC environment,beforeapplyingitontheoperationalenvironment.Inthatcase,asatellite simulatorispartofthesetup. A model to validate the payload telemetry data processing on a representative environmentbeforeapplyingitonthe operationalenvironment.Inthatcase,apayload datasimulatormayberequired,inparticularbeforethelaunch. Atrainingmodel(see5.2.5.2.16).
31
Table52:Summarymodeldefinitions
Model
MockUp(MU)
Objectives
I/Flayout optimization/ assessment Integration procedure validation Accommodation checks
Representativity
Geometrical configuration Layouts Interfaces
Applicability
System/elementlevels
Remarks
Accordingtotheir representativityMUs areclassifiedas: Lowfidelity Highfidelity(tobe maintainedunder configurationcontrol)
DevelopmentModel (DM)
Confirmationof designfeasibility
Totalconformity withfunctional electrical&S/W req.inagreement withverif. objectives(size, shape&I/Fscould notbe representative) Flightstandard withrespectto structural parameters Equipment structural dummies Flightstandard withrespectto thermal parameters Equipment thermaldummies
Alllevels
Developmenttesting Sometimeitisalso calledbreadboard (BB)
StructuralModel(SM)
Qualification structuraldesign Validationof structural mathematical model
SSlevel(structure) Sometimeitcould beconsidered systemlevelif involvesotherSS orismergedwith thesystemtest flow SSlevel(thermal control) Sometimeitcould beconsidered systemlevelif involvesotherSS orismergedwith thesystemtest flow Systemlevel
Qualificationtesting
ThermalModel(ThM)
Qualificationof thermaldesign Validationof thermal mathematical model
StructuralThermal Model(STM)
SM&ThMobjectives
SM&ThM representativity Equipmentthermo structural dummies
SuitcaseModel
Simulationof functional&RF performances
Flightdesign Commercialparts Functional representativity
Equipmentlevel Systemlevel
Spacetoground interfacetesting
ElectricalandFunctional Model(EFM)
Functional development S/Wdevelopment Procedure validation Prepareflighttest programme Closedlooptests
Functional representativity Commercialparts Simulatorsof missingparts
Alllevels
Developmentor qualificationtesting Itcouldbeconsidered somethinginbetween amockupandanEM Sometimeiscalled alsoIntegration Model
32
Model
EngineeringModel (EM)
Objectives
Functional qualificationfailure survival demonstration& parameterdrift checking
Representativity
Flight representativein formfitfunction withouthigh reliabilityparts andusually without redundancy Fullflightdesign MILGradeparts procuredfromthe same manufacturerof highreliability parts Fullflightdesign &flightstandard Flight representative withrespecttothe qualifiedfunction
Applicability
Alllevels
Remarks
Partialfunctional qualificationtesting
Engineering QualificationModel (EQM)
Functional qualificationof design&I/Fs EMC
Alllevels
Functionalqualification testing
QualificationModel (QM) LifetestModel(LTM)
Designqualification
Equipmentlevel SSlevel Equipmentlevel
Qualificationof lifetime
Modelfor mechanismsina protoflightapproach withlifetime requirements Cannotbeusedfor flight
ProtoflightModel(PFM)
Flightuse Design qualification
Fullflightdesign& flightstandard
Alllevels
Protoflightqualification testing
FlightModel(FM)
Flightuse
Fullflightdesign& flightstandard Fullflightdesign& flightstandard Flightrepresentative asnecessaryforthe limitedqualification objectives Flightrepresentative withmodificationsto allowfornormal gravityoperation Virtualorphysical flightrepresentativity asnecessaryforthe applicableverification objectives Flightrepresentative asnecessaryforthe limitedqualification objectives Representativeas necessaryforthe applicableverification objectives
Alllevels
Acceptancetesting
FlightSpare(FS)
Spareforflightuse
Equipmentlevel
Acceptancetesting
Functionorientedmodel
Qualificationagainst theapplicable functional requirements Flighttraining baselinedata
Alllevels
Qualificationtesting orientedtoaspecific functionorrequirement
Trainingmodel
Alllevels
Qualificationtesting orientedtospecificHFE requirements Compositionmay changeincourseof theprojectlifecycle Oftenreplacespure hardwaremodels
Virtualandhybrid models
Developmentand verificationofspecific aspects
Alllevels
Humanrelatedmodels
Qualificationagainst theapplicableHFE requirements
Alllevels
Qualificationtesting orientedtospecificHFE requirements
groundsegmentspecific models
Verificationprocessof thegroundsegment andoperations
Groundsegment
SeealsoECSSEST70
33
5.2.5.3 Model philosophies description Introduction
5.2.5.3.1
The model philosophy defines the optimum number and the characteristics of physical models required to achieve confidence in the product verification with the shortest planning and a suitable weighingofcostsandrisks The model philosophy is defined by means of an iterative process which combines programmatic constraints, verification strategies and the integration and test programme, taking into account the developmentstatusofthecandidatedesignsolution. ThevariousissuestobeconsideredareshowninFigure52.
Programmatic Constraints Schedule / Cost Industrial Architecture Reviews Interfaces Customer requirements
Verification Strategy Requirements Categories Verification methods Verification levels Verification stages
Model Philosophy
Integration and Test programme Test Requirements Test Sequence Test Configurations Test Facilities
Development Status New Technologies Design Qualification Heritage Potential Suppliers
Figure52:ParametersforModelPhilosophydefinition
Thestartingpointisthedevelopmentstatusoftheproducts.Developmentofanewproductwithnew technology requires an extensive model philosophy which allows full qualification. On equipment level, breadboards and development models are used to identify problems at an early stage. For qualificationadedicatedmodelisused.OnsystemlevelEMsareusedwhichhaveononesideahigh fidelitybutavoidthecostandscheduleimpactofhighreliabilitypartsinQMsandFMs. The model philosophy is also influenced by the verification and the test strategy. For specific verificationtasks,specifictestmodelscanberequired.
34
Ontheotherhandthemodelphilosophystronglyinfluencestheschedule.Asequentialuseofamodel on different levels and for different purposes can increase the schedule duration, whereas parallel workonvariousmodelscanshortenit. Also industrial structure may affect the model philosophy, in particular additional model maybe necessary.Itisgoodpracticetohaveclearinterfaces,responsibilitiesanddeliveries Theselectionofamodelphilosophyforaspecificprojectisalwaysabalancebetweenthecostandthe schedule of the program and the risk which can be taken. Cost increases if specific models are necessaryforearlyverificationorcheckofcriticalaspectsSeveraltypesofmodelphilosophiescanbe employedaccordingtoverificationrequirements.Ashortdescriptionofthemajormodelphilosophies utilizedintheverificationprocessisgiveninwhatfollows.
5.2.5.3.2
Prototype philosophy
This approach is generally used in projects for which all affordable measures are taken to achieve minimumrisk.Theusualcharacteristicsoftheseprojectsare: a. b. c. neworcomplexdesign, impossibilitytoberecoveredorrepairedafterlaunch,and specialmissionrequirements.
The prototype approach makes extensive use of the aforementioned defined models to cover verificationneeds.Thedisadvantageishighcost.Theadvantagesofthisapproachare a. b. c. d. lowrisks, capabilitytoperformparallelactivitiesondifferentmodels, completionofqualificationactivitiespriortoacceptance,and capabilitytouseQMorEQM(seeTableB1)asintegrationspareduringhigherlevelactivities.
Onthebasisofprojectrequirements,therelatedmodelphilosophyistailored.
35
Figure53:ExampleofUnmannedprojectmodelphilosophy
Figure 53 and Figure 54 show examples of prototype philosophies for unmanned and manned projects respectively. In the figures the different models and their flow at several verification levels togetherwiththerespectivetestactivitiesandthefinalutilizationareidentified. In particular the Figure 53 shows the common case in which, after the thermal and structural qualification, parts of the STM (namely structure and thermal control) are utilized to complete the satellite level EM, in addition to EM/QM equipment. It is important to note that after the system electricalorfunctionalqualificationtheEMisusedforgroundsupporttoflightoperation.Feedback fromqualificationontheFMmanufacturingisalsotakenintoaccount. Figure 54 shows an example of model philosophy for a manned transportation project, in which element level mockups are utilized for interface and layout optimization and human factor engineering dedicated verification. High fidelity mockups are used in conjunction with IM (i.e. specialcaseofEFM)forcrewtrainingonground. In addition, after system functional, thermal and structural interface verification between elements, EQMandSTMareusedforflightsimulationonground.TheFMissubjectedtoanorbitalflighttest forfinalinorbitverification.
36
Figure54:ExampleofMannedprojectmodelphilosophy
5.2.5.3.3
Protoflight model philosophy
Thisapproachisappliedtoprojectswhosecharacteristicsare: a. b. c. nocriticaltechnologyisemployedinthedesign, qualifiedproductsareextensivelyused,and compromiseispermittedtoreducecostbyacceptingamoderatelevelofrisk.
The pure protoflight approach is based on a single model (protoflight model: see Figure 55) to be flownafterithasbeensubjectedtoaprotoflightqualificationandacceptancetestcampaign(seeECSS EST1003fordetails). Theadvantageofthisapproachisitslowercost.Thedisadvantagesare a. b. c. d. increasedrisk, serialactivityflowonthesamemodel, mixedqualificationandacceptanceactivities,and nointegrationspares.
Intheeventofrecurringunitsthefollowingistakenintoaccount:
37
a. b. TherecurringunitcanbeFMonlyifthereisnomodification,orifmodificationsareminorto theextentthatnodeltaqualificationtestisnecessary. OtherwisetherecurringunitisPFM.
Figure55showsanexampleofprotoflightmodelphilosophyforaprojecthavingalsoincorporated subsystemactivitiesintothesystemresponsibility,formallydeletingthesubsystemverificationlevel. Inthisexample,EQMisutilizedatequipmentlevelforprequalification(whenevernecessary).
Figure55:ExampleofProtoflightmodelphilosophy
5.2.5.3.4
Hybrid model philosophy - Hybrid model philosophy (hardware oriented)
The hybrid philosophy is a compromise between prototype and protoflight approaches. The hybrid modelphilosophyisusedinprojectswhereadvancedqualificationactivitiesareperformedinareasof newdesignorinareashavingacriticalimpactontheverificationprogramme.Thehybridapproach always results in a protoflight model be flown after a protoflight test campaign whose scope is reduced with respect to that of the pure protoflight approach (see ECSSEST1003). Specific qualification tests in the critical areas are carried out on dedicated models (see Figure 56). In these areas only acceptance testing is performed on the PFM. The advantages and disadvantages of this approach lie between those of the prototype and the protoflight approaches in terms of risks, costs and schedule. It represents agood compromise;infact thisis the reason whyit is often selected. In particular,inthehybridapproachitisfeasibleto a. performsomeparallelactivities,
38
b. c. useQMandEQM(ifplannedinthemodelphilosophy)asintegrationsparesduringhighlevel activities,and conformtothedeliverydatesofhighreliabilitycomponentsandaccommodatepossibleuseof commercialcomponents.
Figure 56 shows an example of hybrid model philosophy for a scientific satellite in which payload instrumentverificationlevelssimilartothespacecraftsubsystemverificationlevelsaredefined.Itis importanttonotethat a. b. c. d. e. thedecouplingoftheSTMactivitiesfromtheEMactivitiesenablesprogrammeflexibilityand reductionofschedulerisks, the protoflight approach for the instruments advances availability of the Payload EM for the satellitefunctionalqualificationtestcampaign, theEQMorPFMisqualifiedatequipmentlevel,dependingonitsdevelopmentstatus, a suitcase model and the software validation facility at satellite level can be used to verify specificinterfaceperformance,and amockupstructurecanbeusedfortheEMconfiguration. Hybrid model philosophy (including virtual models)
5.2.5.3.5
Currentdevelopmentinmodellingandsimulation techniques supports partial or total replacement of the EMbysoftwaremodels.Thisapproachisalreadyusedintheengineeringanddesignphase(see ECSSETM1021A(SystemModellingandSimulation).Inthisapproachthesystemstartswithapure numerical representation in which critical components are gradually replaced by hardware product (breadboardsorEMs).ThisconfigurationisoftencalledFunctionalVerificationTestbench(FVT)asit providesthemeanstoperformthefunctionalverificationnormallyperformedonanEM. The advantage is a continuous flow from design into verification which avoids a break due to unavailablehardware.Thedisadvantageisthattherealwaysremainsalevelofuncertaintynomatter howwellthesimulationrepresentstheactualfinalproduct. ThisapproachalsoallowsthereuseofthestructurefromtheSTMafterrefurbishmentfortheflight model,resultinginlowercost.
5.2.5.3.6
Perspectives in Model Philosophy
Thechoiceofmodelphilosophyisstronglyinfluencedbythetypeofproject.Inthecaseofoneofa kindprojects(typicallyscientificmissions),thetendencyistogointhedirectionofapureprotoflight approachsupportedbyvirtualmodels(wherethequalificationcampaigniscarriedoutbyanalysisor directlyontheflighthardware).Inthecaseofaseriesofsatellites(e.g.constellation),apureprototype approachisnormallyusedwhereaQMundergoesafullqualificationtestcampaignandtherecurring FMsseeonlyalimitedacceptancecampaign(thisincreasesthefrequencyoftheproduction). 5.2.5.4 Product matrix
Onthebasisoftheselectedmodelphilosophyandofthequalificationstatusoftheproduct,aproduct matrixisprepared.Theproductisnormallyclassifiedaccordingtotheproductcategoriesdefinedin Table51.Thetypeandtheextentofthetestprogrammesforeachcategoryalsodependontheproject modelphilosophy.TherequirementsforthetestprogrammedefinitionareprovidedinECSSEST10 03.Theproductmatrixidentifiesforeachproducttherelatedqualificationstatusandthemodelstobe used. Table51showsanexampleofproductmatrixatsatellitelevel.
39
Figure56:ExampleofHybridmodelphilosophy
40
Table53:Exampleofaproductmatrixasviewedwithasatelliteperspective
No. Subsystem/Instrument
1 2 3 Structure Thermal control AOCS Coarse sun sensor Star tracker Star tracker electr. Gyro package Gyro electronic Reaction wheel Wheel drive electronic Actuator gyro electronic Flap assembly Control electronic RCS Tanks Thrusters Thrusters bracket Latch valves Filter Flow meter Fill & drain valves Valve brackets Pressure transducers Pipework Power Power control unit Battery regulator unit Battery mgt unit Pyro drive unit Power distribution unit Battery OBDH Central terminal unit Common pulsed distr. unit Digital bus unit Intelligent control unit Mass memory unit Remote bus interface Solar array Deployable panel Yokes Mid-panel body TT&C Transponder RF distribution unit Antenna Harness Gradio instrument GPS Boom Magnetometer
Qual.Status STM EM PFM SP Remarks

D D A A A A A A A A D D B(A) A D A A D A D A D C A A C D A A A A C(D) D(C) A D D D C A D D D D 1 1 2* 3* 3* 1* 4* 1* 1* 1* 2* 1* 8* 12* 4* 11* 1* 1* 3* 2* 3* 1* 1* 1* 1* 1* 1* 2* 1* 1* 4* 2* 1* 2* 2* 1* 3* 2* 1* 3* 1 1* 1* 1* 1* * 1 1 1 1 1 1 1 1 1 1 8** 1 4** 1 1 1 1 2** 1 1** 1** 1 1 1** 1 2 1 1 4 2** 1 2 1 1** 1 1** 1 1 1 1 1 1** 1 1 1 2 3 3 1 3 4 1 1 2** 1** 8 12 4 11 1 1 3 2 3 1 1 1 1 1 1** 2 1 1 4 2** 1 2 2 2 1 2 1 3** 1 1** 1** 1 1** * 1 * STM Spare * STM Spare * Dummy * Dummy * Dummy * Dummy * Dummy * Dummy * Dummy * Dummy * Dummy ** PFM * Dummy ** PFM * Dummy ** from STM * Dummy * Dummy ** from STM * Dummy * Dummy * Dummy * Dummy * Dummy ** from STM * Dummy * Dummy ** from STM * Dummy ** EQM * Dummy * Dummy * Dummy ** EQM * Dummy ** PFM * Dummy * Dummy * Dummy * Dummy * Dummy ** EQM * Dummy ** PFM * Dummy * Dummy * Dummy ** from STM * Dummy * Dummy * Dummy * Dummy ** 1PFM ** 2EQM * Dummy ** PFM * Dummy ** PFM * Dummy ** from STM * Dummy ** PFM
9 10 11 12 13
41
5.2.6
5.2.6.1
Verification tools
General
ECSSEST1002Cclause5.2.6.1specifiesthat: a. b. c. Toolstobeusedtosupporttheimplementationoftheverificationprocessshallbeidentified. Allverificationtoolsshallbeverifiedfortheirintendeduse. Thedegreeofverificationappliedtotoolsusedtosupporttheverificationprogrammeshall beestablished. Note: d. This requirement does not imply that formal verification is performed for all verification tools (e.g. tools of common use).
Formalverificationproceduresshallbeestablishedandappliedtotoolswhicharespecified asdeliverableitems.
Verification tools include Ground Support Equipment, simulators, virtual models, test benches, analyticaltools,testfacilities,communicationtoolasrequiredforthescopeofECSSEST50standards (e.g.suitcase,NDIU),clampband,TMrecorder,RFrecorder,toolstosupportSVT,toolstoexchange data between satellite and Mission control centre before launch (e.g. NDIU), database, TM/TC list, satellitesimulatorandinorbit/commissioningtools.Thestandardandthehandbookcannotaddress thedetailsofallofthemindividuallybutgiveshighlevelrequirementsapplicabletoaclassoftools. Sinceverificationresultsstrictlydependonthequalityofthesetools,specialattentionispaidtotheir designandverification. The compatibility between system and lower level verification tools should be ensured to enable systemactivitiestobebuiltuponthenextlowerlevelactivities(e.g.reuseoftestprocedures). 5.2.6.2
Ground Support Equipment (GSE)
ECSSEST1002Cclause5.2.6.2specifiesthat: a. b. c. AllGroundSupportEquipment(GSE)shallbeverifiedunderexpectedenvironmental conditionsandoperationalconstraints. ThecompatibilityoftheinterfacesoftheGroundSupportEquipment(GSE)withflight productsandfacilitiesshallbeverifiedbytest. ThepreventionofdamageontheflightproductduetoGroundSupportEquipment(GSE) failureshallbeverified. Note: d. For hazards to personnel, flight hardware, facilities and environments related to GSE, see ECSS-Q-ST-40.
GroundSupportEquipment(GSE)thatismodifiedorusedinanewapplicationshallbe reverifiedorrevalidated.
Space segment Ground Support Equipment (GSE) are used to support assembly, integration, test, handling, transport, storage, launch campaign and postflight activities. GSE that connects to space equipment follows the same interfacing standards as the flight equipment and has adequate protection to prevent damage to the space equipment (mechanically and electrically). In particular matinganddematingofphysicalconnectionsiscloselymonitored. GSEisalsobuilttocomplywithsafetystandardsimposedbythecountriesinwhichitwillbeused. GSEisvalidatedforuseonFMspacecraftthroughuseofsimulatorsandearliermodelsofthespace element. AnyequipmentpartoftheoperationalGroundSegmentinterfacingphysicallywithaflightproduct (e.g.duringaprelaunchcompatibilitytest)hastofollowtherequirementsonGSEaswell.
42
5.2.6.3
Software validation facility (SVF)
ECSSEST1002Cclause5.2.6.3specifiesthat: a. b. TheSVFshallbeverifiedbycomparingtheperformanceofthesimulationmodelswiththe specifiedperformanceoftheproductorenvironmenttobesimulated. AnyflighthardwareorsoftwareproductsimulatedbytheSVFshallbefinallyverified againstthemeasuredperformanceoftheactualflightproduct.
The Software Validation Facility (SVF) is one of the test benches capable to support all phases of onboardsoftwaretestandvalidationincluding: a. b. modelling of the software operating environment (including the capability for margins and errorinjection), verification of the onboard software in operational conditions, using nonintrusive methods, debuggingandtroubleshootingofonboardsoftwareTheSVFisusedpriortotheintegrationof the software into the target hardware during the software development activity, as a tool to supportindependentsoftwarevalidationandtosupportsoftwaremaintenance(e.g.duringin orbitstage). Simulators
5.2.6.4
ECSSEST1002Cclause5.2.6.4specifiesthat: a. Simulatorsshallbevalidatedtodemonstratethatthesimulatorcharacteristicsare representativeofthesimulatedproducttotheextentrequiredfortheverificationtobe supported.
Simulatorsareusedatalllevelstosimulateproducts,functions,environmentsorinterfacesinabsence of the real hardware and software during integration and test activities. Simulators of physical characteristics (e.g. 3D digital mockups) are used to support integration activities in terms of accessibility demonstration, handling, interfaces with launcher, GSE and facilities etc. Simulators of functionalcharacteristics(e.g.virtualfunctionalmodels)areusedtosupportverificationactivitiesin termsofsimulatingmissingequipment,testprocedurevalidation,supportequipmentinterfaces,etc. Simulators are also used whenever the actual system constituents are not available. Example of simulatorsandtheirusescanbe:

I/Fsimulators:structuralinterfacedevices,integrationtesting. Environmental simulators: environmental testing, operational scenario validation (e.g. solarchambers,watersubmersionmodel). System(fullorpartiale.g.satellite)simulators:operationalscenariovalidation,procedure verification,operationstraining,missionsimulations,jointintegratedsimulations.
Dependingontheindividualmissionandpurpose,modelfidelitycanrangefrommockuptosimple frontendfidelityortoflightrepresentative. 5.2.6.5
Software tools for verification by analysis
ECSSEST1002Cclause5.2.6.5specifiesthat: a. b. Suitabilityofpreviouslyvalidatedanalyticalsoftwaretoolsshallbeassessedforthe intendedapplication. Nonvalidatedanalyticalsoftwaretoolsshallbesubjectedtoavalidationprocesspriorto theiruse.
43
Software tools are utilized to carry out the analytical verification in domain such as thermal, mechanical, fluid dynamics, optical, EMC, flight dynamics andlink budget. The use of existingand validatedtoolsisthepreferredapproach. 5.2.6.6
Integration & test facilities and test tools
ECSSEST1002Cclause5.2.6.6specifiesthat: a. Thecapabilityoftheintegrationandtestfacilitiesandtesttoolstoperformtheirintended functionintermsofperformanceandcalibrationshallbeverifiedaspartoftheoverall integrationandtestprocess. Note: See ECSS-Q-ST-20-07 for test facilities.
Integrationandtestfacilitiesandtesttoolsareusedtosupporttheintegrationandtestprogrammeof thespaceandgroundsegment,aswellasatsystemlevel.
5.2.7
5.2.7.1
Verification process phasing

General
ECSSEST1002Cclause5.2.7specifiesthat: a. b. c. d. Theverificationprocessshallbephasedwiththeprojectlifecycle,inaccordancewith ECSSMST10 Verificationplanningtoassessfeasibilityandsupportprogrammaticsshallstartinthe earlyphases(e.g.duringphaseA). Thepreliminaryverificationplanningshallcoverallproductsandrequirementsbytheend ofphaseB. VerificationplanningshallbecompletedbytheendofPhaseC. Note: e. f. g. Covering all verification stages e.g. pre-launch, in-orbit (including commissioning) and post landing.
Verificationexecutionandreportingshallbeincrementallycarriedoutthroughtheproject lifecyclestartingfromphaseC. Verificationcontrolshallstartwiththeinitialissueoftheverificationcontroldocument (VCD)duringphaseB. Verificationcloseoutstatusshallbeassessedandapprovedbythecustomerforeach productattheendofeachstage. Note: E.g. qualification close out status at the end of the qualification stage during the Qualification Review (QR).
On the basis of the logic of the verification process, a verification planning that synchronizes the verification activities with the project milestones and programmatic constraints is established and agreedwiththecustomer. Figure 57 shows an example of the verification process with its output in relation to the project phasesandmilestones.
44
PHASE A
PHASE B
PHASE C
PHASE D
PHASE E
PHASE F
FEASIBILITY PROJECT LIFE CYCLE (ECSS-M-10)

REQ ASS & VERIFIC PHILOSOPHY DEFINITION
PRELIMINARY DEFINITION
DETAILED DEFINITION
PRODUCTION
UTILIZATION
DISPOSAL
VERIFICATION PROCESS
VER. REQ.S IDENTIFICATION & ALLOCATION VERIFICATION PLANNING
EQUIPMENT & SS DEVELOPMENT TEST SYSTEM DEVELOPMENT TEST EQUIPMENT SS & SYSTEM ANALYSIS EQUIPMENT SS & SYSTEM ROD EQUIPMENT SS & SYSTEM INSPECTION EQ. SS & SYSTEM QUALIFICATION TEST EQ. SS & SYSTEM ACCEPTANCE TEST
LAUNCH CAMPAIGN IN-ORBIT VERIFICATION
RECOVERY & POST LANDING VERIFICATION
VERIFICATION IMPLEMENTATION CONTROL AND REPORTING
PROJECT MILESTONES (ECSS-M-10) MAJOR VERIFICATION OBJECTIVES
PRR
SRR
PDR
CDR
QR
AR ORR
LRR
CRR
ELR
VERIFICATION REQ.S & VERIFICATION PLANNING REQ.S ASSESSMENT DEVELOPMENT AND VERIFICATION PHILOSOPHY
ANALYSIS & ROD COMPLETION QUALIFICATION TEST START
QUALIFICATION COMPLETION ACCEPTANCE TEST START
OPERATIONAL READINESS REVIEW
COMMISSIONING COMPLETION
RICOVERY & POST LANDING VERIFICATION COMPLETION
DEVELOPMENT TEST AND PRELIMINARY ANALYSIS & ROD
ACCEPTANCE COMPLETION DELIVERY FOR LAUNCH
LAUNCH VERIFICAITON COMPLETION
DISPOSAL RETRIEVAL RE ENTRY READINESS
Figure57:Exampleofverificationprocessphasingwiththeprojectlifecycle
45
5.2.7.2
Phase A
Duringthefeasibilityphase(PhaseA)theverificationactivitiesarefocusedontheassessmentofthe general project requirements and on the definition of the development and verification approach, includingthemodelphilosophyandtheassociatedproductmatrix. The results are discussed at the Preliminary Requirement Review (PRR) in order to assess the feasibilityofthedevelopmentandverificationprogramme. Theverificationpersonnelshouldbeinvolvedinordertofollowaconcurrentengineeringapproach whichavoidsseparationbetweendesignandverification. 5.2.7.3 Phase B
Duringthepreliminarydefinitionphase(PhaseB)inparallelwiththesystemdefinitionanddesign, particulareffortisspentinsupportingtherequirementsgenerationandallocationinordertohavea consistentsetofverifiableandtraceablerequirementsatalllevels.Thisworkincludesthepreparation of verification matrices that form the basis of subsequent verification planning and control. In particular, the environmental requirements are used as an input to generate the project test requirementspecificationapplicabletothedifferentverificationlevels. The applicable requirements may be grouped in categories and, for each (group of) requirements, a verificationstrategyisgeneratedbasedonthedetailedverificationmethods,levelsandstages,andthe coherenceoftheoverallverificationapproachischecked.Thesestrategiessupporttheidentificationof theverificationtasks(intermsofobjectives,characteristics,successcriteriaandsupportingtools),that form the core of the assembly integration and verification plan. The same strategies are inputs for lower level planning. The verification approach is also included as fundamental part of the System EngineeringPlan(SEP). Usually,inPhaseB,lowerlevelactivitiesarealsoinitiated.InparticularsomeC/Ddevelopmenttests are anticipated for critical items. In addition, it is a good practice to prepare the verification control documents at the different levels, in order to arrive to a more reliable phase C/D programmatic assessment.TheoutputofphaseB,inparticularverificationrequirementsandplanning,arediscussed at the System Requirement Review (SRR) and at the Preliminary Design Review (PDR) in order to freezesystemdesignandimplementationconcepts. 5.2.7.4 Phase C
Withthestartofthedetaileddefinitionphase(PhaseC)thedetaileddesignisinitiated,soparticular attention is paid to accessibility, testability, handling and transport in order that integration can be performed in the most effective way and that the GSE design can be optimized. In this phase, developmenttestsarecarriedout. Preliminaryverificationbyanalysisandreviewofdesignareexecutedatlowerlevelsandtheresults discussed at the relevant Preliminary Design Review (PDR). During the same phase the equipment manufacturingstartsonthebasisofthefrozendesign. Verificationbyinspectionactivitiesstartduringthelowerlevelmanufacturingprocess.Theactivities related to the procurement of the planned verification tools are also initiated and their availability assuredfortherelevantactivities. The integration activities on the system models (e.g. STM and EM) start in accordance with the relevantintegration&testspecificationsandprocedures. The system monitoring and control of lower level verification activities is continued in parallel and resultsarefedtotheverificationdatabase.
46
ThephaseCisnormallyterminatedwiththecriticaldesignreview(CDR)whereanalysisandreview ofdesignactivitiesarecompletedandqualificationtestsareterminatedatlowerlevelsandinitiatedat higherlevel.UsuallytheCDRauthorizestheflightunitmanufacturing(i.e.thestartofthenextphase). 5.2.7.5 Phase D
Theproductionphase(PhaseD)completesthequalificationandacceptanceactivitiesfromthelowest to the highest levels. In particular integration and test are carried out and controlled through the relevantreviewsandthecorrespondingverificationreportsareprepared. TheverificationcloseoutisdocumentedthroughtheVerificationControlDocuments(VCD),frozen by the Verification Control Boards (VCB). They are presented at the Qualification Review (QR) and Acceptance Review (AR) which declare the completion respectively of the qualification and acceptance activities. For a multimission project, a multimission qualification review is often additionallyidentified. The part of the Verification Plan (VP) dealing with inorbit verification (and in particular the commissioning)isrefinedandreviewedattheORR. 5.2.7.6 Phase E
The utilization phase (Phase E) includes launch campaign and commissioning inorbit verification. The evaluation of the verification results of the prelaunch campaign is addressed at the Launch ReadinessReview(LRR),whiletheevaluationoftheverificationresultsoftheLEOPandearlyinorbit stageareaddressedattheCommissioningResultReview(CRR). Additionalreviewsmaybenecessarywheninorbitverificationincludesdelayedactivitiesassociated toeventsofparticularmission(e.g.interplanetarymission). Theverificationcloseoutisdocumentedthroughtheverificationcontroldocuments(VCD),frozenby theverificationcontrolboards(VCB). 5.2.7.7 Phase F
During the disposal phase (Phase F), the reentry and reorbiting activities are authorized with an EndofLife Review (ELR) and the recovery and post landing verification are evaluated during a dedicatedreview. 5.2.7.8 Verification flow
AdetailedflowoftheverificationactivitiesisshowninFigure58,Figure59andFigure510.
47
.
Figure58:Verificationactivitiesflow(PhasesA/B)
48
Figure59:Verificationactivitiesflow(PhasesC/D)
49
Figure510:Verificationactivitiesflow(PhasesE/F)
50
5.3
5.3.1
Verification execution and reporting

General
a. b. c. Thesuppliershallassignclearresponsibilityfortheimplementationoftheverification programme. TherequirementsforthetestpreparationandexecutionincludingTestReadinessReview (TRR)andPostTestReview(PTR)shallbeasperECSSEST1003 Whennonconformityisdetectedduringtheverificationprocess,aNonconformanceReport (NCR),inconformancewithAnnexAofECSSQST1009,shallberaisedandprocessed accordingtoECSSQST20 Theverificationresultsshallberecordedbythesupplierinreportsforreviewbythe VerificationControlBoard(VCB)throughtheVCD.
ECSSEST1002Cclause5.3.1specifiesthat:
d.
The verification process activities are incrementally performed at different levels and in different stages applying a coherent bottomup strategy and utilizing a suitable combination of different verificationmethods.Inparticulartheverificationbytestiscarriedoutondifferentphysicalmodels inagreementwiththeselectedmodelphilosophy.Whendoingthis,thefollowingshouldbekeptin mind: a. b. The Nonconformance review board (NRB) evaluates the impacts on the verification programme. Afailurequestionnaireshouldbeusedtocollectstatisticalinformationforentryintoadatabase containingverificationlessonslearntasaresultofverificationactivities.
Theverificationcontrolboard(VCB)isdefinedinclause5.4.2. Anexampleofverificationteamresponsibilitiesisgiveninclause5.3.2. Theverificationprocessexecution&reportingensures: a. b. c. d. e. traceability of all requirements to the verification process elements (methods, levels, stages, documentation,closeout,etc.), visibilityofcoherencebetweenproductsandlevels, monitoringoftheverificationprocessthroughouttheprojectlifecycle, identificationofimpactsatthevariouslevelsincaseofchangeofrequirementsorcriticalitys duringlowerlevelverification,and integrationintothehigherlevelofthelowerlevelverificationdata.
5.3.2
5.3.2.1
Example of verification team responsibility and interfaces

Verification team responsibility
Theverificationteam,irrespectiveofthespecificcompanyorganization(i.e.thefactthatitsdutiesare performedbyoneormoregroupsinthecompany)isresponsiblefor: a. b. c. verificationmanagementandinterfaceswiththecustomerforverificationaspects; contributiontoprojectreviews; requirementallocationandtraceabilitysupport;
51
d. e. f. g. h. i. j. k. l. m. n. o. p. q. thepreparationoftheVCDintermofmethods,levelsandstagesdefinition; thepreparationoftheverificationphilosophyandVP(ortheverificationpartoftheAIVplan); thereview/approvaloftheAITPlan(ortheAITpartoftheAIVPlan) VCDpopulationandverificationdatabasemanagement; providingthechairmanfortheverificationcontrolboard; themonitoringoflowerlevelverificationdocumentation; participationinlowerdesignandtestreviews; thereviewandapprovaloflowerverificationdocumentation; thepreparationoftestspecificationsandthereview/approvaloftheTestProcedure; thepreparationofthereviewofdesign,analysisandinspectionprocedures; providingthechairmanforthetestreviewboards(TRRandPTR); evaluatingtheintegrationandtestexecutionandparticipationinthenonconformancereview board(NRB); thereview/approvaloftest,analysis,inspectionandReviewofdesignreports thepreparationoftheverificationreports; Relationship with specific engineering disciplines
5.3.2.2
Coordinationandcoherenceofthecontributionofspecificengineeringdisciplinestotheverification processisassuredbytheverificationteam.Inparticularthefollowingfromthespecificengineering disciplinesisnormallyenvisaged: a. b. c. d. e. f. g. h. i. j. k. l. supporttoensurethattherequirementsareverifiable; ensure high level requirements decomposition, when necessary, to have individually measurableparameters; supportinthepreparationoftheVCDintermofmethods,levelsandstagesdefinition; embeddingtheverificationapproachinsidethetechnicalspecification; supporttoverificationcontrolboard(VCB); supportintestspecificationspreparation; participationinlowerlevelverificationmonitoring; reviewandapprovaloftestprocedures; participationinreviews; monitoringofsystemintegrationandtestexecutioninordertoevaluatetestresults; executionofanalysisandreviewofdesign,andpreparationoftherelevantreports; supportinphaseE/Fverificationrequirementsgeneration. Relationship with product assurance and quality control
5.3.2.3
The verification team works in cooperation with the product assurance andquality control team. In particular the following support from the product assurance and quality control is normally envisaged:
52
a. b. c. d. e. f. supportinthepreparationoftheVCDintermofmethods,levelsandstagesdefinition; participationinlowerlevelverificationmonitoring; participationinreviews; monitoringofintegrationandtestexecutionandchairingofNRB; executionofanalysisandinspection,andpreparationoftherelevantreports; monitoringofphaseE/Foperations. Relationship with project management and product/quality assurance
5.3.2.4
The verification team works in cooperation with the project management and product/quality assuranceteams.Inparticularthefollowingsupportisnormallyenvisaged: a. b. c. d. e. f. supportinverificationplanningandmodelphilosophy; supportinmonitoringandcontrolofresourcesandschedule; supportinmanagementofchanges; preparationoftestconfigurationlist; participationinlowerlevelverificationmonitoring; participationinreviews.
5.4
5.4.1
Verification control and close-out

General
a. b. c. d. TheimplementationoftheverificationprocessshallbecontrolledbytheVerification ControlBoard(VCB). Theverificationprocesscontrolshallbesupportedbyacomputerbasedverification database. Theverificationdatabaseshallbedeliveredtothecustomerinanelectronicformtobe agreedwiththecustomer. Thesuppliershallprovidetothecustomerverificationevidenceforthecustomers applicablerequirementsagreedtobeverified,independentlyfromthelevelwhere verificationhasbeenaccomplished.
Theverificationcontrolboard(VCB)isdefinedinclause5.4.2.Theverificationprocessiscontrolledin its execution and declared completed by the Verification Control Board (VCB) when, based on objective evidence, the product is verified against the identified requirements and the associated verificationobjectivesfullyreached. Theuseofacomputerbaseddatabaseenablesimmediateandflexiblereportingofdatainsupportof the verification documentation, avoidance of repetitive jobs and minimization of errors. It should supportthewholeverificationprocessandthuscontainfortherequirementstobeverifiedatleastall the information to be published in the VCD. It should also allow exchanging or sharing these data between customer and supplier. The content and format as deliverableis specified andagreed with thecustomer. Theimplementationoftheverificationprogrammeiscontrolledandmonitoredfollowing:
53
a. b. A daybyday verification control approach oriented to identify potential problems, to reduce theriskofcostincreaseandscheduleslippage. Formalcontrolandreviewboards(TRR,PTRandVCB).
InorderfortheVCDtobereviewedatcustomerlevel,itisnecessarytohaveadequatesynthesisofthe verificationcloseoutstatusasstatedintheDRD.
5.4.2
Verification control board (VCB)

a. AVerificationControlBoard(VCB),withparticipationofcustomerandsupplier representatives,shallbeestablishedtoincrementallyassesstheachievementsandthestatus oftheverificationprocess. Note: b. The VCB is set-up in relation to the complexity and the extents of the verification activities.
TheverificationprocessshallbeconsideredcompletedwhentheVerificationControlBoard (VCB)confirmsthat: 1. documented evidence is recorded in the VCD, 2. identified requirements have been verified 3. associated product verification objectives are reached TheconclusionsoftheVCBshallbesubmittedforapprovaltothecustomerscontractual authority. TheVerificationControlBoard(VCB)shallassesstheverificationstatuswithaperiodicity agreedwiththecustomer,alongtheprojectlifecycle. Note: The results of the VCB are at least presented on the occasions of project reviews as defined in ECSS-M-ST-10.
c. d.
e.
TheVerificationControlBoard(VCB)shallendorsethefinalissueoftheVerification ControlDocument(VCD).
TheVCBmeets,alongtheprojectlifecycle,withaperiodicityagreedbetweencustomerandsupplier assoonastheevidence,oftheverificationcloseout,isavailable(asaminimumintheoccasionsofthe projectreviews).Inthesemeetingsthesuppliershowstheverificationstatusevidenceandasksforthe concurrenceofthecustomer. OthermembersoftheVCBarenotspecifiedinthestandard,butshouldincluderelevantexpertsfrom thesupplierandcustomerandQArepresentatives.
5.4.3
Re-verification
a. TheextentofthereverificationtobeperformedshallbedeterminedbySupplierandagreed withthecustomer,inthefollowingcases: 1. failure and repair as decided by Non-conformance Review Board (NRB); 2. unplanned disassembly or demating; 3. refurbishment, maintenance or design changes; 4. changes of requirements after initial verification; 5. long duration storage; 6. flight use of qualification hardware. TheVerificationControlDocument(VCD)shallbeupdatedbythesuppliertorecordas open,thoserequirementssubjecttoreverificationuntilthisisperformedandcloseout agreedbythecustomer.
b.
54
The planned verification process may change due to any of the events listed above. In these circumstances the need for reverification is considered and agreed between supplier and customer. ThenewverificationplanningisreflectedinanewversionoftheVCD.
55
6 Verification documentation
6.1 Introduction
Theverificationprocessanditsimplementationactivitiesaredocumentedbymeansofaspecificsetof verificationdocuments: a. b. c. d. e. f. g. h. i. j. Verificationplan(VP),seeclause6.2 Assembly,integrationandtestplan(AITP),seeclause6.2.3.1andECSSEST1003 Verificationcontroldocument(VCD),seeclause6.2.2 Testspecification(TSPE),seeclause6.3.7.1andECSSEST1003 Testprocedure(TPRO),seeclause6.3.7.2andECSSEST1003 Testreport(TRPT),seeclause6.3.1andECSSEST1003 Analysisreport(ARPT),seeclause6.3.2andECSSEST10 Reviewofdesignreport(RRPT),seeclause6.3.3 Inspectionreport(IRPT),seeclause6.3.4 Verificationreport(VRPT),seeclause6.3.5
Thelistaboveisacompromisebetweenminimizingdocumentationefforttomeetcostconstraintsand the requirement to properly trace the verification events, which is fundamental in order to reduce risksandtofacilitaterecoveryactionsincaseofproblems.Theverificationprocessdocumentationis summarizedinFigure61. TheVerificationMatrixisnolongerconsideredaseparatedocument(seeclause6.2.2). A certain level of documentation tailoring may be utilized to reduce the costs, on the basis of the specificcircumstancesagreedbetweencustomerandsupplier.Forexample: a. TheVerificationPlanandtheAITPlancanbecombinedinasingledocumentcalledAssembly IntegrationandVerificationPlan(AIVPlan),maintainingtheentiresetofuniqueinformationof thetwodocuments. TheVerificationPlanandAITPlancanbereducedtoasingleTestPlan(e.g.atequipmentlevel, whentheverificationismainlybytest). TheAITplancanincludetheTestSpecifications(e.g.inthecaseofaproductwithouttheneed ofcomplextests). TheTestSpecificationcanincludetheTestProcedures(e.g.whentheprocedureissimple). The VCD can include the information of the Verification Reports (e.g. for the case of single verificationmethod).
b. c. d. e.
56
Reqs to be verified
VERIFICATION ENTRIES (Methods, Levels, Stages)
BACK TO THE PROCESS AS APPLICABLE
Document Task Methods
Thearrowsrepresentthelogicalconnectionbetweendocumentsandmajortasks,andnotthecompleteprocessflow.
Figure61:Verificationdocumentation
Takingasanexampleasystemthermalrequirementtobeverifiedwithathermalbalancetestandthe associatedanalysisinthequalificationstage,thefollowingdocumentationstepstakeplace: a. Therequirementisidentifiedintherelevantsystemspecificationtogetherwithitsverification entries (i.e. T and A methods at System level in Qualification stage) before being documentedintheVCD. ThesystemVPandAITPPlansdefinetherelevantverificationeventsandassociatedflows(i.e. thermalbalancetestandthermalanalysis),outliningtheminthededicatedactivitysheets. The specific test requirements, which take into account project general test requirements contained in the test requirement specification (i.e. tailoring of the ECSSEST1003), are subsequently detailed in a thermal balance test specification which is followed by test procedureswiththerelevantstepbystepinstructions. Thetestresultsaresummarizedinthededicatedtestreport. In parallel the required analysis is carried out in relation to the test activities (i.e. test prediction/correlation) and the results presented in the relevant analysis report (including the flightpredictions). The synthesis of the performed verification activities (test plus analysis) is described in the verificationreport. The system verification control document progressively records the status of the verification implementationandfinallygivestheevidenceoftherequirementverificationcloseout.
b. c.
d. e.
f. g.
57
6.2
6.2.1
6.2.1.1
Verification planning documents

Verification plan (VP)
General
ECSSEST1002Cclause5.2.8.1specifiesthat: a. ThesuppliershallprovideaVerificationplan(VP)forthereviewsasagreedwiththe customer Note: b. Guidelines are in Annex G. ThecontentsoftheVerificationplan(VP)shallbeinconformancewiththeDRDin AnnexA. NOTE Thequotedannexesaboverefertothestandard.
The VP is the master plan for the project verification process and serves to demonstrate how the requirementsareverifiedbyacoherentimplementationapproach. ItiscreatedonthebasisofthespecificationoftheproducttobeverifiedanditsassociatedinitialVCD (see clause 6.2.2), taking into account the development philosophy, the applicable standards, the programmaticconstraintsandtheavailabilityoftoolsandfacilities.Thelevelofdetailvarieswiththe typeofproductandinrelationtotheactualphaseoftheproject. It is the starting point for the AIT Plan (see ECSSEST1003) containing the test programme whilst theAnalysis,ReviewofDesignandInspectionprogrammesareusuallydirectlycontainedintheVP. The VP is issued for the different project reviews starting with preliminary versions at PRR/SRR in ordertoexplaintheverificationapproachandsupportprogrammaticevaluation.Thecontentwillbe phased,asshowninannexA,inordertomeettheprojectreviewobjectives. ForeachsectionoftheDRDprovidedinECSSEST1002CAnnexA,therequirementsarerecalledat thebeginningofthesectioninitalics.Itisthenfollowedbyguidancewheneverconsideredrelevant. 6.2.1.2 VP DRD explanation Introduction a. b. TheVPshallcontainadescriptionofthepurpose,objective,contentandthereason promptingitspreparation. Openissues,assumptionandconstraintrelevanttothisdocumentshallbestatedand described. Applicable and reference documents a. TheVPshalllisttheapplicableandreferencedocumentsinsupporttothegenerationofthe document.
6.2.1.2.1
6.2.1.2.2
Theapplicabledocumentsarenormallytheproductspecification,therelatedstandards(e.g.ECSSE ST1002 and ECSSEST1003) and any other documents crossreferenced in the text to the extent indicatedinthetext. The reference documents provide additional information to the authors and readers (e.g. this handbook). Thedocumenttobeproducedareaddressedinclause6.2.1.2.11.
58
Definitions and abbreviations a. TheVPshalllisttheapplicabledictionaryorglossaryandthemeaningofspecifictermsor abbreviationsutilizedinthedocument. Verification subject a. TheVPshallbrieflydescribethesubjectoftheverificationprocess.
6.2.1.2.4
The product to be verified is identified and briefly described to allow understanding its role, main functionsandbreakdown.
6.2.1.2.5
Verification approach a. TheVPshalldescribethebasicverificationconceptsanddefinitions(methods,levelsand stages).
Defining methods, level and stages is a fundamental step of preparing the verification plan. The selectable methods are defined in the standard, whilst the level and stages can be tailored for the specificapplication.
6.2.1.2.6
Model philosophy a. TheVPshalldescribetheselectedmodelsandtheassociatedmodelphilosophy,product matrix.
Seeclause5.2.5above.
6.2.1.2.7
Verification strategy a. TheVPshalldescribetheselectedcombinationofthedifferentverificationmethodsatthe applicableverificationlevelsandstages,ingeneralandforeachrequirementtype/group (includingsoftware). Theallocationoftherequirementstothespecificverificationtasksshallbegiven.
b.
Thesestrategiesmaybesummarizedindedicatedtables(seeFigure62andFigure63). Figure62showsanexampleofthesummarytableforeachrequirementgroupattheselectedlevels. Figure 63 shows an example of the verification strategy for one single requirement group (Data Management)includinglevels/stepsandspecificmodels/events.
59
Figure62:ExampleofVerificationStrategiesperGroup/level
60
Figure63:ExampleofverificationstrategyforasingleRequirementGroup
6.2.1.2.8
Verification programme a. b. TheVPshalldocumenttheverificationactivitiesandassociatedplanningintheapplicable verificationstages. Analysis,reviewofdesign,inspectionandtestprogrammesshouldbedetailedthrough dedicatedactivitysheets,orthroughreferencetotheAITPlan.
Figure64showsexamplesoftheoverallverificationplanning. Figure65andFigure66showexamplesofactivitysheets.
61
Figure64:Exampleofverificationplanning
62
Figure65:Exampleofactivitysheetforanalysisprogramme
63
Figure66:ExampleofActivitySheetforIntegrationandTestProgramme
6.2.1.2.9
Verification tools a. TheVPshalldescribehighleveldefinitionsoftheverificationtoolstobeused,suchasS/W facilities,specialtools,simulators,analyticaltools.
64
Verification control methodology a. TheVPshalldescribetheproposedmethodologytobeutilizedforverificationmonitoring andcontrol.includingtheuseofaverificationdatabase. Documentation a. TheVPshalllisttheinvolvedverificationdocumentsanddescribetheircontent.
6.2.1.2.11
TheDRDsofECSSEST1002andECSSEST1003aretheinvolvedverificationdocumentation
6.2.1.2.12
Organization and management a. b. TheVPshalldescribetheresponsibilityandmanagementtoolsapplicabletothedescribed verificationprocess. Itshalldescribetheresponsibilitieswithintheprojectteam,therelationtoproduct assurance,qualitycontrolandconfigurationcontrol(includinganomalyhandlingand changecontrol)aswellastheresponsibilitysharingwithexternalpartners. Therelevantreviewsshallbeplannedandresponsibilitiesdescribed.
c.
6.2.2
6.2.2.1
Verification control document (VCD)

General
ECSSEST1002Cclause5.2.8.2specifiesthat: a. ThesuppliershallprovideaVerificationControlDocument(VCD)forthereviewsas agreedwiththecustomer Note: b. Guidelines are provided in Annex G. ThecontentsoftheinitialissueoftheVerificationControlDocument(VCD)shallbein conformancewiththeDRDinAnnexB.
a. b. c.
ThecontentofthecompletedVerificationControlDocument(VCD)shallbeinaccordance withtheDRDinAnnexB. ThesuppliershallupdatetheVerificationdatabasewithinoneweekoftheapprovalofa report. TheintermediateissuesoftheVerificationControlDocument(VCD),reflectingthecurrent statusoftheverificationdatabase,shallbemadeavailabletotheVerificationControlBoard (VCB)uponrequest. TheintermediateissuesoftheVerificationControlDocument(VCD),reflectingthecurrent verificationandcompliancestatus,shallbedeliveredateachformalreviewasagreedwith thecustomer Note: Guidelines are provided in Annex G. ThefinalissueoftheVerificationControlDocument(VCD)shallbesubmittedtothe VerificationControlBoard(VCB)aftertheapprovalofthelastreport,withinthetime frameagreedwiththecustomer. NOTE Thequotedannexesaboverefertothestandard.
d.
e.
TheVCDprovidestraceabilityduringthephaseB,C,DandEofhowandwheneachrequirementis plannedtobeverifiedandisactuallyverified. The initial issue of the VCD is prepared for each product specification at the selected verification levels. It is an input to the preparation of the verification plan by listing all the requirements to be verifiedwiththeselectedmethodsintheapplicablestagesatthedefinedlevels.Inthepast,thisissue wascalledtheverificationmatrixdocument.
65
The initial issue of the VCD is completed along the project life cycle to provide evidence of the implementationoftheVerificationprocess.InparticulartheVerificationControlDataSheets(VCDS) areprogressivelyfilled(seeexampleinFigure18). A specific issue of the VCD is released for each stage of the verification (e.g. at the end of the QualificationStage,theVCDcontainsallthecloseoutrecordsrelevanttoqualificationactivities). Itshouldbenotedthatincaseofrecurrentproductsbasedonthesamequalification,theVCDforthe acceptanceisrelevanttoeachsingleproductevenifthequalificationstageisvalidforall. InsummarytheVCDprovides,withthesupportoftheVerificationDataBase,thefollowing: a. b. c. d. e. f. traceabilityofrelationshipsbetweenrequirements, traceability of all requirements to the verification process (methods, levels, stages, planning documentation,reports,waivers,closeout,andcomplianceetc.), visibilityofthecoherenceacrossproductsandlevels, monitoringoftheverificationprocessthroughouttheprojectlifecycle, identificationofimpactsatthevariouslevelsincaseofchangeofrequirementsorcriticalitys duringlowerlevelverification, integrationintothehigherlevelofthelowerlevelverificationdata.
The VCD is formally agreed with the customer. The VCD becomes part of the EIDP, as detailed in ECSSQST20. ForeachsectionoftheDRDprovidedinECSSEST1002CAnnexB,therequirementsarerecalledat the beginning of the section. The quoted text is in italic. It is then followed by guidance whenever consideredrelevant. 6.2.2.2 VCD DRD explanation Introduction a. b. c. TheVCDshallcontainadescriptionofthepurpose,objective,contentandthereason promptingitspreparation. Openissues,assumptionsandconstraintsrelevanttothisdocumentshallbestatedand described. TheVCDcontentshallbephasedwiththeproductlifecyclesuchthattheinitialissue containstheverificationmatrix,intermediateissuescovertheplannedonground verificationsandtheirexecutionsevidence(inparticularforqualificationandacceptance completion),theinorbitandpostlandingactivities;finalissueprovidesevidenceofthe closeoutoftheoverallverificationprocess. Applicable and reference documents a. TheVCDshalllisttheapplicableandreferencedocumentsinsupporttothegenerationof thedocument.
6.2.2.2.1
6.2.2.2.2
Theapplicabledocumentsarenormallytheproductspecification,therelatedstandards(e.g.ECSSE ST1002)andanyotherdocumentscrossreferencedinthetexttotheextentindicatedinthetext. The reference documents provide additional information to the authors and readers (e.g. this handbook).
6.2.2.2.3
Definitions and abbreviations a. TheVCDshalllisttheapplicabledictionaryorglossaryandthemeaningofspecificterms orabbreviationsutilizedinthedocument.
66
Verification subject a. b. TheVCDshalldescribetheverificationcontrolapproachappliedtotheproduct,the involveddocumentation,andthecomputerizedtool,usedtosupporttheprocess: TheVCDshallincludetherequirementstobeverified(withreferencetothespecifications involved),calluptheverificationmethods,levelsandstagesdefinitionsandexplainthe verificationcloseoutcriteria.
Thesubjectisthedescriptionoftheverificationcontrolapproachandnotoftheproductitself.
6.2.2.2.5
Verification summary status a. EachissueoftheVCDshallsummarizethecurrentVerificationCloseoutstatus.
ExampleofthecloseoutstatustableisprovidedinFigure67.
PROJECT:
ZZZ LEVELS SS EL X(Y) X(Y) ........ ........ N/A ........ ........ ........ ........ ........ ........ ........ ........ ........
METHODS T A R I
NOTE:
STAGES Q A IO Q Q Q A
X = Planned
EQ X(Y) X(Y) X(Y) ........ ........ ........ ........

Y = Executed
SY X(Y) ........ ........ ........ ........ ........ ........
N/A = Not Applicable
Figure67:Exampleofthecloseoutstatustable
6.2.2.2.6
Verification control data a. TheVCDshallcollectintheformofamatrix,foreachrequirement,thefollowing verificationinformation: 1. Requirement identifier, 2. Requirement text 3. traceability between requirement, 4. Levels and stages of verification, 5. methods, 6. link to the relevant section of the verification plan and any planning document, Note: 7. Note: 8. 9. 10. b. For example, test specification. For example, report, analysis, waivers, RFD, NCR, NRB, customer closeout records. References to any documentation that demonstrates compliance to the requirements,
Status of Compliance (yes, no, partial), Close-out status (open / closed), Reasons of the close-out status,
TheinitialissueoftheVCDshallcontainaverificationmatrixlimitedto: 1. Requirement identifier, 2. Requirement text,
67
3. 4. 5. 6. traceability between requirement, Levels and stages of verification, methods, link to the relevant section of the verification plan.
Figure68showsanexampleoftheVerificationControldatasheet.
Specification data Verification Control Document data Verification Levels
Title: <VCD_Header> Title: <Spec_Header> Methods L2 L3 EX.DOC L4 REP.DOC
Verification Stage
AIVDB Report Page: 1 of XXX Stage : <Stage> CI Identifier: <CI_number> REMARKS O/C VCB Ref.
Program name: <Progran Name> VCD DOC.: < VCD_Id> Iss/Rev: <Iss/Rev> Date: <VCD_date>
SPECIFICATION: No.: <Spec_Nr> Issue/Rev: <Iss/Rev> Date: <Spec_date> Req_Nr Req TEXT Header Serial Number RFW
L1
COMMENTS VERIFICATION PLANNING DOCUMENT CODE & STATUS RFWs CODE EXECUTION STATUS
REQUIREMENT NUMBER TITLE & TEXT
H/W data
VERIFICATION METHODS AT DIFFERENT LEVELS
VERIFICATION REPORTING DOCUMENT CODE & STATUS
CUSTOMER APPROVAL
Figure68:ExampleofVCDsheet
6.2.3
6.2.3.1
Other verification planning Documents

Assembly, Integration and Test plan (AITP)
ECSSEST1002Cclause5.2.8.3specifiesthat: a. b. ThesuppliershallprovidetheAITPforthereviewsasagreedwiththecustomer Note: Guidelines are provided in Annex G. TheAssembly,IntegrationandTestplan(AITP)shallbeinaccordancewiththeDRDin ECSSEST1003. NOTE Thequotedannexabovereferstothestandard.
The AIT plan contains the assembly, integration & test programme for all models, the AIT activity sheets, the relevant planning, the selected test facilities, the involved documentation and the AIT management&organization.TheAITplanisthemasterplanfortheAITprocess. Ifagreedwiththecustomer:
68
a. The plan for Assembly and Integration may be separated from the plan for the Test. This is normallydoneinspecificcircumstancessuchasprojectwithacomplexproductioncycle(e.g. forlauncher). The AIT Plan may contain only the test programme. This is normally done for certain lower levelproducts,suchassimpleequipment. Test Requirement Specification
b.
6.2.3.2
The test requirement specification was a system support specification, containing the general test requirementsintermsoftypeoftests,sequences,margins,durations,tolerances,screeningpolicyand methodology. It was applicable to all verification levels through the relevant product specifications (e.g.system,subsystemandequipmentspecification). Since the release of verification and testing standard at issue B, the test requirement specification is replacedbytheECSSEST1003tailoredtothespecificapplication.
6.3
6.3.1
6.3.1.1
Verification execution and reporting documentation

Test report (TRPT)
General
ECSSEST1002Cclause5.3.2.1specifiesthat: a. b. c. Thetestreport(TRPT)shallbesubmittedtotheVerificationControlBoard(VCB)afterthe testcompletion,withinthetimeframeagreedwiththecustomer. ThecontentoftheTestreport(TRPT)shallbeinaccordancewiththeDRDinAnnexC. ThesuppliershallprovidetheTestreports(TRPT)forthereviewsasagreedwiththe customer Note: d. Guidelines are provided in Annex G. ATestreport(TRPT)shallbeprovidedforeachTestverificationtaskasidentifiedinthe VPorAITP. NOTE Thequotedannexesaboverefertothestandard.
AtestreportispreparedforeachtestcorrespondingtoaVPorAITPTestActivitySheetortoaTest Specification. Theprincipalpurposeistoprovidethecustomerwiththeevidenceofthetestactivityperformedfor verification closeout of the relevant requirements. It responds to the requirements contained in the product specification and in the test specification (see ECSSEST1003) and the test procedure (see ECSSEST1003).Incaseofenvironmentaltests,pertinentdataaboutthetestfacilityisalsogiven.It isaninputtoaverificationreportinthecaseofmultimethodverification. Itmayincluderesultscomingfrommanytestprocedurese.g.aTestReportforaFMenvironmental testnormallyincludesalsotheasrunproceduresoftheassociatedfunctionaltests. In some cases, a first issue of the document may only contain the raw results with the preliminary engineeringassessmentswhilstthefinalissuecontainsthecompleteengineeringevaluation. The test report including its engineering assessment may be complemented with a more detailed analysisreport.
69
ForeachsectionoftheDRDprovidedinECSSEST1002CAnnexC,therequirementsarerecalledat the beginning of the section. The quoted text is in italic. It is then followed by guidance whenever consideredrelevant. 6.3.1.2 TRPT DRD explanation Introduction a. b. TheTRPTshallcontainadescriptionofthepurpose,objective,contentandthereason promptingitspreparation. Openissues,assumptionsandconstraintsrelevanttothisdocumentshallbestatedand described. Applicable and reference documents a. TheTRPTshalllisttheapplicableandreferencedocumentsinsupporttothegenerationof thedocument.
6.3.1.2.1
6.3.1.2.2
The applicable documents are normally the product specification, the test specification, the test procedure(s),therelatedstandards(e.g.ECSSEST1002,ECSSEST1003)andanyotherdocuments crossreferencedinthetexttotheextentindicatedinthetext. The reference documents provide additional information to the authors and readers (e.g. this handbook).
6.3.1.2.3
Definitions and Abbreviations a. TheTRPTshalllisttheapplicabledictionaryorglossaryandthemeaningofspecificterms orabbreviationsutilizedinthedocument Test results a. b. c. TheTRPTshallcontainthetestresultswithsupportingdata(includingthetestexecution dates,theasrunprocedure,andthetestfacilityresults). TheTRPTshallcontaintheanalysisoftestdataandtherelevantassessment TheTRPTshallprovideasynthesisofthetestresults. Anomalies a. TheTRPTshallincludethelistofdeviationstothetestprocedure,thenonconformance includingfailuresandtheproblems. Conclusions a. TheTRPTshallsummarize 1. the test results, including: (a) thelistoftherequirementstobeverified(incorrelationwiththeVCD), (b) traceabilitytouseddocumentation, (c) conformanceordeviationincludingreferencesandsignatureanddate), 2. the comparison with the requirements and. 3. the verification close-out judgement Openissuesshallbeclearlystatedanddescribed Separatetestanalysesshallbecrossreferenced.
6.3.1.2.4
6.3.1.2.5
6.3.1.2.6
b. c.
Therequirementcloseoutmaybesummarizedinaseparatetabletobepreparedforeachpertinent requirementorgroupofrequirements(seeFigure69).
70
Figure69:Exampleoftestreportsheet
6.3.2
6.3.2.1
Analysis report (ARPT)

General
ECSSEST1002Cclause5.3.2.2.specifiesthat: a. b. c. TheAnalysisreport(ARPT)shallbesubmittedtotheVerificationControlBoard(VCB) afteranalysiscompletion,withinthetimeframeagreedwiththecustomer. TheAnalysisreport(ARPT)shallbeinconformancewiththeDRDinAnnexQofECSS EST10. ThesuppliershallprovideanAnalysisreport(ARPT)forthereviewsasagreedwiththe customer Note: d. Guidelines are provided in Annex G. AnAnalysisreport(APRT)shallbeprovidedforeachAnalysisverificationtaskidentified intheVP. NOTE Thequotedannexabovereferstothestandard.
Analysis without verification objectives are out of scope the ECSSEST1002 standard. But for documentationsimplificationreasonstheAnalysisReportDRDhasbeenkeptatE10levelwithclear identificationinitscontentofthespecificaspectslinkedtoverificationobjectives. ThefollowingconsiderationsarethereforeapplicabletotheAnalysisReportversionforVerification.
71
TheAnalysisReportispreparedforeachanalysiscorrespondingtoananalysisActivitySheetofthe VP. It contains proper evidence that the relevant requirements are verified and the indication of any deviation. Itisaninputtoaverificationreportinthecaseofmultimethodverification. Itsapplicabledocumentsarenormallytheproductspecification,theverificationplan,thedocument containingtheanalysisrules,therelatedstandards(e.g.ECSSEST1002)andanyotherdocuments crossreferencedinthetexttotheextentindicatedinthetext. Its reference documents provide additional information to the authors and readers (e.g. this handbook). Therequirementcloseoutmaybesummarizedinaseparatetabletobepreparedforeachpertinent requirementorgroupofrequirements(seeFigure610).
Figure610:Exampleofananalysisreportsheet
6.3.3
6.3.3.1
Review-of-design report (RRPT)

General
ECSSEST1002Cclause5.3.2.3specifiesthat: a. TheReviewofdesignreport(RRPT)shallbesubmittedtotheVerificationControlBoard (VCB)aftertheReviewofDesigncompletion,withinthetimeframeagreedwiththe customer.
72
b. c. TheReviewofdesignreport(RRPT)shallbeinconformancewiththeDRDinECSSE ST1002CAnnexD. ThesuppliershallprovideaReviewofdesignreport(RRPT)forthereviewsasagreedwith thecustomer Note: d. Guidelines are provided in Annex G.. AReviewofdesignreport(RRPT)shallbeprovidedforeachReviewofdesignverification taskidentifiedintheVP. NOTE Thequotedannexesaboverefertothestandard.
The reviewofdesign report (RRPT) is prepared for each reviewofdesign task corresponding to a reviewofdesign activity sheet of the VP. Its principal purpose is to provide the customer with the evidence of satisfactory completion of review ofdesign for verification closeout of the relevant requirements.Thereviewofdesignreportcancovertheactivityrelevanttotheverificationofseveral requirementsinthecasethattheeventisunique(forexamplereviewofdesignperformedduringa projectdesignreview). Itisaninputtoaverificationreportinthecaseofmultimethodverification. ForeachsectionoftheDRDprovidedinECSSEST1002CAnnexD,therequirementsarerecalledat the beginning of the section. The quoted text is in italic. It is then followed by guidance whenever consideredrelevant. 6.3.3.2 RRPT DRD explanation Introduction a. b. TheRRPTshallcontainadescriptionofthepurpose,objective,contentandthereason promptingitspreparation. Openissues,assumptionsandconstraintsrelevanttothisdocumentshallbestatedand described. Applicable and reference documents a. TheRRPTshalllisttheapplicableandreferencedocumentsinsupporttothegenerationof thedocument.
6.3.3.2.1
6.3.3.2.2
Theapplicabledocumentsarenormallytheproductspecification,theverificationplan,thedocument containing the review of design rules, the related standards (e.g. ECSSEST1002) and any other documentscrossreferencedinthetexttotheextentindicatedinthetext. The reference documents provide additional information to the authors and readers (e.g. this handbook).
6.3.3.2.3
Definitions and Abbreviations a. TheRRPTliststheapplicabledictionaryorglossaryandthemeaningofspecifictermsor abbreviationsutilizedinthedocumentwiththerelevantmeaning. Review-of-design summary a. TheRRPTdescribesthereviewofdesignactivityintermsofmethodandproceduresused. Conclusions a. TheRRPTshallsummarize 1. the review-of-design results, including 1. thelistoftherequirementstobeverified(incorrelationwiththeVCD), 2. traceabilitytouseddocumentation,
6.3.3.2.4
6.3.3.2.5
73
2. 3. b. 3. conformanceordeviationincludingreferencesandsignatureanddate, the comparison with the requirements and the verification close-out judgment.
Openissuesshallbeclearlystatedanddescribed..
Figure611:Exampleofreviewofdesignreportsheet
6.3.4
6.3.4.1
Inspection report (IRPT)

General
ECSSEST1002Cclause5.3.2.4specifiesthat: a. b. c. TheInspectionreport(IRPT)shallbesubmittedtotheVerificationControlBoard(VCB) aftertheinspectioncompletion,withinthetimeframeagreedwiththecustomer. TheInspectionreport(IRPT)shallbeinconformancewiththeDRDinAnnexE. ThesuppliershallprovideanInspectionreport(IRPT)forthereviewsasagreedwiththe customer Note: d. Guidelines are provided in Annex G. AnInspectionreport(IRPT)shallbeprovidedforeachInspectionverificationtask identifiedintheVP. NOTE Thequotedannexesaboverefertothestandard.
74
TheInspectionReportispreparedforeachinspectionverificationtaskcorrespondingtoanInspection Activity Sheet of the VP. The principal purpose is to provide the customer with the evidence of the performed inspection activity in verification closeout of the relevant requirements. The inspection reportcancovertheactivityrelevanttotheverificationofseveralrequirementsincasethattheevent isunique(forexampleaninspectionofseveralI/Frequirements). Itisaninputtoaverificationreportinthecaseofmultimethodverification. ForeachsectionoftheDRDprovidedinECSSEST1002CAnnexE,therequirementsarerecalledat thebeginningofthesection.Thequotedtextisinitalic. Itisthenfollowedbyguidancewheneverconsideredrelevant. 6.3.4.2 IRPT DRD explanation Introduction a. b. TheIRPTshallcontainadescriptionofthepurpose,objective,contentandthereason promptingitspreparation. Openissues,assumptionsandconstraintsrelevanttothisdocumentshallbestatedand described. Applicable and reference documents a. TheIRPTshalllisttheapplicableandreferencedocumentsinsupporttothegenerationof thedocument.
6.3.4.2.1
6.3.4.2.2
Theapplicabledocumentsarenormallytheproductspecification,theverificationplan,thedocument containingtheinspectionrules,therelatedstandards(e.g.ECSSEST1002)andanyotherdocuments crossreferencedinthetexttotheextentindicatedinthetext. The reference documents provide additional information to the authors and readers (e.g. this handbook).
6.3.4.2.3
Definitions and Abbreviations a. TheIRPTshalllisttheapplicabledictionaryorglossaryandthemeaningofspecificterms orabbreviationsutilizedinthedocumentwiththerelevantmeaning. Inspection summary a. TheIRPTshalldescribetheproductconfigurationdataoftheinspecteditem. Conclusions a. The IRPT shall summarize: 1. inspection results, including: a. thelistoftherequirementstobeverified(incorrelationwiththeVCD), b. traceabilitytouseddocumentation, c. inspectioneventlocationanddate, d. expectedfinding, e. conformanceordeviationincludingproperreferencesandsignatureanddate, comparison with the requirements, and verification close-out judgement.
6.3.4.2.4
6.3.4.2.5
2. 3. b.
Openissuesshallbeclearlystatedanddescribed
75
Figure612:Exampleofaninspectionreportsheet
6.3.5
6.3.5.1
Verification report (VRPT)

General
ECSSEST1002Cclause5.3.2.5specifiesthat: a. b. c. ThesuppliershallprepareaVerificationreport(VRPT)whenmorethanoneofthedefined verificationmethodsareutilizedtoverifyarequirementoraspecificsetofrequirements. TheVerificationreport(VRPT)shallbeinaccordancewiththeDRDinAnnexF. TheVerificationreport(VRPT)shallbesubmittedtotheVerificationControlBoard(VCB) afterthecompletionofthelastcontributingverificationactivities,withinthetimeframe agreedwiththecustomer. ThesuppliershallprovideaVerificationreport(VRPT),forthereviewsasagreedwiththe customer Note: NOTE Guidelines are provided in Annex G. Thequotedannexesaboverefertothestandard.
d.
TheVRPTreportstheapproachfollowedandhowtheverificationmethodswerecombinedtoachieve theverificationobjectives.Theverificationreportcancovertheverificationofseveralrequirements. The VRPT is prepared on the basis of the initial Verification Control Document (VCD) and the associated Verification Plan (VP), considering the results of the relevant test, analysis, reviewofdesignandinspectionreports.
76
ForeachsectionoftheDRDprovidedinECSSEST1002CAnnexF,therequirementsarerecalledat the beginning of the section. The quoted text is in italic. It is then followed by guidance whenever consideredrelevant.
6.3.6
6.3.6.1.1
VRPT DRD explanation

Introduction a. b. TheVRPTshallcontainadescriptionofthepurpose,objective,contentandthereason promptingitspreparation. Openissues,assumptionsandconstraintrelevanttothisdocumentshallbestatedand described. Applicable and reference documents a. TheVRPTshalllisttheapplicableandreferencedocumentsinsupporttothegenerationof thedocument.
6.3.6.1.2
The applicable documents are normally the product specification, the verification plan, the related standards (e.g. ECSSEST1002), all the elementary reports (i.e. test, analysis, review of design and inspection)usedtobuildthisreportandanyotherdocumentscrossreferencedinthetexttotheextent indicatedinthetext. The reference documents provide additional information to the authors and readers (e.g. this handbook).
6.3.6.1.3
Definitions and Abbreviations a. TheVRPTshalllisttheapplicabledictionaryorglossaryandthemeaningofspecificterms orabbreviationsutilizedinthedocumentwiththerelevantmeaningVerificationsubject. Verification results a. b. TheVRPTshalldescribetheverificationapproach,theassociatedproblemsandresultswith referencetotherelevanttest,analysis,reviewofdesignandinspectionreports. TheVRPTshallidentifythedeviationsfromtheverificationplan. Conclusions a. b. c. TheVRPTshalllisttherequirementstobeverified(incorrelationwiththeVCD). TheVRPTshallsummarizeverificationresults,thecomparisonwiththerequirementsand theverificationcloseoutjudgement. Openissuesshallbeclearlystatedanddescribed.
6.3.6.1.4
6.3.6.1.5
77
Figure613:Exampleofverificationreportsheet
6.3.7
6.3.7.1
Other verification execution and reporting Document

Test Specification (TSPE)
ECSSEST1002Cclause5.3.2.6specifiesthat: a. ThesuppliershallprovidetheTestspecifications(TSPE)forthereviewsasagreedwiththe customer Note: Guidelines are provided in Annex G.
78
b. TheTestspecifications(TSPE)shallbeinconformancewiththeDRDinAnnexBof ECSSEST1003. NOTE Thequotedannexabovereferstothestandard.
Anexampleisgiveninthecorrespondinghandbook(ECSSEHB1003). ThetestspecificationispreparedforeachtestcorrespondingtoaVPorAITPTestActivitySheetwith theobjectivetodetailthetestrequirementsforspecialpurposes(e.g.tointerfacewithatestfacility). The test specification reflects an intermediate step in the test process definition between the overall planning(VPorAITP)andthespecifictestprocedure(s). The test specification contains the specific test activity objectives, the selected approach, the article configuration, the setup description, the necessary GSE, the equipment and instrumentation, the conditions for the activity, the required facilities, the sequence of activities with the detailed verification requirements, the success criteria, the organization and responsibilities, the involved documentation,therelationshipwithproductassuranceactivities,theschedule. Ifagreedwiththecustomer,thetestspecificationmaybecombinedwiththeAITortheAIVplan.This normallydependsontheactualprojectrequirements. 6.3.7.2
Test Procedures (TPRO)
ECSSEST1002Cclause5.3.2.6specifiesthat: c. d. TheTestproceduresshallbeinconformancewiththeDRDinAnnexDofECSSEST10 03. ThesuppliershallprovidetheTestprocedures(TPRO)forthereviewsasagreedwiththe customer Note: NOTE Guidelines are provided in Annex G. Thequotedannexabovereferstothestandard
Anexampleisgiveninthecorrespondinghandbook(ECSSEHB1003). The test procedure provides detailed stepbystep instructions for conducting test activities in agreementwiththetestspecification.Thetestprocedurecontainstheactivityobjective,theapplicable documents, the references to the relevant test specification, the participants required, the article & toolsconfigurationlistandthestepbystepprocedures. TheTestSpecificationcanincludetheTestProcedures(e.g.whentheprocedureissimple). 6.3.7.3
Miscellaneous
ECSSEST1002Cclause5.3.2.6specifiesthat: e. Therulesfortheanalysis,inspectionandreviewofdesignshallbedefinedinwritingbefore theirexecution. Note: For example, analysis, inspection or review of design procedures.
Theserulescanbestatedinselfstandingdocuments(e.g.procedures)orembeddedintheVP.
6.3.7.3.1
Analysis Procedure
Thisdocumentshouldcontainatleastthefollowinginformation: a. b. c. requirementstobeverifiedbythisanalysis analyticaltooltobeused(SWprogramme) shortanalyticalmodeldefinition
79
d. sourceofinputdata(e.g.testreports,assumptions,drawings,) Inspection Procedure
6.3.7.3.2
Thisdocumentshouldcontainatleastthefollowinginformation: a. b. c. d. requirementstobeverifiedbythisinspection producttobeinspected inspectionmethodandrequiredtools(ifany) whentheinspectionisperformed(e.g.before,duringorafterintegration) Review of Design Procedure
6.3.7.3.3
Thisdocumentshouldcontainatleastthefollowinginformation: a. b. requirementstobeverifiedbythisreview documentstobereviewed(e.g.drawings,diagrams,manuals,..) Additional documentation
6.3.7.3.4
In addition, the following documents are usually part of the verification process to provide traceabilityandeventrecord: a. b. c. d. e. f. testconfigurationlists(TCL); enditemdatapackages(EIDP); logbooks(includingworkitemsanddeviationworkitems); nonconformancereports(NCR); requestforwaivers(RFW); manuals,simulationplansandverificationtoolsdocumentation.
6.3.8
Other close-out documents

a. Thesuppliershallmakeavailabletothecustomerforconsultationtheevidencesmentioned intheVCDinadditiontothedeliverablereports.
The VCD is a summary document containing references to deliverable and not deliverable documentation. In this second case the customer has normally the right to access the necessary documentation for consultationpurposes.
80
Annex A Verification documents delivery per review

ECSSEST1002CAnnexG(informative)statesthat: The verification documents are delivered by the supplier to the customer at each review either for information or for approval, with the identified maturity, as per table G-1. Note: NOTE This implies that the DRD template can be adopted, but not followed.
Thequotedannexandtableaboverefertothestandard.
BeforeanITT,thecustomershouldtailorthistabletothespecificitiesoftheproject,levelandproduct toallowpropercostestimatebythesupplier. During the working arrangements negotiation, an agreement should be finalised between the customerandthesupplieronthetailoringofthistable. This table intends to cover the overall system as well as the space and ground segments However, when the standard is applied at a level below the overall system, some reviews are generally not relevant(e.g.ORR,FRR,LRRandCRR). Dependingoftheproductcharacteristics,somedocumentsmaybecombinedtoreducecostsoreven ignoredifnotrelevant. The requirement and design reviews may be simplified or even suppressed depending upon the productmaturity,e.g.whenaproductisalreadyexistingorevenofftheshelf. Some document are mentioned for a given review for programmatic purpose (e.g. VP at PRR) to preparetheproposalofthefollowingphase. PuresoftwareproductshavetofollowthedeliverablelistofECSSEST40. ECSSEST10 also mention requirement traceability and justification activities starting in phase A whicharesometimescalledverificationbutareoutofthescopeofthisstandard.
81
Annex B Verification Standard Tailoring

When viewed from the perspective of a specific project context, the requirements defined in the Standard should be tailored to match the genuine requirements of a particular profile and circumstances of a project (e.g. space element, ground segment, launcher, overall system or lower level product). It is normally done under the customer responsibility, before business agreement award,evenifthesuppliermayprovidecontributionduringtheproposalphase. NOTE Tailoring is a process by which individual requirements of specifications,standardsandrelateddocumentsareevaluated,and made applicable to a specific project by selection, and in some exceptional cases, modification of existing or addition of new requirements.
Thefollowingtableindicatesinwhichcircumstancesthestandardshouldbetailored:
According to the mission/product type (e.g. Commercial Application Satellite, Scientific Interplanetaryprobe,Habitablespaceinfrastructure,transportationsystem,etc.) Accordingtothephaseofthemission(e.g.phaseA,B,C,D,E,F) Accordingtotheproductverificationlevel(e.g.system,subsystem,equipment)
Thefollowingtablegivesalsoexamplesforthetailoringofthestandardforspecificproductssuchas:

Alowerlevelproductwithoutsoftware(e.g.hardwareequipment). Alowerlevelpuresoftwareproduct. A space element (e.g. commercial or scientific satellite) or a major subset of it (e.g. payload,platform). Asatellitegroundsupportequipment(GSE). Anexpendablelauncher. Agroundsegmentoramajorconstituentofit. Anoverallsystem(satellitesplusgroundsegments).
In the table a YES means that tailoring is possible according to the projects and products characteristics,whileaNOindicatesthattherequirementsshouldnotbetailored.
82
ECSSEHB1002A 17December2010 TableB1:Tailoringguidelinesandsomeexamplesperproducttype

perProduct/ Mission
ECSSEST1002CVerificationRequirement
Specificproducttype SpaceHW perPhase SpaceSW perLevel Launcher No Ground segment Overall System No No No No No No Yes No No No Yes No No No Space element No No
5.1VERIFICATIONPROCESS a.Theverificationprocessshalldemonstratesthatthedeliverableproductmeetsthe specifiedcustomerrequirementsandiscapableofsustainingitsoperationalrolethrough: 1. Verificationplanning; 2. Verificationexecutionandreporting; 3. Verificationcontrolandcloseout. 5.2VERIFICATIONPLANNING 5.2.2Verificationmethods 5.2.2.1General a. Verificationshallbeaccomplishedbyoneormoreofthefollowingverificationmethods: 1. test(includingdemonstration); 2. analysis(includingsimilarity); 3. reviewofdesign; 4. inspection. b. Allsafetycriticalfunctionsshallbeverifiedbytest. c. Verificationofsoftwareshallincludetestinginthetargethardwareenvironment. d. Foreachrequirementverifiedonlybyanalysisorreviewofdesign,assessmentanalysis (partoftheVP)shallbeconductedtodeterminethelevel(major/minor)oftheimpactof thisrequirementonthemission e. Iftheimpactoftherequirementismajor,ariskmitigationplan(partoftheVP)shallbe definedwhichincludes,acrosscheckbasedontwoindependentanalyses(intermsof modelusedandsuppliers) 5.2.2.2Test a. Verificationbytestshallconsistofmeasuringproductperformanceandfunctionsunder
No
No
No
No
No
No
No
No
No
No
No
No
GSE No No Yes Yes No
No
No No Yes
No No Yes
No No No
No No No
No No No
No No No
No No No
Yes
Yes
No
No
No
No
No
No
No
No
No
No
No
No
83
perProduct/ Mission
Specificproducttype SpaceHW perPhase SpaceSW perLevel Launcher No No No No No No Ground segment Overall System No No Yes No No No No No No No No No No No No No Yes Yes Yes Yes Space element No No No No No No No No
representativesimulatedenvironments. b. Theanalysisofdataderivedfromtestingshallbeanintegralpartofthetestandthe resultsincludedinthetestreport. c. Whenthetestobjectivesincludethedemonstrationofqualitativeoperational performancetheexecutionshallbeobservedandresultsrecorded. d.Atestprogrammeshallbepreparedforeachproductincompliancewithtest requirementsspecifiedinECSSEST1003. e. Thetestprogrammeshallbecoordinatedwiththeintegrationflow. f. Testsperformedaspartoftheintegrationflowtocheckqualityandstatusofthein progressconfiguration(includinginterfaces),havingaformalverificationpurpose,shall beincludedinthetestprogramme. g. ThetestprogrammeshallbedefinedintheAssembly,IntegrationandTestplan(AITP). 5.2.2.3Analysis a. Verificationbyanalysisshallconsistofperformingtheoreticalorempiricalevaluation usingtechniquesagreedwiththeCustomer. NOTE Techniquescomprisesystematic,statisticalandqualitativedesign analysis,modellingandcomputationalsimulation. b. Verificationbysimilarityshallbepartoftheverificationbyanalysis. c. Similarityanalysisshallprovideevidencethatanalreadyqualifiedproductfulfilsthe followingcriteria: 1. Thealreadyqualifiedproductwasnotqualifiedbysimilarity. 2. TheproducttobeverifiedbelongstocategoryAortocategoryB(definedinTable1) butnotestingisrequiredtoachievequalification. NOTE ImplicitlytheproducttobeverifiedcannotbelongtocategoriesCand Dequipment(definedinTable51). d. Similarityanalysisshalldefinedifferencesthatcandictatecomplementaryverification activities.
No No Yes No No Yes
No No No No No No
No No No yes yes yes
No No No Yes Yes Yes
No No Yes No No Yes
No No Yes No No No
No No
No No
No No
No No
No No
No No
GSE Yes Yes
No No
Yes
No
No
No
Yes
No
No
Yes
No
No
No
Yes
No
No
84
perProduct/ Mission
Specificproducttype SpaceHW perPhase SpaceSW perLevel Launcher No No Ground segment Overall System No No No No No No No No No No No No No No No No No No No No Space element No No No
e. AnanalysisprogrammeshallbedefinedintheVerificationPlan(VP). f. Ananalysisprogrammeshallbeapplicabletoqualificationandinorbitstagesonly. 5.2.2.4Reviewofdesign a. VerificationbyReviewofdesign(ROD)shallconsistofusingapprovedrecordsor evidence(e.g.designdocuments,andreports,technicaldescriptions,engineering drawings)thatunambiguouslyshowthattherequirementismet. NOTE: Examplesofsuchapprovedrecordsaredesigndocumentsand reports,technicaldescriptions,andengineeringdrawings. b. AreviewofdesignprogrammeshallbedefinedintheVerificationPlan(VP). c. Areviewofdesignprogrammeshallonlybeapplicableinthequalificationstageorin theinorbitstage. 5.2.2.5Inspection a. Verificationbyinspectionshallconsistofvisualdeterminationofphysicalcharacteristics. NOTE: Physicalcharacteristicsincludeconstructionalfeatures,hardware conformancetodocumentdrawingorworkmanshiprequirements, physicalconditions,softwaresourcecodeconformancewithcoding standards. b. AninspectionprogrammeshallbedefinedintheVerificationPlan(VP). 5.2.3Verificationlevels a. Verificationshallbeaccomplishedthroughtheselectedverificationlevels.NOTE:Usual levelsaredefinedin4.2.3 b. Whenarequirementisfullyverifiedatlowerlevel,thetraceabilitytolowerlevel verificationevidenceshallbeidentified. c. Formalcloseoutofqualificationandacceptanceatlowerlevelsshallbeperformedprior tocloseoutathigherlevel.
No No
No No
No No
No No
No No
No No
No
No
No
No
No
No
GSE No No No No No No No
No
No No
No No
No No
No No
No No
No No
No No
No
No
No
No
No
No
No
No No No No
No No No No
No No No No
No No No No
No No No No
No No No No
No No No No
85
perProduct/ Mission
Specificproducttype SpaceHW perPhase SpaceSW perLevel Launcher Yes Ground segment Overall System Yes Yes No No No No No No No No Yes No No Yes No No Space element Yes No No No
5.2.4Verificationstages 5.2.4.1General a. Verificationshallbeaccomplishedthroughtheselectionoftheappropriatestagesonthe basisofprojectspecificityfromthefollowing: 1. qualification, 2. acceptance, 3. prelaunch, 4. inorbit(includingcommissioning), 5. postlanding. b. Qualification,acceptanceandprelaunchstagesshallbecompletedbeforelaunch. c. Whentheverificationprogrammeincludesaninorbitstage,theverificationshallnotrely onlyoninorbitactivities. d. Whentheverificationprogrammeincludesapostlandingstage,theverificationshallnot relyonlyorinorbitactivitiesorpostlandingactivities. 5.2.4.2Qualification a. Inthequalificationstagetheverificationshalldemonstratethatthedesign,including margins,meetstheapplicablerequirements. b. Qualificationshallbecarriedoutonhardwareandsoftwarewhichisrepresentativeof theenditemconfigurationintermsofdesign,materials,toolingandmethods. c. Thequalificationprogrammeshallbepreparedconsideringtheproductcategory accordingtoheritageasdefinedinTable51ofthestandardProductcategories accordingtoheritage 5.2.4.3Acceptance 5.2.4.3.1General a. Intheacceptancestagetheverificationshalldemonstratethattheproductisfreeof workmanshiperrorsandisreadyforsubsequentoperationaluse.
Yes
No
Yes
Yes
Yes
Yes
No No No
No No No
No No No
No No No
No No No
No No No
GSE No No Yes No
No No No
No No Yes
No No No
No No No
No No No
No No Yes
No No No
No No No
No
No
No
No
No
No
No
86
perProduct/ Mission
Specificproducttype SpaceHW perPhase SpaceSW perLevel Launcher No No No Ground segment Overall System No No No No No No Yes Yes No No No No No No No No No No Space element No No No No
b. Acceptanceshallbecarriedoutonthefinalhardwareandsoftware 5.2.4.3.2Acceptablearticle a. Theacceptancearticleshallbemanufacturedinagreementwiththequalifieddesign. b. Theacceptancearticleshallperformasthequalifiedproduct. 5.2.4.4Prelaunch a. Intheprelaunchstagetheverificationshalldemonstratethattheproductisproperly configuredforlaunchactivitiesandearlyoperations b. Intheprelaunchstagetheverificationshallconfirmthattheproductiscapableof functioningasplannedduringlaunchandearlyoperations. 5.2.4.5Inorbit a. Intheinorbitstagetheverificationshallensurenodegradationoccurredduringthe launch,earlyorbitphase,atperiodicalintervalsandbeforespecificoperationaluse. b. Intheinorbitstagetheverificationshallsupplement/confirmgroundverificationby providingoperatingconditionswhichcannotbefullyorcosteffectivelyduplicatedor simulatedonground. c. Intheinorbitstagetheverificationshallcharacterizethesystemunderoperational conditionsespeciallyfortheaspectsthatcannotbedeterminedbeforethelaunch d.Intheinorbitstagetheverificationshallconfirmthatthespaceandgroundelementsare compatiblewitheachother e. Intheinorbitstagetheverificationshallperformcalibrationandtuningactivitiesspecific tothemissionpayload. NOTE: Theworkingarrangementbetweentheelementssuppliers(e.g. satellite,groundsegment)andthefinalcustomerdefinestheshareof responsibilitiesforpreparing,conductingandreportingtheinorbit commissioningactivities.Thecompletionofthisstageallows declaringreadinessforroutineoperations(PhaseE2exploitation).
No No No
No No No
No No No
No No No
No No No
No No No
Yes
No
Yes
Yes
Yes
Yes
GSE Yes Yes Yes Yes Yes
No
Yes Yes Yes Yes
No No No No
Yes Yes Yes Yes
Yes Yes Yes Yes
Yes Yes Yes Yes
No No No No
Yes Yes Yes Yes
Yes
No
Yes
Yes
Yes
No
Yes
87
perProduct/ Mission
Specificproducttype SpaceHW perPhase SpaceSW perLevel Launcher Yes Ground segment Overall System Yes Yes Yes Yes No No No No No No No No No No Yes Yes Yes Yes Space element Yes No
5.2.4.6Postlanding a. Theverificationinthepostlandingstageshalladdresstheproductintegrityand performanceafterthemission. b. Incasetheproductisintendedtoberelaunchedtheverificationshalladdress: 1. ahealthcheck,atperiodicalintervalsagreedwiththecustomer,duringstorage periods; 2. theproductperformanceaftermodification,repairorreplacement; 3. thereadinessforreuse. 5.2.5Models a. Themodelphilosophyshallbedefinedaspartoftheoverallverificationplanning. 5.2.6Verificationtools 5.2.6.1General a. Toolstobeusedtosupporttheimplementationoftheverificationprocessshallbe identified. b. Allverificationtoolsshallbeverifiedfortheirintendeduse. c. Thedegreeofverificationappliedtotoolsusedtosupporttheverificationprogramme shallbeestablished. NOTE: Thisrequirementdoesnotimplythatformalverificationisperformed fortheverificationtools(e.g.toolsofcommonuse). d. Formalverificationproceduresshallbeestablishedandappliedtotoolswhichare specifiedasdeliverableitems. 5.2.6.2GroundSupportEquipment(GSE) a. AllGroundSupportEquipment(GSE)shallbeverifiedunderexpectedenvironmental conditionsandoperationalconstraints. b. ThecompatibilityoftheinterfacesoftheGroundSupportEquipment(GSE)withflight productsandfacilitiesshallbeverifiedbytest.
Yes
No
Yes
Yes
Yes
Yes
Yes
No
No
No
Yes
Yes
GSE No No No No No No No
Yes
No
No
No
No
No
No
No
No No No
No No No
No No No
No No No
No No No
No No No
No No No
No
No
No
No
No
No
No
Yes Yes
No No
No No
No No
Yes Yes
No No
No No
88
perProduct/ Mission
Specificproducttype SpaceHW perPhase SpaceSW perLevel Launcher No Ground segment Overall System Yes Yes Yes Yes Yes Yes Yes Yes No No No No No No No No Space element No No
c. ThepreventionofdamageontheflightproductduetoGroundSupportEquipment (GSE)failureshallbeverified. NOTE: Forhazardstopersonnel,flighthardware,facilitiesandenvironments relatedtoGSE,seeECSSQST40. d. GroundSupportEquipment(GSE)thatismodifiedorusedinanewapplicationshallbe reverifiedorrevalidated. 5.2.6.3Softwarevalidationfacility(SVF) a. TheSVFshallbeverifiedbycomparingtheperformanceofthesimulationmodelswith theactualperformanceoftheproductorenvironmenttobesimulated. b. flighthardwareorsoftwareproductsimulatedbytheSVFshallbefinallyverifiedagainst themeasuredperformanceoftheactualflightproduct. 5.2.6.4Simulators a. Simulatorsshallbeverifiedtodemonstratethatthesimulatorcharacteristicsare representativeofthesimulatedproducttotheextentrequiredfortheverificationtobe supported. 5.2.6.5Softwaretoolsforverificationbyanalysis a. Suitabilityofpreviouslyvalidatedanalyticalsoftwaretoolsshallbeassessedforthe intendedapplication. b. Nonvalidatedanalyticalsoftwaretoolsshallbesubjectedtoavalidationprocesspriorto theiruse. 5.2.6.6Integration&testfacilitiesandtesttools a. Thecapabilityoftheintegration&testfacilitiesandtesttoolstoperformtheirintended functionintermsofperformanceandcalibrationshallbeverifiedaspartoftheoverall integrationandtestprocess. NOTE: SeeECSSQST2007fortestfacilities.
Yes
No
No
No
Yes
No
Yes
No
No
No
Yes
No
GSE Yes Yes No No No No
No
Yes Yes
No No
Yes Yes
Yes Yes
No No
No No
No No
No
No
No
No
No
No
No
No No
No No
No No
No No
No No
No No
No No
No
No
No
No
No
No
No
89
perProduct/ Mission
Specificproducttype SpaceHW perPhase SpaceSW perLevel Launcher No No No No No No Ground segment Overall System No No No No No No No No No No No No No No Yes No Yes Yes No Yes Space element No No No No No No No
5.2.7Verificationprocessphasing a. Theverificationprocessshallbephasedwiththeprojectlifecycle,inaccordancewith ECSSMST10. b. Verificationplanningtoassessfeasibilityandsupportprogrammaticsshallstartinthe earlyphase(e.g.duringphaseA). c. Thepreliminaryverificationplanningshallcoverallproductsandrequirementsbythe endofphaseB. d. VerificationplanningshallbecompletedbytheendofPhaseC.NOTE:Coveringall verificationstagese.g.prelaunch,inorbit(includingcommissioning)andpostlanding. e. Verificationexecutionandreportingshallbeincrementallycarriedoutthroughthe projectlifecyclestartingfromphaseC. f. Verificationcontrolshallstartwiththeinitialissueoftheverificationcontroldocument (VCD)duringphaseB. g. Verificationcloseoutstatusshallbeassessedandapprovedbythecustomerforeach productattheendofeachstage. NOTE: E.g.qualificationcloseoutstatusattheendofthequalificationstage duringtheQualificationReview(QR). 5.2.8Verificationplanningdocuments 5.2.8.1Verificationplan(VP) a. ThesuppliershallprovideaVerificationplan(VP)forthereviewsasagreedwiththe customer NOTE: GuidelinesareinAnnexG. b. ThecontentsoftheVerificationplan(VP)shallbeinaccordancewiththeDRDinAnnexA. 5.2.8.2VerificationControlDocument(VCD) a. ThesuppliershallprovideaVerificationControlDocument(VCD)forthereviewsas agreedwiththecustomer
No No No No No No
No Yes Yes Yes Yes Yes
No No No No No No
No No No No No No
No No No No No No
No No No No No No
No
Yes
No
No
No
No
GSE Yes No Yes
No
Yes No Yes
Yes No No
Yes No Yes
Yes No Yes
Yes No Yes
Yes No Yes
Yes No Yes
90
perProduct/ Mission
Specificproducttype SpaceHW perPhase SpaceSW perLevel Launcher No Ground segment Overall System No No Yes No Yes No No Yes No No No No No No No No No Yes Space element No Yes No
NOTE: GuidelinesareinAnnexG. b. ThecontentsoftheinitialissueoftheVerificationControlDocument(VCD)shallbein accordancewiththeDRDinAnnexB 5.2.8.3OtherverificationplanningDocument a. ThesuppliershallprovidetheAITPforthereviewsasagreedwiththecustomer NOTE: GuidelinesareinAnnexG.TheAssembly,IntegrationandTestplan (AITP)shallfollowtheDRDdefinedinECSSEST1003. b. TheAssembly,IntegrationandTestplan(AITP)shallfollowtheDRDdefinedinECSSE ST1003. 5.3VERIFICATIONEXECUTIONANDREPORTING 5.3.1General a. Thesuppliershallassignclearresponsibilityfortheimplementationoftheverification programme. b. TherequirementsforthetestpreparationandexecutionincludingTestReadinessReview (TRR)andPostTestReview(PTR)shallbeasperECSSEST1003. c. Whennonconformityisdetectedduringtheverificationprocess,aNonconformance Report(NCR),inconformancewithAnnexAofECSSQST1009,shallberaisedand processedaccordingtoECSSQST20 d. Theverificationresultsshallberecordedbythesupplierinreportsforreviewbythe VerificationControlBoard(VCB)throughtheVCD. 5.3.2Verificationexecutionandreportingdocumentation 5.3.2.1Testreport(TRPT) a. Thetestreport(TRPT)shallbesubmittedtotheVerificationControlBoard(VCB)after thetestcompletionwithinthetimeframeagreedwiththecustomer. b. ThecontentoftheTestreport(TRPT)shallbeinaccordancewiththeDRDinAnnexC. c. ThesuppliershallprovidetheTestreports(TRPT),forthereviewsasagreedwiththe
No
No
No
No
No
No
Yes No
No No
Yes No
Yes No
Yes No
Yes No
GSE No Yes No No No No Yes
Yes No
No Yes No No
No No No No
No No No No
No No No No
No Yes No No
No No No No
No Yes No No
No No Yes
No No Yes
No No Yes
No No Yes
No No Yes
No No Yes
No
No No Yes Yes
91
perProduct/ Mission
Specificproducttype SpaceHW perPhase SpaceSW perLevel Launcher No Ground segment Overall System No No No No Yes No No No Yes No No No Yes No No No Yes No No No Space element No No No Yes No
customer NOTE: GuidelinesareinAnnexG. d.ATestReport(TRPT)shallbeprovidedforeachTestVerificationTaskasidentifiedinthe VPorAITP 5.3.2.2Analysisreport(ARPT) a. TheAnalysisreport(ARPT)shallbesubmittedtotheVerificationControlBoard(VCB) aftertheanalysiscompletionwithinthetimeframeagreedwiththecustomer. b. TheAnalysisreport(ARPT)shallbeinaccordancewiththeDRDinECSSEST10CAnnexQ. c. ThesuppliershallprovideanAnalysisreport(ARPT),forthereviewsasagreedwiththe customer NOTE: GuidelinesareinAnnexG. d.AnAnalysisReport(ARPT)shallbeprovidedforeachAnalysisTaskasidentifiedinthe VP. 5.3.2.3Reviewofdesignreport(RRPT) a. TheReviewofdesignreport(RRPT)shallbesubmittedtotheVerificationControlBoard (VCB)afterthereviewofdesigncompletionwithinthetimeframeagreedwiththe customer. b. TheReviewofdesignreport(RRPT)shallbeinaccordancewiththeDRDinAnnexD. c. ThesuppliershallprovideaReviewofdesignreport(RRPT),forthereviewsasagreed withthecustomer NOTE: GuidelinesareinAnnexG. d.AReviewofDesignReport(RRPT)shallbeprovidedforeachReviewofDesignTaskas identifiedintheVP 5.3.2.4Inspectionreport(IRPT) a. TheInspectionreport(IRPT)shallbesubmittedtotheVerificationControlBoard(VCB) afterinspectioncompletionwithinthetimeframeagreedwiththecustomer.
No
No
No
No
No
No
No No Yes No
No No Yes No
No No Yes No
No No Yes No
No No Yes No
No No Yes No
GSE No No Yes No No
No No Yes No
No No Yes No
No No Yes No
No No Yes No
No No Yes No
No No Yes No
No No Yes No
No No Yes No
No
No
No
No
No
No
No
92
perProduct/ Mission
Specificproducttype SpaceHW perPhase SpaceSW perLevel Launcher No Yes No Ground segment Overall System No Yes No No Yes No No No No No No No Yes Yes Yes No No Yes Yes No No Yes Space element No Yes No No No No
b. TheInspectionreport(IRPT)shallbeinaccordancewiththeDRDinAnnexE. c. ThesuppliershallprovideanInspectionreport(IRPT),forthereviewsasagreedwiththe customer NOTE: GuidelinesareinAnnexG d.AnInspectionReport(IRPT)shallbeprovidedforeachInspectionVerificationTaskas identifiedintheVP 5.3.2.5Verificationreport(VRPT) a. ThesuppliershallprepareaVerificationreport(VRPT)whenmorethanoneofthe definedverificationmethodsareutilizedtoverifyarequirementoraspecificsetof requirements. b. TheVerificationreport(VRPT)shallbeinaccordancewiththeDRDinAnnexF. c. TheVerificationreport(VRPT)shallbesubmittedtotheVerificationControlBoard (VCB)afterthecompletionofthelastcontributingverificationactivitieswithinthetime frameagreedwiththecustomer. d. ThesuppliershallprovideaVerificationreport(VRPT),forthereviewsasagreedwith thecustomer NOTE: GuidelinesareinAnnexG 5.3.2.6OtherverificationexecutionandreportingDocument a.ThesuppliershallprovidetheTestspecifications(TSPE)forthereviewsasagreedwith thecustomer NOTE: GuidelinesareinAnnexG. b. TheTestspecifications(TSPE)shallbeinconformancewiththeDRDdefinedinAnnexB ofECSSEST1003. c. TheTestproceduresshallbeinconformancewiththeDRDdefinedinAnnexDofECSS EST1003. d.ThesuppliershallprovidetheTestprocedures(TPRO)forthereviewsasagreedwiththe
No Yes No
No Yes No
No Yes No
No Yes No
No Yes No
No Yes No
No No No
No No No
No No Yes
No No No
No No No
No No No
GSE Yes Yes No No Yes
No No No
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes No No Yes
Yes No No Yes
Yes No No Yes
Yes No No Yes
Yes No No Yes
Yes No No Yes
Yes No No Yes
93
perProduct/ Mission
Specificproducttype SpaceHW perPhase SpaceSW perLevel Launcher No Ground segment Overall System No No No No No No No No No No No No No No Space element No No No No No
customer NOTE: GuidelinesareinAnnexG. e. Therulesfortheanalysis,inspectionandreviewofdesignshallbedefinedinwriting beforetheirexecution. NOTE:Forexample,analysis,inspectionorreviewofdesignprocedures. 5.4VERIFICATIONCONTROLANDCLOSEOUT 5.4.1General a. TheimplementationoftheverificationprocessshallbecontrolledbytheVerification ControlBoard(VCB). b. Theverificationprocesscontrolshallbesupportedbyacomputerbasedverification database. c.Theverificationdatabaseshallbedeliveredtothecustomerinanelectronicformtobe agreedwiththecustomer d. Thesuppliershallprovidetothecustomerverificationevidenceforthecustomers applicablerequirementsagreedtobeverified,independentlyfromthelevelwhere verificationhasbeenaccomplished. 5.4.2Verificationcontrolboard(VCB) a. AVerificationControlBoard(VCB),withparticipationofcustomerandsupplier representatives,shallbeestablishedtoincrementallyassesstheachievementsandthe statusoftheverificationprocess. NOTE: TheVCBissetupinrelationtothecomplexityandtheextentsofthe verificationactivities. b. TheverificationprocessshallbeconsideredcompletedwhentheVerificationControl Board(VCB)confirmsthat: 1 documentedevidenceisrecordedintheVCD, 2. identifiedrequirementshavebeenverified 3. associatedproductverificationobjectivesarereached
No
No
No
No
No
No
No No No No
No No No No
No No No No
No No No No
No No No No
No No No No
GSE No No
No No No No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
94
perProduct/ Mission
Specificproducttype SpaceHW perPhase SpaceSW perLevel Launcher No Ground segment Overall System No No No No No No No No No No No No No No No No Space element No No
c. TheconclusionsoftheVCBshallbesubmittedforapprovaltothecustomerscontractual authority. d. TheVerificationControlBoard(VCB)shallassesstheverificationstatuswitha periodicityagreedwiththecustomer,alongtheprojectlifecycle. NOTE: TheresultsoftheVCBareatleastpresentedontheoccasionsofproject reviewsasdefinedinECSSMST10. e. TheVerificationControlBoard(VCB)shallendorsethefinalissueoftheVerification ControlDocument(VCD). 5.4.3Reverification a. TheextentofthereverificationtobeperformedshallbedeterminedbySupplierand agreedwiththecustomer,inthefollowingcases: 1. failureandrepairasdecidedbyNonconformanceReviewBoard(NRB); 2. unplanneddisassemblyordemating; 3. refurbishment,maintenanceordesignchanges; 4. changesofrequirementsafterinitialverification; 5. longdurationstorage; 6. flightuseofqualificationhardware. b. TheVerificationControlDocument(VCD)shallbeupdatedbythesuppliertorecordas open,thoserequirementssubjecttoreverificationuntilthisisperformedandcloseout agreedbythecustomer. 5.4.4Verificationcontrolandcloseoutdocumentation 5.4.4.1VerificationControlDocument(VCD) a. ThecontentofthecompletedVerificationControlDocument(VCD)shallbein accordancewiththeDRDinAnnexB. b. ThesuppliershallupdatetheVerificationdatabasewithinoneweekoftheapprovalofa report. c. TheintermediateissuesoftheVerificationControlDocument(VCD),reflectingthe
No
No
No
No
No
No
No
No
No
No
No
No
GSE No No No No No No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No No No
No Yes No
No Yes No
No No No
No No No
No No No
No No No
95
perProduct/ Mission
Specificproducttype SpaceHW perPhase SpaceSW perLevel Launcher Yes Ground segment Overall System Yes Yes No No No No Space element Yes No
currentstatusoftheverificationdatabase,shallbemadeavailabletotheVerification ControlBoard(VCB)uponrequest. d. TheintermediateissuesoftheVerificationControlDocument(VCD),reflectingthe currentverificationandcompliancestatus,shallbedeliveredateachformalreviewas agreedwiththecustomer NOTE:GuidelinesareinAnnexG. e. ThefinalissueoftheVerificationControlDocument(VCD)shallbesubmittedtothe VerificationControlBoard(VCB)aftertheapprovalofthelastreportwithinthetime frameagreedwiththecustomer. 5.4.4.2Othercloseoutdocuments a. Thesuppliershallmakeavailabletothecustomerforconsultationtheevidences mentionedintheVCDinadditiontothedeliverablereports.
Yes
Yes
Yes
Yes
Yes
Yes
No
No
No
No
No
No
GSE No
No
No
No
No
No
No
No
No
96

ECSS E HB 10 02A (17december2010)

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

ECSS E HB 10 02A (17december2010)

Uploaded by

Copyright:

Available Formats

ECSS-E-HB-10-02A

ESARequirementsandStandardsDivision ESTEC,P.O.Box299, 2200AGNoordwijk TheNetherlands 2010bytheEuropeanSpaceAgencyforthemembersofECSS

4 Verification principles ..........................................................................................12

5 Verification guidelines .........................................................................................14

Verification execution and reporting .........................................................................51

Verification control and close-out ............................................................................. 53

6 Verification documentation .................................................................................56

Verification execution and reporting documentation ................................................ 69

3 Terms, definitions and abbreviated terms

Terms specific to the present handbook

verificationmethodperformingatheoreticalorempiricalevaluationusingtechniquesagreedwiththe customer NOTE Theselectedtechniquescantypicallyincludestatistics,qualitative designanalysis,modellingandcomputersimulation.

ECSSEHB1002A 17December2010 3.2.6 model philosophy

Verification Control Board (VCB)

Verification versus Validation

Applicability to all engineering domains

Select methods and levels of verification and associated model philosophy

Identify the phases and events in which the verification is implemented

Reiterations for technical - cost - schedule reasons

Identificationoftheresourcesrequired. 5.2.1.4 When (stage and event)

Theverificationstagesareselectedtakingintoaccount: a. b. c. theprojectcharacteristics, theassociatedlifecycle theadoptedmodelphilosophy

Eveniftheverificationprogrammeincludesaninorbitstageorapostlandingstage,theverification isconductedalsobeforelaunch(thisisshownwiththeentriesintheVerificationstagesoftheVCD relevanttoprelaunchongroundverificatione.g.qualification,acceptance). 5.2.4.2

Offtheshelfproductwithoutmodifications. Deltaqualificationprogramme, However: decidedonacasebycasebasis.

Offtheshelfproductwithdesign modifications Modificationincludeschangestodesign, parts,materials,tools,processes, procedures,supplier,ormanufacturer Newlydesignedanddevelopedproduct.

Deltaorfullqualification programme(includingtesting), decidedonacasebycasebasis dependingontheimpactofthe modification.. Fullqualificationprogramme.

Intheacceptancestagetheverificationshalldemonstratethattheproductisfreeof workmanshiperrorsandisreadyforsubsequentoperationaluse. Acceptanceshallbecarriedoutonthefinalhardwareandsoftware.

ECSSEST1002Cclause5.2.4.3.2specifiesthat: a. b. Theacceptancearticleshallbemanufacturedinagreementwiththequalifieddesign. Theacceptancearticleshallperformasthequalifiedproduct.

ECSSEST1002Cclause5.2.4.4specifiesthat: a. b. Intheprelaunchstagetheverificationshalldemonstratethattheproductisproperly configuredforlaunchactivitiesandearlyoperations. Intheprelaunchstagetheverificationshallconfirmthattheproductiscapableof functioningasplannedduringlaunchandearlyoperations.

Models and Models Description

Development Model (DM)

ECSSEHB1002A 17December2010 5.2.5.2.4

Thermal Model (ThM)

Structural-Thermal Model (STM)

Electrical and Functional Model (EFM)

Engineering Model (EM)

Engineering Qualification Model (EQM)

ECSSEHB1002A 17December2010 5.2.5.2.11

Life Test Model (LTM)

Proto-Flight Model (PFM)

Flight Model (FM)

Flight Spare (FS)

Function oriented model

aerodynamicmodels, roboticsandautomationmodels,and groundsegmentfunctionalmodels. Training model

trainflightcrewandgroundpersonnel, developandverifyprocedures, establishtrainingrecords,and performbaselinedatacollection.

Virtual and hybrid models

Human related models

Ground segment specific models

Developmenttesting Sometimeitisalso calledbreadboard (BB)

Qualification structuraldesign Validationof structural mathematical model

Qualificationof thermaldesign Validationof thermal mathematical model

SM&ThM representativity Equipmentthermo structural dummies

Simulationof functional&RF performances

Flightdesign Commercialparts Functional representativity

Functional development S/Wdevelopment Procedure validation Prepareflighttest programme Closedlooptests

Functional representativity Commercialparts Simulatorsof missingparts

Developmentor qualificationtesting Itcouldbeconsidered somethinginbetween amockupandanEM Sometimeiscalled alsoIntegration Model

Engineering QualificationModel (EQM)

Functional qualificationof design&I/Fs EMC

QualificationModel (QM) LifetestModel(LTM)

Equipmentlevel SSlevel Equipmentlevel

Modelfor mechanismsina protoflightapproach withlifetime requirements Cannotbeusedfor flight

Flightuse Design qualification

Qualificationagainst theapplicable functional requirements Flighttraining baselinedata