SAO
CONFIDENTIAL – PROPOSAL SENSITIVE
30 Oct 2007
TRACER Mission Operations ROM
We are pleased to provide an informal estimate to conduct the mission operations for TRACER
and believe that integrating this smaller SMEX mission activity with the Chandra operation and
the Harvard science team will be highly synergistic.
SAO is responsible for conducting the science and mission operation for the Chandra X-ray
Observatory, the third of NASA’s Great Observatories. Mission operations are conducted from
the Operations Control Center (OCC) located in a secure location on the 7th floor of the Draper
Laboratory building, 1 Hampshire Street, Cambridge.
The Chandra ground system consists of the On-line system (ONLS) for real-time commanding,
monitoring and trending, and the Off-line system (OFLS) for mission planning and command
generation. The ground system was developed by MSFC to be a multi-mission system with
changes for new missions isolated to well-defined components such as the command and
telemetry database and operational products such as command scripts and displays. SAO
maintains the system and completed a port to Linux in 2006.
The Chandra team has been operating Chandra since launch in 1999 and was deeply involved in
the I&T activities pre-launch. The team has extensive experience in all aspects of mission
operations including on-line operations (uplink/downlink/orbit determination), off-line
operations (mission planning and analysis), engineering support and analysis, anomaly
resolution, routine operations, procedure development and training and certification. Chandra has
no life-limiting consumables (MUPS fuel projected 75+years) and is planned to operate for a
15+ lifetime (>2014).
The costs below are based on utilizing the Chandra ground system and expertise. We understand
that the ITOS ground system is planned for use during TRACER I&T and so we have also
assessed installing and using ITOS at the OCC. We found that the costs are approximately the
same for either system since there will be less software modification required for ITOS but more
training (for example). We recognize there is risk reduction when the same ground system is
used for I&T and operations, and so can choose either option as the Project wishes. Our
recommendation would be to consider ITOS seriously given the advantages in using the same
system in both I&T and operations.
We have based our preliminary cost estimate for operations on the following assumptions.
MOC Functions
1. Ground station scheduling
2. Spacecraft activity planning
3. Command load generation, including constraint checking
4. Command uplink and telemetry processing
5. Spacecraft and instrument health and safety monitoring
6. Spacecraft performance monitoring
7. Level zero processing of the science data
8. Orbit determination and prediction
1
SAO
CONFIDENTIAL – PROPOSAL SENSITIVE
30 Oct 2007
Operations Concept
1. Operations conducted from the Chandra OCC (aka TRACER MOC) with a dedicated
string of ground system hardware and consoles.
2. The MOC interfaces with TDRSS and GSFC Ground Network via GFE T1 or other
network lines.
3. Science plan and instrument commanding provided weekly by Science Team.
4. MOC team performs constraint and command checking and generates final command
loads for uplink.
5. One controller per pass, during work hours, automated passes out of work hours.
6. 7/24 console staffing through a 30 days commissioning phase.
7. Controller conducts any real-time pass activity per certified procedure.
8. Monitoring and limit checks of real-time and dump data are conduced automatically with
pager alerts for out of limit conditions to the console operator and MOM. Anomalies
result in contact to GSFC engineering staff.
9. Dump data processed to L0 by MOC staff, checked for missing data (retransmission
requested from ground station if required), archived and then transferred to Science
Team.
Spacecraft
1. The spacecraft is being built as an in-house project by GSFC.
2. The spacecraft has a robust safe-mode architecture that provides for autonomous safing in
response to violation of standard monitors such as sun avoidance.
3. In-depth engineering knowledge of the spacecraft and its subsystem will be retained at
GSFC during the operations phase and will be available in the event of an anomaly or as
required by procedure (e.g., limit violations).
Orbit and Launch
1. TRACER will be lunched on a Pegasus into a 500 km sun synchronous orbit.
2. Launch communications support will be provided by TDRSS.
3. Commissioning will last for 30 days and the GSFC engineering team will be resident at
the MOC until end of the commissioning and hand-over to the MOC Mission Operations
Manager (MOM) for the start of normal operations. We assume 24 hour operations for 15
days then 12 hour operations for 15 days. The GSFC Engineering team will depart in
stages during the Commissioning phase as the various system activations are completed.
4. Orbit determination will be performed by a third party, e.g., NORAD and data made
available to the MOC for processing with STK.
Communications
1. TDRSS will be used during the launch phase. The GSFC Ground Network (with 2 polar
stations) will provide communications support during normal operations. Both are
CCSDS compliant with Reed-Solomon error correction and no encryption requirements.
2. TDRSS will be available during normal operations in the event of an anomaly.
3. S-band will be used as the communications band.
4. Downlink rate of 4.5 Mbps (M bits/sec) with an on-board telemetry rate of ~104 Kbps;
~100 Kbps science and ~4 Kbps housekeeping.
2
SAO
CONFIDENTIAL – PROPOSAL SENSITIVE
30 Oct 2007
Data Storage and Passes
1. On board storage is sufficient for 1-2 days of telemetry (~10-20 Gbits).
2. There will be 5 passes per day each of 9 minutes or 45 minutes of contact time per day.
3. Total data volume will be ~10 Gbits per day or ~0.5 Tbytes per year.
4. Data can be played back in parallel with taking science.
5. The data rate for the mission is relatively constant and does not vary significantly
depending on the mission phase.
6. Real-time commanding is normally required only for uplink of new command loads for
science observing. We assume there is limited (e.g., 1/month) real-time commanding
required for other routine spacecraft maintenance.
7. Un-staffed contacts for downlink are permitted.
8. There will be a point of contact at GSFC provided for operators in the event of ground
station anomalies.
Planning and Observing
1. Given that the science program involves relatively long pointed observations at predetermined set of stars, the mission planning requirements and number of attitude
maneuvers will be modest.
2. The number of command loads will be small, typically 2 per week.
3. The Science team will generate the target sequence and instrument commanding and the
MOC team will perform constraint checking and build and uplink the command loads.
Data Storage and Delivery
1. There are no stringent data latency requirements.
2. The MOC will perform Level 0 processing and check for missing data from the ground
station. Re-transmission from the station will be requested when data dumps are
incomplete.
3. The MOC will store level 0 data for the duration of the mission.
4. L0 data will be transferred secure to the science team via the internal CfA LAN. The
Science team will be responsible for providing data to GSFC and other team members as
needed. A direct network link to GSFC engineering staff from the MOC is not assumed,
however the interface can be added if needed.
5. The GSFC Ground Network is provided by GSFC (i.e., is not included in costs).
6. The MOC will store orbit and other ancillary data.
I&T Support
1. The ops team will be staffed sufficiently in the year before launch to participate to the
extent feasible in spacecraft I&T. We recommend performing a series of incremental
interface tests leading to full ETE tests from the MOC and including these as part
spacecraft development schedule. This approach is consistent with the “test-as-you-fly”
philosophy that is a key lesson learned from prior flight programs. Ground system
command and telemetry data bases will be coordinated and verified during the process, as
will core flight procedures, scripts and displays. We recommend that someone from the
MOC be present at GSFC for key portions of I&T.
3
SAO
CONFIDENTIAL – PROPOSAL SENSITIVE
30 Oct 2007
Project Management Support
1. SAO will support GSFC project management by preparing the mission operations
portions of the major project reviews: PDR, CDR and MOR.
2. SAO will provide the TRACER MOM who will serve as the point of contact for all
operations questions and issues for the GSFC Project. We assume a handoff of
responsibility will take place from the GSFC lead to the MOM following the completion
of Commissioning.
3. QA for the ground system development and testing and operations product development
and certification will be provided at a level appropriate for a mission of this class. The
function is included in the Systems Engineering labor proposed.
A preliminary labor-mix and fully loaded cost matrix shown below (note that some totals vary
due to rounding).
TRACER Ops ROM
Category
1. Management/Admin
2. Systems Engineer
3. OCC Dev/Test
4. IT Support
5. Ops Lead
6. Planner/Sched/CM
7. Controller
8.Trainer/Simulation
Total FTE
Cost ($FY08)
Total FTE ($K)
Equipment ($K)
ODC ($K)
Total ($K)
L-3
2009
Year 1
0.3
0.3
0.0
0.0
0.0
0.0
0.0
0.0
0.5
L-2
2010
Year 2
0.8
1.0
1.0
0.5
1.0
0.5
1.0
0.0
5.8
L-1
2011
Year 3
0.8
1.0
1.5
0.5
1.0
0.5
1.3
0.6
7.2
L
2012
Year 4
0.8
0.8
0.8
0.5
1.0
0.8
1.3
0.0
6.0
L+1
2013
Year 5
0.5
0.2
0.3
0.5
1.0
0.8
1.0
0.0
4.3
86
0
25
111
998
100
50
1,148
1,238
25
150
1,413
1,032
25
45
1,102
740
25
35
800
Total
3.2
3.3
3.6
2.0
4.0
2.6
4.6
0.6
23.8
4,094
175
305
4,574
Management and Systems Engineering are included in items 1 and 2, Development and Test are
included in items 3 and 4 for Years 1-3, Operations Preparation is items 5-8 for Years 1-3 and
Operations and Sustaining Engineering are items 3-8 for Years 4 and 5 (operations). Other Direct
Costs (ODC) includes travel, software licenses, equipment maintenance, supplies, etc.
The costs above do not include reserves that are typically applied to the overall development and
MO&D costs, and held by the Project.
The costs above also assume nominal operations and do not include additional labor required in
the event of an extended anomaly. A typical scenario would be to assume 3 anomalies per year
each lasting 1-week (e.g., for a recovery from safemode) with the same surge console coverage
as was used during Commissioning. This results in ~0.2 FTE contingency required for anomaly
support ($30-40K/year).
For questions about this input, please contact Roger Brissenden at (617) 495-7387 or
rjb@cfa.harvard.edu.
4