NASA ESA Meeting 012301

1
Achieving Autonomous Operations For NASAs
GLAST Mission
Mike Rackley NASA Goddard Space Flight
Center Michael.W.Rackley_at_nasa.gov Ernest
Canevari ASRC Aerospace Corporation Ernest.Canevar
i_at_akspace.com
2
Agenda

• Mission Overview
• Architecture Overview
• Operations Automation Scenarios
• Mission Planning and Commanding
• Target of Opportunity (TOO) Handling
• Real-Time Contacts
• Burst Alert Handling
• Solid State Recorder (SSR) Management
• Data Processing
• As-Flown Timeline
• Trending and Analysis
• Automation Summary
• Next Step in Automation GMSEC

3
GLAST DOE and NASA Partnership
Department of Energy Office of Science
NASA - Office of Space Science
Chart the evolution of the universe, from origins
to destiny 1. Understand the structure of the
universe 2. Explore the ultimate limits of
gravity and and energy in the universe 3. Learn
how galaxies, stars and planets form, interact
and evolve
Particle physics
Astronomy/astrophysics
Gamma ray Large Area Space Telescope (GLAST) An
astro-particle physics partnership to explore the
high-energy universe
4
GLAST Science

• GLAST is a high-energy gamma-ray observatory for
  observing celestial sources in the energy band
  extending from 20 MeV to 300 GeV with
  complementary coverage between 10 keV and 25 MeV
  for gamma-ray bursts. GLAST will
• Identify/study natures high-energy particle
  accelerators through observations of active
  galactic nuclei, pulsars, stellar-mass black
  holes, supernova remnants, gamma-ray Bursts,
  solar and stellar flares, and the diffuse
  galactic and extragalactic high-energy radiation.
• Use these sources to probe important physical
  parameters of the galaxy and the universe such
  as intensity of infrared radiation fields,
  magnetic fields strengths in cosmic particle
  accelerators, and diffuse gamma-ray fluxes from
  the Milky Way and nearby galaxies, and the
  diffuse extragalactic gamma-ray background
  radiation.
• Use high-energy gamma-rays to search for
  fundamentally new phenomena particle dark
  matter, quantum gravity, and evaporating black
  holes.

5
GLAST Mission Summary

• Objective
• Larger field of view (FOV), higher sensitivity,
  and broader energy detection range than any
  previously flown gamma-ray mission. Affords
  scientists the unprecedented opportunity to
  sample the history of the universe, a variety of
  high energy astrophysical phenomena, and
  many of the little understood features of the sky
• Instruments Large Area Telescope
  (LAT), Gamma-Ray Burst Detector (GBM)
• Launch Date February 2007
• Mission Duration 5 yrs (10 yr Goal)
• Minimum Success 2 years
• Orbit 565 km Circular,
• 28.5 Inclination
• Launch Vehicle Delta 2920H-10
• Launch Site CCAS (Eastern Range)
• TDRSS (SN) Ku-band for real-time housekeeping
  science dump data (gimbaled antenna) S-band
  for commanding, burst alerts, and low rate
  housekeeping (omni antenna)
• GS Sites S-band to USN Hawaii and Australia
  (omni antenna)
• Miscellaneous Orbit determination and clock
  maintenance via on-board GPS

6
Key Features

• First year primarily All-Sky Survey
• Pointed Observations to any celestial target
  after first year
• Gamma Ray Burst (GRB) detection with immediate
  alert messages to ground
• Autonomous repointing to GRBs that meet
  predetermined criteria
• Target of Opportunity (TOO) handling for quick
  turn-around science commanding

7
Large Area Telescope (LAT)
Tracker (16 total)
Anti-Coincidence Detector (ACD)
Mechanical Grid
Radiator (2 total)
Electronics
Calorimeter (16 total)
8
GBM Detector Placement
9
Observing Modes

• Survey Mode - primary mode of operation for the
  1st year
• General Zenith pointed all sky survey
• Enhanced via autonomous rocking profile (up to
  60 degrees, perpendicular to orbit plane, rock
  once every 2 orbits)
• Pointed Observations (3 methods)
• Spacecraft inertially pointed at and tracks
  specific targets (e.g., Gamma-Ray Bursts)
