NEXT GENERATION SPACE TELESCOPE - Stanford...

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 C

Prepared By: E. Larduinat/Code 453.7

Effective Date: October 15, 2008Expiration Date: October 15, 2013

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

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

10/15/2008 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

10/15/2008 Page iii


DOCUMENT CHANGE RECORD Sheet: 1 of 1

REVLEVEL DESCRIPTION OF CHANGE

APPROVEDBY

DATEAPPROVED

- Released by SDO-CCR-0119 R. Lilly 07/20/2004

A Updated and Released by SDO-CCR-0313 R. Lilly 06/23/2005

B Updated and Released by SDO-CCR-0547 R. Lilly 04/27/2006

C Updated and Released by SDO-CCR-0956 R. Lilly 10/15/2008

10/15/2008 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 Connection4-1

4.1.2 Non-Real Time Housekeeping Telemetry Distribution and Retransmissions...................................................................................................4-1

4.2 Format Specification for Housekeeping Telemetry Data.........................4-24.2.1 Real-time Housekeeping Telemetry Messages Format Specification....4-24.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-16.2.3 Command History Reports.....................................................................6-26.2.4 Deleted...................................................................................................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 Deleted...................................................................................................6-3

6.4 Alert Notifications.......................................................................................6-36.4.1 E-mail Addresses for Alert Notifications.................................................6-36.4.2 MOC to SOC Alert Messages................................................................6-46.4.3 SOC to MOC Alert Messages................................................................6-5

6.5 Project Database Input and Updates.........................................................6-56.5.1 Telemetry Definition Database...............................................................6-56.5.2 Command Definition Database..............................................................6-5

10/15/2008 Page v


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

10/15/2008 Page vi


LIST OF FIGURESFigure Page

Figure 1-1. Document Scope 1-1

Figure 1-2. MOC/SOC Interface Context Diagram 1-2

Figure 3-1. SDO Commanding Context Diagram 3-1

Figure 3-2. MOC/SOC Socket Connection Protocol 3-6

Figure 3-3. Commanding Session Protocol 3-7

Figure 3-4. Self-Identifying Message 3-9

Figure 3-5. Connection Acknowledgement Message 3-10

Figure 3-6. CCSDS SDO Command Packet 3-12

Figure 3-7. Command SFDU Structure 3-12

Figure 3-8. Local Response Message 3-14

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

Figure 4-1. CCSDS SDO Housekeeping Telemetry Packet 4-2

Figure 4-2. Telemetry SFDU Structure 4-3

Figure 4-3. Generation of a Housekeeping Telemetry Message 4-4

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

LIST OF TABLESTable Page

Table 3-1. Port Assignments......................................................................................3-8

Table 3-2. Command SFDU Example......................................................................3-14

Table 4-1. Housekeeping Telemetry “Z header”..........................................................4-4

Table 4-2. Housekeeping Telemetry FANN Format.....................................................4-5

Table 4-3. Housekeeping Telemetry “Cxxx” Format...................................................4-5

Table 4-4. Housekeeping Telemetry XML File.............................................................4-7

Table 5-1. FDS Products Provided to SOCs...............................................................5-1

Table 6-1. Naming Conventions and Product Server Locations..................................6-7

10/15/2008 Page vii


LIST OF TBDs

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

10/15/2008 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.

10/15/2008 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

10/15/2008 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

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.

10/15/2008 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)

10/15/2008 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

10/15/2008 Page 1

(Data Stream)

Command SFDU

Command SFDU

Command SFDU

T&C (ASIST)

MOC

PDB

MOC Planning tool

CLTU

CLTU

CLTU

CLTU

CLTU

CLTU

Authentication (Origin/Dest)

Validation

Identification of Critical Commands

Formatting for Uplink

Authentication (Origin/Dest)

Validation

Identification of Critical Commands

Formatting for Uplink

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


EVEReal-time Cmd

Processor


EVEReal-time Cmd

Processor

EVEReal-time Cmd

ProcessorReal-time Cmd

Processor



AIAReal-time Cmd

Processor


AIAReal-time Cmd

Processor

AIAReal-time Cmd


Processor



HMIReal-time Cmd

Processor


HMIReal-time Cmd

Processor

HMIReal-time Cmd


Processor



MOC Product Server


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.

10/15/2008 Page 2


