ARIEL Design, Development, Verification And Engineering Plan

2y ago
31 Views
2 Downloads
1.10 MB
38 Pages
Last View : 1m ago
Last Download : 2m ago
Upload by : Gia Hauser
Transcription

ARIEL PayloadConsortiumARIEL Design,Development, Verificationand Engineering PlanDoc Ref: ARIEL-RAL-PL-PL-002Issue: 1.0Date: 11 February 2017ARIEL Consortium Phase A PayloadStudyARIEL Design, Development,Verification and EngineeringPlanARIEL-RAL-PL-PL-002Issue 1.0Prepared by:ppDigitally signed by PaulEcclestonDate: 2017.02.11 18:12:34ZGeorgia Bishop (RAL Space)Date:Systems EngineerReviewed by:Digitally signed by KevinMiddletonDate: 2017.02.14 08:44:39 ZKevin Middleton (RAL Space)Date:ARIEL Payload Systems EngineerApproved &Released by:Digitally signed by PaulEcclestonDate: 2017.02.11 18:12:57 ZDate:Paul Eccleston (RAL Space)Consortium Project ManagerARIEL Design, Development, Verification and Engineering PlanPage i

ARIEL PayloadConsortiumARIEL Design,Development, Verificationand Engineering PlanDoc Ref: ARIEL-RAL-PL-PL-002Issue: 1.0Date: 11 February 2017DOCUMENT CHANGE 7All1.011/02/17AllDescription Of ChangeNew document created based on ECHO-PL-0004-RAL.Minor changes and updates from proofing by PE. Allprevious tracked changes accepted or modifiedaccordingly. Details of subsystem DDV plans removeduntil iterated with consortium.Updated with comments from consortium review.Further minor updates from reviewFinal additions and review of TRL levels and plans.Document released at draft for MCR datapack.Doc updated with outcomes from second part of phaseA study. Technology evaluation moved to separate TN.Addition of verification level planning matrix as AnnexA.Release of first issue for MSRARIEL Design Development Engineering and Verification PlanCommentUpdated by PE &GBUpdated by PEPage ii

ARIEL PayloadConsortiumARIEL Design,Development, Verificationand Engineering PlanDoc Ref: ARIEL-RAL-PL-PL-002Issue: 1.0Date: 11 February 2017DISTRIBUTION LISTARIEL Payload ConsortiumCo-PIs Giovanna TinettiGiusi MicelaJean-Philippe BeaulieuPaul HartoghEnzo PascaleIgnasi RibasHans Ulrik Nørgaard-NielsenMichiel MinMirek RatajBart VandenbusscheManuel GudelDavid LuzStudy Engineering TeamWorking Group Leads Paul Eccleston Kevin Middleton Emanule Pace Gianluca Morgante Tom Hunt Vania Da Deppo Pino Malaguti Jerome Amiaux Pep Colome Jean-Louis Auguères Etienne Renotte Martin FrericksExternalEuropeanSpaceAgencyGoren PilbrattLudovic PuigAstrid HeskeOther Engineering Team As necessary for docARIEL Design Development Engineering and Verification PlanPage iii

