NEXT GENERATION SPACE TELESCOPEhmi.stanford.edu › NASA_documents › 464-GS-ICD-000… · Web...

Solar Dynamics Observatory (SDO)

Interface Control Document (ICD)Between

The SDO Mission Operations Center (MOC)And

The SDO Science Operations Centers (SOC)

464-GS-ICD-0001Revision B

Prepared By: E. Larduinat/Code 453.7

Effective Date: April 27, 2006Expiration Date: April 27, 2011

CHECK THE SDO MIS AT https://sdomis.gsfc.nasa.govTO VERIFY THAT THIS IS THE CORRECT VERSION PRIOR TO USE.

Goddard Space Flight Center

Goddard Space Flight Center

National Aeronautics andSpace Administration

https://sdomis.gsfc.nasa.gov/


CM FOREWORD

This document is under the control of the Solar Dynamic Observatory Project. Changes to this document require prior approval by the SDO Project Configuration Control Board (CCB) Chairperson. Proposed changes shall be submitted to the SDO Project Configuration Management Office (CMO), along with supportive material justifying the proposed changes.

Questions or comments concerning this document should be addressed to:

SDO Configuration Management OfficeMail Stop 464Goddard Space Flight CenterGreenbelt, Maryland 20771

April 27, 2006 Page ii


Reviewed by (for Revision -)

Anderson, Michael Anderson, Tom Calvo, Bob Ferrara, Jeffrey Gonzales, Pete Grob, Eric Howard, Joe Pages, Ray Potter, Bill Ruffa, John Salo, Chad Scott, Michael Scoville, Frank VanBlarcom, John Ward, Dave Weikel, Craig

April 27, 2006 Page iii


DOCUMENT CHANGE RECORD Sheet: 1 of 1

REVLEVEL DESCRIPTION OF CHANGE

APPROVEDBY

DATEAPPROVED

- Released by SDO-CCR-0119 R. Lilly 07/20/04A Updated and Released by SDO-CCR-0313 R. Lilly 06/23/05B Updated and Released by SDO-CCR-0547 R. Lilly 04/27/06

April 20, 2005April 27, 2006 Page iv


TABLE OF CONTENTSPage

1.0 Scope................................................................................................................1-11.1 Document Identification and Purpose........................................................1-11.2 Interface Overview........................................................................................1-11.3 Document Organization...............................................................................1-3

2.0 Reference Documents.....................................................................................2-13.0 Instrument Commanding Interface.................................................................3-1

3.1 Instrument Commanding Interface Overview............................................3-13.1.1 Commanding Modes and Command Types............................................3-23.1.2 Commanding Protocol Over Socket Connection to MOC........................3-5

3.2 Format Specification for Session Protocol Messages..............................3-83.2.1 Self Identifying Message Format.............................................................3-93.2.2 Connection Acknowledgement Message Format..................................3-10

3.3 Format Specification for Commanding Data............................................3-113.3.1 Commanding Messages Format Specification......................................3-113.3.2 Other Types of Commanding Data Format Specification......................3-16

4.0 Housekeeping Telemetry Interface.................................................................4-14.1 Housekeeping Telemetry Interface Overview............................................4-1

4.1.1 Real-time Housekeeping Telemetry Distribution over Socket Connection 4-14.1.2 Non-Real Time Housekeeping Telemetry Distribution and Retransmissions....................................................................................................4-2

4.2 Format Specification for Housekeeping Telemetry Data..........................4-24.2.1 Real-time Housekeeping Telemetry Messages Format Specification.....4-34.2.2 Housekeeping Telemetry Level-0 Files...................................................4-6

5.0 Flight Dynamics System Interface..................................................................5-15.1 Flight Dynamics System Interface Overview.............................................5-15.2 Format Specification for Flight Dynamics Products.................................5-3

6.0 Mission Support Data......................................................................................6-16.1 Mission Support Data Interface Overview..................................................6-16.2 OPERATIONAL REPORTS...........................................................................6-1

6.2.1 Status Reports.........................................................................................6-16.2.2 Trending Reports.....................................................................................6-26.2.3 Command History Reports......................................................................6-26.2.4 SDO Ground Station (SDOGS) and DDS Status.....................................6-2

6.3 Planning Data................................................................................................6-26.3.1 SOC Planning Input and Calibration Requests........................................6-26.3.2 Observatory Timeline..............................................................................6-36.3.3 Spacecraft Integrated Print......................................................................6-36.3.4 Science Uplink Plan.................................................................................6-3

6.4 Alert Notifications.........................................................................................6-36.5 Project Database Input and Updates..........................................................6-4

6.5.1 Telemetry Definition Database................................................................6-46.5.2 Command Definition Database................................................................6-4

6.6 Mission Support Data Naming Conventions and MOC Product Server...6-57.0 Network Configuration........................................................................................7-1

April 20, 2005April 27, 2006 Page v


April 20, 2005April 27, 2006 Page vi


LIST OF FIGURESFigure Page

Figure 1-1. Document Scope...................................................................................................................1-1Figure 1-2. MOC/SOC Interface Context Diagram.................................................................................1-2Figure 3-1. SDO Commanding Context Diagram.............................................................................. 3-1Figure 3-2. MOC/SOC Socket Connection Protocol 3-6Figure 3-3. Commanding Session Protocol 3-7Figure 3-4. Self-Identifying Message 3-9Figure 3-5. Connection Acknowledgement Message 3-10Figure 3-6. CCSDS SDO Command Packet 3-12Figure 3-7. Command SFDU Structure 3-12Figure 3-8. Local Response Message 3-14Figure 3-9. End-to-End Response Message 3-16Figure 4-1. CCSDS SDO Housekeeping Telemetry Packet 4-3Figure 4-2. Telemetry SFDU Structure 4-3Figure 4-3. Generation of a Housekeeping Telemetry Message 4-4Figure 7-1. Communication Network configuration for MOC-to-SOC interface 7-3

LIST OF TABLESTable Page

Table 3-1. Port Assignments 3-8Table 3-2. Command SFDU Example 3-14Table 3-3. Command Header File 3-17Table 4-1. Housekeeping Telemetry “Z header” 4-5Table 4-2. Housekeeping Telemetry FANN Format 4-5Table 4-3. Housekeeping Telemetry “Cxxx” Format 4-6Table 4-4. Housekeeping Telemetry Header File 4-7Table 5-1. FDS Products Provided to SOCs 5-1Table 6-1. Naming Conventions and Product Server Locations 6-6

April 20, 2005April 27, 2006 Page vii


LIST OF TBDs

Item No. Section# Summary Ind./Org. Due DateNo TBDs

April 20, 2005April 27, 2006 Page viii


1.0 SCOPE

1.1 DOCUMENT IDENTIFICATION AND PURPOSEThis Interface Control Document (ICD) defines the interface between the Solar Dynamics Observatory (SDO) Science Operations Centers (SOCs) and the SDO Mission Operations Center (MOC). It applies to the operational phase of the mission. All special accommodations needed for the I&T phase will be documented separately. This document is intended to support the design and implementation of the MOC and SOCs systems. Operational scenarios and processes will be documented in the operations agreement between the SOCs and the Flight Operations Team. Figure 1-1 illustrates the scope of this ICD.

Figure 1-1. Document Scope

1.2 INTERFACE OVERVIEWSDO carries a complement of three instruments, each with its own SOC:

The Extreme Ultraviolet Variability Experiment (EVE) led from the Laboratory for Atmospheric and Space Physics (LASP) in Boulder, CO.

April 20, 2005April 27, 2006 Page 1


The Helioseismic and Magnetic Imager (HMI) led from Stanford University in Stanford, CA.

The Atmospheric Imaging Assembly (AIA) led from the Lockheed Martin Solar and Astrophysics Laboratory (LMSAL) in Palo Alto, CA.

The HMI and AIA science operations will be co-located within the Joint Science Operations Center (JSOC), which will include sites at LMSAL and Stanford University. The command and control of the instruments will be handled at the LMSAL site. Science data will be received at the Stanford University site. The link between JSOC and the MOC will consist of two functionally separate interfaces, one for each instrument. Figure 1-2 provides a context diagram of the MOC-to-SOC interface.

Figure 1-2. MOC/SOC Interface Context Diagram

April 20, 2005April 27, 2006 Page

Instrument Command Data

Housekeeping Telemetry

T&C Protocol Messages

Project Database

Mission Operations Center (MOC)

FDS Products

MOCTelemetry and Control (T&C)

System

MOCTelemetry and Control (T&C)

System

DDS and SDOGS Integrated

Manager

DDS/Antenna Status

Planning Data

Trending Reports

HMI

SOC

AIA

SOC

EVE

SOC

EVE

SOCMOC Flight

Dynamics SystemMOC Flight

Dynamics System

Mission Planning System

Mission Planning System

Trending System

(ITPS)

Trending System

(ITPS)

SDO Ground System SDO SOCs

Observatory Timeline

AlertNotification

System

AlertNotification

System

Notifications

FlightOperations

Team (FOT)

Reports

MOCProductServer

2


The SDO MOC, located at the Goddard Space Flight Center (GSFC) in Greenbelt, MD, is comprised of several subsystems that exchange products with the SOCs:

The Telemetry and Command (T&C) system supports the observatory health and safety functions. It receives and processes the observatory housekeeping telemetry, and it provides the command generation capabilities. The T&C system is the focal point for the interface with the SOCs, distributing housekeeping telemetry and receiving instrument commands.

The Flight Dynamics System (FDS) provides all functions in the MOC related to orbit and attitude support, as well as planning spacecraft and instrument calibration maneuvers. FDS provides the SOCs with the FDS products identified later in this document.