All activities requiring planning to avoid loss of science or to minimize science impact.

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. Spacecraft RTSs are defined and managed by the FOT, with input from the SOCs when appropriate. The SOC can submit a request to modify a spacecraft RTS to the FOT, who validates it, generates the RTS load and schedules the uplink. During the mission operational phase, RTS modifications will be infrequent and will require formal approval before implementation and upload. The SOCs should allow enough time for the 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

10/15/2008 Page 3


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.

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 notification 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, 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 e-mail, 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

10/15/2008 Page 4


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 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. For commanding sessions, the SOCs will connect to the ASIST Prime workstation on the active real-time MOC segment. For telemetry, the SOCs will connect to the FEDS on the MOC telemetry segment.

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 acknowledgement) 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. In case of failure, it is the responsibility of the SOC to fail-over to the back-up ASIST or FEDS workstation.

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 determine 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).

10/15/2008 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 SSR-recorded data when it is downlinked. Three user’s names are 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.

10/15/2008 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.

10/15/2008 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

10/15/2008 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

10/15/2008 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

10/15/2008 Page 10

20 Bytes 20 bytes 3 or 5 bytes

”Z” Header “I” Header Command Acknowledgment Data

ExamplesCCSD3ZA0000100000023 C7333IA0AKNK00000003 ACKCCSD3ZA0000100000025 C7333IA0AKNK00000005 NAK01 CCSD3ZA0000100000025 C7333IA0AKNK00000005 NAK02

…


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.

10/15/2008 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 in the command definition files provided by the SOCs as part of their Project Database submissions.

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. .

10/15/2008 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 is a convention to represent 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.

10/15/2008 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

10/15/2008 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


C7333IA0AAAATTTTTTTT20 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” Header

10/15/2008 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


CCSD3ZA00001LLLLLLLL20 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 Input for Spacecraft ATS Loads and SBC Table LoadsThe FOT uses load templates to define and generate the ATS loads that implement coordinated activities. All instrument commands included in a spacecraft ATS load must be defined in the command definition database residing in the MOC T&C system. Typically, instrument commands included in the ATS loads are Instrument Notification Commands (INC) and commands to control the Image Stabilization System loops. Modifications related to these commands will be infrequent. The FOT is responsible for defining, validating, and maintaining all ATS load templates. When a modification is necessary, it will be implemented by the FOT and verified with the SOCs through the inspection of the integrated print (see section 6.3.3) resulting from the ATS load generation.

10/15/2008 Page 16


The Guide Telescope calibration maneuver is a particular case since it requires specific command input from AIA prior to each occurrence of the maneuver. In addition, AIA will provide updates to Guide Telescope offsets after the maneuver. These AIA command input files are described in the next sections.

3.3.2.2.1 GT Calibration Maneuver PZT Gains AIA Input FileThis file is used as input to generate the ATS load implementing the monthly GT calibration maneuver.

This is a fixed-format ASCII text file that AIA will deposit on the MOC Product Server at least 5 days before a planned GT calibration maneuver. The format is defined in Appendix B.

Blank lines are ignored and are used for readability Lines starting with a semicolon are treated as comments All other lines starting with the keywords WAIT, SetPredictedError,

EndSetPredictedError, RestoreError, EndRestoreError, or SetPZT should not be modified

AIA must fill-in: the GT Error Gain values as xxx in

/AIA_IS_ERRGAIN DATA = "ISS=1 AXIS=Y GAIN=xxx" the PZT GAIN values as xxx in

/AIA_IS_PZT_GAIN DATA = "ISS=1 PZT=A GAIN=xxx"

The filename is PZTCAL_yyyydoy.VnnWhere yyyydoy is the date of the calibration maneuver and Vnn is the version number, starting with V00.

3.3.2.2.2 Post GT Calibration AIA Input FileParameters included in this file represent the entries in SBC Table 77, “Guide Telescope Processing Parameters”, which will be updated as a result of a GT maneuver. The FOT will use that file to generate the corresponding table load.

This is a fixed-format ASCII text file that AIA will deposit on the MOC Product Server after GT calibration maneuver. The format is defined in Appendix B.

Blank lines are ignored and can be used for readability Lines starting with a semicolon are treated as comments

AIA must fill-in: Offset from Solar Reference Boresight to GT frame as in:

/ACS_GT_PARM.GTU[1].BIAS_SRBTOGT[1] = xxx Limits for linear range of GT error signals as in

/ ACS_GT_PARM.GTU[1].LIM_GTLINEAR[1] = xxx

10/15/2008 Page 17


The filename is POST_GTCAL_yyyydoy.VnnWhere yyyydoy is the date of the calibration maneuver and Vnn is the version number, starting with V00.

3.3.2.3 Requests for Defining a Spacecraft RTS Instrument RTSs are defined on the spacecraft processor, mainly for Telemetry and Statistics Monitor (TSM) responses. These RTSs are under the control of the FOT. They are activated by a spacecraft command originating from the FOT. If updates are needed, the RTS definitions in mnemonic form will be exchanged between the FOT and the SOC via e-mail until agreement is reached. The RTS will be tested by the FOT. The RTS uplink and activation will be coordinated with the originating SOC. 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.

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 the Operations Agreement (Reference 11).

10/15/2008 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 to the FOT.

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, possibly by failing-over to the back-up FEDS.

4.1.2 Non-Real Time Housekeeping Telemetry Distribution

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

10/15/2008 1


4.1.2.2 Deleted

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 the MOC Product Server from where the SOCs can retrieve them. The 24-hour data sets will be generated by 12:00 UTC on a daily basis. They will be available to the SOCs as soon as they are generated, and they will remain on the MOC Product Server for a minimum of 7 days after their creation date

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.

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

10/15/2008 2

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


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:

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

10/15/2008 3

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


Figure 4-3. Generation of a Housekeeping Telemetry Message

4.2.1.2.1 Z header FormatThe “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.

10/15/2008 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)







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 = 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) 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

10/15/2008 5


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 01 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)

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 additional extension, the .xml file will have the same name as the associated .hkt file, that is apid_yyyy_ddd_ver.hkt.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.

10/15/2008 6


Table 4-6. Housekeeping Telemetry XML File

firstPacketUTC= Time stamp of first packet in .hkt file.lastPacketUTC= Time stamp of last packet in .hkt file.totalPackets= Number of packets in .hkt filetotalSize= Size in bytes of the .hkt file.totalGaps= Number of gaps in the .hkt file.totalMissing= Number of packets missing as part of gaps in .hkt file

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

10/15/2008 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.9 Short Term Predicted RFI

RFI_STWS_yyyyddd.SnnRFI_STSS_yyyyddd.Snn

5 weeks Weekly

3.3.10 Predicted Orbital State Vectors (Geocentric)

ORBIT_GEO_yyyyddd.Snn

5 weeks Weekly

3.3.11 Predicted Orbital State Vectors (Heliocentric)

ORBIT_HELIO_yyyyddd.Snn

5 weeks Weekly

10/15/2008 1


3.3.13 Short Term Orbit Maneuver Planning File

PLAN_SK_yyyyddd.Snn

5 weeks Weekly (when maneuver within 35 days)

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.30 Lunar Intensity & Moon Center-to-Sun Center Angles

LUNTRAN_yyyyddd.Snn

5 weeks Weekly

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

3.3.43 Predicted Sun-Moon AnglesSolar Transit file

SUN_MOON_ANGLES_yyyyddd.SnnSUN_MOON_ANGLES_yyyyddd.Lnn

5 weeks8 months

Weekly\ Quarterly

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 provided are those defining commands in support of spacecraft activities and maneuvers.

10/15/2008 2


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 be specified in the Operations Agreement (References 11) and will be noted in the product title.

10/15/2008 3


6.0 MISSION SUPPORT DATA

6.1 MISSION SUPPORT DATA INTERFACE OVERVIEWMission 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 REPORTSSeveral 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 ReportsVarious 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, science 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.

6.2.2 Trending ReportsThe 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).

10/15/2008 1


6.2.3 Command History ReportsThe 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 day 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 Deleted

6.3 PLANNING DATA

6.3.1 SOC Planning Input and Calibration RequestsThe 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.

10/15/2008 2


6.3.2 Observatory TimelineThe Observatory Timeline displays mission events, primarily obtained from FDS products, ground station schedule, and other planned activities. This is a “calendar” providing the start and stop times for relevant events and activities.

The FOT makes the timeline available to the authorized users through the web. The URL for the web is https://sdomoc.nascom.nasa.gov/mps. The web page has an option to generate a timeline report in XML format.