ARIEL PayloadConsortiumARIEL Design,Development, Verificationand Engineering PlanDoc Ref: ARIEL-RAL-PL-PL-002Issue: 1.0Date: 11 February 2017TABLE OF CONTENTSDocument Change Details . iiDistribution List.iiiTable of Contents . ivPreamble . 71.1Scope . 71.2Purpose . 71.3Background to ARIEL and the ARIEL Payload . 71.4Applicable Documents . 71.5Reference Documents . 81.6Terms, Definitions and Abbreviations . 8Product Tree and Payload Responsibilities . 9Development Plan . 103.1Payload Qualification Approach . 103.2Payload Level Model Philosophy Analysis . 10Required Deliverable Models . 103.2.13.2.1.1Deliverable Structural Thermal Model (STM) . 103.2.1.2Deliverable Avionics Model (AVM) . 103.2.1.3Deliverable Proto Flight Model (pFM) . 113.2.1.4Non-Deliverable FS Components. 113.2.2Generic Payload Level Verification Flow . 113.2.3Critical Items and Risk Reduction Requirements . 113.2.3.1Active Cooler System . 113.2.3.2Detector Modules . 123.2.3.3Dichroic Chain . 12Payload Test Summary . 133.33.3.1Payload Level Test Matrix . 133.3.2Detailed Payload Model Build Standards . 143.3.2.1STM Payload Build Standard. 143.3.2.2AVM Payload Build Standard . 153.3.2.3PVM (for use at RAL) Payload Build Standard . 153.4Subsystem Level Development Approach Overview . 153.5Ground Support Equipment Development Plans . 153.5.1Required Ground Support Equipment Requirements by Payload Model . 153.5.2Mechanical Ground Support Equipment (MGSE) . 153.5.3Optical Ground Support Equipment (OGSE) . 153.5.4Electrical Ground Support Equipment (EGSE) . 163.5.5Integration and Test Facilities . 16ARIEL Design Development Engineering and Verification PlanPage iv

ARIEL PayloadConsortiumARIEL Design,Development, Verificationand Engineering PlanDoc Ref: ARIEL-RAL-PL-PL-002Issue: 1.0Date: 11 February 2017Payload Level AIV Planning . 163.6TECHNOLOGY ASSESSMENT AND NEAR-TERM DEVELOPMENT PLANS . 18Spares Philosophy . 19Subsystem Level Spares . 195.1Engineering Planning . 20Requirements Management . 206.1Requirements Engineering Process . 206.1.16.1.1.1Requirement Identification, Analysis and Validation . 206.1.1.2Requirement Allocation . 226.1.1.3Requirement Maintenance . 22System Analysis . 236.26.2.1Structural Analyses. 236.2.2Thermal Analyses. 236.2.3Optical Analyses . 246.2.4STOP Analysis . 246.2.5Electrical Analysis . 246.2.6Systems Interaction Analyses . 25Technical Design Activities . 256.36.3.1Payload Systems Team . 256.3.2Technical Resource Management . 25Flight Software Activities . 276.4Verification Planning . 28Verification Objectives . 287.17.1.1Verification Process Logic . 287.1.2Verification Process Flow . 287.1.3Verification Approach . 287.1.3.1Verification Approach Derivation . 297.1.3.2Verification Close-out . 297.1.3.3Verification Close-out Exceptions. 29Verification Methods . 297.1.4Verification Responsibilities . 297.27.2.1Verification Control Board (VCB) . 297.2.2Other Reviews . 30Verification Planning Overview. 307.37.3.1Planning for Verification by Test. 307.3.1.1Test Programme Definition. 307.3.1.2Re-Integration Tests . 307.3.1.3Test Versus Verification Stages . 30ARIEL Design Development Engineering and Verification PlanPage v

ARIEL PayloadConsortiumARIEL Design,Development, Verificationand Engineering PlanDoc Ref: ARIEL-RAL-PL-PL-002Issue: 1.0Date: 11 February 20177.3.1.4Test Versus Verification Levels . 307.3.1.5Test Matrices . 307.3.2Planning for Verification by Analysis . 307.3.2.1Analysis Programme Definition . 317.3.2.2Verification Analysis Criteria . 317.3.2.3Similarity Criteria . 317.3.2.4Analysis Versus Verification Stages and Levels . 317.3.3Planning for Verification by Review of Design. 317.3.3.1Review-of-design Programme Definition . 317.3.3.2Review-of-design Versus Verification Stages and Levels . 327.3.4Planning for Verification by Inspection . 327.3.4.1Inspection Programme Definition . 327.3.4.2Inspection Versus Verification Stages and Levels . 32Annex A: Verification and Calibration PreliMinary Planning Table . 33ARIEL Design Development Engineering and Verification PlanPage vi