• (1) Pointed observations normally planned via the
  weekly science timeline (Observing Plan)
• (2) Quicker turn-around observations achieved via
  Target of Opportunities (TOOs)
• Project Scientist able to more quickly retarget
  observatory (24x7)
• Maximum 6 hours from initiation of TOO to receipt
  of TOO commands
• (3) Fastest pointed observations via Autonomous
  Repoints (ARs)
• On-board autonomous reaction to a detected GRB
  that matches predetermined threshhold criteria
  (see next slide)
• ARs expected to occur a few times per month,
  largely dependent upon the ground-settable
  threshold criteria

10
Autonomous Repoints

• Both the LAT and GBM instruments are able to
  detect GRBs, but only LAT determines if the
  detected burst meets the threshold criteria and
  requests the Autonomous Repoints
• LAT detects high energy bursts (20 MeV to 300
  GeV) and sees about 20 of the sky
• GBM covers a lower energy range (10 keV to 25
  MeV) and provides a wider field of view (full sky
  coverage less earth occultation)
• Typical Autonomous Repoint (AR) sequence
• LAT and/or GBM detects a GRB
• If detected by GBM, it sends the burst
  information to LAT over the spacecraft bus
• LAT determines if the GRB meets the predetermined
  threshold criteria
• If it does, LAT will send an Autonomous Repoint
  (AR) request to the spacecraft, providing the
  target location information
• Spacecraft will autonomously slew to the target
  if needed, and then track the target, keeping it
  within 30o of the Z-axis (max slew rate of 75o in
  10 minutes)
• LAT and/or GBM immediately begin sending Burst
  Alert telemetry packets to the ground via the
  TDRSS Demand Access Service (DAS), which provide
  information on burst location and
  characteristics
• Burst Alerts autonomously distributed to science
  community via the GRB Coordinates Network (GCN)
• AR continues for a ground-settable duration
  (default 5 hours)
• Upon completion of the AR, the stored observation
  timeline will be resumed (go to the appropriate
  preplanned target or return to the Survey Mode)

11
Ops Week in the Life Snapshot

• Nominal MOC operations highly automated
• Single 8x5 staffed shift (On-call FOT outside
  normal 8x5 shift)
• Approximately 6-8 scheduled passes per day with
  TDRSS Ku-band service
• Manual Activities (FOT)
• Mission Activity Planning and Scheduling, SN and
  GN (as backup) Scheduling, Real-Time Commanding,
  Telemetry Monitoring, Spacecraft and Instrument
  FSW Loading, MOC Maintenance (PDB, Software, or
  Hardware)
• Automated Activities (Software, Scripts)
• Off-Shift Pass Execution, Data Dumps/Processing,
  Telemetry Monitoring, Data Archiving, Trending,
  Event Logging, Burst Alert Handling, Alarm
  Recognition, Automated Personnel Notification

12
Key Operations Requirements

• Support highly autonomous mission operations that
  enable lights-out operations approach
• Automated pass operations (including SSR dumping)
• Automated data handling/processing
• Automated telemetry monitoring, alarm detection,
  and operator paging
• Support operators with remote access to
  data/displays
• Provide processed (Level 1) data products to
  users within 72 hours of initial on-board
  detection by instrument
• Provide ability to support science observation
  planning, and to translate this planning into
  on-board activities/commands
• Provide record of actual observations (As-Flown
  Timeline)
• Provide Burst Alert Telemetry from spacecraft to
  GRB Coordinates Network (GCN) within 7 seconds
• Provide ability to respond to TOO Requests within
  6 hours

13
Key Mission Ops Challenges

• Support 24x7 autonomously slewing spacecraft with
  an 8x5 operations staff
• Observation of a newly detected GRB causes change
  to Observing Plan
• Burst Alert Telemetry arrives to ground
  unsolicited and must be made available to science
  community within 7 seconds
• Slewing will impact at least one TDRSS Ku-band
  contact, which impacts on-board recorder
  management
• Support attitude dependent TDRSS scheduling
• Orientation of spacecraft affects TDRSS views
  given bottom location of Ku-band antenna
• Require approximately 6-8 contacts per day,
  approximately 7 minutes per contact
