280 likes | 442 Views
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:
E N D
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: • 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
Space-craft implementations • The “real thing” • The Spectrum-Astro Instrument Simulator (SIIS) • The SLAC SC simulator (VSC)
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
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)
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)
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
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
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
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
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…)
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
Software development and test environment To platform(s) hosting T/E
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)
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)
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)
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
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)
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?
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)
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
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?
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