The Mission Planning System accepts observatory operational plans and planning products, and generates the associated observatory schedule and spacecraft commanding sequences.

The remote control system for the Data Distribution System (DDS) and the SDO Ground Station (SDOGS) enables the Flight Operations Team (FOT) in the MOC at GSFC to monitor and control the DDS and SDO dedicated antennas at White Sands, NM. It provides status information that is available to the SOCs.

The Trending System is primarily used by the FOT to analyze and trend selected housekeeping telemetry parameters. Trending results are available to the SOCs.

The Alert Notification System receives monitoring status and alarms from the other MOC subsystems. When abnormal conditions occur or when limits are violated, it sends notices and alerts to the operations personnel. The SOCs personnel will be included in that notification system.

1.3 DOCUMENT ORGANIZATIONThis document is structured as follows:

Section 1 provides an overview of this document and the interface it describes.

Section 2 lists all referenced documents.

Section 3 defines the interface for commanding.

Section 4 defines the interface for housekeeping telemetry.

Section 5 defines the interface for FDS products.

Section 6 defines the interface for all other mission support data, including operational reports, planning data, and alert notifications.

Section 7 describes the communications network as related to this interface.

Appendix A provides an acronym list.

April 20, 2005April 27, 2006 Page 3


2.0 REFERENCE DOCUMENTSThe following documents are applicable to the development or implementation of this ICD.

Reference 1. SDO Operations Concept Document, 464-GS-PLAN-0010 Reference 2. Solar Dynamics Observatory (SDO) Project Database Format

Control Document (DFCD), 464-GS-PLAN-0042. Reference 3. Detailed Mission Requirements (DMR) for SDO Mission, 464-GS-

REQ-0005 Reference 4. Mission Requirements Document (MRD), 464-SYS-REQ-0004 Reference 5. SDO CCSDS Implementation Document, 464-SYS-SPEC-0033 Reference 10. Solar Dynamics Observatory (SDO) Interface Control Document

(ICD) Between the Flight Dynamics System (FDS)/Mission Operations Center (MOC) and the SDO Ground System 464-GS-ICD-0068

The following documents provide information related to this ICD.

Reference 6. SDO Project Spacecraft to Helioseismic and Magnetic Imager (HMI) ICD, 464-HMI-ICD-0002

Reference 7. SDO Project Spacecraft to Atmospheric Imaging Assembly (AIA) ICD, 464-AIA-ICD-0011

Reference 8. SDO Project Spacecraft to Extreme Ultraviolet Variability Experiment (EVE) ICD, 464-EVE-ICD-0004

Reference 9. NASA Security Procedures and Guidelines, NPG 2810 Reference 11. Solar Dynamics Observatory (SDO) Project Operations

Agreement (OA) between the SDO Science Operations Centers (SOC) and the SDO Flight Operations Team (FOT), 464-GS-LEGL-0087.

Reference 12. Deleted Reference 13. Deleted Reference 14. Integrated Trending and Plotting System (ITPS) Users’ Guide. Reference 15. Advanced System for Integration and Spacecraft Testing (ASIST)

User’s Guide. http://asist.gsfc.nasa.gov

If conflicts would exist between this document and other referenced documents, the following order of precedence will apply:

1. SDO Project Spacecraft to Instruments ICDs (References 6, 7 and 8)2. SDO CCSDS Implementation Document (Reference 5)3. Detailed Mission Requirements (DMR) for SDO Mission (Reference 3)4. Interface Control Document between the SDO MOC and the SOCs (this

document)

April 27, 2006 Page 1


3.0 INSTRUMENT COMMANDING INTERFACE

3.1 INSTRUMENT COMMANDING INTERFACE OVERVIEW

The interface between the MOC and the SOCs for instrument commanding, as well as housekeeping telemetry distribution, is the MOC Telemetry and Command (T&C) system. The MOC T&C system is implemented using the Advanced Spacecraft Integration and System Test (ASIST) system. In this document, the term T&C system refers to the MOC ASIST architecture, which, in addition to ASIST itself, includes the Front-End Data Subsystem (FEDS). Figure 3-1 provides a context diagram for SDO instrument commanding.

This section describes the following: Operational modes and command types available for instrument commanding. High level transfer protocol between the SOCs and the MOC. This protocol

includes supporting messages to initiate and control transfer sessions over socket connections. Note that this protocol is identical for commanding and housekeeping telemetry distribution.

Figure 3-3. SDO Commanding Context Diagram

June 23, 2005April 27, 2006 Page 1

(Data Stream)

Command SFDU

Command SFDU

Command SFDU

T&C (ASIST)

MOC

PDB

MOC Planning tool

CLTU

CLTU

CLTU

Authentication(Origin/Dest)

Validation

Identification ofCritical Commands

Formatting forUplink

EVE SOC

SOC Planning tool

SOC Operator

SOC T&C

Cmd Validation &Constraint Checking

Critical CmdIdentification

IDB

HMI SOC

AIA SOC

SDO Combined Operations Team

Mission DirectorSOC Point Of Contact

Command File

(FTP)

(Data Stream)

Observatory

S/CBus

EVEReal-time Cmd

Processor

Time-tagged CmdProcessor

AIAReal-time Cmd

Processor

Sequenced CmdProcessor

HMIReal-time Cmd

Processor

Sequenced CmdProcessor


3.1.1 Commanding Modes and Command TypesThe SDO Operations Concept Document (Reference 1) describes the various commanding modes available to the SOCs and supported by the MOC. This section provides an overview of these commanding modes and the corresponding types of commands involved. There are three main commanding modes: routine, coordinated, and contingency, which are defined in the following sections.

3.1.1.1 “Routine” Instrument Commanding ModeRoutine commanding mode is used for the majority of instrument command activities. It applies to those instrument command activities that are nominal operational activation of safe, routine observation sequences or instrument reconfigurations that have been planned well in advance, do not involve interaction between instruments and/or spacecraft subsystems, and do not require time, or other constrained synchronization at the observatory level.

In accordance with the SDO Operations Concept, the SOCs are principally responsible for the generation of routine instrument commands. The prime method to conduct routine instrument commanding is for the SOCs to send their commands to the MOC as a data stream over a socket connection. The MOC to spacecraft command link will be activated by the FOT during the MOC staffed periods. Command link activation during weekends or off-hours will be coordinated or treated as contingency. Upon receipt of instrument commands, the MOC verifies that the commands come from an authorized source and are addressed to the corresponding valid destination. The MOC screens, recognizes and authorizes critical commands before uplink. Critical commands require a two-step MOC authorization process since there is some operational risks associated with these commands if specific operational conditions are not satisfied.

For each command received from the SOCs, the MOC returns a “Local response” confirmation message to the sending SOC to indicate the disposition of the command at the MOC. The MOC formats valid commands and uplinks them as soon as feasible, in the order they are received. The spacecraft recognizes and routes the instrument commands to the proper instrument. The MOC supports COP-1 verification and sends an “End-to-end” confirmation message to inform the originating SOC of the uplink status of each command.

3.1.1.2 “Coordinated” Instrument Commanding ModeCoordinated instrument commanding applies to instrument commanding activities that require coordination among other instruments or coordination of spacecraft resources.

These “coordinated activities” include: All activities that could potentially harm or damage the observatory if not

executed under the proper conditions. All activities requiring planning to avoid loss of science or to minimize science

impact.

June 23, 2005April 27, 2006 Page 2


All activities requiring synchronization of operations or shared spacecraft resources.

Examples of such activities include, but may not be limited to, spacecraft maneuvers (momentum management, station keeping), high gain antenna hand-overs, instrument calibration maneuvers (off-pointing and roll maneuvers), door opening and closing, Guide Telescope (GT) switching, GT changes in calibration parameters, and eclipses.

In this mode, the commanding activities are coordinated through the use of the on-board stored command capabilities of the spacecraft. The spacecraft flight software provides two time-tagged stored command capabilities including Absolute Time Sequence (ATS) and Relative Time Sequence (RTS) functions. ATS command sequences execute commands at specified UTC times; RTS command sequences execute commands at specified time delays after the RTS has been started, rather than a specified UTC time. The use of ATS and RTS capabilities requires stored command load assembly by the MOC, and the SOCs are not allowed to directly send commands to the spacecraft ATS or RTS buffers. They provide the command requests necessary for the MOC/FOT to generate the corresponding spacecraft stored command loads. The MOC generates ATS loads only as needed and on an event basis, and the ATS command buffer is not intended for instrument routine commanding. To implement coordinated activities, the MOC will generate ATS loads based on pre-approved command sequence templates, reviewed and agreed upon between the FOT and the instrument teams through the planning process.

The SOCs can also use the spacecraft RTS capabilities. RTSs are uniquely identified sets of commands, stored in the spacecraft on-board processor. Each command in an RTS has an associated ‘delta time’, which is the time interval between the execution of this command and the execution of the previous command. The RTS itself may be activated via a real-time command, a Telemetry and Statistics Monitor (TSM) command, an ATS command or a call from within another RTS. To define or modify a spacecraft RTS, the SOC must submit the RTS definition to the MOC; the MOC then validates it, generates the RTS load and schedules the uplink. A spacecraft RTS may include both spacecraft commands and instrument commands. During the mission operational phase, modifications of on-board RTSs are expected to be very infrequent and will require review and formal approval before implementation and upload. The SOCs should allow enough time for the review and approval process and submit an RTS definition or modification to the MOC at least 5 working days before the desired uplink.

3.1.1.3 DELETED

3.1.1.4 Contingency Commanding ModesThere are several ways to command the instruments during contingency situations, and the method utilized depends on the nature of the contingency. There are on-board capabilities and ground based capabilities to deal with contingencies.