• Support 24x7 TOOs with an 8x5 operations staff
• But not required to automatically uplink TOO
  commands
• Generate accurate As-Flown Timeline given that
  the pre-planned on-board schedule will
  autonomously be changed by the spacecraft
• Perform End-to-End data handling/processing with
  minimal staff involvement
• From raw frame data at White Sands Complex (WSC)
  to Level 1/2 Science Products at the GLAST
  Science Support Center (GSSC)

14
Ground System Architecture
TLM Ku-band _at_ 40 Mbps S-band _at_
1,2,4,8 kbps CMD S-band _at_ .25, 4 kbps
GPS
GPS Timing Position Data
TDRS
TLM S-band _at_ 2.5 Mbps CMD S-band _at_ 2 kbps
GLAST
RT HK Telemetry Alerts Sci HK Data
Dumps Command Data
RT HK Telemetry Command Data HK Data Dumps
White Sands Complex
Ground Stations
Launch Site
TC Data Flows
USN (Hawaii Australia)
Mission Operations Center
KSC
Orbit Support
Test Sim Data Sustaining Eng Data
FDF
Spacecraft IT Facility
GSFC
GSFC
GCN Notices (from BAP)
Level 0 Data Observing Plan ToO Orders As-Flown
Timeline
Gamma-Ray Coordinates Network
Level 0 Data Contingency Cmd As-Flown Timeline

Level 0 Data Contingency Cmd
As-Flown Timeline Burst Alerts
Spectrum Astro
GLAST Science Support Center
Level 1/2 Data GBM Commands/Loads
Level 1/2 Data LAT Commands/Loads
GSFC
LAT Instrument Science Ops Center
GBM Instrument Ops Center
GSFC
Archive Data
GCN Notices
Science Products
MSFC/NSSTC
SLAC
HEASARC
Science Community
Version 5/19/04
GSFC
15
Ground System Architecture

• Space Network (TDRS, WSC, DAS, SWSI) primary
  communications path for operations
• Provides 40 Mbps Ku-band return service for the
  downlink of Science and Housekeeping data
• Provides continuous MA Demand Access Service
  (DAS) for Burst Alert and Safe Mode telemetry
• Provides schedulable MA and SSA services for TOO
  support, housekeeping, flight software updates
• GLAST-unique Ku-band front end system at WSC
  processes incoming 40 Mbps stream, sorts by VC,
  forwards real-time data to the MOC, stores data
  during contacts, and forwards recorded data to
  the MOC after contacts
• Ground stations for backup or contingency
  commanding and S-band Housekeeping data dumps
• Universal Space Network (Commercial)
• South Point, Hawaii and Western Australia
• Perform RS-decoding, report statistics to MOC,
  sort data by virtual channel, and time stamp data
  at the frame level
• 2.5 Mbps S-band Real-time telemetry (HK and
  Burst Alerts), Memory Dumps, Housekeeping Data
  Dumps (SSR)

16
Ground System Architecture

• Mission Operations Center (MOC)
• Provides real-time command control, telemetry
  processing, and data monitoring and analysis
• Provides 24x7 operations support with 8x5
  operations staffing
• Provides mission planning, TOO handling, Level 0
  data processing
• Serves as single point of commanding for the
  ground system
• Generates As-Flown Timeline to document what
  observatory actually accomplished (e.g., reflects
  autonomous repointing)
• Flight Dynamics Facility (FDF)
• Sends MOC predictive orbit products based on
  onboard GPS data received from the MOC (to
  support mission planning)
• Also using Differenced One-Way Doppler (DOWD)
  from TDRSS, which would go to FDF for use in
  orbit product generation for initial GPS
  validation and contingency support
• Provides ability to perform OD without 2-way
  doppler/tracking data

17
Ground System Architecture

• GLAST Science Support Center (GSSC)
• Supports the Guest Investigator program, which
  provides ability for science community to request
  specific observations
• Reviews commands and memory loads from the IOCs
  for their impact on the observing timeline
  (science-level constraint checking)
• Provides the MOC with an observing timeline based
  on accepted Guest Investigator proposals, IOC
  inputs, and science requirements
• Generates TOO Orders approved by the Project
  Scientist and forwards to the MOC