ARIEL PayloadConsortiumARIEL Design,Development, Verificationand Engineering PlanDoc Ref: ARIEL-RAL-PL-PL-002Issue: 1.0Date: 11 February 2017PREAMBLE1.1SCOPEThis plan defines the design and development approach for the ARIEL Payload during Phase B andPhase C/D activities. It is based on the currently defined requirements and constraints as given in theMRD (AD1) and PID-A (AD7). In particular, this DDEVP is informed by, and tailored from the ESA ECSSrequirements.This version of the document has been prepared for the Mission Selection Review (MSR), at the end ofthe phase A. Much detailed work remains to be carried out on all levels of the design and developmentplans at system, payload and sub-system level. We anticipate that this work will form a significant partPhase B activities and the DDEVPs for the spacecraft, payload and sub-systems will be harmonised andcompleted by the time of the PDR. A further review and iteration will then take place up to the CDR.After CDR it is proposed that this document would not normally be maintained and the information willbe superseded by subsequent up-issues of the following documents: 1.2ARIEL Payload AIV PlanARIEL Payload Internal Receivables and Deliverables Items List (RecDels)ARIEL Payload Product TreeARIEL Payload ScheduleSubsystem and unit level Design and Development Plans (as necessary)PURPOSEThis document serves as the master guide to the proposed plans for design and development of theARIEL Payload. The required hardware model philosophy is analysed and suggested (will be definitivelydefined in later issues of the document) and the impacts on the required fidelity of the deliveredsubsystems are examined. This document also provides the framework for the design and verificationmethodologies to be used by the ARIEL team throughout the project lifecycle.1.3BACKGROUND TO ARIEL AND THE ARIEL PAYLOADBackground information of the mission and science objectives can be found in [AD1] and [AD3] and adescription of the current Payload design can be found in the Design Document, [AD4].1.4APPLICABLE DOCUMENTSAD #1APPLICABLE DOCUMENT TITLEARIEL MRD (Mission Requirements Document)23Deleted at Iss 0.6 – superceeded by [AD4] and[AD7]ARIEL SciRD (Science Requirements Document)4567ARIELARIELARIELARIEL8ARIEL Payload Level Assembly Integration andVerification PlanARIEL Payload Product Assurance PlanARIEL Payload Critical Technologies Status andPlans910Payload Design Description DocumentPayload Consortium Management PlanTerms, Definitions and AbbreviationsPayload Interface Document Part-A PID-AARIEL Design Development Engineering and Verification PlanDOCUMENT E / DATE1.2 / Jan-20171.1 / Sep 20151.3 / Feb-2017ARIEL-RAL-PL-PL-0072.0 / Feb 20171.0 / Feb 20172.0 / Feb 20170.14 / December20161.0 / Feb 2017ARIEL-RAL-PL-PL-006ARIEL-RAL-PL-TN-0061.0 / Feb 20171.0 / Feb 2017Page 7

ARIEL PayloadConsortium1.5ARIEL Design,Development, Verificationand Engineering PlanREFERENCE DOCUMENT TITLEDeleted at Iss 0.6 – duplicate of [AD7]2Minutes of Meeting:Pathfinder Telescope Mirror Program KO1.6Issue: 1.0Date: 11 February 2017REFERENCE DOCUMENTSRD #13Doc Ref: ARIEL-RAL-PL-PL-002DOCUMENT IDARIEL-RAL-PL-DD001ARIEL-RAL-PL-MIN006ISSUE / DATE1.01.0TERMS, DEFINITIONS AND ABBREVIATIONSA list of the terms, definitions and abbreviations applicable to ARIEL can be found in [AD6].ARIEL Design Development Engineering and Verification PlanPage 8

ARIEL PayloadConsortiumARIEL Design,Development, Verificationand Engineering PlanDoc Ref: ARIEL-RAL-PL-PL-002Issue: 1.0Date: 11 February 2017PRODUCT TREE AND PAYLOAD RESPONSIBILITIESThe product tree is TBD.A block diagram of the payload (with the identification of national contributions) is shown in Figure 1below.Figure 1: Payload Block Diagram and ResponsibilitiesARIEL Design Development Engineering and Verification PlanPage 9

