1 / 28

GLAST Large Area Telescope: A review of the LAT EGSE Plan January 24, 2005 Mike Huffer

Gamma-ray Large Area Space Telescope. GLAST Large Area Telescope: A review of the LAT EGSE Plan January 24, 2005 Mike Huffer mehsys@slac.stanford.edu (650) 926-4269. Outline. Objective was to define the components necessary to:

audra
Télécharger la présentation

GLAST Large Area Telescope: A review of the LAT EGSE Plan January 24, 2005 Mike Huffer

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Gamma-ray Large Area Space Telescope GLAST Large Area Telescope: A review of the LAT EGSE Plan January 24, 2005 Mike Huffer mehsys@slac.stanford.edu (650) 926-4269

  2. Outline • Objective was to define the components necessary to: • support LAT development & test from lab through observatory • Enumerate constraints: • space/craft (S/C) “implementations” • test-executives • The VSC (Virtual Space/Craft) … • Enumerate a set of test, development, and integration Environments • For each environments specify: • logical block diagram (identifies necessary components) • S/C implementation used • test-executives used • S/C to LAT harness differentiation • identify hot issues • Goals: • preserve continuity of test environments • minimize number of different harness • compile “issues” list and an implementation plan

  3. Space-craft implementations • The “real thing” • The Spectrum-Astro Instrument Simulator (SIIS) • The SLAC SC simulator (VSC)

  4. Test-Executives (T/E) • Generic requirements for a Test-Executive: • monitors the safety and health of its equipment under test • controls the equipment under test • performs necessary real-time analysis of equipment’s telemetry • relays telemetry to science analysis center for off-line analysis and achieving • LAT’s EGSE model based on the necessity for two different types of T/Es based on use: • Instrument commissioning • Instrument acceptance and validation • Instrument validation & operation • Must treat the instrument as if it were operating in its fly-away context • Instrument commissioning: • requires precise control of the instrument under test • must be highly responsive • must have “fat” telemetry pipes for rapid turn-around of analysis

  5. Test-Executive numbers • I & T and FSW’s differing emphasis required 2 more Test Executives: • LTX • uses the instrument to develop and test its software • LATTE • used by the sub-systems to develop the instrument • used by I & T to test both the instrument and FSW • If four were not enough, additional requirements required yet more: • AstroRT • required for interface validation and observatory operation • ISOC test-executive (ITE) • may be driven by MOC choice • final architecture under development (blend of LATTE5 and ITOS)

  6. Test-Executives summarized • Test-executives developed for instrument commissioning: • LTX • LATTE4 • Test-executives developed for instrument validation and operation: • LTX++ • LATTE5 • AstroRT • ITE • Six are a lot! • even if one makes the case that LATTE is a super-set of LTX they cannot (should not) be merged: • would lose significant investment in user code base and training • cannot discard instrument commissioning T/E’s in instrument validation phase: • valuable and necessary diagnostic tool when things go wrong • schedule dictates may make fat telemetry pipes necessary • Significant goal of the VSC is to ensure coherency of T/Es used in all environments which require instrument validation and operation: • common Command and Telemetry Database • common Interface to Space-Craft (independent of its implementation)

  7. Environments requiring EGSE support • Software development and test • Location: Dataflow lab • Prime participants: • FSW • I & T • ISOC • Subsystems • Instrument integration and test • Location: SLAC clean room • Prime participants: • I & T • FSW • S/C-LAT interface validation: • Location: SLAC clean room and Dataflow lab • Prime participants: • I & T • Spectrum-Astro • Must test both functional interface and harness • Thermo-Vac (TV) testing: • Location: NRL • Prime participant: • I & T • Electro-Magnetic Interference (EMI) testing • Location: NRL • Prime participant: • I & T • Observatory integration and test (from the LAT’s perspective) • Location: Spectrum-Astro and KSC • Prime participant • I & T • ISOC • Mating of S/C and LAT

  8. VSC “features” • The VSC is: • both a physical module and an external software interface to it… • a functional interface (does not emulate S/C mechanics or power) • No ITAR restrictions • Tests all redundancy (Primary, Redundant and cross-strapping) • Acquires and relays all LAT-centric spacecraft telemetry • Public, well defined, Back-End (ground) interface • allows use by more then one type of test executive • Delivery, maintenance, and extensibility issues under LAT control • Extensive and flexible physics simulation • attitude and re-pointing model • interface to FES • allows time correlation and coherency between spacecraft, dataflow system, and simulated event data • Relatively inexpensive • Portable

  9. TTM 637 SCI SCI DISC 1553 1553 TCLK TCLK A A HRS B B MINS SECS Hardware discretes and reset VMESC5 SBC 2304 Primary Science A B C D E Primary 1553 SYSTRAN I/O GPS Analogs 6U/9S VME crate

  10. VSC Proxy Interface B B A B B B A A A A discretes discretes reset reset 1553 discretes discretes reset reset 1553 1553 Science Science Science 1-PPS 1-PPS 1-PPS GRB GRB GRB VSC Interfaces Test Executive GPS TCP/IP Time-tone VSC control LAT commanding LAT telemetry VSC telemetry LAT science Front-End Back-End VSC Primary Redundant Primary Primary A B 1553 FES Analogs Science 1-PPS GRB DAQprimary DAQredundant SIUprimary SIUredundant FES GASU LAT

  11. Proxy (T/E) interface • Queue for either immediate or deferred (timed) execution on VSC: • Commanding stream • any arbitrary set of telecommands, in any order from C & T DB • Control stream • ancillary sequence (for an arbitrary number of cycles) • GRB Message • LAT reset request • assert/Deassert discrete(s) • assert/Deassert SSR “device ready” • select: • GASU DAQ board and its cross-strapping • SIU and its cross-strapping • Discretes and their cross-strapping • start/Stop FES • set time • Receive (asynchronously) telemetry from … • LAT (housekeeping and diagnostics) • LAT Science (events and science diagnostics) • VSC telemetry (analog temperatures, voltages, etc…)

  12. EGSE following the instrument through most of its phases… • LAT Test-Executives hosting environments (not an EGSE issue) • The Virtual Space-craft (VSC) • simulates the functional role of the S/C from the LAT’s perspective • Power Resource Box • presents “flight-like” power interface between LAT and S/C • regulates and monitors S/C power presented to LAT • External Test Box • allows margin testing of both clock and internal power • synchronizes observatory and external clocks • provides external trigger for dataflow system • External Crate • emulates either an SIU or EPU • allows monitoring of LAT while operating in fly-away context • allows standalone operation of instrument commissioning Test Executives, which include: • LATTE4 • LTX

  13. Software development and test environment To platform(s) hosting T/E

  14. Software development and test environment • VSC assumes role of spacecraft • Little logical difference from instrument test & integration environment • adds support for physics simulation (FES) • Harness designed for room specific restrictions • built, tested, in use • External crate is used to operate: • LATTE4 (I & T, subsystem, and electronics, development) • LTX (FSW development) • VSC is used to operate: • LATTE5 (I & T development) • LTX ++ (FSW and FSW/Test development) • ITE (ISOC development and eventually flight maintenance)

  15. Instrument integration and test environment

  16. Instrument integration and test environment • VSC assumes role of spacecraft • Harness designed to be “flight like” • Issue: this might be in conflict with physical constraints • External crate is used principally as a diagnostic tool • LATTE 4 (I & T, subsystem, and electronics, diagnostics, perhaps a part of the total CPT) • LTX (FSW diagnostics) • VSC is used to operate: • LATTE 5 (I & T CPT) • LTX ++ (FSW and FSW/Test CPT)

  17. TV testing environment

  18. TV testing environment • VSC assumes role of spacecraft • Harness has two components: • outside the TV chamber and inside the TV chamber • both harness penetrate chamber through 7 flanges • primary and redundant penetrations must be located close to each other. This implies 5 sets of flanges which could be located anywhere with respect to each other. • outside harness is re-used for EMI testing • for inside harness attempt re-use of Spectrum-Astro cables • Issue: what does reuse imply? • External crate is used principally as a diagnostic tool • LATTE 4 (I & T, subsystem, and electronics, diagnostics, perhaps forms a part of the total CPT) • LTX (FSW diagnostics) • VSC is used to operate: • LATTE 5 (I & T CPT)

  19. S/C-LAT interface validation environment

  20. S/C-LAT interface validation environment • SIIS assumes role of spacecraft • Uses Spectrum-Astro harness • issue: will this conflict with proposal of re-use from TV? • This test is conducted only when ICD is either validated or modified. The goal would be once in the: • dataflow lab • clean-room • External crate is used principally as a diagnostic tool • LATTE 4 (I & T, subsystem, and electronics, diagnostics, perhaps forms a part of the total CPT) • LTX (FSW diagnostics) • SIIS is used to operate: • Astro-RT • acceptance test is re-used from ISIS experience

  21. EMI testing environment

  22. EMI testing environment • VSC assumes role of spacecraft • Harness has two components: • outside the EMI chamber and inside the EMI chamber • re-use external cables from TV • internal harness (power) must be changed to accommodate: • NIIS • Isolation transformer • issue: There seems to be some difference of opinion about whether or not EGSE must be outside chamber • External crate is used principally as a diagnostic tool • LATTE 4 (I & T, subsystem, and electronics, diagnostics, perhaps forms a part of the total CPT) • LTX (FSW diagnostics) • VSC is used to operate: • LATTE 5 (I & T CPT)

  23. Observatory test and integration environment

  24. Observatory test and integration environment • The “real thing” assumes role of spacecraft • Harness is now irrelevant • External crate is used to operate: • LATTE4 (I & T, subsystem, and electronics, diagnostics) • LTX (development of FSW) • Operation of LAT is now through some (as yet unidentified) Spectrum-Astro EGSE • issue: Can we preserve VSC’s proxy interface and our total code base, if this EGSE has a back-end interface? • issue: If so, ITAR?

  25. Summary • Multiple Test Executives are a forgone conclusion • External crate and test-box are invariants • VSC stays until observatory test and integration • SIIS only used for interface validation • ITAR issues can be either eliminated or substantially reduced: • but requires VSC… • Four additional harnesses are envisioned: • clean-room operation and “Flight-Like” harness validation • external harness for EMI and TV • internal harness for TV • internal harness for EMI • Potential LAT schedule drivers: • VSC completion for FSW and FSW/Test • Harness design and construction for clean-room • Internal harness decisions for TV (long-lead times on connectors)

  26. Implementation plan (1) • Complete detailed VSC design: • review for go-ahead by interested parties: • FSW and FSW/Test • I & T • ISOC • Build four (4) VSC’s: • 2 for Dataflow Lab (testbed and hot spare used in corners) • 2 for I & T (operation and one cold spare) • parts currently on hand (or order) to build two • estimated four week lead-time for additional parts • incremental M/E cost estimated at 40K$ • prototype completion estimated at four weeks after pulling trigger

  27. Implementation plan (2) • Compose substantive harness plan: • can we use only one (“flight-like”) harness throughout the LAT’s time in the clean-room? • what do the internal harness for TV and EMI look like? • what re-use can be achieved with Spectrum-Astro’s current harness? • how will re-use affect interface validation? • how will re-use affect harness delivery and schedule?

  28. Implementation plan (3) • Understand limitations and capabilities of Spectrum-Astro’s observatory EGSE • is there a back-end interface? • can we get its specifications? • can we modify specifications to meet our requirements? • what are the ITAR implications? • what are the consequences with respect to VSC control and telemetry interfaces? • The answers to these questions will require close interaction and cooperation with both Goddard and S/A

More Related