• Ingests observatory data from the MOC and IOCs
  for distribution to the science community and
  mission archives at the HEASARC
• Distributes analysis tools to the science
  community
• HEASARC
• Provides long-term permanent archive for GLAST
• Receives data products from GSSC

18
Ground System Architecture

• LAT Instrument Science Operations Center (ISOC)
• Performs higher level data processing (Level 1
  2) using Level 0 data provided by MOC, and
  provides data products to the GSSC
• Archives and distributes science data products
  (for LAT collaborations)
• Supports instrument calibration activities
• Performs instrument activity planning, trending
  performance analysis and anomaly investigation
• Perform sustaining engineering for the LAT
  instrument
• GBM IOC
• Performs higher level data processing (Level 1
  2) using Level 0 data provided by MOC, and
  provides data products to the GSSC
• Archives and distributes science data products
  (for GBM collaborations)
• Supports instrument calibration activities
• Performs instrument activity planning, trending
  performance analysis and anomaly investigation
• Provides a Burst Alert Processor (BAP) to the MOC
  that performs additional processing of Burst
  Alerts to improve burst location information to
  the GCN
• Performs additional person in the loop burst
  alert processing to generate improved burst
  location information
• Perform sustaining engineering for the GBM
  instrument

19
Ground System Architecture

• Gamma-Ray Coordinates Network (GCN)
• Receives Burst Alerts (GCN Notices) from the
  Burst Alert Processor resident in the MOC and the
  GBM IOC
• Immediately forwards Burst Alert GCN Notices to
  the science community for rapid follow-up
  observations
• Includes real-time Burst Alerts and the offline
  refined Burst location information (generated by
  the GBM IOC)
• Spacecraft IT Facility
• Provides access to spacecraft and instruments
  during pre-launch testing and operations
  simulations activities
• Provides flight software maintenance and general
  sustaining engineering support (option in
  Spectrum contract)

20
Operations Automation Scenarios

• Mission Planning and Commanding
• Target of Opportunity (TOO) Handling
• Real-Time Contacts
• Burst Alert Handling
• Solid State Recorder (SSR) Management
• Data Processing
• As-Flown Timeline
• Trending and Analysis

21
Mission Planning and Commanding

• Nominal path always goes from the IOCs to the
  GSSC and then to the MOC
• Backup path from the IOC to the MOC for test
  support and use during LEO

SN Schedules
Commands, FSW loads
ToO commands, FSW loads, ATS loads
Timeline inputs, commands, FSW loads
LISOC
SN Schedules
GSSC
Contingency activities
Weekly Timelines, commands, FSW loads, TOO Orders
GIOC
Timeline inputs, commands, FSW loads
Commands, FSW loads
22
Mission Planning and Commanding

• GSSC serves as central collection point and
  coordinator for science/mission planning and
  scheduling, providing an integrated science
  timeline to MOC weekly
• Integrated science timeline is a list of
  activities and/or commands for the instruments
  and observatory
• Timeline inputs (onboard activities) are received
  from the IOCs
• FSW loads, calibration activities, instrument
  adjustments, etc.
• GSSC checks for impact to existing timelines and
  notifies IOC if there are problems
• Nominally covers a period of at least 7 days
• GSSC also forwards instrument flight software
  patches and tables provided by the IOCs to the
  MOC for uplink
• Uplinked as per instructions given with each
  table/load

23
Mission Planning and Commanding

• MOC merges the integrated science timeline
  received from GSSC with spacecraft commands such
  as TDRSS contact schedule, SSR control commands,
  ephemeris updates, etc.
• MOC performs command-level constraint checking,
  such as detecting invalid commands, missing
  sub-mnemonics, out of range parameters, command
  frequency limit violations, etc.
• MOC creates and uplinks the command and memory
  loads
• MOC provides GSSC with status information on the
  load uplinks
• Process at best is semi-automated, as majority of
  steps require operator interaction

24
SN Scheduling Accommodation

• Placement of the Ku-band antenna on the Nadir
  side of the observatory makes the portion of sky
  that the antenna has line-of-sight access to
  dependent on observatory attitude
• For all observatory attitudes one or more TDRS
  satellites are visible at some point in the orbit