ARIEL PayloadConsortiumARIEL Design,Development, Verificationand Engineering PlanDoc Ref: ARIEL-RAL-PL-PL-002Issue: 1.0Date: 11 February 2017DEVELOPMENT PLAN3.1PAYLOAD QUALIFICATION APPROACHThe ARIEL Payload Module (PLM) will follow a proto Flight Model (pFM) approach to overall qualification.Some major design aspects will be de-risked earlier in the program using the prior models (as discussedin sections below), but it is planned that formal environmental qualification at complete payload modulelevel only takes place on the pFM Payload Module.The basic philosophy for the ARIEL verification programme is to test the critical interfaces,environmental requirements and functionality as early as possible during phases B/C/D to remove asmuch risk as possible from the proto flight model programme. This applies to all levels in the payloadand system build. The development and verification of the payload will be undertaken in accordancewith the requirements in the PID-A (AD7) and the guidance in the applicable ECSS standards.In order to allow early de-risking we plan to build a Performance Verification Model (PVM) of thePayLoad Module (PLM) and warm electronics units (ICU, FGE and CDE)) that will be form, fit andfunctionally compliant but with no compulsion that the units within it are capable of undergoingenvironmental testing to qualification level. This model will not be environmentally tested toqualification levels and is not proposed to be deliverable to spacecraft level. By following thisprogramme rather than committing to a full qualification model we allow flexibility in the schedule.That is, we are not dependent on completion of all unit qualification programmes to start the interfaceand performance verification activities at Payload level.At subsystem level there are a variety of qualification approaches that may be followed as outlined insection 3.4. Some subsystems (i.e. the cooler) have a dedicated qualification model which will undergoa full suite of environmental testing (including lifetime testing) prior to the FM builds. Some preliminarydetails are contained later in this document and in the appropriate subsystem level design anddevelopment plans, to be produced at a later stage.3.2PAYLOAD LEVEL MODEL PHILOSOPHY ANALYSIS3.2.1Required Deliverable ModelsThe following sub-sections outline our currently foreseen model philosophy, tailored to fit with ourdevelopment plan, the need to de-risk major interfaces with the spacecraft as early as possible and toreduce the overall model development schedule. Here then we outline our proposed build standardand the top level purpose of each of the deliverable models to be delivered to system level.3.2.1.1 Deliverable Structural Thermal Model (STM)The STM ARIEL Payload Module that will be delivered to S/C level AIV: Basic PLM structure with mass and thermal dummies – no functional requirementsThe earlier breadboard model of the Telescope primary mirror may well be part of this STM.Mechanical and thermal interfaces flight representative but not necessarily form / tolerancecompliantDevelopment of engineering model (EDM) coolers delivered alongside STM with EM CoolerDrive Electronics (CDE) – this is TBC dependant on schedule matching with S/C program.Capable of undergoing full spacecraft level environmental testing to qualification levels and hasbeen tested to qualification levels before delivery (TBC)Demonstrate thermal design and provide correlation for Thermal Mathematical Model (TMM)Used for mechanical fit check, vibration testing and thermal tests at S/C level3.2.1.2 Deliverable Avionics Model (AVM)The AVM that the ARIEL Payload will be delivered to S/C level AIV: ICU (incl. DCU), FGE and TCU engineering models or simulators and EGSE to simulate Payloadfunction.ARIEL Design Development Engineering and Verification PlanPage 10

