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