• The attitude profile of the observatory dictates
  which TDRS satellites can be used for contacts
• WSC requires TDRSS contact requests to be
  submitted 3 weeks prior to the week containing
  the first contact
• Science activities must, therefore, be determined
  over 3 weeks in advance to ensure that
  GLAST-TDRSS contact requests receive the proper
  consideration when WSC does TDRSS scheduling
• Challenge 3 week SN scheduling lead-time is too
  limiting for expected science needs

25
SN Scheduling Accommodation

• Solution Define a scheduling mechanism to
  provide as much scheduling flexibility as
  possible
• Commit to a minimum portion of the planning
  period 3-weeks in advance, with emphasis on
  observation requests that affect the attitude
  (i.e., pointed observations)
• MOC will request a series of TDRSS contacts so as
  not to impact the observatory science schedule
  based on a preliminary plan of science activities
• Must also account for rocking profile in Survey
  Mode
• Allow for as much flexibility as possible in
  changing the expected science activities
• Science planners may change anything about the
  science plan as long as requested or scheduled
  TDRSS contacts are not impacted
• Allow command changes/additions that do not
  effect the TDRSS contact schedule to be made as
  close as possible to the upload time
• Late changes may be made up to 2 days before the
  ATS file is uploaded

26
Target of Opportunity Handling
TOO Command(s)
TDRS
HK Telemetry
Flight Ops Team
TOO Page Alert
TOO Commands, HK Telemetry
FOT staffs MOC
TOO Order
TOO Request
SN MAF Scheduling Coordination
TOO Ack
27
Target of Opportunity Handling

• TOO Request can result from an approved Guest
  Investigator proposal or an interesting celestial
  event
• GSSC initially analyzes the TOO Request
  (feasibility, impact on schedule) and advises the
  Project Scientist accordingly, who ultimately
  approves the TOO Request
• Upon receiving authorization to proceed with the
  TOO, the GSSC constructs the TOO Order and
  forwards to the MOC
• GSSC checks for constraint violations,
  occultations, availability, etc. and sends to MOC
• MOC recognizes TOO Order and automatically
  notifies appropriate FOT personnel
• TOO Order can arrive any time
• FOT processes TOO Order
• Works with SN to schedule a forward link via
  TDRSS (within 30 minutes)
• MOC transmits the TOO commands to the spacecraft
  as soon as the SN forward link is available
• FOT monitors telemetry to verify TOO is being
  acted upon if done in real time otherwise FOT
  analyzes after-the-fact

28
Target of Opportunity Handling

• MOC provides GSSC with TOO status (e.g.,
  received, uplinked)
• TOO handling process required to take no more
  than 6 hours
• From point when Project Scientist approves the
  TOO to when the TOO commands hit the spacecraft
• Observatory autonomously returns to on-board
  observing schedule at completion of the TOO
• TOO length dependent upon the nature of the
  observation (average expected to be about 5
  hours)
• Returning to where it should be at that time (not
  where it was just before the start of the TOO)
  preserves the TDRSS schedule
• GSSC evaluates resulting science telemetry to
  confirm that the TOO actually executed
• Makes the necessary adjustments to the
  Observation Timeline, coordinating with the IOCs
  and MOC as appropriate

29
TOOs vs. ARs

• Question What happens if the instruments detect
  a Gamma-Ray Burst that warrants an Autonomous
  Repoint (AR) during a TOO?
• Concern the scientists do NOT want to miss the
  burst of the century because of satisfying a
  routine TOO Request!
• Solution Developed concept of interruptible
  TOOs
• Ground can set a flag so that the FSW will view
  the TOO as interruptible, ensuring that the
  spacecraft will chase a burst if appropriate
• But conversely can also ensure that the TOO will
  not be interrupted by an AR (e.g., might be going
  back to look at a GRB that had previously been
  viewed via an AR)
• Flags set appropriately in the GSSC based on the
  TOO Request approved by Project Scientist

30
Real-Time Telemetry

• Handling and processing of real-time observatory
  telemetry highly automated end-to-end
• Ku-band GLAST Front-End Processor (GFEP) at WSC
  automatically and remotely configured by the MOC
• MOC uses scripts to automatically configure for
  contacts