ARIEL PayloadConsortium ARIEL Design,Development, Verificationand Engineering PlanDoc Ref: ARIEL-RAL-PL-PL-002Issue: 1.0Date: 11 February 2017Cooler control electronics breadboard / EM to simulate power draw and EMC to S/C level.Pull through of Payload AIV process including test facilities and proceduresUsed for Electrical interface compatibility testing at S/C levelUsed at system level to check out electrical and communications interfaces and set up groundtest sequences and flight operations.3.2.1.3 Deliverable Proto Flight Model (pFM)The pFM ARIEL Payload that will be delivered to S/C level AIV will provide for: pFM approach to most design aspects except as outlined elsewhere in this documentFull AIV sequence including appropriate system level performance verification and calibration3.2.1.4 Non-Deliverable FS ComponentsThe ARIEL flight spare philosophy is subject to further discussion and alteration.The FS ARIEL Payload components that will be held at either their institute of origin or at RAL (TBC)and delivered to S/C level if required for rapid replacement either at the satellite integration facility orfollowing return of the Payload Module to RAL All major units of the Payload will provide flight spare components at the appropriate level(TBD).Flight spare units will be tested at unit level or, where not possible on the Payload level PVM(TBD).Acceptance testing for most design aspects since formally qualified on pFM model.Further details on the spare philosophy and expected Flight Spare items will eventually (in phase B)given in the Project Management Plan [AD5].3.2.2Generic Payload Level Verification FlowWe show in Figure 2 how the various interface and environmental requirements are verified using thepayload models and how the information flows within the Payload development programme. Thisphilosophy mimics closely that undertaken for the JWST MIRI programme. In addition to undergoingtesting at Payload and unit level, we also expect information on interface compliance, functionality andperformance to be generated during the system level tests with the STM and AVM. This philosophy isexpected to be followed for the critical sub-systems and interfaces in the Payload. In somecircumstances full qualification before delivery to the PVM programme will be waived and a separateQM/pFM path may be followed. We have made an initial identification of the critical items which wediscuss in the following subsections. As the design is consolidated during phase B we will review andadjust both the AIV plan and the model philosophy as required to ensure all critical items are addressedas early as possible and at the appropriate level with the Payload, instrument and sub-system level AIVprogrammes.3.2.3Critical Items and Risk Reduction RequirementsIn order to reduce the risk levels on some of the key aspects of the ARIEL Payload design the followingactivities over and above those required to simply deliver the minimum required build standard for eachmodel have been included in the program.3.2.3.1 Active Cooler SystemWe highlight the active cooler system (ACS) as this is deemed as a single point failure for the Payload(and mission) requirements. The ACS will therefore follow a full qualification path. There will be atleast one EDM (i.e. engineering demonstration model) to address the functional, interface andperformance aspects as early as possible in the programme, a QM to undergo full qualification levelperformance, environmental and interface verification and a flight model. A second EDM may be builtfor use in the Payload PVM programme and either this or the QM will be used for lifetime testing. AnEDM is denoted as deliverable for system level testing and either this model or the QM will beARIEL Design Development Engineering and Verification PlanPage 11