June 23, 2005April 27, 2006 Page 3


The prime approach to responding to observatory emergencies is implemented on-board in the flight software via Instrument Notification Commands and the on-board TSM service. Under certain recognizable situations, predefined instrument notifications commands will be sent to the instruments to announce the imminent onset of a change in the spacecraft operational state which may require particular reconfiguration responses from the instruments.

In order to respond to instrument emergencies or emerging instrument emergencies, the FOT will maintain a set of STOL procedures in the MOC that can be activated under limited, predefined and pre-arranged conditions.

Under certain contingency situations, which are not emergencies and allow enough time, the instruments may be commanded from the SOCs using the socket connection, for instance during failure investigation and recovery activities. This requires both the SOC and the MOC to be staffed and voice communication to be available. The alert notification system can be used to arrange for SOC and FOT personnel to come in and support such a scenario during off-hours.

Finally, the SOCs will maintain the capability to command from the MOC, using the SOC backup command stations resident in the MOC.

3.1.1.4.1 STOL ProceduresIn anticipation of potential emergencies and contingency scenarios, such as line outages or other failures, the instrument teams will work with the FOT to define contingency STOL procedures to be executed by the FOT in the SOCs’ stead. Formal operations agreements will define under what conditions these procedures should be activated, when the FOT has the authority to execute them, and under what conditions they should first consult with the proper authority at the SOC. If SOC approval is required before execution, it will be confirmed via voice contact, an authenticated email, or an authenticated fax. These processes will be described in the Operations Agreement (Reference 11) between the FOT and the SOCs.

STOL procedures will be placed under FOT configuration control, and changes will not be allowed without the approval of both the concerned instrument team and the FOT. Proper verification and validation of the procedures will be required before configuration baselining. Procedures will be tested during the I&T phase in a joint effort between the instrument teams and the FOT. Post-launch, they will be established and verified by the FOT and instrument teams.

3.1.1.4.2 Back-up Commanding from the MOC

As a backup in case of major failure of a SOC or the communication lines, the SOCs are required to permanently maintain a minimal T&C system at the MOC at GSFC. The instrument teams will be responsible for keeping the software, databases and procedures up-to date in the backup SOC T&C systems at GSFC. These processes will

June 23, 2005April 27, 2006 Page 4


be described in the Operations Agreement (Reference 11) between the FOT and the SOCs

3.1.2 Commanding Protocol Over Socket Connection to MOCThe MOC supports socket connections with authorized remote users for commanding sessions. This method of commanding is only applicable to the routine commanding mode.

This section fully describes the socket connection protocol, which is identical for commanding and for telemetry sessions.

3.1.2.1 Session ProtocolThe SOC is the Client and the MOC is the Server. A session is established as follows (see Figure 3-2):

The SOC initiates the socket connection The SOC sends a “self-identifying” message to the MOC The MOC receives the “self-identifying” message The MOC sends an ACK/NAK (positive/negative acknowledgment) message

to the SOC The SOC reads the ACK/NAK message After a positive ACK message, the MOC and the SOC are ready to exchange

application messages Either the SOC or the MOC may end a session by terminating the socket

connection. There is no “end-session” message.

On the MOC side, there is no pre-set time-out. The SOCs should implement their own time-outs, in which case the SOCs would drop the socket connection and re-start. Commanding sessions are only allowed while the MOC is staffed and must be enabled by the FOT. Real-time housekeeping telemetry sessions are continuously active.

Several sessions can be open concurrently with each SOC. Three port numbers are defined, the port number determining the nature of the session:

1. Commands,2. Real-time telemetry, i.e., telemetry downlinked in real-time over Virtual

Channel VC0,3. Recorded telemetry, i.e., telemetry recorded on the on-board Solid State

Recorder (SSR).

June 23, 2005April 27, 2006 Page 5


At any given time, on the real-time telemetry port, a SOC is either receiving real-time housekeeping data (VC0) or a replay of previously downlinked data. On the recorded telemetry port, the SOC receives Solid-State Recorder (SSR) recorded data that was downlinked in the same time period. If deemed necessary, up to three user’s names can be attributed to each SOC to provide additional ports for telemetry distribution. The data rates on these additional ports are constrained by the network bandwidth and bandwidth allocation.

Figure 3-2. MOC/SOC Socket Connection Protocol

3.1.2.2 Commanding Session ScenarioOnce a commanding socket connection has been established as described in Section 3.1.2.1, and the MOC has enabled the SOC for commanding, the SOC and MOC exchange commanding data as illustrated in Figure 3-3.

June 23, 2005April 27, 2006 Page 6

SOC

MOC and SOCs ready to exchange application messages

MOCSOC initiates socket connection

MOC reads Self-Identifying message

MOC sends ACK/NAK message

MOC accepts socket connection

SOC sends Self-Identifying message

SOC reads ACK/NAK message


Figure 3-3. Commanding Session Protocol

A commanding session is comprised of the following steps:

The SOC sends a command formatted as a Standard Format Data Unit (SFDU). The MOC receives the command SFDU. The MOC answers with a “Local response” as follows:

Local Response DescriptionLACC MOC accepts the command SFDU.

SOC may proceed with the next command SFDU

LREJ MOC rejects the command SFDU. The reason for rejection depends on the level of validation implemented in the MOC.SOC may proceed with the next command SFDU

LHAZ MOC stopped the command because it was recognized as critical.A MOC operator must allow the command before it may proceed to uplink.SOC must wait before proceeding with next command SFDU.

LALL/LCAN These two responses only follow LHAZ response to a critical command.MOC will reject all commands received after LHAZ and prior to LALL/LCAN. LALL if MOC has allowed the critical command to proceed LCAN if MOC has cancelled it. SOC may proceed with the next command SFDU.

June 23, 2005April 27, 2006 Page 7

SOC

MOC and SOCs have established a session.MOC has enabled SOC for commanding

MOCSOC sends command SFDU

MOC reads command SFDU

MOC sends Local Response message•LACC (acknowledge non-critical command) •LREJ (reject command) •LHAZ (found Critical command )

•LALL (Critical command allowed)•LCAN (Critical command cancelled)

SOC reads local Response message

MOC sends End-to-end Response message

SOC may send the next command SFDU after LACC or LREJAfter LHAZ (Critical Command found) SOC must wait for LALL or LCAN

SOC reads End-to-end Response message

COP-1 verification


After an LACC or LALL, the MOC forwards the command for uplink The MOC analyzes the Command Link Control Word (CLCW) and performs COP-1

verification. The MOC sends the “End-to-end” response message to the SOC, indicating

acceptance by the spacecraft or failure to uplink.

3.1.2.3 Command RetransmissionsThe MOC T&C system handles command retransmissions upon failure to uplink to the spacecraft. Retransmissions based on COP-1 pass/fail are controlled from the MOC. The number of retransmissions is configurable by the FOT and is typically set between 0 and 3. Independently, the SOCs control their own command retransmissions to the MOC.

3.1.2.4 Command Queues and Priority SchemesThe FOT within the MOC controls the commanding throughput:

The FOT can interrupt a SOC commanding session by disabling the SOC for commanding or terminating the socket connection.

The FOT can define a delay between commands from each SOC. The FOT can intersperse real-time spacecraft commands in the flow of SOC

commands with only a minor delay, typically on the order of a few seconds. The uplink of large amounts of commands from a SOC will be planned. The

command link will be scheduled and reserved for that activity.

It is the responsibility of each SOC to manage its command queue in accordance with operational conditions and parameters, such as the uplink rate, systems capacity, and operational delays set by the FOT. Each SOC will control the number of queued commands awaiting a local–response (Section 3.3.1.3) or End-to-end-response (Section 3.3.1.4). The SOCs are also responsible for properly sequencing their commands and managing the commanding session in the event of an uplink failure or a rejection by the MOC of a SOC-generated command.

3.2 FORMAT SPECIFICATION FOR SESSION PROTOCOL MESSAGESThis section defines the communication protocol messages exchanged over the socket connection between the MOC and the SOCs for both commanding and telemetry sessions. All messages are in the form of SFDUs.

The socket connection protocol is TCP/IP using Berkeley Software Distribution (BSD) stream sockets. Table 3-1 defines the port allocations.

Table 3-1. Port AssignmentsData Type User/Port numberCommands 2002Housekeeping Real-time telemetry 2001Housekeeping Recorded telemetry 2051

June 23, 2005April 27, 2006 Page 8


The communication protocol for establishing a commanding or a telemetry session between the MOC and a SOC was described in Section 3.2.1.2. The format for the self-identifying and the connection acknowledgement protocol messages are described below.

3.2.1 Self Identifying Message FormatThe Self-Identifying message is sent by the SOC after a successful “socket connect call”. It is an SFDU consisting of 3 parts as illustrated in Figure 3-4.

Figure 3-4. Self-Identifying Message

3.2.1.1.1 “Z” HeaderCCSD3ZA0000100000022 20 bytes where: CCSD3ZA00001 are 12 fixed characters 00000022 are 8 fixed decimal characters, representing the length in bytes of

the value field of the SFDU (22 bytes)

3.2.1.1.2 “I” HeaderC7333IA0SFID0000000220 bytes where: C7333IA0SFID are 12 fixed characters 00000002 are 8 fixed decimal characters representing the length of the data

field (2 bytes)

3.2.1.1.3 “Data field”This field contains the 2-byte Instrument ID Code, corresponding to the instrument and user’s name:EV, E2, or E3 for EVEHM, H2, or H3 for HMIAI, A2, or A3 for AIA

June 23, 2005April 27, 2006 Page 9

20 Bytes 20 bytes 2 bytes