• GFEP forwards selected Virtual Channels (VCs) to
  MOC in real-time (frame data)
• Observatory HK telemetry, Burst Alerts, Safe-mode
  telemetry, and Memory Dumps
• GFEP stores all VCs locally and automatically
  forwards VC files to MOC post-contact
• MOC also receives and processes status data from
  the SN, GS, and GFEP systems

RT Observatory HK Telemetry
GFEP Status control
LAT ISOC
SN
GFEP
ITOS Displays
Burst Alerts
GBM IOC
Mission Operations Center
ITOS Displays
RT Telemetry VCs, Status Data
GS
Burst Alerts
FOT Page
BAP/GCN
31
Real-Time Telemetry

• MOC performs traditional real-time processing on
  incoming telemetry
• Extract packets, decommutate and display HK data,
  generate/display event messages and alarms,
  perform command verification
• MOC automatically pages FOT if predefined alarm
  conditions are detected
• Example Red limit conditions and specific alarm
  flags
• MOC will optionally forward telemetry packets in
  real-time to the LAT ISOC to assist in instrument
  monitoring
• IOCs can also call up MOC ITOS displays over the
  Internet (MOC Web server)
• If Burst Alert Telemetry is received, the MOC
  automatically forwards the packets to the Burst
  Alert Processor (for forwarding to the GCN) and
  directly to the GIOC
• MOC must handle the arrival of spacecraft
  safemode telemetry or instrument alarm packets
  sent on-demand by the observatory via the SN
  Demand Access Service
• MOC automatically begins processing of data and
  pages FOT personnel
• No automatic commanding for contingencies

RT Observatory HK Telemetry
GFEP Status control
LAT ISOC
SN
GFEP
ITOS Displays
Burst Alerts
GBM IOC
Mission Operations Center
ITOS Displays
RT Telemetry VCs, Status Data
GS
Burst Alerts
FOT Page
BAP/GCN
32
Burst Alert Handling
T0, T1
Burst Alerts
TDRS
If not in contact DAS (1 kbps) If in contact
Ku-band (40 Mbps)
Ground station link (2.5 Mbps) (if in a contact)
Burst Alerts
T2
Burst Alerts (frames)
Burst Alerts (packets) Keep Alive Msgs
MOC
GCN notices
Burst Alerts (packets)
GCN notices
T3
BAP
33
Burst Alert Handling

• Ground system must be prepared to automatically
  handle the Burst Alert data 24x7
• Ground component failures must be automatically
  detected (e.g. Burst Alert Processor keep alive
  messages to the GIOC)
• Recovery either automatic (to a back-up system)
  or manually (via page to an operator), depending
  on the component
• Spacecraft initiates link with TDRSS/DAS, and
  sends Burst Alert packets as received from
  instruments
• Burst Alerts go through the Ku-band link if GLAST
  is in a Ku-band contact
• Burst Alerts go through S-band link if GLAST is
  in a TDRSS S-band contact (MA or SSA) or a ground
  station contact
• SN or GN forwards messages to MOC, which pulls
  out Burst Alert packets and forwards to the Burst
  Alert Processor (BAP) located in the MOC facility
  and to the GBM IOC
• BAP processes the messages from both instruments
  and creates Gamma-Ray Coordinates Network (GCN)
  Notices
• BAP immediately forwards the GCN notices to the
  science community via the GCN, enabling other
  assets to be targeted at the GRB
• GBM IOC performs person in the loop processing
  on the Burst Alerts to generate refined burst
  location information
• GBM personnel paged upon receipt of Burst Alerts
  from the MOC
• Provides improved location information to GCN for
  dissemination to the science community
• Decided to send Burst Alerts to a single location
  (i.e. the MOC)
• Differs from Swift model, where the Burst Alerts
  go directly from the SN to the GCN
• Single location desired for GLAST since the
  Alerts can come from multiple sources
• Also prefer to centralize the Burst Alert frame
  processing/packet extraction

34
SSR Management

• Two distinct types of on-board data stored in
  recorder Science and Housekeeping
• Stored in two separate partitions (i.e., two
  virtual recorders)
• Dumped separately, but simultaneously
• At 40 Mbps, require a minimum of 6 contacts per
  day (avg 7 minutes per contact) to ensure
  adequate downlink time