6.3.3 Spacecraft Integrated PrintThe 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 Deleted

6.4 ALERT NOTIFICATIONSThe MOC Alert Notification System (ANS) is capable of notifying a given SOC 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 has its own alert notification system that is capable of communicating with the MOC ANS. The SOC alert notification system is responsible for detecting incoming MOC ANS e-mail messages and propagating them to the SOC personnel. The SOC alert notification system sends alert messages to the MOC ANS in the form of e-mail messages.

6.4.1 E-mail Addresses for Alert NotificationsThe SOCs will define e-mail addresses where the MOC ANS will send all the alert messages it generates for a specific instrument and SOC function.

Each instrument team will provide a maximum of two e-mail addresses, one for e-mails related to health and safety and T&C functions, and one for e-mails related to science data processing functions. Those addresses are related to an instrument (i.e., not to an individual person), and they are static (i.e., they change very infrequently). They are documented in the Operations Agreement (Reference 11) between the FOT and the SOCs.

10/15/2008 3

https://sdomoc.nascom.nasa.gov/mps


The SOCs will use the address [email protected] to send all alert messages destined to the MOC/FOT, and to acknowledge alerts received from the MOC.

6.4.2 MOC to SOC Alert MessagesEach SOC is responsible for:

checking their mail accounts and detecting e-mails from the MOC ANS notifying their operations personnel when MOC alert messages are

received acknowledging alert messages originating from the MOC maintaining the SOC personnel distribution list.

The interface for checking e-mail on mail.nascom.nasa.gov is POP3 over SSL, or POP3S (TCP port 995). The SSL certificate for mail.nascom.nasa.gov is currently self-signed; the fingerprints will be provided to the SOC owners of the e-mail accounts.

6.4.2.1 MOC Message SubjectE-mails from the ANS will have a subject of the following format:

Id = <message ID/Date> Messages = NWhere:

<message ID/Date> represents the date and time when the alert message was generated as YYYY_DDD_hh:mm:ss.nnnnnn.N is the number of alert lines contained in the message.

Example for a message sent on 25 Aug 2008 at 20:11:12.123456 UTC and containing one alert

Id = 2008_238_20:11:12.123456 Messages = 1

6.4.2.2 MOC Message BodyThe message body is ASCII text of variable length. In the majority of cases, the text of the message is the ASIST event log message, i.e., <event time> <event class> <message text>

6.4.2.3 Acknowledgement by receiving SOC The SOCs will acknowledge receipt of e-mails from the MOC ANS by sending an e-mail to [email protected]. The subject of the acknowledgement e-mail must contain the message ID number of the alert. Extra text before and after the message ID is permitted. The body of the acknowledgement e-mail is ignored. The recommended approach is for the SOC to simply REPLY to the original MOC message.

Example: the subject of the acknowledgement to the example above must contain "2008_238_20:11:12.123456”.

10/15/2008 4


6.4.3 SOC to MOC Alert MessagesThe SOCs send alert messages to the FOT MOC-ANS as e-mail messages to [email protected]. They use a standard SMTP interface (TCP port 25). No authentication is required.

The only format requirement for those e-mail messages is that the subject must contain a pre-determined "secret" ASCII text string that will be verbally communicated to the SOCs.

6.5 PROJECT DATABASE INPUT AND UPDATESThe 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. Files in Record Definition Language (RDL) format will be used for all exchanges of database information between the MOC and the SOCs.

6.5.1 Telemetry Definition DatabaseThe 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 SOCs can access the spacecraft subsystems telemetry definition files, allowing them to process the spacecraft health and safety parameters they need to monitor.

6.5.2 Command Definition DatabaseThe 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 will identify instrument critical commands in the command definition RDL by using the keyword CRITICAL..

6.6 MISSION SUPPORT DATA NAMING CONVENTIONS AND MOC PRODUCT SERVER

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

10/15/2008 5


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-8 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.

10/15/2008 6


Table 6-8. Naming Conventions and Product Server Locations

Directory name File name (1) Retention time

Comments

MOC to SOC Level 0 Data moc/lzp/yyyy_ddd apid_yyyy_ddd_nn.hkt

apid_yyyy_ddd_nn.hkt.xml7 days One subdirectory for a given DOY:

All APIDs .hkt and .xml files, all versions

FDS Short Term

moc/fds/shortterm See MOC/SOC ICD Table 5.1Example: ECLIPSE_yyyyddd.Snn

2 cycles (4): current & previous

One single directory for All sets of short term productsAll file versions

FDS Long Term moc/fds/longterm See MOC/SOC ICD Table 5.1Example: ECLIPSE_yyyyddd.Lnn

2 cycles (4): current & previous

One single directory for All sets of long term productsAll file versions

Command History

moc/cmdsums/rt1ormoc/cmdsums/rt2

yyyydddhhmm_yyyydddhhmm_nn_userfield.cmh 21 days One single directory for all files.yyyydddhhmm: start and stop times.userfield: sc, obs, hmi, aia or eve

Integrated Print moc/integratedprint loadtype_yyyyddd_hhmm_actnnnn_vnn.xmlorbatch_yyyyddd_hhmm_yyyyddd_hhmm_vnn.xml

The style sheet is sdp_report.xsl (3)

21 days Loadtype: kind of ATS load (e.g., eclipse, hmiroll, evefov, etc. “batch is for loads including several activitiesyyyyddd_hhmm: ATS load start and end times

MOC reports: Status

moc/reports/status mocstatus_yyyyddd_userfield_vnn.doc Variable,Minimum 30 days

yyyyddd: 1st day covered by reportuserfield: type of report, e.g. weekly, monthly, sim#1, etc.

MOC reports Minutes

moc/reports/minutes minutes_ yyyyddd_userfield_vnn.doc Variable,Minimum 30 days

yyyyddd: day the meeting occurreduserfield: type of meeting (e.g., weekly planning, quarterly, SOWG, etc

Science Data Accounting

moc/sdata_accounting account_yyyydddhhmm_userfield_vnn Variable yyyydddhhmm: start date of the reportuserfield: type of accounting report, (e.g. Instrument, daily, weekly or end date)

DDS Late file Notices

moc/dds_latefiles soc_yyyy_ddd_hh_mm_ss.erl

soc_yyyy_ddd_hh_mm_ss.fnl

Variable See DDS-to-SOC ICD section 4.1.7soc is aia, eve or hmi

Product Directory name File name Retention Comments

10/15/2008 7


timeSOC to MOC (2)SOC Reports status Instrument_userfield.ext Variable,

Minimum 30 days

Operational SOC reportsInstrument: aia, eve or hmiUserfield: free field describing file.ext: file extension, e.g. .doc, .xml, .dat …

GT CAL files(only available to AIA)

pztcal

postgtcal

PZTCAL_yyyyddd.Vnn

POST_GTCAL_yyyyddd.Vnn

Variable See section 3.3.2.2.1.

See section 3.3.2.2.2

(1) Italicized characters are variable. yyyy is the 4-digit year, ddd is the 3-digit day of yearnn is the 2 decimal digits used for file version number. The higher version number is the most recent and most appropriate to use.

(2) FOT will clean the “SOC to MOC” directories(3) The .xsl style sheet is required to properly view the integrated print is also in the same directory.(4) See Table 5-1 for the definition of the cycle for each product.

10/15/2008 8


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

10/15/2008 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 may be 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. All other connections will require waivers.

The SOC T&C segment is allowed access to the Network Time Protocol (NTP) server on the IONet as well as an IONet e-mail 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.

10/15/2008 2


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

10/15/2008 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 sequenceSBC Single Board ComputerS/C SpacecraftSDO Solar Dynamics ObservatorySDOGS SDO Ground StationSDP Science Data Processing

10/15/2008 1


SFDU Standard formatted data unitSOC Science Operations CenterSSR 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

10/15/2008 2


APPENDIX B. AIA INPUT FILES FOR GT CALIBRATION MANEUVERS

B.1 Format for GT Calibration Maneuver PZT Gains AIA Input File

; GT Calibration Maneuver PZT Gains AIA Input File Template; File Name: PZTCAL_2008210.V00 ; Generated By: Paul Boerner ; Planned maneuver date: 28 July 2008

; Commands in this file support the monthly Guide Telescope calibration maneuver.; They are provided by the AIA team at least 5 business days before the maneuver.

; AIA must fill-in:; the GT Error Gain values as in /AIA_IS_ERRGAIN DATA = "ISS=1 AXIS=Y GAIN=123"; the PZT GAIN values as in /AIA_IS_PZT_GAIN DATA = "ISS=1 PZT=A GAIN=123"

; General Notes: ; The file is an ASCII text file; Filename is PZTCAL_yyyydoy.Vnn where yyyydoy is the date of the calibration maneuver and Vnn is the version number, starting with V00.; Blank lines are ignored and can be used for readability; Lines starting with a semicolon are treated as comments; All other lines starting with the keywords ; WAIT, SetPredictedError, EndSetPredictedError, RestoreError,; EndRestoreError, or SetPZT should not be modified

;############ ERROR GAINS (PREDICTED) #######################; Set Error gains for predicted seasonal values at beginning of PZT CALSetPredictedError Error gains Predicted/AIA_IS_ERRGAIN DATA = "ISS=1 AXIS=Y GAIN=32"/AIA_IS_ERRGAIN DATA = "ISS=1 AXIS=Z GAIN=16"/AIA_IS_ERRGAIN DATA = "ISS=2 AXIS=Y GAIN=2"/AIA_IS_ERRGAIN DATA = "ISS=2 AXIS=Z GAIN=1"WAIT 1/AIA_IS_ERRGAIN DATA = "ISS=3 AXIS=Y GAIN=0"/AIA_IS_ERRGAIN DATA = "ISS=3 AXIS=Z GAIN=-1"/AIA_IS_ERRGAIN DATA = "ISS=4 AXIS=Y GAIN=-8"/AIA_IS_ERRGAIN DATA = "ISS=4 AXIS=Z GAIN=-127"EndSetPredictedError Error gains Predicted;#########################################################

;############ ERROR GAINS (NOMINAL) ######################; Restore Error gains at end of PZT CAL;RestoreError Error gains Nominal/AIA_IS_ERRGAIN DATA = "ISS=1 AXIS=Y GAIN=-16"/AIA_IS_ERRGAIN DATA = "ISS=1 AXIS=Z GAIN=-4"/AIA_IS_ERRGAIN DATA = "ISS=2 AXIS=Y GAIN=-2"/AIA_IS_ERRGAIN DATA = "ISS=2 AXIS=Z GAIN=-1"WAIT 1/AIA_IS_ERRGAIN DATA = "ISS=3 AXIS=Y GAIN=0"/AIA_IS_ERRGAIN DATA = "ISS=3 AXIS=Z GAIN=1"

10/15/2008 1


/AIA_IS_ERRGAIN DATA = "ISS=4 AXIS=Y GAIN=4"/AIA_IS_ERRGAIN DATA = "ISS=4 AXIS=Z GAIN=65"EndRestoreError Error gains Nominal;#########################################################

; Repeat the following sequence at "PZT steps" at +10, 0, and -10 arcseconds on Y and Z axes.;############ PZT GAINS (GROUP 1) #################; Command PZT gains to 1st set of values and dwell for ~one minuteSetPZT PZT Gains/AIA_IS_PZT_GAIN DATA = "ISS=1 PZT=A GAIN=123"/AIA_IS_PZT_GAIN DATA = "ISS=1 PZT=B GAIN=-128"/AIA_IS_PZT_GAIN DATA = "ISS=1 PZT=C GAIN=-128"WAIT 1/AIA_IS_PZT_GAIN DATA = "ISS=2 PZT=A GAIN=123"/AIA_IS_PZT_GAIN DATA = "ISS=2 PZT=B GAIN=0"/AIA_IS_PZT_GAIN DATA = "ISS=2 PZT=C GAIN=0"WAIT 1/AIA_IS_PZT_GAIN DATA = "ISS=3 PZT=A GAIN=128"/AIA_IS_PZT_GAIN DATA = "ISS=3 PZT=B GAIN=0"/AIA_IS_PZT_GAIN DATA = "ISS=3 PZT=C GAIN=0"WAIT 1/AIA_IS_PZT_GAIN DATA = "ISS=4 PZT=A GAIN=123"/AIA_IS_PZT_GAIN DATA = "ISS=4 PZT=B GAIN=0"/AIA_IS_PZT_GAIN DATA = "ISS=4 PZT=C GAIN=0"WAIT 57

;############ PZT GAINS (GROUP 2) #################; Command PZT gains to 2nd set of values and dwell for ~one minute/AIA_IS_PZT_GAIN DATA = "ISS=1 PZT=A GAIN=0"/AIA_IS_PZT_GAIN DATA = "ISS=1 PZT=B GAIN=127"/AIA_IS_PZT_GAIN DATA = "ISS=1 PZT=C GAIN=0"WAIT 1/AIA_IS_PZT_GAIN DATA = "ISS=2 PZT=A GAIN=0"/AIA_IS_PZT_GAIN DATA = "ISS=2 PZT=B GAIN=123"/AIA_IS_PZT_GAIN DATA = "ISS=2 PZT=C GAIN=0"WAIT 1/AIA_IS_PZT_GAIN DATA = "ISS=3 PZT=A GAIN=-127"/AIA_IS_PZT_GAIN DATA = "ISS=3 PZT=B GAIN=123"/AIA_IS_PZT_GAIN DATA = "ISS=3 PZT=C GAIN=-127"WAIT 1/AIA_IS_PZT_GAIN DATA = "ISS=4 PZT=A GAIN=0"/AIA_IS_PZT_GAIN DATA = "ISS=4 PZT=B GAIN=123"/AIA_IS_PZT_GAIN DATA = "ISS=4 PZT=C GAIN=0"WAIT 57

;############ PZT GAINS (GROUP 3) #################; Command PZT gains to 3rd set of values and dwell for ~one minute/AIA_IS_PZT_GAIN DATA = "ISS=1 PZT=A GAIN=0"/AIA_IS_PZT_GAIN DATA = "ISS=1 PZT=B GAIN=0"/AIA_IS_PZT_GAIN DATA = "ISS=1 PZT=C GAIN=123"WAIT 1/AIA_IS_PZT_GAIN DATA = "ISS=2 PZT=A GAIN=0"/AIA_IS_PZT_GAIN DATA = "ISS=2 PZT=B GAIN=0"/AIA_IS_PZT_GAIN DATA = "ISS=2 PZT=C GAIN=123"WAIT 1/AIA_IS_PZT_GAIN DATA = "ISS=3 PZT=A GAIN=0"/AIA_IS_PZT_GAIN DATA = "ISS=3 PZT=B GAIN=-127"

10/15/2008 2


/AIA_IS_PZT_GAIN DATA = "ISS=3 PZT=C GAIN=-128"WAIT 1/AIA_IS_PZT_GAIN DATA = "ISS=4 PZT=A GAIN=127"/AIA_IS_PZT_GAIN DATA = "ISS=4 PZT=B GAIN=0"/AIA_IS_PZT_GAIN DATA = "ISS=4 PZT=C GAIN=128"WAIT 57

; ############ PZT GAINS (GROUP 4) #######################; Command PZT gains to 4th set of values and dwell for ~one minute/AIA_IS_PZT_GAIN DATA = "ISS=1 PZT=A GAIN=-2"/AIA_IS_PZT_GAIN DATA = "ISS=1 PZT=B GAIN=-2"/AIA_IS_PZT_GAIN DATA = "ISS=1 PZT=C GAIN=-2"WAIT 1/AIA_IS_PZT_GAIN DATA = "ISS=2 PZT=A GAIN=4"/AIA_IS_PZT_GAIN DATA = "ISS=2 PZT=B GAIN=4"/AIA_IS_PZT_GAIN DATA = "ISS=2 PZT=C GAIN=4"WAIT 1/AIA_IS_PZT_GAIN DATA = "ISS=3 PZT=A GAIN=-8"/AIA_IS_PZT_GAIN DATA = "ISS=3 PZT=B GAIN=-8"/AIA_IS_PZT_GAIN DATA = "ISS=3 PZT=C GAIN=-8"WAIT 1/AIA_IS_PZT_GAIN DATA = "ISS=4 PZT=A GAIN=16"/AIA_IS_PZT_GAIN DATA = "ISS=4 PZT=B GAIN=16"/AIA_IS_PZT_GAIN DATA = "ISS=4 PZT=C GAIN=16"WAIT 57

; ############ PZT GAINS (GROUP 5) #######################; Command PZT gains to 5th set of values and dwell for ~one minute/AIA_IS_PZT_GAIN DATA = "ISS=1 PZT=A GAIN=32"/AIA_IS_PZT_GAIN DATA = "ISS=1 PZT=B GAIN=32"/AIA_IS_PZT_GAIN DATA = "ISS=1 PZT=C GAIN=32"WAIT 1/AIA_IS_PZT_GAIN DATA = "ISS=2 PZT=A GAIN=-64"/AIA_IS_PZT_GAIN DATA = "ISS=2 PZT=B GAIN=-64"/AIA_IS_PZT_GAIN DATA = "ISS=2 PZT=C GAIN=-64"WAIT 1/AIA_IS_PZT_GAIN DATA = "ISS=3 PZT=A GAIN=65"/AIA_IS_PZT_GAIN DATA = "ISS=3 PZT=B GAIN=65"/AIA_IS_PZT_GAIN DATA = "ISS=3 PZT=C GAIN=65”WAIT 1/AIA_IS_PZT_GAIN DATA = "ISS=4 PZT=A GAIN=-65”/AIA_IS_PZT_GAIN DATA = "ISS=4 PZT=B GAIN=-65”/AIA_IS_PZT_GAIN DATA = "ISS=4 PZT=C GAIN=-65”WAIT 57

;############ PZT GAINS (NOMINAL) ###########; Return to nominal PZT gains (No dwell, No exposure)/AIA_IS_PZT_GAIN DATA = "ISS=1 PZT=A GAIN=-1"/AIA_IS_PZT_GAIN DATA = "ISS=1 PZT=B GAIN=0"/AIA_IS_PZT_GAIN DATA = "ISS=1 PZT=C GAIN=1"WAIT 1/AIA_IS_PZT_GAIN DATA = "ISS=2 PZT=A GAIN=1"/AIA_IS_PZT_GAIN DATA = "ISS=2 PZT=B GAIN=0"/AIA_IS_PZT_GAIN DATA = "ISS=2 PZT=C GAIN=-1"WAIT 1/AIA_IS_PZT_GAIN DATA = "ISS=3 PZT=A GAIN=-1"/AIA_IS_PZT_GAIN DATA = "ISS=3 PZT=B GAIN=1"/AIA_IS_PZT_GAIN DATA = "ISS=3 PZT=C GAIN=0"WAIT 1

10/15/2008 3


/AIA_IS_PZT_GAIN DATA = "ISS=4 PZT=A GAIN=0"/AIA_IS_PZT_GAIN DATA = "ISS=4 PZT=B GAIN=-1"/AIA_IS_PZT_GAIN DATA = "ISS=4 PZT=C GAIN=1";#########################################################

10/15/2008 4


B.2 Format for Post GT-Calibration AIA Input File

File name POST_GTCAL_yyyydoy_Vnn

; SBC Table 77, ACS GT Processing Parameters, AIA INPUT FILE TEMPLATE; File name: ; Generated By: ; Date of GT calibration maneuver: ; Date updates must take effect:

; Parameters included in this file represent the entries in “(SBC Table 77), Guide ; Telescope Processing Parameters”, that will be updated as a result of a GT maneuver.; AIA provides these updates to the FOT within 5 business days after the maneuver.; General Notes: ; The file is an ASCII text file; Blank lines are ignored and can be used for readability; Lines starting with ; are treated as comments; Filename is POST_GTCAL_yyyydoy.Vnn ; Where yyyydoy is the date of the calibration maneuver; and Vnn is the version number, starting with V00

; Offset from Solar Reference Boresight to GT frame (in arcseconds, default=0)ACS_GT_PARM.GTU[1].BIAS_SRBTOGT[1] = ACS_GT_PARM.GTU[1].BIAS_SRBTOGT[2] =

ACS_GT_PARM.GTU[2].BIAS_SRBTOGT[1] = ACS_GT_PARM.GTU[2].BIAS_SRBTOGT[2] =



; Limits for linear range of GT error signals (in arcseconds, default=95)ACS_GT_PARM.GTU[1].LIM_GTLINEAR[1] = ACS_GT_PARM.GTU[1].LIM_GTLINEAR[2] =

ACS_GT_PARM.GTU[2].LIM_GTLINEAR[1] = ACS_GT_PARM.GTU[2].LIM_GTLINEAR[2] =



10/15/2008 5

NEXT GENERATION SPACE TELESCOPE - Stanford...

Documents

Transcript of NEXT GENERATION SPACE TELESCOPE - Stanford...