”Z” Header “I” Header Data Field Instrument ID Examples CCSD3ZA0000100000022 C7333IA0SFID00000002 EV CCSD3ZA0000100000022 C7333IA0SFID00000002 HM CCSD3ZA0000100000022 C7333IA0SFID00000002 AI


3.2.2 Connection Acknowledgement Message FormatThe MOC issues a Connection Acknowledgement message in response to a Self-Identifying message from the SOC. The Acknowledgement message indicates whether the MOC accepted or rejected the connection. It is an SFDU consisting of 3 parts as illustrated in Figure 3-5.

Figure 3-5. Connection Acknowledgement Message

3.2.2.1.1 “Z” HeaderCCSD3ZA00001LLLLLLLL20 bytes where: CCSD3ZA00001 are 12 fixed characters LLLLLLLL are 8 decimal characters, zero-padded, representing the length in

bytes of the value field of the SFDU, (that is “I” header plus data field)

3.2.2.1.2 “I” HeaderC7333IA0AKNKLLLLLLLL20 bytes where: C7333IA0AKNK are 12 fixed characters LLLLLLLL are 8 variable decimal characters, zero-padded, representing the

length of the data field (3 or 5 bytes in this case)

3.2.2.1.3 “Data field”3 or 5 characters representing Command Acknowledgement Data, as follows:

ACK for “Acknowledge”NAK01 for reject, “Invalid instrument ID”NAK02 for reject, “Already connected”Currently ASIST only implements these two “reject” values. More could be provided in future releases of ASIST

June 23, 2005April 27, 2006 Page 10

20 Bytes 20 bytes 3 or 5 bytes

”Z” Header “I” Header Command Acknowledgment Data

ExamplesCCSD3ZA0000100000023 C7333IA0AKNK00000003 ACKCCSD3ZA0000100000025 C7333IA0AKNK00000005 NAK01 (1)CCSD3ZA0000100000025 C7333IA0AKNK00000005 NAK02 (2)


3.3 FORMAT SPECIFICATION FOR COMMANDING DATA

3.3.1 Commanding Messages Format SpecificationASIST supports the commanding interface between the SOCs and the MOC. The prime commanding link with remote sites/SOCs is through sockets over TCP/IP. All the commanding messages exchanged are ASCII text.

3.3.1.1 CCSDS Command Packet

3.3.1.1.1 Command Packet Structure in the SDO ApplicationFigure 3-6 illustrates the command packet structure for the SDO application. It is provided in this ICD for information only. Reference 5, SDO CCSDS Implementation Document, 464-SYS-SPEC-0033 is the original source for this information.

A CCSDS command packet consists of:

1. Packet Primary Header: (6 octets). This is the CCSDS standard header containing: the APID or command destination address the packet sequence control field the packet length

2. Packet Secondary Header (2 octets) containing: A reserved bit, fixed to 0 A Function Code, 7 bits long. A Checksum, 8 bits long, calculated based on the contents of the entire

command packet. The algorithm for checksum calculation is defined in Reference 5.

3. The Application Data field (variable length), which contains command specification data.

The checksum is calculated by the SOCs before they insert the command packet into the command SFDU that they send to the MOC.

June 23, 2005April 27, 2006 Page 11

Packet Identification Packet Seq.Control

PacketLength

Application Data

(3) (1) (1) (11) (2) (14) (16)2 octets Maximum 242 octets2 octets 2 octets 2 octets

Secondary Header (SDO)

(bits)(octets)

(1) (7) (8) (variable N*16)(000) (1) (1) (x...x) (11) (x...x) (x...x) (0) (x…x) (x…x) (x…x)

PRIMARY HEADER(CCSDS Standard)

DATA FIELD(Mission Specific)

Version Type Sec Applic. Seq. Source Res Function Checksum # Hdr. Process Flgs Seq Code Flag ID Count

Length: Even Number of octets, <= 250


Figure 3-6. CCSDS SDO Command Packet

3.3.1.1.2 Identification of Critical CommandsCritical commands will be identified by the combination APID/Function code. The SOCs will provide the MOC with a list of those APID/Function codes and the MOC will recognize critical commands by scanning the packet primary and secondary headers.

3.3.1.2 Command SFDU MessageEach command issued by the SOC is wrapped into an SFDU consisting of 4 parts (see Figure 3-7).

1. “Z header”, specifying the length of this command SFDU in bytes.2. “Destination”, specifying the ground destination of the command SFDU, that is the

MOC machine that will process it.3. “Label”, specifying the ground origin of the command. This identifies the SOC

machine that originated the SFDU and will receive responses. It contains a command identification that will be returned in the end-to-end response pertaining to this command.

4. “Command”, specifying the command itself as the ASCII hex representation of the CCSDS packet.

All the data within a command SFDU are ASCII characters.

Figure 3-7. Command SFDU Structure

3.3.1.2.1 “Z header”The “Z header” is comprised of 20 bytes/characters as follows:

CCSD3ZA00001LLLLLLLLwhere:

CCSD3ZA00001 are 12 fixed characters

LLLLLLLL are 8 decimal characters, zero-padded, representing the length in bytes of the remainder of the SFDU, i.e., destination+label+command. .

June 23, 2005April 27, 2006 Page 12

Length of this SFDU in bytes.

Command ground destination, i.e., processing MOC machine

Command origin, i.e., SOC machine receiving responses. Contains command ID returned in the end-to-end response

Command CCSDS packet (ASCII hex representation)

Z Header

Destination

Label

Command

1

2

3

4

LENGTH DESCRIPTION

20 bytes

29 bytes

Variable

Variable


3.3.1.2.2 Destination“Destination” is a fixed length 29-byte field that pre-defines what MOC machine will process the command for uplink.

C7333IA0DEST00000009FEDS:FEDSwhere:

C7333IA0DEST are 12 fixed characters

00000009 are 8 decimal characters representing the length in bytes of the following field (i.e.,FEDS:FEDS)

FEDS:FEDS represents the host name and task name for commanding within the MOC

3.3.1.2.3 Label“Label” is of variable length and identifies the machine within the SOC that originates the command and will receive the MOC “local response” and “end-to-end” reply messages. This label allows the originating SOC to match the MOC responses to the original command.

C7333IA0LABLLLLLLLLLmachine:taskname:#####where:

C7333IA0LABL are 12 fixed characters