• Will likely schedule one or two extra contacts to
  be better prepared to handle missed contacts,
  e.g., due to Autonomous Repoints
• Cannot dump Science data at ground station to
  help catch up
• SSR holds approximately 30 hours of Science Data
• Allows several contacts to be missed without data
  loss
• But does require that downlink problems be dealt
  with over the weekend
• Current plan is for MOC to initiate SSR playbacks
  via automated ground commands
• MOC script will monitor telemetry and SN status
  data to ensure space-to-ground link is solid, and
  will initiate dump commands only if link is
  nominal
• Prevents SSR from dumping unless a valid contact
  occurs, which better accommodates the contacts
  that are missed due to Autonomous Repoints
• If contact missed, SSR dump pointers have not
  been advanced and ground script can simply pick
  up at next contact

35
SSR Management

• Recent developments may allow the spacecraft to
  automatically stop SSR dumps on its own if a
  loss of TDRS contact is detected
• Would eliminate need to automatically command
  from the ground
• Would also better handle the situation where the
  contact is disrupted in the middle of the SSR
  dump, where the SSR pointers would stop advancing
• During all contacts, the MOC automatically
  monitors RF-related statistics and SSR pointers
  in Housekeeping telemetry
• FOT notified (paged) if problems detected that
  require operator interaction
• MOC makes assessment of data completeness once
  frame files received from the SN (GFEP) or Ground
  Stations
• Again, operators notified if significant problems
  detected
• Recovery of lost data performed manually by FOT
  no automatic data recovery procedures

36
Data Processing

• Receipt, transfer, and processing of recorded
  telemetry data highly automated
• As discussed, dumps of SSR are nominally an
  automated process
• Ku-band GFEP at SN/WSC processes and records
  frame-level SSR data during each TDRSS contact
• Performs RS-decoding and VC sorting
• One VC per file
• GFEP automatically transfers VC files to MOC
  post-contact

VC Files
Mission Operations Center
Level 0 Files
Level 0 Files
L1 Products
Level 0 Files
GBM Instrument Ops Center
Level 1,2
Level 1,2
37
Data Processing

• MOC automatically recognizes receipt of raw VC
  frame files and performs Level-0 processing
• Includes Extraction of packets from frames, time
  ordering of data, removal of duplicate packets,
  and generation of quality and accounting
  information.
• Upon completion of Level 0 processing, the packet
  files are automatically sent to a MOC file server
• GSSC and IOCs notified that files are ready for
  transfer
• GSSC and IOCs automatically retrieve the Level 0
  files and IOCs perform higher level (1 and 2)
  science data processing
• IOCs automatically send the science products to
  the GSSC

VC Files
Mission Operations Center
Level 0 Files
Level 0 Files
L1 Products
Level 0 Files
GBM Instrument Ops Center
Level 1,2
Level 1,2
38
As-Flown Timeline

• GLAST observations are nominally conducted via
  the preplanned weekly Observation Timeline
• Planned timeline would generally equal the
  As-Flown Timeline
• But the two methods for changing the observing
  plan affect the Timeline
• Targets of Opportunity and Autonomous Repoints
• MOC required to generate an accurate As-Flown
  Timeline based on what observatory actually did
  on orbit, reflecting the changes caused by the
  TOOs and ARs
• As-flown Timeline needed by the IOCs and GSSC to
  help process and interpret science data
• Also used to influence observation planning for
  the next week
• MOC automatically creates and maintains the
  As-Flown Timeline from the observatory
  housekeeping telemetry
• Intended to be a high level record of the actual
  observations
• Guarantees that the Timeline reflects what was
  actually observed
• Requires that adequate information be provided by
  the observatory in the telemetry stream (e.g.,
  slew and target information)
• Lesson from Swift is to try to keep the Timeline
  at the observation level, and not at the command
  level
• Command level As-Flown Timeline maintenance has
  proven to be more complex than originally
  envisioned

39
Trending and Analysis

• Generally trending and analysis performed on
  recorded Observatory Housekeeping telemetry, and
  routine trending is automated
• After the Housekeeping Level 0 files are
  generated, they are automatically processed
• Extract parameters, perform EU conversions,
  perform limit checks