ARIEL PayloadConsortiumARIEL Design,Development, Verificationand Engineering PlanDoc Ref: ARIEL-RAL-PL-PL-002Issue: 1.0Date: 11 February 2017permanently available for spacecraft integration and performance tests. The need for more than oneEDM is highly dependent on the spacecraft development programme and merging of the spacecraftand Payload development schedules must be addressed as early as possible during phase B. The PVMPayload testing will use QM or a hybrid GSE and EDM cooler. The pFM PLM will require the FM coolerto be delivered to RAL Space as separate parts (see AIV flow) for integration and full thermal verificationahead of delivery to the spacecraft. The FM cooler will therefore be integrated and tested in arepresentative thermal environment, and acceptance vibration tested before being delivered into thePayload PFM AIV programme.3.2.3.2 Detector ModulesThe detector modules are a complex mix of solid state detector array technology and highly integratedcold front end electronics (CFEE). For the FGS / NIRPhot / NIRSpec and AIRS modules, the interfacebetween the CFEE and the detector arrays, provided by potentially different consortium institutes, is apotential critical item. To de-risk the interface problems we will request representative engineeringmodel detector arrays to be supplied as early as feasible within the project cycle at the same time asthe CFEE. The development of the CFEE can then be conducted against known interfaces muchreducing the risk of incompatibility later in the project. Thermal and mechanical aspects of the detectormodule design will be separately developed and verified in STM modules using mechanicallyrepresentative detector arrays and CFEE.3.2.3.3 Dichroic ChainThe individual dichroics and filters do not represent a significant development risk for the Payload.However, previous experience has shown that using chains of dichroics and filters in combination canlead to unexpected results with possible straylight paths and chromatic leaks. To reduce the risk ofthis we will purchase a representative set of dichroics and filters early in the program to test themindividually and, where possible, in combination. The testing will be carried out in a representativeoptical environment paying particular attention to testing them in the same optical beams (f/#) andincident angles at which they will be employed in the Payload.Figure 2: Generic verification flow for the ARIEL Payload programmeARIEL Design Development Engineering and Verification PlanPage 12

ARIEL Design,Development, Verificationand Engineering PlanARIEL PayloadConsortiumDoc Ref: ARIEL-RAL-PL-PL-002Issue: 1.0Date: 11 February 2017The blue boxes indicate the unit level models required, the green boxes indicate payload modelsproposed for delivery to system and the grey box non deliverable payload models. The red connectorsshow physical deliveries and the others information flow. The uncoloured boxes indicate theinformation generated from the model test programmes at unit, Payload and/or system level. The textbelow each model indicates what verification issues will be addressed.3.3PAYLOAD TEST SUMMARY3.3.1Payload Level Test MatrixOur approach to test and qualification of the Payload as a whole is to remove as much of the risk atthe higher levels of integration as possible by undertaking verification activities on the sub-systemsdelivered into first the Instruments then the Payload Module AIV programme. To this end we arecurrently suggesting the following model and verification plan for the deliverable sub-systems; thesewill be iterated throu

and Engineering Plan Doc Ref: ARIEL-RAL-PL-PL-002 Issue: 1.0 Date: 11 February 2017 ARIEL Design Development Engineering and Verification Plan Page vi 7.3.1.4 Test Versus Verification Levels. 30 7.3.1.5 Test Matrices

Related Documents:

Genuine Ariel Parts selected and installed by an Ariel distributor. Ariel's "Unit‑Down" Parts Procurement Process If something happens to your Ariel compressor, whether a warranty issue or other event, Ariel and its Distributors will work together to determine the best plan of action to get your unit back in operation.

Ariel Original Equipment Manufacturer Parts keep your Ariel compressor running like new. Ariel OEM Parts are the exact same high-precision, exceptional quality parts that go into Ariel's new units. Available through over 700 world-wide distributor locations, Ariel OEM Parts are offered at a fair price and supported by Ariel expertise.

Sebastian attempts, without success, to convince Ariel that the sea is where Ariel should be (Under The Sea & After “Under”). King Triton confronts Ariel about saving a human and during the confrontation King Triton destroys Ariel’

Design vs. Verification Verification may take up to 70% of total development time of modern systems ! This ratio is ever increasing Some industrial sources show 1:3 head-count ratio between design and verification engineers Verification plays a key role to reduce design time and increase productivity 10 IC Design Flow and Verification

Ariel drive in spirits in the shape of dogs and hounds, who chase off the would-be conspirators. Act Five Scene 1 The same Ariel informs Prospero that it has reached the sixth hour, the time at which he has promised Ariel his freedom. Prospero acknowledges this, but skims over it as he is fully engrossed in his plan now.

Fruchtenbaum, Arnold G. FOOTSTEPS OF THE MESSIAH, Ariel Press, Ariel Ministries Ryrie, Charles C. DISPENSATIONALISM, Moody Press Ryrie, Charles C. BASIC THEOLOGY, Victor Books Showers, Renald E. THERE REALLY IS A DIFFERENCE, Friends of Israel Gospel Ministry Walvoord, John F., Editor LEWIS SPERRY CHAFER SYSTEMATIC THEOLOGY, ABRIDGED

(System-on-Chip). This has made verification the most critical bottleneck in the chip design flow. Roughly 70 to 80 percent of the design cycle is spent in functional verification. [1]System Verilog is a special hardware verification language to be used in function verification. It provides the high-level data structures available

The mission of The American Board of Radiology is to serve patients, the public, and the medical profession by certifying that its diplomates have acquired, demonstrated, and maintained a requisite standard of knowledge, skill and understanding essential to the practice of diagnostic radiology, radiation oncology and radiologic physics Six Competencies 1. Professional & Medical Knowledge 2 .