LLLLLLLL are 8 decimal characters representing the length in bytes of the following field (i.e. machine:taskname:#####

machine:taskname is a variable length ASCII alphanumeric string providing the host name and task name of the machine that sends the command and will receive the replies, e.g. HMI:CMDING.

##### is a 5-digit decimal number from 00000 to 99999 identifying this SFDU. It is recommended that this number be monotonically incremented by each SOC.

3.3.1.2.4 Command Packet“Command packet” is of variable length, and contains the ASCII hex representation of the command packet.

C7333IA0CPKTLLLLLLLLcommanddatawhere:

C7333IA0CPKT are 12 fixed characters

LLLLLLLL are 8 decimal characters, zero-padded, representing the length in bytes of the following field (i.e. commanddata)

commanddata is of variable length and is the ASCII hex representation of the CCSDS command packet. The binary contents of the CCSDS command packet are expressed using ASCII characters representing their hexadecimal value.

June 23, 2005April 27, 2006 Page 13


3.3.1.2.5 Command SFDU Example

Table 3-2. Command SFDU Example

Component Example Comments

Z header CCSD3ZA0000100000105 Length of rest of SFDU(20+9)+(20+16)+(20+20) = 105

Destination C7333IA0DEST00000009FEDS:FEDS Destination MOC machine

Label C7333IA0LABL00000016HMI:CMDING:00003 Example providing SOC machine and task getting responses. 00003 is unique ID for this command

Command C7333IA0CPKT000000201808C000000302290007 CCSDS command packet. This example is 20 characters in ASCII Hex (10 bytes or 5 words in binary)

3.3.1.3 Local Response to CommandThe MOC sends a Local Response reply to a SOC command that indicates the instrument command status in the MOC. The MOC will reject any new command until it has sent the Local Response to the current command. The Local Response is an SFDU consisting of 3 parts as illustrated in Figure 3-8.

Figure 3-8. Local Response Message

3.3.1.3.1 “Z” HeaderCCSD3ZA00001LLLLLLLL20 bytes where:


LLLLLLLL are 8 decimal characters, zero-padded, providing the number of bytes in the value field of the SFDU (i.e., TTTTTTTT+20)

3.3.1.3.2 “I” Header

C7333IA0AAAATTTTTTTT

June 23, 2005April 27, 2006 Page 14

20 Bytes 20 bytes n bytes

”Z” Header “I” Header Data Examples CCSD3ZA0000100000020 C7333IA0LACC00000000 CCSD3ZA0000100000032 C7333IA0LREJ00000012 Illegal user CCSD3ZA0000100000033 C7333IA0LHAZ00000013 Wait for LALL CCSD3ZA0000100000022 C7333IA0LALL00000002 Go


20 bytes where:

C7333IA0 are 8 fixed characters

AAAA is a 4-char status code qualifying the response: LACC when the command has been accepted by the MOC LREJ when the command has been rejected by the MOC LHAZ when the command has been identified as critical by the MOC. The

MOC will reject any subsequent command sent prior to sending LALL or LCAN.

LALL when a critical command has been allowed by the MOC LCAN when a critical command has been rejected by the MOC

TTTTTTTT are 8 decimal characters, zero-padded, representing the length of the following data/text field.

3.3.1.3.3 “Data/text” FieldThis is an optional ASCII text message of variable length used to explain the reason for the status of the Local Response. It is empty for a successful acceptance (LACC) and would contain some standard explanation in the case of a rejection (see examples in Figure 3-8).

3.3.1.4 End-to-end Response to CommandThe End-to-end Response indicates whether the command failed uplink or was successfully received and accepted by the spacecraft. The End-to-end Response makes reference to the “label” contained in the command SFDU. This label reference enables SOC association of End-to-end Response to the originating command SFDU. The End-to-end Response is an SFDU consisting of 3 parts as defined below and in Figure 3-9.

Figure 3-9. End-to-End Response Message

3.3.1.4.1 “Z” HeaderCCSD3ZA00001LLLLLLLL

June 23, 2005April 27, 2006 Page 15

20 Bytes 20 bytes n bytes

”Z” Header “I” Header (Acceptance) Label

Examples CCSD3ZA0000100000036 C7333IA0EACC00000016 HMI:CMDING:00003 CCSD3ZA0000100000048 C7333IA0EREJ00000028 HMI:CMDING:00003:Xmit failed


20 bytes where:


LLLLLLLL are 8 decimal characters, zero-padded, providing the number of bytes in the value field of the SFDU.

3.3.1.4.2 “I” HeaderC7333IA0EEEETTTTTTTT20 bytes where:

C7333IA0 are 8 fixed characters

EEEE is 4-character status code qualifying the end-to-end status of the command. The values currently used by ASIST are:

EACC when the command has been accepted (COP-1 verified) EREJ when the command has been rejected (most likely failed

transmission)

TTTTTTTT are 8 decimal characters, zero-padded, representing the length of the following Label field.

3.3.1.4.3 “Label”This is a variable length field reflecting the command ID provided by the SOC in the Label part of the command SFDU as described in Section 3.3.1.2.3. It allows linking the verification status to the original command. This may be followed by an optional explanatory text.

3.3.2 Other Types of Commanding Data Format SpecificationThis section defines the format of commanding data that will not be transmitted over the socket connection with ASIST.

3.3.2.1 DELETED

3.3.2.2 Spacecraft ATS Load Template Input for Coordinated ActivitiesThe spacecraft ATS processor will be used to support coordinated activities. The FOT will define and control templates containing all ATS commands, including RTS activation commands and instrument commands, necessary to implement a given coordinated activity. The MOC will use these templates to generate the required spacecraft ATS load supporting each instance of a coordinated activity. All instrument commands to be included in a spacecraft ATS load must be defined in the command definition database residing in the MOC T&C system.

It is recommended that the SOCs provide input to these templates using the file format defined below. The requests for spacecraft ATS commands consist of a series of commands in mnemonic form, preceded by their associated time tag specified in UTC. The command format is as follows:

June 23, 2005April 27, 2006 Page 16


WAIT UNTIL START_TIME or STOP_TIME ± delayWhere START_TIME indicates the start of a given event (e.g. eclipse) STOP_TIME indicates the end of the event

delay is a positive or negative delay relative to that event/mnemonic-1 [parameter-1, parameter-2, parameter-n]

Where parameter-n may beSubmnemonic

or Submnemonic=valueor Submnemonic=[value1,value2,…,valuen]

A maximum of 4 commands can be specified with the same time tag. The set “WAIT UNTIL/mnemonics” is repeated for each time tag specified.

If files are used, the recommended file naming convention is as follows:

soc_activity_yyyy_ddd_ver.atswhere:

soc is EVE, HMI or AIA, representing the originating SOCactivity represents the coordinated activity to be supported (HMIROLL, EVECRUCI, etc.)yyyy_ddd is the operational day to which this activity applies (UTC).ver is the version number, 2 decimal characters from 00 to 99, incremented when file is re-processed.ats is the file extension

Example: EVE_EVECRUCI_2007_222_01.ats

3.3.2.3 Requests for Defining a Spacecraft RTS The SOCs can define spacecraft processor RTSs. The definition of RTSs that include spacecraft commands in addition to instrument commands must be coordinated with the FOT. The requests will be submitted to the FOT that will generate the corresponding RTS load for uplink. All instrument commands to be included in a spacecraft RTS must be defined in the command definition database residing in the MOC T&C system. This process will be used infrequently for the occasional modification of on-board RTSs.

3.3.2.3.1 File formatSpacecraft RTS definitions consist of a series of commands in mnemonic form, followed by their associated delta time in seconds. The format is as follows:

/mnemonic-1 [parameter-1, parameter-2, parameter-n] Where parameter-n may be

Submnemonicor Submnemonic=valueor Submnemonic=[value1,value2,…,valuen]

WAIT seconds

June 23, 2005April 27, 2006 Page 17


The pair “mnemonic/WAIT” is repeated for each command in the RTS. The maximum size of an RTS is defined in the Spacecraft to instruments ICDs (References 2, 3, and 4), which specify that an RTS will be 300 bytes maximum, including a 2-byte time field associated with each command.

3.3.2.3.2 File Naming Conventionsoc_rtsnum_yyyy_ddd_ver.rdtwhere:

soc is EVE, HMI or AIA, representing the originating SOCrtsnum is a 3-digit decimal number representing the RTS numberyyyy_ddd is the operational day when this RTS load will be uplinked (UTC).ver is the version number, 2 decimal characters from 00 to 99, incremented when file is re-processed providing an updated RTS definition.rdt is the file extension

Example: EVE_034_2007_222_01.rdt

3.3.2.4 Request for STOL Procedure ActivationNo formal message is planned to request STOL procedure activation. Voice communication with confirmation via E-mail or fax will be used. The detailed procedures will be defined in Operations Agreement (Reference 11).

June 23, 2005April 27, 2006 Page 18


4.0 HOUSEKEEPING TELEMETRY INTERFACE

4.1 HOUSEKEEPING TELEMETRY INTERFACE OVERVIEW The interface between the MOC and the SOCs for distribution of housekeeping telemetry is also supported by the MOC T&C system. The MOC receives the S-band telemetry from the antenna sites. This may be real-time telemetry or telemetry that was recorded on-board the spacecraft. The MOC processes the housekeeping telemetry to the packet level and stores it for the life of the mission. The housekeeping telemetry can be distributed to the SOCs over a socket connection or as Level-0 files. Each SOC can select which packets it wants to receive by specifying a list of VCID/APIDs. The SOCs will have access to a menu-driven program provided within ASIST in the MOC to select the VCID/APIDs they want to receive in real-time. This program will also allow controlling telemetry playbacks from the MOC. However this program is not intended for “on-the-fly” requests. The access to this program is described in the ASIST User’s Guide, (Reference 15), Appendix J. All housekeeping telemetry APIDs downlinked on the S-band will be available for distribution to the SOCs.

4.1.1 Real-time Housekeeping Telemetry Distribution over Socket Connection

The MOC distributes the real-time housekeeping telemetry to the SOCs in the form of packets wrapped in SFDUs over a socket connection in near real-time. The latency between the MOC receipt time and reception by the destination SOC will be less than 30 seconds. MOC sends the telemetry packets with no delay as soon as there is space on the SOC socket.

4.1.1.1 Session ProtocolThe housekeeping telemetry interface uses sockets over TCP/IP with each SOC. The communication protocol for establishing a telemetry session is identical to the protocol used for commanding, as described in Section 3.1.2.1: the session is open once the SOC receives a positive acknowledgement message.

4.1.1.2 Housekeeping Telemetry Session Scenario Since the downlink is continuous, a telemetry session should stay open for very long periods of time. Either the SOC or the MOC can terminate a session by disconnecting the socket. The SOCs, which are the Client, will be responsible for re-initiating the connection after a termination.

April 27, 2006 1


4.1.2 Non-Real Time Housekeeping Telemetry Distribution and Retransmissions

4.1.2.1 On-board Recorded TelemetryThe SSR recorded telemetry is downlinked on separate VCIDs and can be forwarded to the SOCs as soon as received by the MOC in parallel with the real-time telemetry. However it is also provided as part of the Level-0 data sets.

4.1.2.2 Telemetry Playbacks from the MOCThe MOC can “playback” archived housekeeping telemetry on demand, that is re-transmit previously downlinked telemetry over the socket connection. The MOC stores all housekeeping telemetry for the life of the mission. The SOCs may select the VCID/APIDs they want to playback, as well as the start/stop times, and the playback speed. ASIST supports playback speeds that are several times faster than real-time. The MOC can be configured to simultaneously transmit both real-time and “playback” telemetry over separate sockets. However, the amount of data and speed requested for playbacks will be limited by the communication line capacity. The playback housekeeping telemetry has the same format as the real-time housekeeping telemetry.

4.1.2.3 Level-0 Housekeeping DataThe MOC generates Level-0 housekeeping telemetry files. These files cover a 24-hour time span and contain packets for a single APID. Each file contains all packets for a given APID downlinked for a given day, with time stamps from 00:00:00 to 23:59:59 UTC, merging real-time and SSR recorded telemetry. The packets within a file are time-ordered, and duplicates are removed. The MOC automatically writes the 24-hour data sets to a MOC server from where the SOCs can retrieve them. The 24-hour data sets will be generated by 12:00 UTC on a daily basis, and they will be available to the SOCs as soon as they are generated.

4.2 FORMAT SPECIFICATION FOR HOUSEKEEPING TELEMETRY DATAThis section defines the detailed format of all the data flows and messages exchanged between the MOC and the SOCs as related to the distribution of housekeeping telemetry.

There are two main ways to distribute the housekeeping telemetry: Telemetry messages sent through sockets over TCP/IP. Telemetry files for the Level-0 or “24-hour” data sets.

April 27, 2006 2


4.2.1 Real-time Housekeeping Telemetry Messages Format Specification

4.2.1.1 CCSDS Housekeeping Telemetry PacketThe structure of a CCSDS packet for housekeeping telemetry for the SDO application is illustrated in Figure 4-1. It is provided in this ICD for information only. Reference 5, SDO CCSDS Implementation Document, 464-SYS-SPEC-0033, is the original source for this information.

Figure 4-1. CCSDS SDO Housekeeping Telemetry Packet

4.2.1.2 Housekeeping Telemetry MessageA housekeeping telemetry message is formatted as an SFDU and is structured as illustrated in Figure 4-2. This SFDU consists of a “Z header” followed by a series of pairs “FANN-Cxxx”:

Figure 4-2. Telemetry SFDU Structure

1- “Z header”, specifying the length of the data in this SFDU2- For each packet, there are 2 components:

- “FANN” (FEDS Annotation data), fixed length component containing information about the telemetry packet:

April 27, 2006 3

Fixed fields (SDO)

Packet Identification Packet Seq.Control

PacketLength

Application Data

(3) (1) (1) (11) (2) (14) (16)8 octets2 octets 2 octets 2 octets

Secondary Header (SDO)

(bits)(octets)

(32) (32) (variable N*8)(000) (0) (1) (x...x) (11) (x...x) (x...x) (x…x) (x…x) (x…x)

PRIMARY HEADER(CCSDS Standard)

DATA FIELD(Mission Specific)

Version Type Sec Applic. Seq. Source Seconds Sub # Hdr. Process Flgs Seq Seconds Flag ID Count

Length: Even Number of octets

Length of this SFDU in bytes.

“FEDS Annotation” describing the telemetry packet

Telemetry CCSDS packet (see Table 4-3)

Z Header

FANN

Packet (Cxxx)

May berepeated.

LENGTH DESCRIPTION/CONTENTSFIELD

20 bytes

58 bytes

Variable


VCDU Primary headerVCDU Insert zoneM-PDU headerPacket Primary header

- “Packet” (or “Cxxx”), containing the CCSDS telemetry packet itself Packet Primary headerPacket secondary headerPacket data

The pair “FANN / Packet” may be repeated several times under a single “Z Header”. The number of FANN / Packet pairs is based on the size of the SFDU and the rate of the data being downlinked. Parameters will be set within ASIST to define the maximum size of an SFDU, typically between 4K and 8K, and the maximum time elapsed before an SFDU is sent, typically 1 or 2 seconds. The SFDU is completed and sent when either the maximum size or the maximum time is reached. Figure 4-3 shows the construct of the FANN and the Packet/Cxxx components

Figure 4-3. Generation of a Housekeeping Telemetry Message

4.2.1.2.1 Z header Format

April 27, 2006 4

M_PDU Header(2 Octets)

VCDU Data Source Packet Data 1080 or 1084 Octets

VCDU PrimaryHeader (6 Octets)

Next Packet

VCDU Insert Zone(6 Octets)

Packet PrimaryHeader

(6 Octets)

Secondary Header(8 Octets) Packet Data


(6 Octets)

Packet SecondaryHeader

Packet DataPacket PrimaryHeader

Packet #N Next Packet



VCDU InsertZone (6 Octets)

Spacecraft To MOC

MOC to SOC

MOC

...

FANN

Packet

Packet

Packet

FANN

FANN

FANN Fields(38 Octets)

Cxxx Fields(20 Octets)


(6 Octets)



(6 Octets)







(6 Octets)



(6 Octets)







The “Z header” is the first part of the telemetry SFDU. It is 20 bytes long and its format is defined in Table 4-3.

Table 4-3. Housekeeping Telemetry “Z header”

Bytes Length Value Type Comments0-3 4 CCSD Fixed Control Authority ID (CAID)4 1 3 Fixed Version ID5 1 Z Fixed Class ID indicating this SFDU contains other SFDUs6 1 A Fixed Indicates that SFDU length is specified in ASCII7 1 0 Fixed Spare

8-11 4 0001 Fixed Data Description ID (DDID)12-19 8 var 8 ASCII

decimal charsNumber of bytes in the value field of the SFDUDecimal, zero-padded.

4.2.1.2.2 FANN (FEDS Annotation data)The FANN is 58 bytes long and its format is defined in Table 4-2.

Table 4-4. Housekeeping Telemetry FANN Format

Bytes Length Value Type Comments

0-3 4 C733 Fixed Control Authority ID (CAID)4 1 3 Fixed Version ID5 1 I Fixed Class ID6 1 A Fixed Indicates that SFDU length is specified in ASCII7 1 0 Fixed Spare

8-11 4 FANN Fixed Data Description ID (DDID)12-19 8 var 8 ASCII

decimal charsNumber of bytes in the value field of the SFDUDecimal, zero-padded.

20-23 4 var Binary Sequence counter in binary for this SFDU. Number generated by the MOC, individually incrementing for each SOC and each SFDU sent.

24-25 2 var ASCII Reserved26 1 I/Q/S ASCII Telemetry channel27 1 var Binary Error code:

0= no error, Not 0= error encountered (1)

28-31 4 var Binary Reserved32-35 4 var Binary Ground system time (UTC) seconds36-37 2 var Binary Ground system time (UTC) milliseconds38-51 14 var Binary First 14 bytes of AOS Frame

VCDU primary header (6 bytes)+VCDU insert zone (6 bytes)+ MPDU header (2 bytes)

52-57 6 var Binary First 6 bytes of packet: Packet primary header

(1) 1 = no Reed-Solomon errors but only partial packet was received2 = Reed-Solomon errors encountered and corrected and the entire packet was received3 = Reed-Solomon errors encountered and corrected but only partial packet was received

4.2.1.2.3 “Cxxx” (Telemetry Packet Data)

April 27, 2006 5


The “Cxxx” part, where “xxx” represents the APID, is of variable length and contains the CCSDS telemetry packet. Its format is defined in Table 4-3.

Table 4-5. Housekeeping Telemetry “Cxxx” Format

Bytes Length Value Type Comments

0-3 4 C733 Fixed Control Authority ID (CAID)4 1 3 Fixed Version ID5 1 I Fixed Class ID6 1 A Fixed Indicates that SFDU length is specified in ASCII7 1 0 Fixed Spare

8-11 4 Cxxx ASCII Hex chars

Data Description ID where xxx is the APID in hexadecimal, zero-padded.

12-19 8 var ASCII decimal chars

Number of bytes in the CCSDS packet, zero-padded(length of the following field)

20-n var var Binary CCSDS packet

4.2.2 Housekeeping Telemetry Level-0 Files The instrument level-0 housekeeping telemetry is provided to the SOCs as files. This section describes the format of these telemetry files.

4.2.2.1 Housekeeping Telemetry Data File Format

4.2.2.1.1 File Naming ConventionThe file naming convention for housekeeping data files is:

apid_yyyy_ddd_ver.hktwhere:

apid is the APID of the packets contained in file, 4 decimal characters, zero-padded.yyyy_ddd is the year and day of year covered by that file.ver is the version number, 2 decimal characters from 00 to 99, incremented when file is re-processed.hkt is the file extension

Example: 0012_2007_222_01.hkt

4.2.2.1.2 File FormatEach telemetry file contains a succession of telemetry packets in binary format Each packet consists of:

Primary header (6 octets) Secondary header (8 octets) Application data (variable length)

April 27, 2006 6


4.2.2.2 Housekeeping Telemetry File AnnotationEach .hkt file will be accompanied by a descriptive .xml file.

4.2.2.2.1 File Naming ConventionExcept for the different extension, the .xml file will have the same name as the associated .hkt file, that is apid_yyyy_ddd_ver.xml

4.2.2.2.2 File FormatThe file is in XML (Extensible Markup Language) format and it includes, but is not limited to, the information listed in Table 4-4.

Table 4-6. Housekeeping Telemetry Header File

file Name of the associated .hkt file (string between quotes)APID= APID of packets in the .hkt file.totalSize= Size in bytes of the .hkt file.NUMBER_PKTS= Number of packets in .hkt file.FirstPacketUTC= Time stamp of first packet in .hkt file.LastPacketUTC= Time stamp of last packet in .hkt file.totalMissing= Number of packets missing

All text strings are enclosed in double quotes. All times are UTC and in the form yyyy-ddd-hh:mm:ss.sss

April 27, 2006 7


5.0 FLIGHT DYNAMICS SYSTEM INTERFACE

5.1 FLIGHT DYNAMICS SYSTEM INTERFACE OVERVIEW

The Flight Dynamics System (FDS), in conjunction with the Flight Dynamics Facility (FDF), generates various products in support of the SDO Mission. These products and their formats are described in detail in the ICD between the FDS/MOC and the SDO Ground System (Reference 10).

Table 5-1 lists the FDS products that are available to the SOCs and, for each product, it defines:

Product reference number, which provides the link to the FDS to Ground System ICD (Reference 10). This is where the detailed format for this product is defined.

Product name and file name Time span and Delivery schedule, which define the length of time covered

by each file and the frequency of its renewal.

Table 5-7. FDS Products Provided to SOCs

Product Ref Number

Product NameandFilename

Time span Delivery Schedule

3.3.1 Short Term Predicted Eclipses

ECLIPSE_yyyyddd.SnnECLIPSEATM_yyyyddd.Snn

5 weeks Weekly

3.3.1 Long Term Predicted Eclipses

ECLIPSE_yyyyddd.LnnECLIPSEATM_yyyyddd.Lnn

8 months Quarterly

3.3.6 Short Term Predicted HGA View Periods of SDOGS

HGA_POS_VIEW_yyyyddd.SnnHGA_NEG_VIEW_yyyyddd.Snn

5 weeks Weekly

3.3.7 HGA Gimbal Angles (TBC)

HGA_GIMBALS_ yyyyddd.Snn

5 weeks Weekly

3.3.9 Short Term Predicted RFI

RFI_STWS_yyyyddd.SnnRFI_STSS_yyyyddd.Snn

5 weeks Weekly

3.3.10 Predicted Orbital State Vectors (Geocentric) 5 weeks Weekly

June 23, 2005April 27, 2006 1


ORBIT_GEO_yyyyddd.Snn3.3.11 Predicted Orbital State Vectors (Heliocentric)

ORBIT_HELIO_yyyyddd.Snn

5 weeks Weekly

3.3.13 Short Term Orbit Maneuver Planning File

PLAN_SK_yyyyddd.Snn

5 weeks Weekly

3.3.13 Long Term Orbit Maneuver Planning File

PLAN_SK_yyyyddd.Lnn

8 months Quarterly

3.3.17 Orbit Maneuver Summary

MNVRSUM_yyyyddd.xls

Life of mission

Following each maneuver

3.3.21 2-Line Elements

2LINE_ELEM_yyyyddd.nn

Single set Following each orbit determination

3.3.23 Predicted Celestial Bodies in Instrument FOV

SCI_FOV_yyyyddd.Snn

5 weeks Weekly

3.3.25 Computed Orbit Solution

COMP_ORBIT_yyyyddd.nn

One Solution

Weekly

3.3.26 SBC Attitude Validation File

VALATT_yyyyddd.nn

snapshot Weekly

3.3.30 Lunar Intensity & Moon Center-to-Sun Center Angles

LUNSHAD_yyyyddd.Snn

5 weeks Weekly

3.3.32 Instrument Calibration Command Data Files

CMD_HROLL_yyyyddd.nnCMD_EFOV_yyyyddd.nnCMD_ECRUC_yyyyddd.nnCMD_HMIAIAOFF_yyyyddd.nnCMD_GTPZT_yyyyddd.nn

As needed As needed.At least 24 hours before maneuver starts

3.3.36 Momentum Management Maneuver Planning File

PLAN_MM_yyyyddd.Snn

5 weeks As needed

3.3.37 Solar Transit file

SOLAR_TRANSIT_yyyyddd.Snn

5 weeks Weekly

Note: Other FDS products defined in the FDS/MOC to GS ICD may be provided, without modifications, to the SOCs if needed. The only products that cannot be

June 23, 2005April 27, 2006 2


provided are those defining commands in support of spacecraft activities and maneuvers.

5.2 FORMAT SPECIFICATION FOR FLIGHT DYNAMICS PRODUCTSThe ICD between the FDS and the SDO Ground System (Reference 10) contains the detailed format specifications for each FDS product. However, a few general rules apply that are summarized in this section.

1- All FDS products are in ASCII text file format.

2- All times are in UTC.

3- The file naming conventions are included in Table 5-1, where: Upper case letters represent fixed characters, and italicized letters

represent variable characters “yyyyddd” represents the 4-digit year and 3-digit day of year for the

first day covered by the data in this product The file extension may be

- xls for an excel spreadsheet- Snn or Lnn where:

- S indicates a short term product covering 5 weeks- L indicates a long term product covering 35 weeks- ”nn” represents the 2-digit version number of the file, from

00 to 99; 00 is the first version and the highest version supersedes all other versions.

4- The FDS products are generated on a weekly, quarterly and special request basis, as defined in Reference 10. Weekly products will cover a 5-week period beginning at 00:00 hours UTC on the first day of the 5-week period. Quarterly products will be delivered during the first full week of each quarter (January, April, July and October) and will cover a period of 35 weeks starting at 00:00 hours UTC on the first day of the next week. Delivery of the quarterly products will occur before their start date.

5- The FDS products are available on the MOC product server from where the SOCs retrieve them. Copies of each product will be kept on the product server to cover the current time period and the previous time period. For instance, there will be a copy of a 5-week product covering the time period starting this week and another copy covering the time period starting last week. If a product covering a given time period is re-generated, the file name will remain the same but the version number will be incremented.

6- Note on predicted eclipse products. The products with file type ECLIPSE are calculated using the Earth radius. The products with file type ECLIPSEATM are calculated using the Earth radius incremented by a given atmospheric height. That height can vary from 1 to 400 kilometers. The value used in calculations will

June 23, 2005April 27, 2006 3


be specified in the Operations Agreement (References 11) and will be noted in the product title.

June 23, 2005April 27, 2006 4


6.0 MISSION SUPPORT DATA

6.1 MISSION SUPPORT DATA INTERFACE OVERVIEW

Mission support data refers to data items exchanged between the MOC and the SOCs not previously described in this ICD. This includes operational reports, planning products and Project Database files. Detailed specifications for these data items are provided in this ICD as they affect the design and implementation of the interfacing systems. When additional detailed specifications are provided in other applicable documents, references are made in the corresponding sections.

The Operations Agreement (Reference 11) between the FOT and each SOC will contain additional operational information related to mission support data, such as specific delivery schedule, e-mail addresses, or hierarchy of personnel to respond to alert notifications.

6.2 OPERATIONAL REPORTS

Several reports and logs generated by the MOC are available to the SOCs. These reports will be exchanged using the MOC Product Server, which is accessible for read and write by the SOCs. Section 6.6 and Section 7 provide additional information regarding file naming conventions, and the MOC Product Server structure and accessibility.

6.2.1 Status Reports

Various operational reports and meeting minutes are generated by the FOT and by the SOCs operations personnel. They contain information about the status of the observatory, instruments, data accounting metrics, and activities of interest. They are free-format text files.

The FOT and the SOCs will typically produce a status report on a weekly basis with a higher frequency during commissioning and times of coordinated activities. The FOT will generate minutes after every planning meeting.

Their originator will deposit these reports on the MOC Product Server.

April 27, 2006 1


6.2.2 Trending Reports

The MOC Integrated Trending and Plotting System (ITPS) produces statistics and plots for selected housekeeping telemetry points. The SOCs have access to a web-based ITPS located in the MOC. The SOCs can generate their own reports following standard ITPS procedures that will be described in the ITPS User’s Guide (Reference 14).

6.2.3 Command History Reports

The MOC T&C system generates a log of all system events, including all commands sent to the observatory. The command History Report is extracted from the event log and the SOCs can obtain that information for a given time period. The FOT generates the Command History Report every weekday and on an as-needed basis, such as after a maneuver or an anomaly.

The Command History Report is a machine-readable fixed-format ASCII text file that will be placed on the MOC Product Server for retrieval by the SOCs.

6.2.4 SDO Ground Station (SDOGS) and DDS Status

The MOC has status information about the SDO Ground Station (SDOGS) and from the Data Distribution System (DDS). The MOC will generate status pages viewable by the SOCs. These will require proper login and password.

6.3 PLANNING DATA

6.3.1 SOC Planning Input and Calibration Requests

The SOCs will participate in the long term and short term planning meetings where requests for all coordinated activities will be formulated, discussed, integrated with forecasted events, and scheduled. To exchange planning information outside of meetings, operations personnel will interact via telephone or e-mail over the Center Network Environment (CNE) administrative network. This information will be captured in meeting minutes and MOC status reports.

April 27, 2006 2


6.3.2 Observatory Timeline

Mission events, primarily obtained from FDS products and planned activities will be collected on the Observatory Timeline. This is a “calendar” providing the start and stop times for relevant events and activities.

Electronic copies in JPEG or PNG format of the Observatory Timeline will be available on the MOC product server. They will also be available as reports in XML format. There are several views with different time-scales: long-term (8 months), medium term (one month) and short-term (one week).

6.3.3 Spacecraft Integrated Print

The spacecraft Integrated Print is a chronological listing of all commands included in a given spacecraft ATS load. It provides the list of ATS commands with associated mnemonic, criticality and execution time. Commands originating from expanded RTSs are merged with the ATS commands.

A spacecraft Integrated Print is produced each time an ATS load is generated. The FOT puts it on the MOC product server for retrieval by the SOCs.

6.3.4 Science Uplink Plan

Each SOC will provide a human readable list of all commands loaded onto their instrument processor prior to uplinking an absolute time command load or a timed command sequence. The Science Uplink Plan is similar in contents to the Spacecraft Integrated Print, providing a chronological listing of command mnemonics, associated criticality and execution time. The SOCs will deposit their Science Uplink Plan on the MOC product server for use by the FOT.

6.4 ALERT NOTIFICATIONS

Each SOC has its own alert notification system that is capable of communicating with the MOC Alert Communication System (ANS). The MOC ANS shall be capable of notifying a given SOC alert notification system via e-mail messages when specific events occur. The FOT will maintain a list of all the events that cause a MOC alert message to be sent to the SOCs. Each SOC will provide the e-mail address that will receive alert messages originating from the MOC. These alert messages will trigger pages to the SOC team following the process implemented by each SOC.

April 27, 2006 3


Similarly, the SOC alert notification systems shall be capable of sending alert messages to the FOT in the form of e-mail messages addressed to the MOC ANS.

An IONet e-mail server will be provided that the SOCs can access through the MOC firewall.

6.5 PROJECT DATABASE INPUT AND UPDATES

The MOC maintains the Ground System Project Database and the SOCs maintain the instrument databases. During the various mission phases, the MOC and the SOCs need to exchange subsets of these databases. The SDO Project Database Format Control Document (DFCD) (Reference 2) defines the structure and format of the MOC project database. It also provides basic rules and conventions that facilitate the exchange of database information. Record Definition Language (RDL) files will be used to exchange database information between the MOC and the SOCs.

6.5.1 Telemetry Definition Database

The SOCs provide the instrument telemetry definition database related to the instrument telemetry parameters that the FOT monitors at the MOC. This enables the MOC to process the S-band telemetry packets containing these parameters.

Similarly, the MOC provides the SOCs with the telemetry database allowing them to process the spacecraft health and safety parameters they need to monitor.

6.5.2 Command Definition Database

The SOCs provide the MOC with the definition of all instrument commands the FOT may have to generate. This includes instrument commands that the FOT may send as real-time commands as part of STOL procedures as well as instrument commands used in spacecraft ATS loads and spacecraft RTS definitions.

The SOCs must provide the information necessary for the MOC to recognize critical commands. The MOC can accept either the full definition database for these commands or a list of APID/Function codes reserved for critical commands.

April 27, 2006 4


6.6 MISSION SUPPORT DATA NAMING CONVENTIONS AND MOC PRODUCT SERVER

Table 6-1 provides a summary of file naming conventions for products identified in this ICD that will be exchanged using the MOC Product Server.

The MOC will deposit/push files destined to the SOCs on the MOC Product Server and the SOCs will retrieve/pull them.

The SOCs will deposit/push files destined to the MOC on the MOC Product Server and the MOC will retrieve/pull them.

Table 6-1 also specifies the directory where each product will reside, and how long it will be available. The SOCs access the MOC Product Server, under the control of firewall rules, using either secure FTP or https.

April 27, 2006 5


Table 6-8. Naming Conventions and Product Server Locations

Product From File name(1), (2), (3), (4)

Directory(1)

Life on Product Server

Comments

Level-Zero HK telemetry files MOC See Section 4.2.2 MOCtoSOC/LZyyyyddd 7 days All APIDs for the same day are in the same directory

FDS Products MOC See Table 5-1 MOCtoSOC/FDSyyyyddd 2 product cycles

All products covering time periods starting on the same day are in the same directory

MOC Status Report MOC moc_status_yyyyddd _vnn.rpt MOCtoSOC/reports/status LOM yyyyddd is first day coveredMeeting Minutes MOC minutes_yyyyddd_vnn.rpt MOCtoSOC/reports/minutes LOM yyyyddd is day of meetingMOC Data Accounting report MOC account_yyyyddd_vnn.rpt MOCtoSOC/reports/account LOM yyyyddd is first day coveredSOC Status Report SOC ins_status_yyyyddd_vnn.rpt SOCtoMOC/reports/status LOM yyyyddd is first day coveredCommand History Report MOC cmdhist_yyyyddd_vnn.rpt MOCtoSOC/reports/cmdhist 21 days yyyyddd is first day coveredMOC Integrated Print MOC IP_loadtype_yyyyddd_vnn.rpt MOCtoSOC/reports/Intgprint 21 days yyyyddd is first day coveredScience Uplink Plan SOC ins_uplink_yyyyddd_vnn.rpt SOCtoMOC/reports/sciuplink 21 days yyyyddd is first day coveredLong term Observatory Timeline View MOC TL_long_yyyyddd_vnn.jpg or png MOCtoSOC/timeline 9 months yyyyddd is first day coveredMonthly Observatory Timeline View MOC TL_medium_yyyyddd_vnn.jpg MOCtoSOC/timeline 3 month yyyyddd is first day coveredWeekly Observatory Timeline View MOC TL_short_yyyyddd_vnn.jpg MOCtoSOC/timeline 21 days yyyyddd is first day coveredObservatory Timeline XML Report MOC TL_XML_yyyyddd_vnn.xml MOCtoSOC/timeline 9 months yyyyddd is first day coveredProject Data base CMD files SOC See DFCD (Ref 2) See DFCD (Ref 2) N/A See DFCD (Ref 2)Project Data base TLM files SOC See DFCD (Ref 2) See DFCD (Ref 2) N/A See DFCD (Ref 2)Project Data base TLM files MOC See DFCD (Ref 2) See DFCD (Ref 2) N/A See DFCD (Ref 2)

(1) Italicized characters are variable. yyyy is the 4-digit year, ddd is the 3-digit day of year(2) “vnn” is the version number; nn are 2 decimal digits from 00 to 99. The higher version number is the most recent and most appropriate to use.(3) “ins” is AIA, EVE or HMI(4) “loadtype” identifies the activity supported by this load (e.g.,. ECLIPSE, EVEFOV, etc)

June 23, 2005April 27, 2006 6


7.0 NETWORK CONFIGURATION

Figure 7.1 illustrates the MOC/SOC network interface configuration.

For network configuration and security considerations, each SOC has two distinct segments:

- The SOC Telemetry and Command (T&C) Segment is isolated from any physical network connections other than through the SDO-provided switch-routers. Typically, this segment is where the instrument Telemetry and Control (T&C) functions are performed. All communications between the SOC T&C segment and any other network must go through the MOC firewall. Instrument commanding must originate from the SOC T&C segment or the Instrument Support segment within the MOC at GSFC.

- The SOC Science Data Processing (SDP) Segment may have connections with outside networks. This ICD only concerns the segment directly connected to the SDO-provided switch-routers. This segment primarily interfaces with the Data Distribution System (DDS), but it can also interface with the MOC to receive housekeeping telemetry or exchange mission support data. It also needs to access outside network for science data distribution. The SOCs are responsible for providing the proper isolation via routers and firewalls.

Similarly, the MOC has several segments with various degrees of network protection. The MOC segments relevant to this interface are:

- The MOC Real-time Segments (2) that can be connected to the SOCs T&C segment for instrument commanding. Only one commanding connection at a time will be allowed for each instrument.

- The MOC Telemetry Segment that is connected to the SOCs for distribution of real-time housekeeping telemetry

- The MOC “DMZ” Segment that provides a secure interface for direct file transfers to and from remote users, including the SOCs. This is where the SOC-accessible MOC Product Server and web-based ITPS are located.

- The Instrument Support Segment where the instrument ground support equipment is resident in the MOC.

Real-time mission critical lines connect the MOC and the SOCs’ T&C segment to support instrument commanding and housekeeping data distribution. High rate

April 27, 2006 1


data lines connect the DDS and the SOCs’ SDP segment to support the distribution of science data.

The SOC SDP segment can interface with the MOC, for instance to receive housekeeping telemetry and exchange mission support data. The connection between the SOC SDP and the MOC is made over the high-speed lines, through the DDS firewalls at White Sands and through the MOC firewall. This same route is used for data exchanges between the SOC T&C segment and SDP segment if the SOC T&C segment needs to push data to or pull data from the SDP computers directly connected to the SOC SDP routers.

The SOC T&C segment is allowed access to the Network Time Protocol (NTP) server on the IONet as well as an IONET email server through the MOC firewall.

Figure 7-1 indicates the connecting machines for the various types of data exchanged.

- For commanding, the SOC T&C must connect to the commanding ASIST workstation in either MOC Real Time Segment #1 or Segment #2

- For real-time housekeeping telemetry, the SOCs must connect to FEDS#3 or FEDS#4

- For access to the MOC Product server, the SOCs must connect to the server located in the DMZ segment.

April 27, 2006 2


Figure 7-1 Communication Network configuration for MOC-to-SOC interface

March 3 2006April 27, 2006 3


APPENDIX A – ABBREVIATIONS AND ACRONYMS

ACK AcknowledgementAIA Atmospheric Imaging AssemblyANS Alert Notification SystemAPID Application idASCII American Standard Code for Information InterchangeASIST Advanced System for Integration and Spacecraft TestingATS Absolute time sequenceBSD Berkeley Software distributionCAID Control Authority IDCCB Configuration Control BoardCCSDS Consultative Committee for Space Data StandardsCLCW Command link control wordCMD CommandCNE Center Network EnvironmentCOP Command Operating ProcedureDDID Data Description IDDDS Data Distribution SystemDFCD Data Format Control DocumentDMR Detailed Mission RequirementsDMZ DeMilitarized Zone EUV Extreme ultravioletEVE Extreme Ultraviolet Variability Experiment FANN FEDS AnnotationFDF Flight Dynamics FacilityFDS Flight Dynamics SystemFEDS Front-End Data SubsystemFOT Flight operations teamFTP File transfer protocolGSFC Goddard Space Flight CenterGT Guide telescopeHGA High Gain AntennaHMI Helioseismic and Magnetic ImagerI&T Integration and testICD Interface control documentID IdentificationIP Internet ProtocolITPS Integrated Trending and Plotting SystemJPEG Joint Photographic Experts GroupJSOC Joint Science Operations CenterLASP Laboratory for Atmospheric and Space PhysicsLMSAL Lockheed Martin Solar and Astrophysics LaboratoryLWS Living with a StarMOC Mission Operations CenterMRD Mission Requirements DocumentNASA National Aeronautics and Space AdministrationNTP Network Time ProtocolOA Operations AgreementPNG Portable Network GraphicsRDL Record Definition LanguageRTS Relative time sequenceS/C SpacecraftSDO Solar Dynamics ObservatorySDOGS SDO Ground StationSDP Science Data ProcessingSFDU Standard formatted data unitSOC Science Operations Center

March 3 2006April 27, 2006 1


SSR Solid State RecorderSTK Satellite Tool KitSTOL Spacecraft test and operations languageT&C Telemetry and commandTBD To be defined TLM TelemetryTSM Telemetry and Statistics MonitorUTC Universal Time Coordinated VC Virtual channelVCDU Virtual channel data unitVCID Virtual Channel IDXML Extensible Markup Language

March 3 2006April 27, 2006 2

NEXT GENERATION SPACE TELESCOPEhmi.stanford.edu › NASA_documents › 464-GS-ICD-000… · Web...

Documents

Transcript of NEXT GENERATION SPACE TELESCOPEhmi.stanford.edu › NASA_documents › 464-GS-ICD-000… · Web...