• Uses same decom engine as for real-time
  processing (i.e., ITOS)
• If any alarm conditions are detected (same
  processing and criteria as with real-time
  telemetry processing), FOT is paged
• Selected spacecraft and instrument housekeeping
  parameters are extracted and placed into
  Sequential Print files, which are used by the
  Trending System for generating trend plots and
  reports
• Trending System provides ability to automatically
  kick-off various plots and statistics reports
• Examples Selected plots on each SSR dump and
  min/max/mean plots and reports once per day
• System also provides remote access over the
  Internet to users such as FOT, spacecraft
  contractor and instrument teams for conducting
  their own trending and analysis

40
Automation Summary

• Burst alerts automatically received from
  spacecraft when needed, and automatically
  processed and sent through system to GCN
• Real-time contacts automated via ground/command
  scripts to set up and configure ground system,
  and perform SSR dumps
• Real-time and recorder dump data automatically
  monitored for out-of-limit/alarm conditions, and
  FOT paged when appropriate
• SSR dump data automatically processed by all
  ground system elements so that data is nominally
  processed end-to-end without user interaction
• As-Flown Timeline automatically updated based on
  evaluation of telemetry, which reflects what
  spacecraft actually did at the observation level
• Trending and statistics reports automatically
  generated each day using the automatically
  processed Level 0 data

41
Automation Summary

• A few items only semi-automated
• Planning/commanding requires science team and FOT
  interaction to work out the science plan
• SN scheduling supported by automatic
  determination of contact opportunities (attitude
  dependent scheduling), but actual scheduling with
  SN tends to be more manual
• MOC automatically constructs command loads, but
  FOT must take action to actually achieve the
  uplink to the spacecraft
• FOT must also get involved if problems
  encountered with command loads (e.g., constraint
  violations)
• TOOs mostly handled manually so that science
  team and FOT can work out the plan (since the
  existing plan is being impacted)
• FOT is paged to start the process, but
• FOT must interact with SN to get an SN contact
  quickly scheduled
• FOT must come into the MOC to achieve the uplink

42
Next Step in Automation GMSEC

• The GSFC Mission Services Evolution Center
  (GMSEC) was established in 2001 to coordinate
  ground and flight data systems development and
  services at NASA GSFC
• GMSEC system architecture represents a new way to
  build the next generation systems to be used for
  many different missions.
• Old approach was to find or build the best
  products and integrate them into a reusable
  system to meet everyones needs, but . .
• Requirements, product offerings, and companies
  may change tomorrow
• There is too much variation in mission needs to
  assume one size can fit all
• It is often difficult to infuse new technologies
  into a large, configured system
• New approach assumes that needs, products, and
  technology will change.
• GLAST currently evaluating ability to incorporate
  GMSEC architecture into the GLAST MOC design,
  which is currently based on the Swift MOC
  architecture
• Paging and trending systems primarily

43
GMSEC System Concepts

• Standardized Interfaces (not components)
• Applications should have the same key interface
  definitions (or functionally similar)
• Use XML where appropriate
• Goal is to allow for plug-and-play modules that
  can be integrated quickly and to allow the
  trading of components with other organizations
• Middleware
• Provides message-based communications services on
  a GMSEC software bus
• Publish/subscribe, point-to-point, file transfer
• Makes it much easier to add new tools, reduce
  integration effort
• Provides opportunities for applications to
  interact (e.g., for automation) in ways that
  would otherwise be much more difficult and
  expensive to implement
• User Choices
• We are not comparing available tools and
  declaring one to be the best for all missions.
• Want to give user a choice of TC systems, flight
  dynamics systems, etc.
• GMSEC Owns the Architecture and Interfaces
• The traditional development organizations still
  own their domain areas
• A contractor or in-house team creates the
  missions system from the GMSEC offerings,
  populates the databases, adds mission unique
  features, etc.
• GMSEC point of contact info
• Dan Smith / GMSEC Project Manager / 301-286-2230
  / Dan.Smith_at_nasa.gov
• http//gmsec.gsfc.nasa.gov/

44
GMSEC New Middleware Approach
Socket Connections
Middleware Connections
45
GMSEC Architecture
GMSEC Software Bus