SDO Database Format Control Document...

Solar Dynamics Observatory (SDO) Project

Database Format Control Document

(DFCD)464-GS-PLAN-0042

Revision A

Effective Date: 03/23/2006

Expiration Date: 03/23/2011

Prepared By: Maureen Suckling/Code 452

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

Goddard Space Flight CenterGreenbelt, Maryland

National Aeronautics andSpace Administration

http://sdoweb.gsfc.nasa.gov/

464-GS-PLAN-0042Revision A

CM FOREWORD

This document is a Solar Dynamics Observatory Project controlled document. Changes to this document require prior approval of 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 change.

Questions or comments concerning this document should be addressed to:

SDO Configuration Management OfficeMail Stop 464Goddard Space Flight Center (GSFC)Greenbelt, Maryland 20771

March 23, 2006 ii


Reviewed ByHollys AllenDave AmasonTom AndersonTom BialasEJ BickleyBob CalvoHarry CulverBob DeFazioPaula EversonCindy FirmanMike GarnerPete GonzalesAmri Hernandez-PelleDennis HewittSteve HimesRich HollenhorstKevin HughesTom KenneyDenney KeysMichelle LacombeEliane LarduinatStephen LeakeMaria LechaLeo McConvilleMarco MidonWendy MorgensternSon NgoDaniel NguyenRay PagesDean PesnellBill PotterMike PowersBrent RobertsonJohn RuffaChad SaloBrett SapperJoe SchepisMichael ScottFrank ScovilleChris SilvaVijayasree SontiScott StarinHun TannBarbara ThompsonJohn VanBlarcomMark WaltersDave WardJim WiedmanCraig WeikelMike Xapsos

March 23, 2006 iii


Solar Dynamics Observatory Project Database Format Control Document

DOCUMENT CHANGE RECORDREV/ VER

LEVEL DESCRIPTION OF CHANGEAPPROVED

BYDATE

APPROVED

-

A

Baseline release of document per the approval of SDO-CCR-0298

Updated following approval of SDO-CCR-0505

R. LILLY

R. Lilly

06/20/05

03/23/06

March 23, 2006 iv


Table of Contents1.0 Introduction............................................................................................................1

1.1 Purpose.............................................................................................................11.2 Scope.................................................................................................................11.3 References........................................................................................................31.4 Telemetry and Command Database Abstract....................................................31.5 Instrument Database Responsibilities................................................................3

2.0 T&C Systems and Project Database Development..............................................62.1 Facilities Using a T&C System...........................................................................62.2 Project Database Development.........................................................................7

3.0 ASIST RDL Guidelines..........................................................................................83.1 ASIST RDL File Naming Convention.................................................................83.2 Flight Software System Table RDL Files.........................................................103.3 RDL File Preamble..........................................................................................10

4.0 Telemetry Mnemonic Naming Convention..........................................................114.1 Observatory Telemetry Mnemonics.................................................................114.2 SDO GSE and Ground System Telemetry Mnemonics...................................124.3 Pseudo Telemetry Mnemonics........................................................................134.4 Flight Software System Table Mnemonics.......................................................13

5.0 Command Mnemonic Naming Convention..........................................................145.1 Observatory Command Mnemonics................................................................145.2 GSE and Ground System Directive Mnemonics..............................................15

6.0 ASIST Telemetry Display Pages.........................................................................177.0 STOL Procedures................................................................................................18

7.1 STOL Procedure Development Philosophy.....................................................187.2 STOL Procedure Development Guidelines......................................................187.3 STOL Procedure Naming Convention.............................................................197.4 STOL Procedure Preamble..............................................................................21

8.0 Configuration Management and Distribution of the Project Database.................228.1 Project Database Lifecycle..............................................................................22

8.1.1 Component Development.........................................................................228.1.2 Observatory I&T........................................................................................268.1.3 Flight Operations......................................................................................28

8.2 Project Database CM and Distribution Process...............................................308.2.1 MOC File Transfer Gateway.....................................................................328.2.2 File Transfer Gateway Implementation.....................................................328.2.3 File Transfer Gateway Directories............................................................338.2.4 Project Database Validation.....................................................................378.2.5 Project Database Central Repository.......................................................37

APPENDIX A: Recommended Abbreviations and Acronyms for RDL, Telemetry, and Command Names..........................................................................................................39APPENDIX B: Telemetry RDL Preamble......................................................................46APPENDIX C: Command RDL Preamble.....................................................................47APPENDIX D: FSW System Table RDL File Preamble................................................48APPENDIX E: STOL Procedure Example and Guidelines............................................49APPENDIX F: Contact List for Component Development.............................................55

March 23, 2006 v


APPENDIX G: Contact List for Observatory I&T...........................................................56APPENDIX H: Database Release Milestones................................................................57APPENDIX I: ASIST Database Directory Description...................................................58APPENDIX J: Acronyms...............................................................................................59

March 23, 2006 vi


List of FiguresFigure 8-1 Initial Project Database Build.................................................................................23Figure 8-2 Database Flow during Observatory I&T...............................................................27Figure 8-3 Database Flow during Flight Operations.............................................................29Figure 8-4 Project Database CM and Distribution.................................................................32Figure 8-5 File Transfer Gateway Login..................................................................................33Figure 8-6 File Transfer Gateway Home Directory................................................................34Figure 8-7 Database Distribution Directory Structure...........................................................36

List of Tables

Table 3-1 RDL File Name Values...............................................................................................9Table 4-1 Observatory Telemetry Mnemonic Name Values................................................11Table 4-2 GSE Telemetry Mnemonic Name Values.............................................................13Table 5-1 Observatory Command Mnemonic Name Values...............................................14Table 5-2 Directive Mnemonic Name Values.........................................................................16Table 7-1 Procedure Field Naming Convention Guidelines.................................................19Table 8-1 Telemetry and Command Database Files............................................................24

List of TBDs/TBRs

Item No. Location Summary Ind./Org. Due

Date

March 23, 2006 vii

1.0 Introduction

This Database Format Control Document (DFCD) defines the specific requirements for creation and maintenance of the ground system Project Database for the Solar Dynamics Observatory (SDO) mission.

1.1 Purpose

The purpose of this DFCD is to provide the basic rules of convention, construction, and style for the SDO Project Database. Additionally, it defines the rules of exchange of the Project Database between Telemetry and Command (T&C) systems and the Project Database repository at GSFC.

The construction of the Project Database begins during the development phase of the SDO instruments and spacecraft hardware and software components. The Project database continues to mature throughout Observatory Integration and Test (I&T) and ultimately becomes the database used during Flight Operations.

The T&C system used for development, I&T, and Flight Operations in the Mission Operations Center (MOC) is the Advanced Spacecraft Integration and System Test (ASIST). Each Science Operations Center (SOC) uses its own T&C system, which interfaces with the MOC ASIST T&C system. Therefore, portions of this document will extend to the Project Database elements that reside in the SOC T&C systems, including the Extreme Ultraviolet Variability Experiment (EVE), Atmospheric Imaging Assembly (AIA), and Helioseismic and Magnetic Imager (HMI). The extent to which this DFCD applies to the SOCs is summarized in Section 1.5.

Also included in this document are guidelines for Spacecraft Test and Operations Language (STOL) procedure development, guidelines for telemetry display page development, and the Project Database Configuration Management (CM) process that will be applied at the various stages of mission development.

1.2 Scope

This DFCD is intended for use by anyone directly using or interfacing with the SDO MOC T&C System and is of particular use during the early stages of the Project Database creation.

The scope of this document extends to the databases used by external T&C systems that interface with the MOC T&C system. This DFCD specifies conventions that apply to elements of these external T&C databases that must be compatible and exchangeable with the Project Database. The SOCs’ remote T&C systems are important examples of this extension in scope. All subsets of the SOCs local databases that will be provided for use by the MOC T&C system as well as all subsets of the

Project Database that will be provided to the SOCs for use by their own T&C systems will adhere to the conventions defined in this document.

In addition to supporting the MOC, ASIST will be the central T&C system supporting pre-launch spacecraft development and I&T activities at GSFC in the Flight Software Development Lab and the Attitude Control Electronics (ACE), Power System Electronics (PSE), Gimbal Control Electronics (GCE), and Command & Data Handling (C&DH) hardware component development labs. The ASIST T&C system is also integrated with the Spacecraft Simulator (SSIM) that is provided to the instrument development labs.

Project Database elements covered in this document include the following:

a) Observatory Telemetry Database – Includes all spacecraft housekeeping telemetry definitions and a subset of the instrument housekeeping telemetry.NOTE: Instrument science telemetry format is outside the scope of this document.

b) Ground Support Equipment (GSE) Status Database – Includes definition of status telemetry for all I&T Electrical Ground Support Equipment (EGSE), Instrument Ground Support Equipment (IGSE), and Ground System elements such as the SDO Ground Station (SDOGS), the Data Distribution System (DDS), and the DDS and SDOGS Integrated Manager (DSIM).

c) Pseudo Telemetry Database – All pseudo-telemetry for spacecraft, GSE, Ground System, and a subset for the instruments. Pseudo-telemetry includes data points that are computed, constructed, or otherwise derived from one or more telemetry items.

d) Observatory Command Database – Includes all spacecraft command definitions and a subset of the instrument command databases.

e) GSE and Ground System Directive Database - Includes definition of directives to control I&T EGSE, IGSE, and all ground system components, including the MOC, SDOGS, and DDS, that can receive directives from ASIST.

f) Procedure Database – Includes STOL procedures that contain a sequence of steps to command, configure, control, test and/or monitor the Observatory, I&T GSE, and ground system components.

g) Flight Software (FSW) System Table Definitions - Includes definitions for the real-time interpretation and display of system tables used by the spacecraft flight software and downlinked in the spacecraft housekeeping telemetry stream.

h) ASIST Display Page Database – Includes page displays used to evaluate and monitor the Observatory, I&T GSE, and Ground System components.

1.3 References

The following documents are applicable to this DFCD and changes in these documents take precedence over this document:

1. SDO Detailed Mission Requirements (DMR) Document, 464-GS-REQ-005, GSFC

2. SDO CCSDS Implementation Document, 464-SYS-SPEC-0033

3. Interface Control Document (ICD) Between the SDO Mission Operations Center (MOC) and the Science Operations Centers (SOC), 464-GS-ICD-0001

4. SDO Project CM Procedures Document, 464-PROJ-PROC-0010

5. SDO Project Problem Reporting (PR) Procedure, 464-SA-PROC-0029.

The following document is for reference only, providing additional useful information related to this DFCD:

6. ASIST Workstation Users Guide, GSFC, Release 9.4 or higher (GSFC onsite access available online at “http://asist.gsfc.nasa.gov”)

1.4 Telemetry and Command Database Abstract

During the SDO component and instrument development effort and prior to the start of the SDO Observatory I&T activity, it is essential that the Observatory Command Database and Observatory Telemetry Database be constructed. Each telemetry and command definition includes a mnemonic. A unique alphanumeric mnemonic is given to each command function and each telemetry item. Each command mnemonic contains the information needed to generate the binary commands acceptable by the spacecraft. Each telemetry mnemonic contains the information needed to interpret the binary packets received from the spacecraft.

The IGSE (including the instrument T&C systems) may have T&C systems that are different from ASIST, and it may not be possible to have "ASIST-like" mnemonics within an IGSE. However, the goal is to establish mnemonics that are compliant with this DFCD where practical. In all cases where adherence to this DFCD is not possible, a clear mechanism for mnemonic translation will be defined.

1.5 Instrument Database Responsibilities

Section 6.5 of the MOC-to-SOC ICD, Reference 3, defines the high level agreements for the exchange of database files between the MOC and the SOCs. These agreements can be summarized as follows:

The SOCs define the instrument commands that may be used by the MOC and I&T Control Center in real-time command procedures and spacecraft stored command sequences (absolute time sequences and relative time sequences).

The SOCs define the instrument housekeeping telemetry packets containing data points that the MOC and I&T Control Center may monitor on behalf of the instrument teams.

The MOC provides each SOC the definition of all spacecraft telemetry packets containing data points that the SOC may want to monitor

All telemetry and command definition exchanges will be in ASIST Record Definition Language (RDL) format.

All Instrument STOL procedures resident in the MOC will follow the STOL conventions defined in this DFCD.

The portions of this document that are applicable to the instruments include:

1) Section 2.0 T&C Systems and Project Database Development - describes the T&C systems being used and gives an overview the Project Database development

2) Section 3.0 ASIST RDL Guidelines- This applies to the subset of the command and telemetry databases that is exchanged between the SOCs and the MOC.

3) Sections 4.0 Telemetry Mnemonic Naming Convention and Section 5.0 CommandMnemonic Naming Convention - These sections defines the rules for generating mnemonics. The EVE T&C system, the Operations and Science Instrument Support – Command and Control (OASIS-CC), does not accommodate the mnemonic naming convention defined in this DFCD. The EVE instrument team shall provide the translation from the OASIS-CC telemetry and command mnemonics to the ASIST command mnemonics as needed for the subset of the EVE T&C database provided to the Project Database. The in-house T&C system used by HMI and AIA accommodates the mnemonic naming conventions defined in this DFCD.

4) Section 6.0 ASIST Telemetry Display Pages - The instrument telemetry data points that are to be viewed in the MOC will adhere to the guidelines laid out for telemetry display pages. The Flight Operations Team (FOT) will work with the instrument teams to develop all required instrument display pages for the MOC.

5) Section 7.0 STOL Procedures - This section provides guidelines for developing STOL procedures. All instrument STOL procedures residing on an ASIST T&C system in the MOC or I&T Control Center are required to follow the procedure template defined in this DFCD, including the defined preamble and naming convention

6) Section 8.0 Database CM - This section describes the CM process applicable to the Project Database. This CM process also applies to all instrument database information that is incorporated into the Project Database. It is not the intent to impose any specific CM policy or procedure on the instrument teams with regard to

their systems. However, the instrument teams are responsible for implementing an appropriate CM process, which incorporates the essential elements of configuration control and assures that the accuracy, availability, and overall integrity of the T&C database are preserved.

2.0 T&C Systems and Project Database Development

This section describes the various facilities developing and using the Project Database as well as a description of the Project Database development.

2.1 Facilities Using a T&C System

T&C systems will be used during the multiple mission phases and in multiple facilities. The following list details the T&C systems for each of the mission phases.

1) Component Development: Flight Software Development Lab, GSFC (ASIST) ACE, C&DH, GCE and PSE Hardware labs, GSFC (ASIST) HMI Development Lab, Lockheed-Martin Solar and Astrophysics Laboratory

(LMSAL) (HMI/AIA T&C System) AIA Development Lab, LMSAL (HMI/AIA T&C System) EVE Development Lab, Laboratory For Atmospheric and Space Physics (LASP)

(OASIS-CC)Note: each Instrument Development Lab includes SSIM (ASIST)

2) Integration and Test: SDO I&T Control Center, GSFC Bldg-7 (ASIST) AIA I&T System, I&T Control Center, GSFC (HMI/AIA T&C System) HMI I&T System, I&T Control Center, GSFC (HMI/AIA T&C System) EVE I&T System, I&T Control Center, GSFC (OASIS-CC) SDO MOC (GSFC Bldg-14) (ASIST) DDS/ DSIM Development Lab, GSFC Bldg-11 (ASIST) FSW Development Lab (including FlatSat), GSFC Bldg-1 (ASIST)

3) Launch Site Operations: All T&C systems from the I&T Control Center at GSFC will be relocated to

Kennedy Space Center and Cape Canaveral Air Station (KSC/CCAS) to support launch site operations

4) Flight Operations: SDO MOC, GSFC Bldg-14 (ASIST) AIA SOC, LMSAL (HMI/AIA T&C System) HMI SOC, LMSAL (HMI/AIA T&C System) EVE SOC, LASP (OASIS-CC) SDO "Mini-MOC", White Sands Complex (WSC) (ASIST) AIA T&C System, GSFC MOC Science Operations Support (SOS) room

(HMI/AIA T&C System) HMI T&C System, GSFC MOC SOS (HMI/AIA T&C System) EVE T&C System, GSFC MOC SOS (OASIS-CC)

FSW Maintenance Lab (including FlatSat), GSFC Bldg-1 (ASIST)Note: each SOC includes SSIM (ASIST)

2.2 Project Database Development

The Project Database will evolve starting initially at the component level in the FSW and hardware development labs, through observatory-level tests, then maturing to its final form to support Flight Operations.

When a spacecraft hardware or software component is delivered for observatory integration, its associated database and procedures are also delivered and added to the master Project Database. As the spacecraft evolves, so does the Project Database. Similarly, as instruments and their GSE are brought to GSFC, their associated T&C systems that include their database and procedures will accompany them. The instrument T&C system and supporting GSE are maintained independent from the Observatory T&C system. However, for critical commanding and health and safety purposes, some subset of the instrument command and telemetry database is required to be incorporated and maintained within the ASIST T&C system. Specific identification of the instrument T&C database subset is coordinated between the Project Database Administrator (DBA) and each instrument’s on-site GSFC Instrument Manager. Since the database and procedures are constantly being developed, updated and/or are running on numerous workstations in numerous locations for both the spacecraft and instruments, careful database coordination is crucial.

Configuration control of the database at the various site locations is defined and managed by the Product Development Leads (PDLs) or their designate. Database configuration in a lab or facility would be consistent with the function of the lab or facility, the integration level of the component or observatory, and the mission phase. Project Database CM is discussed in Section 8 of this document.

3.0 ASIST RDL Guidelines

Observatory telemetry and ground support equipment status information are received by the ASIST system as CCSDS packets encapsulated into Standard Formatted Data Units (SFDU’s). These packets are processed to produce useful information utilizing the telemetry packet definitions in the Project Database. The detailed composition of a telemetry packet is defined in ASIST using RDL, a database structure language. A unique Application ID (APID) defines each packet. The packet definition contains all the information necessary for the dissemination of the packet into individual telemetry parameters and conversion into useable information.

All observatory commands are formatted into CCSDS command packets before uplink to the spacecraft. ASIST uses the command definitions provided in RDL files to translate a user command request into its binary packet equivalent.

Chapter 4 of the ASIST User’s Guide discusses Telemetry RDL structures and applicable database tools. Chapter 5 of the ASIST User’s Guide discusses Command RDL structures and applicable database tools. It is recommended that database developers and users become familiar with these chapters.

The following section discusses acceptable naming conventions for RDL files and telemetry and command mnemonics.

3.1 ASIST RDL File Naming Convention

Each telemetry, command, and GSE APID packet is defined in one and only one RDL file. This is to support configuration management of APID definitions during the development process. (Note that one RDL file may contain multiple APID’s.) The following RDL file naming convention must be used for all RDL files.

RDL file names shall be all lower case characters. Table 3-1 lists acceptable values for each portion of the file name. Approval by the Project DBA is required for all RDL file names using values not included in this table.

Format: mission id_ type_subsys.rdlWhere:

mission id: 3 characters identifying the mission

type: 3 to 4 characters identifying the type of RDL file as defined in Table 3-1

subsys: 3 to 6 characters identifying the data source, as defined in Table 3-1

Table 3-1 RDL File Name Values

Field Name Value

mission id sdo

type

tlm = observatory telemetrycmd = observatory commandsptlm = pseudo telemetrygcmd = gse or ground system directivesgtlm = gse or ground system telemetryttlm = flight software table definitions

subsys

Flight Subsystems:pse[a/b] = power system electronics (side a or b)gce[a/b] = gimbal control electronics (side a or b)ace[a/b] = attitude control electronics (side a or b)scom[a/b] = s-band comm card (side a or b)kcom[a/b] = k-band comm card (side a or b)acs = attitude control system FSW on the SBCsbc = single board computeraia = atmospheric imaging assemblyhmi = helioseismic and magnetic imagereve = extreme ultraviolet variability experimentst[1/2] = star tracker 1 or 2dss = digital sun sensor

GSE and Ground Subsystems:gds = goddard dynamic simulatorssim = spacecraft simulatorbsim = battery simulatorsas = solar array simulatorumb = umbilicalsdogs = SDO ground stationdds = data distribution systemdsim = DDS/SDOGS integrated managermoc = Mission Operations Center

RDL File Name Example: sdo_tlm_psea.rdl

The above example is interpreted as:

Solar Dynamics Observatory mission, RDL telemetry data, Power System Electronics side-a processor definitions

3.2 Flight Software System Table RDL Files

The FSW System Table RDL files include definitions for the real-time identification, interpretation, and display of system tables used by the spacecraft flight software through the STOL and SAMMI display software interface with the ASIST Current Value Table (CVT). The naming convention for FSW system table RDL definition files is the ASIST RDL file naming convention defined in Section 3.1. These RDL definitions represent tables that are selectively commanded for downlink in the spacecraft housekeeping telemetry stream (as asynchronous data packets). The ASIST system generates dump transfer format (DTF) files in the working account’s image directory. The FSW System Table database provides decoding of the DTF data once the DTF file is transferred to the ASIST machine’s Current Value Table. The transfer of the DTF data to the Current Value Table is local to each individual ASIST system.

3.3 RDL File Preamble

The Telemetry RDL file preamble consists of several free-text comment records located at the beginning of the RDL file. The preamble provides additional packet documentation and historical information, which are not evident from the telemetry packet definition itself. See Appendix B for the format of the telemetry RDL preamble.

The Command RDL file preamble consists of several free-text comment records located at the beginning of the RDL file. The preamble provides additional packet documentation and historical information, which are not evident from the command packet definition itself. See Appendix C for the command RDL preamble format.

Each FSW System Table RDL file requires a file preamble. The preamble consists of several free-text comment records located at the beginning of the file. See Appendix D for definition of the FSW System Table telemetry RDL preamble.

4.0 Telemetry Mnemonic Naming Convention

ASIST telemetry mnemonics can be no more than 32 characters in length. Chapter 4 of the ASIST Users Guide (Reference 6) provides information on telemetry RDL structures and applicable database tools. Chapter 8 of the ASIST Users Guide describes how telemetry is handled and processed by an ASIST workstation.

SDO telemetry mnemonics are constructed as underscore-delimited fields.

4.1 Observatory Telemetry Mnemonics

The naming convention for observatory telemetry mnemonics is as follows:

Format: source_subsys/component_description_value/stateWhere:

source: required field, 2 to 6 characters, indicates the source of the telemetry. For observatory telemetry, the source is typically defined as a node on the 1553 bus.

subsys/component: required field, 2 to 6 characters, indicates the subsystem, module, board, circuit, or component where the telemetry value was generated.

description: required field, variable length, describes the function of the telemetry point.

value/state: optional field, 1 to 4 characters. If used, indicates the functional element value or state. This field and the leading underscore may be omitted if the telemetry point is adequately identified in the description field.

Table 4-2 lists recommended values for each field.

Table 4-2 Observatory Telemetry Mnemonic Name Values

Field Name Valuesource pse[a/b] = power system electronics (side a or b)

gce[a/b] = gimbal control electronics (side a or b)ace[a/b] = attitude control electronics (side a or b)scom[a/b] = s-band comm card (side a or b)kcom[a/b] = k-band comm card (side a or b)acs = attitude control system FSW on the SBCsbc = single board computeraia = atmospheric imaging assemblyhmi = helioseismic and magnetic imager

Field Name Valueeve = extreme ultraviolet variability experimentst[1/2] = star tracker 1 or 2dss = digital sun sensor

subsys or component Varies by source, see Appendix A for common abbreviations

description User defined, see Appendix A for common abbreviationsvalue or state See Appendix A for common abbreviations.

Observatory telemetry mnemonic example: acea_rwa1_sp_rpm


Attitude Control Electronics side a reaction wheel assembly 1 speed reading in revolutions per minute.

4.2 SDO GSE and Ground System Telemetry Mnemonics

A range of APIDs have been assigned to support GSE and ground system packet development. The specific APID allocation is documented in Reference 2, the SDO CCSDS Implementation Document.

The naming convention for GSE and Ground System mnemonics is as follows:

Format: source_unit/component_description_value/stateWhere:

source: required field, 2 to 5 characters, indicates the source of the GSE or Ground System status telemetry.

unit/component: required field, 2 to 6 characters, indicates the stimulus, measurement device, module, board, circuit or component within a system or rack of equipment from where the value was generated.

description: required field, variable length, describes the function of the telemetry point.

value/state: optional field, 1 to 4 characters, indicates the functional element value or state. This field and the leading underscore may be omitted if the telemetry point is adequately identified in the description field.

Table 4-3 lists acceptable values for each field.

Table 4-3 GSE Telemetry Mnemonic Name Values

Field Name Value

source

gds = goddard dynamic simulatorssim = spacecraft simulatorbsim = battery simulatorsas = solar array simulatorumb = umbilicalgs = SDO ground stationdds = data distribution systemdsm = DDS/SDOGS integrated manager

unit or component

Can vary by source, see Appendix A for common abbreviations

description User defined, see Appendix A for common abbreviations value or state See Appendix A for common abbreviations.

GSE telemetry mnemonic example: dd_qcp1_tm_s


DDS Quality Compare Processor #1 telemetry status

4.3 Pseudo Telemetry Mnemonics

Pseudo telemetry is used to provide further manipulation of database items, such as logical expressions, concatenation, scientific expressions, etc. The combination of two or more mnemonics to perform an engineering calculation is a typical usage. The naming convention for pseudo telemetry is identical to the observatory telemetry mnemonic naming convention.

Pseudo telemetry for each major subsystem of SDO is delivered with the database with a unique APID. The range for subsystem pseudo telemetry APIDs is listed in Reference 2, the SDO CCSDS Implementation Document.

4.4 Flight Software System Table Mnemonics

FSW System Table RDL files consist of definitions for the real-time interpretation and display of system tables used by the spacecraft flight software. The naming convention for FSW table mnemonics is identical to the observatory telemetry mnemonic naming convention.

5.0 Command Mnemonic Naming Convention

The command mnemonic naming convention follows a similar format to the telemetry mnemonic naming convention. ASIST command mnemonics can be no more than 32 characters in length. Chapter 5 of the ASIST Users Guide (Reference 6) provides information on command RDL structures and applicable database tools.

5.1 Observatory Command Mnemonics

SDO command mnemonics for spacecraft subsystems and instruments will use the following naming convention:

Format: destination_subsys/component_description_value/stateWhere:

destination: required field, 2 to 4 characters, indicates the destination of the command. For observatory command mnemonics, the destination is typically the 1553 Subsystem Data Node or Bus Controller/Remote Terminal node.

subsys/component: optional field, 2 to 6 characters, indicates the sub-system, module, board, circuit, or component to perform an action upon. In limited cases this field may be omitted for commands sent to an SDN or for simple direct commands. See examples below.

description: required field, variable length, describes the function of the command.

value/state: optional field, 1 to 4 characters, to indicate the functional element value or state. This field and the leading underscore may be omitted if the command is adequately identified in the description field.


Table 5-4 Observatory Command Mnemonic Name Values

Field Name Valuedestination pse[a/b] = power system electronics (side a or b)

gce[a/b] = gimbal control electronics (side a or b)ace[a/b] = attitude control electronics (side a or b)scom[a/b] = s-band comm card (side a or b)kcom[a/b] = k-band comm card (side a or b)acs = attitude control system FSW on the SBCsbc = single board computeraia = atmospheric imaging assemblyhmi = helioseismic and magnetic imagereve = extreme ultraviolet variability experiment

Field Name Valuest[1/2] = star tracker 1 or 2

subsys or component See Appendix A for common abbreviations

description User defined, See Appendix A for common abbreviations

value or state See Appendix A for common abbreviations

Command mnemonic example 1: cdha_sm_load

The command example above is interpreted as:

Command & Data Handling side A software manager load to memory

Command mnemonic example 2: aceb_noop

The example above is a simple direct command that requires only a “destination” and “description” field. The example is a “no operation” test command to the attitude control electronics side B.

5.2 GSE and Ground System Directive Mnemonics

In the context of this DFCD, “directive” is the term used for any command with a destination other than the flight observatory. Commands to ground support equipment, ground system elements or subsystems within ASIST are referred to as directives. An example of a directive would be a command for a General Purpose Interface Bus (GPIB) device. Chapter 5 of the ASIST Users Guide (Reference 6) provides information on how to format directives.

GSE and Ground System directive mnemonics will use the following naming convention:

Format: destination_subsys/component_description_value/stateWhere:

destination: required field, 2 to 5 characters, indicates the destination of the directive.

subsys/component: optional field, 2 to 6 characters, indicates the sub-system, module, board, circuit, or component to perform an action upon. In limited cases this field may be omitted for simple discrete or obvious directives.

description: required field, variable length, describes the function of the command.

value/state: optional field, 1 to 4 characters, to indicate the functional element value or state. This field and the leading underscore may be omitted if the command is adequately identified in the description field.


Table 5-5 Directive Mnemonic Name Values

Field Name Value

destination

gds = goddard dynamic simulatorssim = spacecraft simulatorbsim = battery simulatorsas = solar array simulatorumb = umbilicalgs = SDO ground stationdds = data distribution systemdsm = DDS/SDOGS integrated manager

subsys or component See Appendix A for common abbreviations

description User defined, See Appendix A for common abbreviations

value or state See Appendix A for common abbreviations

GSE directive mnemonic example: dd_qcp_dmpinstcfg


DDS Quality Compare Processor dump instrument configuration

6.0 ASIST Telemetry Display Pages

At the time of component delivery to Observatory I&T, a limited set of telemetry display pages will be required. A subset of display pages that are created during box level testing in the lab will be delivered with the component. A minimal set of operational display pages will eventually be maintained and referenced for each sub-system during Flight Operations. Chapters 6 and 18 of the ASIST Users Guide (Reference 6) provide information on how to create display pages.

The naming convention for spacecraft and instrument displays is the same as the naming convention for mnemonics. The display pages created for incorporation into the Project Database should follow these guidelines:

Information to be included: GMT in upper left corner spacecraft time below GMT page name packet counter(s), where applicable packet time(s), where applicable text headers (e.g. relays) mnemonic (or brief text description) followed by the Dynamic Display Object

(DDO) and 2-character quality field

Page display formatting: create text and data columns in a logical flow add boxed areas to group data. use graphical display tools if space permits use a color scheme that does not preclude observation of RED and YELLOW

limit flags use a minimum font size of 12

Units: use engineering units or base 10 unless the base is clearly identified annotate the units being used, for example: Deg K or Deg C, Volts or Milli-

Volts, etc.

Pages should be constructed to clearly and logically summarize each subsystem’s operations. A primary subsystem page should group the information used by the subsystem lead to perform summary evaluations of subsystem operations. All critical health and safety parameters for a given subsystem should be contained on a single page.

7.0 STOL Procedures

STOL allows procedures or scripts to be developed that perform a sequence or series of steps typically involving sending commands and/or directives. These procedures will be used to perform ground and spacecraft functions that can be used over the life of the mission.

7.1 STOL Procedure Development Philosophy

The objective is to develop sound operational STOL procedures in the component and instrument development labs for use throughout the remainder of the mission. Small, modular procedures with minimal nesting that perform single functions will be used. The ultimate goals of STOL procedure development and execution for SDO are as follows:

To test SDO at the component and Observatory levels during I&T To test SDO and the ground segment in a “Test It Like You’ll Fly It” mode Maintain the health and safety of the Observatory during all phases of the

mission (pre-launch and post-launch) Develop and use STOL procedures during pre-launch I&T with reuse for post-

launch flight operations where practical

An important concept in the development of procedures is portability. Where appropriate, procedures should be written with the intent that they will be reused in a later mission phase, with little or no modification required. For example, procedures written in the component development labs should be reusable during Observatory I&T. Small modular single function procedures should be written in the component development labs. The component-level procedures can be called from higher level calling procedures to create more involved system-level test procedures. These modular single function procedures will also be organized and called from higher level calling procedures to make up the observatory-level test procedures. Ideally, these modular single function procedures can then be ported to Flight Operations with little modification and will provide a subset of the tested, verified on-orbit operations procedures.

7.2 STOL Procedure Development Guidelines

STOL procedure style guidelines and a recommended template for a STOL procedure are provided in Appendix E. The template illustrates some important features of a typical STOL procedure. Commands or command sequences should be preceded by a check that the prerequisite conditions are met prior to issuing the command. Commands or command sequences should be followed by a validation of command receipt, correct command response, and directions to be followed in the event the command fails to produce the desired response.

Another important aspect of the template shown in Appendix E is the illustration of using and verifying procedure arguments. Procedures often allow options that can be queried in line with the execution of the procedure or passed as arguments to the procedure at the start time of the procedure. During Observatory I&T, procedure options are only allowed as arguments passed to the procedure, because STOL procedures will be called from written documents such as Work Order Authorizations (WOAs) and test procedures. During Flight Operations, both in-line queries and arguments are acceptable.

7.3 STOL Procedure Naming Convention

Procedures developed for the SDO spacecraft and instruments are identified using a naming convention that describes the primary function of the procedure. The naming convention for STOL procedures is as follows:

Format: subsys_type of proc_description of operation(“arg1”,”arg2”,…)Where:

subsys: 3 to 6 characters that indicate the subsystemtype Of proc: optional field primarily used for special purpose tests during Observatory I&TDdescription of operation: abbreviated text description of procedure, including type of procedure, if appropriate“arg1”, “arg2”,…: optional arguments passed to procedure

Table 7-6 lists recommended values for each field.

Table 7-6 Procedure Field Naming Convention Guidelines

Field Name Valuesubsystem Flight Subsystems

aia = atmospheric imaging assemblyhmi = helioseismic and magnetic imagereve = extreme ultraviolet variability experimentcdh = SBC, SSR, SC, TSMs, RTS, filter tables, etc.gnc = (Guidance, Navigation & Control) ACS, ACE, Propulsion, IRU, DSS, STeps = (Electrical Power System) PSE, battery, Solar Arrays, deployablesfsw = common flight softwareacs = attitude control softwareprop = propulsion thm = thermalsrf = (S-band RF) omni antennas, s-band xpndr, s-

Field Name Valuecomm cardkrf = ka xmttr, HSB, Ka-comm cardhgs = hga, gceobs = observatory (system level)

GSE and Ground Subsystemsgds = goddard dynamic simulatorssim = spacecraft simulatorbsim = battery simulatorsas = solar array simulatorumb = umbilicalrcp = Receive, Range Command Processoraca = Antenna Controller Assemblyrfd = RF Distribution Assemblygs = SDOGS system levelspa = spectrum analyzerrfs = RF switch Matrixrsg = range signal generatorfep = VCDU file serverhdr = high data rate receiverqcp = quality compare processorfop = file output processordds = data distribution system leveldsm = DDS/SDOGS integrated managermoc = mission ops centergse = ground support equipment (general)

type of proc(optional)

ops = on-orbit routine or periodic ops)cgy = on-orbit contingencycpt = I&T comprehensive performance testfunc = I&T functional testalive = I&T aliveness testtvac = I&T thermal vaccume testemi = I&T electrical magnetic interference testtest = general test

description of operation Short text that describes the operation or test

STOL procedure name examples:

eps _setvt(“vt5”) - Electrical Power System procedure to set VT level 5

srf _lossofcomm - S-band Radio Frequency procedure for loss of communication

cdh_func_hsbtest - Command & Data Handling functional test of the High Speed Bus

hmi _iss(“openloop”) - HMI procedure to set the Image Stabilization System to open loop gnc_alive_ace - Guidance, Navigation & Control procedure for Attitude Control Electronics aliveness

obs_tvac_coldstart - observatory thermal-vac cold start procedure

7.4 STOL Procedure Preamble

The STOL Procedure file preamble consists of several free-text comment records located at the beginning of the file. These comment records provide additional documentation and historical information, which are not evident from the STOL Procedure itself. See Appendix E for the STOL preamble format.

8.0 Configuration Management and Distribution of the Project Database

The Project Database evolves through the mission development process. There are three distinct phases for database configuration: Component Development, Observatory I&T, and Flight Operations. Generally, elements of the database originate at the component development and/or flight software labs. Upon delivery of a component for Observatory I&T, the associated database files are delivered for inclusion into the Project Database. The Project Database is further developed during Observatory I&T and ultimately becomes the database used during Flight Operations. Section 8.1 describes each of the phases of Project Database development in more detail.

Project Database Configuration Management (CM) becomes centrally controlled at the end of Component Development and at the beginning of Observatory I&T. From the beginning of Observatory I&T to the end of the mission, the Project Database Administrator (DBA) is responsible for maintaining the integrity of the database in a central repository and for the distribution of the database to the appropriate users. Section 8.2 describes the Project Database CM and distribution process.

8.1 Project Database Lifecycle

8.1.1 Component Development

In the component development labs, developers maintain their own database. Each lab’s PDL is responsible for CM of the lab’s database elements during the component development phase. The guidelines in this document serve as the means to ensure uniformity of database elements during component development. Test Conductors (TC’s) supporting database development in the labs are responsible for ensuring that database products from the labs meet the database guidelines. It is expected that the database is validated during component-level testing.

When a component is delivered for Observatory I&T, the supporting lab database files are delivered for inclusion in the Project Database. The following component development labs supply input files for the first combined observatory-level Project Database release, as shown in Figure 8-1:

C&DH Development Lab Flight Software Development Lab GDS Development Lab ACE Development Lab PSE Development Lab GCE Development Lab RF Development Lab EGSE Development Lab DDS/DSIM Development Lab

AIA Development Lab HMI Development Lab EVE Development Lab

PSE Development

Lab

GDS Development

Lab

CDBA CDBA

CDBA

CDBA

CDBA

CDBA = Component DBACDBA = Component DBA

CDBA CDBA CDBA

CDBA

CDBA

CDBA

CDBA

FSW Development

Lab

C&DH Development

Lab

ACE Development

Lab Project Database Configuration Management

Project DBA

AIA Development Lab

HMI Development Lab

EVE Development Lab

DDS/DSIMDevelopment

Lab EGSE

Development Lab

RF Development

Lab

GCE Development

Lab

Figure 8-1 Initial Project Database Build

The development database consists mostly of RDL files, but also includes a minimal set of display pages and STOL procedures. Table 8-7 lists the RDL file names that are supplied by each of the component development labs.

A Component DBA (CDBA) serves as the point of contact for each lab. The CDBA for each development lab along with contact information is listed in Appendix F.

Table 8-7 Telemetry and Command Database Files

Development Lab

TelemetryDefinitions

Command Definitions

TableDefinitions

GSE Status Definitions

GSE Directive Definitions

ACE Lab sdo_tlm_acea.rdlsdo_tlm_aceb.rdlsdo_ptlm_acea.rdlsdo_ptlm_aceb.rdl

sdo_cmd_acea.rdlsdo_cmd_aceb.rdl

sdo_ttlm_acea.rdlsdo_ttlm_aceb.rdl

None None

C&DH Lab sdo_tlm_scoma.rdlsdo_tlm_scomb.rdlsdo_ptlm_scoma.rdlsdo_ptlm_scomb.rdlsdo_tlm_kcoma.rdlsdo_tlm_kcomb.rdlsdo_ptlm_kcoma.rdlsdo_ptlm_kcomb.rdl

sdo_cmd_scoma.rdlsdo_cmd_scomb.rdlsdo_cmd_kcoma.rdlsdo_cmd_kcomb.rdl

sdo_ttlm_scoma.rdlsdo_ttlm_scomb.rdl

sdo_gtlm_cdh.rdl sdo_gcmd_cdh.rdl

PSE Lab sdo_tlm_psea.rdlsdo_tlm_pseb.rdlsdo_ptlm_psea.rdlsdo_ptlm_pseb.rdl

sdo_cmd_psea.rdlsdo_cmd_pseb.rdl

sdo_ttlm_psea.rdlsdo_ttlm_pseb.rdl

sdo_gtlm_pse.rdl sdo_gcmd_pse.rdl

GCE Lab sdo_tlm_gcea.rdlsdo_tlm_gceb.rdlsdo_ptlm_gcea.rdlsdo_ptlm_gceb.rdl

sdo_cmd_gcea.rdlsdo_cmd_gceb.rdl

sdo_ttlm_gcea.rdlsdo_ttlm_gceb.rdl

sdo_gtlm_gce.rdl sdo_gcmd_gce.rdl

RF Lab None None None sdo_gtlm_rf.rdl sdo_gcmd_rf.rdlGDS Lab None None None sdo_gtlm_gds.rdl sdo_gcmd_gds.rdlEGSE Lab None None None sdo_gtlm_ssim.rdl

sdo_gtlm_umb.rdlsdo_gtlm_display.rdl

sdo_gcmd_ssim.rdlsdo_gcmd_umb.rdl

Table 8-1 Telemetry and Command Database Files (cont'd)

Development Lab Telemetry Definitions

Command Definitions Table Definitions

GSE Status Definitions

GSE Directive Definitions

FSW Lab sdo_ccsds_header.rdlsdo_tlm_types.rdlsdo_pseudo_types.rdlsdo_tlm_acs.rdlsdo_ptlm_acs.rdlsdo_tlm_sbc.rdlsdo_ptlm_sbc.rdlsdo_tlm_st1.rdlsdo_tlm_st2.rdlsdo_ptlm_st1.rdlsdo_ptlm_st2.rdlsdo_tlm_dss.rdlsdo_ptlm_dss.rdl

sdo_cmd_types.rdlsdo_cmd_acs.rdlsdo_cmd_sbc.rdlsdo_cmd_sta.rdlsdo_cmd_stb.rdlsdo_cmd_dss.rdl

sdo_ttlm_acs.rdlsdo_ttlm_sbc.rdlsdo_ttlm_dss.rdl

None None

AIA Lab sdo_tlm_aia.rdlsdo_ptlm_aia.rdl

sdo_cmd_aia.rdl sdo_ttlm_aia.rdl None None

HMI Lab sdo_tlm_hmi.rdlsdo_ptlm_hmi.rdl

sdo_cmd_hmi.rdl sdo_ttlm_hmi.rdl None None

EVE Lab sdo_tlm_eve.rdlsdo_ptlm_eve.rdl

sdo_cmd_eve.rdl sdo_ttlm_eve.rdl None None

DDS/DSIM Lab None None sdo_ttlm_sdogs.rdlsdo_ttlm_dds.rdlsdo_ttlm_dsim.rdl

sdo_gtlm_sdogs.rdlsdo_ptlm_sdogs.rdlsdo_gtlm_dds.rdlsdo_ptlm_dds.rdlsdo_gtlm_dsim.rdlsdo_ptlm_dsim.rdl

sdo_gcmd_sdogs.rdlsdo_gcmd_dds.rdlsdo_gcmd_dsim.rdl

8.1.2 Observatory I&T

For the purposes of database configuration management, the Observatory I&T phase begins when the component development labs deliver the initial database files and continues until the Observatory Pre-ship Review (PSR). Throughout Observatory I&T, the Project DBA is responsible for maintaining the central database repository and distributing Project Database releases.

During Observatory I&T, Project Database releases are distributed at predetermined milestones. Milestones that drive database releases include the Comprehensive Performance Tests (CPTs), the Thermal Vacuum/Thermal Balance (TV/TB) Test, and Acceptance Testing of each MOC software release. A list of database release milestones is provided in Appendix H. Additional Project Database releases may be made as needed, as determined by the Observatory I&T Manager and the Project DBA.

Project Database releases are distributed to the following elements, as shown in Figure8-2:

the I&T Control Center the Mission Operations Center the FSW Development Lab, including FlatSat the DDS/DSIM Development Lab the Portable Spacecraft Simulator (PSS)

During Observatory I&T, changes may be made to local copies of the database files in the I&T Control Center and the DDS/DSIM Development lab, including RDL, display pages, and STOL procedures, as needed. Spacecraft RDL changes originating in the I&T Control Center must be documented via a Problem Report, consistent with the process defined in the SDO Project Problem Reporting (PR) Procedure document, Reference 5. The Observatory I&T Lead Test Conductor evaluates all Problem Reports written against the Project Database during Observatory I&T.

The local changes are incorporated into the Project Database as major I&T tests are completed, as agreed to by the Observatory I&T Manager and the Project Systems Team.

MOC (GSFC, Bldg-14)

ASISTASISTITPS FDS

I&T Control Center

(GSFC, Bldg-7/10)

Portable S/C Simulator (PSS)

(GSFC)

DDS/DSIMDevelopment Lab

(GSFC)

EVE T&C

HMI T&C

AIA T&C

ASISTASISTCDBA

CBDA

CDBA

CDBA


CDBA

CDBA

CDBA

CDBA

Project Database Configuration Management

Project DBA

MPSITPS

FSW Development Lab (GSFC)

FlatSat

FSW Development Lab (GSFC)

FlatSat

Figure 8-2 Database Flow during Observatory I&T

A Component DBA serves as the point of contact for each element participating in the Observatory I&T phase. The CDBA for each element along with contact information is listed in Appendix G. The responsibilities of each CDBA and the Project DBA during Observatory I&T are described below.

I&T CDBA - The CDBA for the I&T Control Center is responsible for maintaining the configuration control of the I&T ASIST workstations and the Integrated Trending and Plotting system (ITPS) workstation in the I&T Control Center. The Lead Observatory Test Conductor will also serve as the I&T CDBA. The I&T CDBA will load the Project Database on the ASIST systems and ITPS in the I&T Control Center. The I&T CDBA will coordinate and approve all changes made to the spacecraft portions of the Project Database in the I&T Control Center. The I&T CDBA will also coordinate and approve all changes identified in the FSW Development Lab. After each I&T milestone, it is the responsibility of the I&T CDBA to submit all approved changes to the Project Database for inclusion in the next Project Database release.

Instrument Team CDBAs - During I&T, it is the responsibility of the CDBA for each Instrument T&C system to load the Project Database on the instrument T&C system(s) in the I&T Control Center and to distribute the Project Database to T&C system(s) located in the SOCs, including SSIM, as needed. Each Instrument Team CDBA will make changes to the instrument portion of the local copy of the Project Database as needed. After each I&T milestone, each Instrument Team CDBA will submit changes to

the instrument portion of the Project Database for inclusion in the next release of the Project Database.

DDS/DSIM CDBA - It is the responsibility of the DDS/DSIM CDBA to load the Project Database on the ASIST workstations in the DDS/DSIM Development Lab. The DDS/DSIM CDBA will make changes to the DDS/DSIM portion of the local copy of the Project Database as needed. After each I&T milestone, the DDS/DSIM CDBA will submit changes to the Project Database for inclusion in the next release of the Project Database.

MOC CDBA - It is the responsibility of the MOC CDBA to load the Project Database on the ASIST, ITPS, Flight Dynamics System (FDS), and Mission Planning System (MPS) in the MOC as needed. It is also the responsibility of the MOC CDBA to distribute the Project Database to the mini-MOC as needed. Changes to the Project Database will not originate from the MOC during Observatory I&T.

Other CDBA’s - It is the responsibility of the remaining CDBAs to load the Project Database on the systems in the FSW Development Lab and PSS as needed. Changes to the Project Database will not originate from these elements during Observatory I&T. Required changes identified in the FSW Development Lab will be coordinated through the Observatory I&T CDBA.

Project DBA - During Observatory I&T, the Project DBA has the following responsibilities:

merge and validate all input to the Project Database from the Component Development phase to create the initial Project Database release going into Observatory I&T

maintain a central repository of the Project Database distribute the initial Project Database release and all subsequent releases of the

Project Database merge and validate all input to the Project Database after each I&T milestone notify all elements when a new Project Database release is ready

8.1.3 Flight Operations

For the purposes of database configuration management, the Flight Operations phase begins after the Observatory PSR. Throughout Flight Operations, the Project DBA is responsible for maintaining the Project Database repository and distributing Project Database releases.

Figure 8-3 shows the distribution of Project Database releases during Flight Operations. Project Database releases are distributed to the following elements:

the MOC the SOC’s the FSW Development Lab, including FlatSat

the Mini-MOC

ASISTASIST

FSW Maintenance Lab (GSFC Bldg-1)

FlatSat

FSW Maintenance Lab (GSFC Bldg-1)

FlatSat

Project Database Configuration Management

Project DBA

AIA SOC (LMSAL)

Mini-MOC(WSC)

ITPS MPS DSIM

AIA T&C

HMI T&C

EVE T&C

AIACDBA

HMICDBA

EVECDBA

PSS

MOC (GSFC, Bldg-14)

HMI SOC (LMSAL)

EVE SOC (LASP)

FDS

MOCCDBA

MOCCDBA

FSWCDBA


Figure 8-3 Database Flow during Flight Operations

During Flight Operations, a CDBA is assigned for each element interfacing with the Project Database. The responsibilities of each CDBA and the Project DBA during Flight Operations are described below.

MOC CDBA - It is the responsibility of the MOC CDBA to load the Project Database on the ASIST, ITPS, FDS, MPS, PSS, and DSIM in the MOC, as needed, and to distribute the Project Database to the mini-MOC, as needed. It is also the responsibility of the MOC CDBA to test database updates off-line and to submit changes to the spacecraft portion of the Project Database for inclusion in the next Project Database release after the changes have been tested and approved. The MOC CDBA is also a member of the FOT.

AIA CDBA - It is the responsibility of the AIA CDBA to load the applicable portions of the Project Database on the AIA systems in the AIA SOC and the MOC, including SSIM. It is also the responsibility of the AIA CDBA to test database updates off-line and to submit changes to the AIA portion of the Project Database for inclusion in the next Project Database release after the changes have been tested and approved.

HMI CDBA - It is the responsibility of the HMI CDBA to load the applicable portions of the Project Database on the HMI systems in the HMI SOC and the MOC, including SSIM. It is also the responsibility of the HMI CDBA to test database updates off-line and to submit changes to the HMI portion of the Project Database for inclusion in the next Project Database release after the changes have been tested and approved.

EVE CDBA - It is the responsibility of the EVE CDBA to load the applicable portions of the Project Database on the EVE systems in the EVE SOC and the MOC, including SSIM-. It is also the responsibility of the EVE CDBA to test database changes off-line and to submit changes to the EVE portion of the Project Database for inclusion in the next Project Database release after the changes have been tested and approved.

FSW CDBA – It is the responsibility of the FSW CDBA to load the Project Database on the systems in the FSW Maintenance Lab. It is also the responsibility of the FSW CDBA to test database changes off-line and to submit changes to the FSW portion of the Project Database for inclusion in the next Project Database release after the changes have been tested and approved.

Project DBA – The Project DBA is a member of the FOT. During Flight Operations, the Project DBA has the following responsibilities:

maintain a central repository of the Project Database distribute Project Database releases

During Flight Operations, Project Database releases will be distributed on an as-needed basis. Changes to the Project Database will be documented and approved through a web-based SDO Mission Operations Change Request (MOCR) system. Updates to the Project Database during Flight Operations will be made only after the associated MOCR is approved by the NASA-appointed Mission Director.

8.2 Project Database CM and Distribution Process

The elements of Project Database CM and distribution are shown in Figure 8-4. The Project Database CM and distribution processes apply to the Observatory I&T and Flight Operations phases.

The Project Database is stored in a central repository. A revision control system, Subversion, is used to manage the central repository. Direct access to the central repository is limited to the Project DBA and the designated backup. Details of the central repository are given in Section 8.2.5

All Project Database file exchanges between the Project DBA and the CDBA’s flow through the MOC File Transfer Gateway. Details of the MOC File Transfer Gateway are given in Section 8.2.1.

For a given Project Database release, the initial step is to gather the updates to the Project Database files from the CDBA’s. Each CDBA transfers updated Project

Database files to a private workspace on the File Transfer Gateway. The Project DBA has access to each CDBA’s private workspace.

The Project DBA merges all current Project Database files and validates the Project Database. Details of the validation process are given in Section 8.2.4. If errors are discovered, the Project DBA contacts the responsible CDBA, the CDBA corrects the errors, and the CDBA resubmits the file. When the Project Database compiles without errors, the Project DBA stores the current Project Database files in the central repository and distributes the Project Database release.

To distribute a Project Database release, the Project DBA copies the current version of each Project Database file from the central repository to the Project Database distribution workspace on the File Transfer Gateway.

Significant database releases are numbered sequentially, beginning with Release 1.0. If it is determined that a delta release is necessary, the delta releases are numbered Release 1.1, Release 1.2, etc.

At the time of each database release, the Project DBA distributes a release notification via e-mail. In addition, the Project DBA prepares release notes, which include the database release number, the list of files that are new or updated, a brief summary of the reason for any updates, the SBC (C&DH and ACS) flight software version, the ACE flight software version, the PSE flight software version, and the GCE flight software version. The release notes are attached to the release notification and are also distributed with the Project Database release on the File Transfer Gateway.

CDBA

CDBA

CDBA

WebServer

Apache

WebServer

Apache

SSL

SSL

SSL

ProjectDBA

Project DBRepository

RevisionControlSystem

Subversion

Project DBRepositoryProject DBRepository

RevisionControlSystem

Subversion

FTPServer

PureFTPd

DBDistributionWorkspace

PrivateWorkspace

SSL = Secure Socket LayerCDBA = Component DBA

File Transfer Gateway

Figure 8-4 Project Database CM and Distribution

8.2.1 MOC File Transfer Gateway

8.2.2 File Transfer Gateway Implementation

The MOC File Transfer Gateway provides a web-based file manager front-end. The gateway allows the CDBA’s to exchange files with the Project DBA through a web browser and a file server. Access to the gateway is password protected. A single Secure Socket Layer (SSL) connection is used to provide security for the data transfer.

The File Transfer Gateway login page is shown in Figure 8-5.

Figure 8-5 File Transfer Gateway Login

8.2.3 File Transfer Gateway Directories

Home Directory

Upon login to the File Transfer Gateway, the CDBA is placed in a home directory, which is a private workspace, as shown in Figure 8-6. Private workspaces are not accessible to other users of the system, except the Project DBA and the designated backup administrator(s).

The CDBA’s private workspace is used as a staging area for the submission of Project Database file updates. The CDBA can upload one or more files from a local

workstation to their home directory on the File Transfer Gateway using the “Upload” button provided on the File Transfer Gateway interface. In the example shown in Figure8-6, the CDBA has uploaded the files sdo_cmd_acea_update.rdl and sdo_tlm_acea_update.rdl for inclusion in the next database release.

Figure 8-6 File Transfer Gateway Home Directory

The CDBA may choose to create one or more subdirectories within their home directory using the “Create New Directory” button provided. Creating subdirectories may be useful for organizing numerous file updates.

When the correct files have been uploaded, the CDBA notifies the Project DBA and the designated backup administrator(s) via email. The email should contain the name of any subdirectories, the name of each file, a brief summary of the changes to each file, and the reason(s) for the changes.

It is the CDBA’s responsibility to leave the files in their home directory until the Project DBA moves the files.

Distribution Directories:

The CDBA has links to one or more public database distribution directories from their home directory. The Project DBA creates read-only directories on the File Transfer Gateway for the distribution of Project Database releases.

The distribution directory structure is shown in Figure 8-7. Each user is given access to one or more of the following directories:

Telemetry_rdl_Distribution, Telemetry_Report_Distribution, Command_rdl_Distribution, Command_Report_Distribution, Display_Page_Distribution, and STOL_Procedure_Distribution

Permission for read access to the distribution directories is given to CDBA’s on an as-needed basis. For example, instrument CDBA’s will have access to the Telemetry_rdl_Distribution directory, but will not have access to the Command_rdl_Distribution directory.

Within each of the distribution directories, a subdirectory is created for each database release. The Project DBA obtains a copy of the current version of each database file from the central repository in SubVersion and places the files in the appropriate directory on the File Transfer Gateway.

The Project DBA uses ASIST’s Data Query Tool (TDQ) to create database reports for each database release. The ITPS and PSS ingest the report files in lieu of RDL files for telemetry and/or command RDL definitions. In addition, other telemetry and command reports are created to provide an overview of the telemetry and command RDL definitions.

8.2.4 Project Database Validation

The Project DBA moves new and updated Project Database files from each CDBA’s private workspace on the File Transfer Gateway to the appropriate directories on a designated ASIST workstation. The ASIST directory structure is described in Appendix I.

The Project DBA uses the ASIST Telemetry Database Compiler (dbcmptlm) to verify the telemetry RDL files. The administrator edits the master list of telemetry RDL files (user_tlm.rdl) as necessary, and initiates dbcmptlm to compile the telemetry database. Errors from the telemetry database compilation process are written to an error log, otlmdbcmp.log. If errors occur, the administrator examines the error log to determine the source of the error.

The Project DBA uses the ASIST Command Database Compiler (dcmpcmd) to verify the command RDL files. The administrator edits the master list of RDL files (user_cmd.rdl) as necessary, and initiates dbcmpcmd to compile the command database. Errors from the command database compilation process are written to an error log, ocmddbcmp.log. If errors occur, the administrator examines the error log to determine the source of the error.

If errors occur during the telemetry or command compilation process, the Project DBA posts the error log(s) on the File Transfer Gateway and contacts the CDBA responsible for each RDL file in question. The CDBA updates the RDL file to correct the identified error(s), and resubmits the updated file.

The verification process is repeated until all errors are resolved. When the telemetry and command compilations are error-free, the Project DBA places the updated RDL files to be included in the next Project Database release into the Project Database central repository.

8.2.5 Project Database Central Repository

The central repository for the Project Database files is implemented using Subversion. Subversion is a free/open-source version control system, based on the Concurrent Versions System (CVS), that can be used to manage any collection of files and directories in a central repository. Subversion stores every version of every file, which allows the user to recover older versions of data and to view the history of how the data has changed.

Access to the files within the Subversion repository is limited to the Project DBA and the designated backup. The Project DBA commits new or updated files that have been verified and are ready for inclusion in the next Project Database release. The Project DBA copies the current version of each database file from Subversion and places it in

the appropriate directory on the File Transfer Gateway to distribute a Project Database release.

Backups of the central repository will be made regularly during Observatory I&T and Flight Operations to prevent loss of data. Both full and incremental backups will be performed.

APPENDIX A: Recommended Abbreviations and Acronyms for RDL, Telemetry, and Command Names

Note: This is not a complete list; additional abbreviations may be used when needed.

Appendix-A: Recommended Abbreviations and Acronyms for RDL, Telemetry and Command Naming Conventions

Abbreviation / Acronym Description Applicable

FieldsGeneric/General Subsystem AbbreviationsAB Abort descADR Address descANG Angle descAPID CCSDS Application ID descARM Arm (pyro) descASIC Application-Specific Integrated Circuit descAUX Auxiliary descBDY Body desc, componentBOX Box descBP/BSPLT Baseplate desc, componentBRF Band Reject Filter descBS/BIAS Bias descBUF Buffer descBUS Bus descCAL Calibration descCCD Charge Coupled Device desc, componentCE Control Electronics desc, componentCFG Configuration descCGY Contingency descCH/CHAN Channel descCIE Channel Interface Electronics descCLK Clock desc, componentCLR Clear descCMT Commit descCMD Command descCNT Count descCNV Converter descCP Copy descCPU Central Processing Unit desc, componentCSM Command Signal Module desc, componentCSS Coarse Sun Sensor desc, componentCUR/CR Current (not electrical) descDC Direct Current descDEG Degrees descDET Detector descDIAG Diagnostics descDIP Dipole desc



FieldsDLY Delay descDAMP Damping descDR Driver descDS/DIS Disable descDWL Dwell descECL Eclipse descEEPR EEPROM Desc, componentEH Echo descEL/ELEC Electronics desc, componentELM Element descELV Elevation descEN/ENA Enable descENC Encoder desc, componentENG Engineering descER Error descEVD Engine Valve Driver descEXE/EX Execute descFCT/FT Factor descFIRE Fire (pyro) descFLG/FG/F Flag descFLT Filter descFPGA Field Programmable Gate Array descFS Frequency Standard desc, componentFX Fixed descGS SDO Ground System descGN/GAIN Gain descHD/HEAD Head descHI High descHSB High Speed Bus desc, componentHTR Heater descHW Hardware descI Current (electrical) / I Channel desc, valueID Identification descIF Interface desc, componentINST Instrument desc, componentINT Internal descINX Index descK Kilo descLCK Lock descLD/LOAD Load descLG Logic descLO Low descLPSC Low Power Switching Card desc, componentLVDS Low Voltage Differential Signal desc



FieldsLVL Level descMAG/MG Magnetic descMAT/MX Matrix descMD/MODE Mode descMEM Memory descMP Main processor descMSG/MS Message descMUX Multiplexer descN15V Negative 15 Volts desc, valueN5V Negative 5 Volts desc, valueNOOP No Operation descOC Overcurrent descOFF Off descOPHTR Operational Heater desc, componentON On descOP/OPER Operation descOS Offset descOSC Oscillator descOT/OVTEMP Over Temperature descOVR Override descP15V Positive 15 Volts Desc, valueP5V Positive 5 Volts Desc, valuePA/PREAMP/PWRAMP Pre Amp / Power Amp

desc, component

PCC Power Converter Card desc, componentPCI Peripheral Component Interconnect desc, componentPCU Proportional Controller Unit desc, componentPH Phase descPIM Pyrotechnic Initiation Module desc, componentPNT Point / Pointing descPOS Position descPROM Programmable Read-Only Memory desc, componentPROP Propulsion desc, componentPRS Pressure descPRT Platinum Resistance Thermometer desc, componentPS Power Supply descPV Previous descPWM Pulse Width Modulator desc, componentPWR Power descPYRO Pyrotechnic descPZT Piezoelectric Transducer desc, componentQ Q Channel Telemetry descRAD Radiator descRAM Random Access Memory desc, componentRCVR Receiver desc, component



FieldsREC Record descREF Reference descREG Regulator descRLY Relay descRST Reset descRT 1553 Remote Terminal desc, componentSCI Science descSCL Scale descSDN Subsystem Data Node desc, componentSEL/SL Select descSET Set descSH/SFHLD Safehold desc, componentSHNT Shunt desc, componentSLR Solar descSN Sensor descSP Speed descSPM Signal Processing Module descSPN Spin descSPR Spare descS Status / State descST Star Tracker desc, componentSTCF Spacecraft Time Correlation Factor descSTEP Step / Stop descSTR Start descSVHTR Survival Heater desc, componentSYS System descT/TEMP Temperature Desc, valueTAI Time Synchronized to International Atomic Time Desc, valueTBL Table descTHM Thermistor desc, componentTI Time descTLM Telemetry Desc, valueTRQ Torque descUPD Update descUTC Universal Time Coordinated Desc, valueV Volts / Voltage Desc, valueVAL Value Desc, valueVC Virtual Channel descVEC Vector descVEL Velocity descVL Voltage Level Desc, valueVLV Valve Desc, componentWD Word descXDUCR Transducer desc, component



FieldsXSUM Checksum desc

Abbreviation /Acronym Description Applicable

Fields

HGAS/RF AbbreviationsAGC Automatic Gain Control Desc, valueANT Antenna Desc, componentBR Bit Rate Desc, valueCOHO Coherent DescDNLK/DL Downlink DescDPX/DX Diplexer Desc, component

GCE Gimbal Control ElectronicsSource, destination, desc

HGA High Gain Antenna Desc, componentHGADS High Gain Antenna Deployment Desc, componentNOCO Non-Coherent DescRF Radio Frequency DescRFTS RF Transfer Switch Desc, componentSPE Static Phase Error Desc, valueUPLK/UL Uplink DescXM/XMTR Transmitter Desc, componentXP/XPNDR Transponder Desc, component


Fields

Flight Software Abbreviations1553 1553 bus descATP Absolute Time Processor descATS Absolute Time Sequence descBC 1553 Bus Controller componentCDH C&DH descCI Command Ingest (S/W task) componentCLCW Command Link Control Word descCRC Cyclic Redundancy Check descCS Checksum desc, componentDMP Dump descDS Data Storage (S/W task) componentFSW Flight Software descHD High Speed Bus Director (S/W task) componentHS Health & Safety (S/W task) desc, componentHSB High Speed Bus descMD Memory Dwell desc, componentPKT Packet desc


Fields

RT Remote Terminal desc, componentRTP Relative Time Processor descRTS Relative Time Sequence descSB Software Bus desc, componentSC Spacecraft / Stored Command desc, componentSM Software Manager (S/W task) componentSSR Solid State Recorder descSW Software descTC Time Code (S/W task) / Trickle componentTM/ Time Time descTO Telemetry Output (S/W task) componentTS Telemetry & Statistics (S/W task) componentXB External Bus (1553 Bus) (S/W task) component


Fields

Instrument AbbreviationsAIA Atmospheric Imaging Assembly Source, destinationCEB Camera Electronics Box Desc, componentESP EUV Spectral Photometer Desc, componentEUV Extreme Ultraviolet descEVE Extreme Ultraviolet Variability Experiment Source, destinationGT Guide Telescope Desc, componentFLTRWHL Filter Wheel Desc, componentHMI Helioseismic and Magnetic Imager Source, destinationIMC Image Motion Compensation System Desc, componentISS Image Stabilization System Desc, componentMEGS Multiple EUV Grating Spectrograph Desc, componentSAM Solar Aspect Monitor Desc, componentSHM Shutter Mechanism Desc, componentSUR/SUROM Start-Up Read-Only Memory Desc, component


Fields

Ground Systems, GSE, SOC AbbreviationsACA Antenna Control Assembly ComponentBSIM Battery Simulator ComponentDC Diversity Combining DescDDS Data Distribution System ComponentDSM DDS SDOGS Interface Manager Source, destinationFC Frequency Conversion System descFDS Flight Dynamics System Source, destination

FEP Ka-Band Front End ProcessorSource, destination, Component

FOA Fiber Optic Assembly ComponentFOP File Output Processor Component


FieldsGDS Goddard Dynamic Simulator Source, destinationIF Intermediate Frequency DescIM IF Modulator DescIR IF Receiver DescQCP Quality Compare Processor ComponentRFS RF Switch Matrix ComponentRSG Ranging Signal Generator ComponentRFD RF Distribution Assembly ComponentRU Tone Ranging Unit DescRCP Range, Receive, and Command Processor ComponentSAS Solar Array Simulator Source, destinationSPA Spectrum Analyzer ComponentSSIM Spacecraft Simulator (for Inst Labs) Source, destinationTC Telecommand Unit DescTS Telemetry Simulator DescTU Telemetry Unit DescUMB Umbilical Source, destination


FieldsACS/ACE Refer to ACS/ACE naming conventions document

APPENDIX B: Telemetry RDL Preamble

File Preamble:

! ! Responsible TC: name phone! Responsible PDL: name phone! Rev: id Last Change: ddmmmyy!!! SDO Telemetry Packet # apid (dec) (give apid # or range of apid’s)! ================================!! REFERENCES:!! NOTES:!! HISTORY:!! Originator: nnnnn nnnnnnnn ddmmmyy!! Rev Description of change Rev ID & Date! id bbbbbbbbbbbbbbbbbbbbbbbbbbbbbb iii ddmmmyy!

APID Preamble: (repeat for each apid in file)

! ================================!! Packet Application ID: dec (Hex hhh)! Packet Title: packet! Packet Source: source! Packet Length: total bytes (Including 14 Bytes Of Header)! Packet Description: description!! ================================!PACKET Phhh APID=%xhhh, DESC="packet title - description" STALE = ss # include “ccsds_header.rdl” (if necessary)!!END !END PACKET hhh

APPENDIX C: Command RDL Preamble

File preamble:

! ! Responsible SC: name phone! Responsible CSE: name phone! Rev: id Last Change: ddmmmyy!!! SDO Command Packet # apid (dec) ) (give apid # or range of apid’s)! ================================!! REFERENCES:!! NOTES:!! HISTORY:!! Originator: nnnnn nnnnnnnn ddmmmyy!! Rev Description of change Rev ID & Date! id bbbbbbbbbbbbbbbbbbbbbbbbbbbbbb iii ddmmmyy!

APID Preamble: (repeat for each apid in file)

! ================================!! Packet Application ID: dec (Hex hhh)! Packet Title: packet! Packet Target: source! Packet Description: description!! ================================

CLASS Phhh APID=%xhhh, DESC="packet title - description"!!END !END CLASS hhh

APPENDIX D: FSW System Table RDL File Preamble

! ! Responsible SC: name phone! Responsible CSE: name phone! Rev: id Last Change: ddmmmyy!PACKET Phhh APID=%xhhh, DESC="packet title - description" STALE = ss!END !END PACKET hhh

APPENDIX E: STOL Procedure Example and Guidelines

Example STOLProcedure with Preamble

PROC standardproc(strng, nmbr)IF ((%LIV(LOG_PROCEDURE) = 0)) PROCON;Version 1 (X = int start from 1) Last Change Date: 14-DEC-05 TC Initials: BPS; PURPOSE: Serve as procedure templateGOTO PREAMB;@*********************************************************************;@ Introduction:;@ Mission: SDO;@ Proc Name: standardproc;@ Subsystem: All;@ Author:;@;@ Change History;@ REV DATE INITIALS CHANGE DESCRIPTION ;@ 1 12/14/05 BPS Initial release;@;@ Approval: (Name, Date);@;@ Validating Personnel: ________________________ _____________;@;@ Technical Review: ________________________ _____________;@;@ Systems Review: ________________________ _____________;@;@ Q.A Review: ________________________ _____________;@*********************************************************************;@ Description:;@;@ Narrative Description;@ (Detailed description of operations that procedure performs);@;@ References: (pages);@;@ Variable Directory: (List ALL variables used in the proc);@;@ Variable = Definition;@;@ Arguments:;@ <arg1> = <definition>;@ <arg2> = <definition>;@*********************************************************************;@ Instructions for Use:;@;@ Tables/Loads Required:;@;@ Child Procedures: (any STOL procs called by this one);@ <proc name> = <intended use>;@;@ Applicable Local Operating Procedures (LOPs) or Scripts:;@ <Script Identifier> <Script Name>;@

Example STOLProcedure with Preamble (Continued)

;@ Critical Commands:;

;@ None;@;@ Special Constraints or Activities:;@;@ None;@ ;@*********************************************************************;@ STEPS:PREAMB:

;----------------------;Initializing variables;----------------------LOCAL mnemonic, variable; Define Local Variables. Only valid within this procLOCAL proc_name ;Allows proc_name to be referenced within this procLOCAL MyPrcStartTime ;Declare variable to record proc start timeLOCAL strng, nmbr, duration, errstat ;Declare passed parameters

Let MyPrcStartTime = GMT ;Store proc start time

;<variable> = <value> ;Set variable to initial value to fail any proc checksproc_name = stol_proc_namemnemonic = 2errstat = -1

BROADCAST Starting procedure {proc_name}

;------------------;Comment about GOTO ;------------------;Try to minimize use of GOTO statements (except GOTO OUT is valid)

;-----------------------------------------------------------;Prevent Procedure Comments from appearing in events page;Useful when using the "WRITE" directive to avoid seeing the ;the same two statements in the event log.;-----------------------------------------------------------PROCOFF ;Procedure comments will not appear in events display OR event filePROCON ;Procedure comments will again appear in event display AND event file

;----------------------------------------------------;Verify number of arguments passed to proc;----------------------------------------------------IF (%NARGS < 2) THEN ;---------------------------------------------------------------------- ;Inform User invalid # arguments passed, and name of expected arguments ;---------------------------------------------------------------------- PROCOFF WRITE" Correct number of arguments NOT passed, proc Exiting"Example STOLProcedure with Preamble (Continued)

WRITE "Expecting 2 arguments: <arg1>, <arg2>"

PROCON errstat = 1 GOTO OUTENDIF

;---------------------------------------------;Verify passed arguments within expected range;---------------------------------------------strng = %UPPER(strng)IF ((strng <> "Y") .AND. (strng <> "N")) THEN PROCOFF WRITE strng & " is not a valid input for arg1, proc exiting" PROCON errstat = 1 GOTO OUTENDIF

IF ((nmbr < 0) .OR. (nmbr > 35)) THEN PROCOFF WRITE nmbr & " is not a valid input for arg2, proc exiting" PROCON errstat = 1 GOTO OUTENDIF

;------------------;Calling Procedures;------------------;START <procedure name> ;All procedure calls should use START vice S

;------------------------------------------;Verifying any pre-existing conditions true;------------------------------------------IF (mnemonic != 3) THEN PROCOFF WRITE "PRE-COMMAND CONSTRAINT CHECK FAILED" PROCON WAIT ; Type 'GO' to exit procedure errstat = 1 GOTO OUTENDIF

;-------------------;Command Description;-------------------WAIT ;Type "GO" to transmit command/ACEA_CA_NOOP

;*NOTE* Commands being sent because of health check failure do;not require hard waits before being sent.WAIT 3

Example STOLProcedure with Preamble (Continued)

;------------------------------------------------;Description of check to verify command execution;------------------------------------------------WAIT UNTIL (MNEMONIC = 3)

OUT: ;Used to demarcate code that is ALWAYS executed at the end of the proc

; Calculating procedure run time.PROCOFFduration = %time(GMT-MyPrcStartTime)duration = %substring(duration,8 ,20)WRITE (proc_name) &" execution time "& durationPROCON

IF (errstat = -1) THEN BROADCAST Successfully executed procedure {proc_name} PROCOFF WRITE "Successfully executed procedure " & (proc_name) PROCONELSEIF (errstat = 1) THEN BROADCAST ERROR OCCURED - Procedure {proc_name} exited PROCOFF WRITE "ERROR OCCURED - Procedure " & (proc_name) &" exited" PROCONENDIF

;@*********************************************************************;@ Final Constraints;@;@ Note here any final actions or comments;@;@*********************************************************************ENDPROC ;Must have a carriage return after this line

STOL Procedure Style Guidelines

1. Procedure names will be unique and different from any other procedure name.2. Procedure filenames will all be lowercase with an extension of “.prc”3. In the procedures, the header section will be followed by a steps section. This

section contains the commands, telemetry checks, and all relative comments.4. Ample use of STOL comment directives is desired to allow analyst to follow what the

procedure is doing. Also, use a comment to title logical sections of the procedure. Use asterisks on both sides of the title and asterisks to surround each section.

5. All command blocks and telemetry checks will have comments as needed for readability. The format will consist of a line of all hyphens, a line containing the text, and another line of hyphens.

;--------------------; Text description;--------------------

6. For Flight Operations, commanding will be in one-step mode. The command description line is followed by a line with WAIT; “go” to transmit command, followed by the command mnemonic on the next line. This guideline does not apply to Observatory I&T.

7. All commands, telemetry checks, and other STOL directives will be in all capital letters.

8. All comments will use nominal English writing styles.9. Use the WRITE command to add additional comments which you want displayed to

the operator at time of execution. Use of PROCOFF prior to the WRITE statement and PROCON after, is encouraged so that the text being written will only appear once in the event display page.

10. Immediately below the PROC <proc name> line is a line to check if procedure logging is off, and if so, turn it on: IF ((%LIV(LOG_PROCEDURE = 0)) PROCON.

11.All procedures will have a comment with the version number directly underneath the check that procedure logging is on.

12.All variables must be declared as LOCAL or GLOBAL, and must initially set to a value that will fail any checks contained in the procedure

13.All procedure calls should use the directive START, not the alias S.14. If the procedure requires arguments to be passed, there should be a check that the

correct number of arguments was passed, and that the arguments are within the expected range.

15.All procedures will have a label OUT prior to the ENDPROC line to accommodate a procedure abort any time during execution.

16.The use of GOTO loops should be minimized to simplify the logic and make the procedure easier to follow (I&T procs may use them more often to avoid dangerous configurations based on spacecraft location, GSE configuration, or level of integration). A “GOTO OUT” is acceptable. Use only labels with GOTO statements, no line numbers.

17.Avoid long series of directives without WAIT statements to allow the analyst to monitor and control procedure execution

18.Avoid nesting %( ) STOL functions in procedures. Instead, separate the functions into multiple lines. For example,

LET FOO = %REX(%BIN(H'$MAG',8),"000[01]{5,5}$")should be coded as:

LET FOO = %BIN(H'$MAG',8)LET FOO = %REX("$FOO","000[01]{5,5)$")

APPENDIX F: Contact List for Component Development

Component Contact Phone E-mail AddressACE Lab E.J. Bickley 301 286-6232 [email protected]&DH Lab John Pope 301 286-9318 [email protected] Lab Bill DeHaven 301 286-7821 [email protected] Lab Glen Miller 301 286-2384 [email protected] Lab Leo McConville 301 286-8552 [email protected] Lab Stephen Leake 301 286-6023 [email protected] Lab E.J. Bickley 301 286-6232 [email protected] Lab Dan Berry 301 286-0060 [email protected] Lab acs only Lisa Hoge 301 286-5686 [email protected] Lab Jerry Drake 650 424-3404 [email protected] Lab Jerry Drake 650 424-3404 [email protected] Lab Karen Bryant 303 492-4496 [email protected]/DSIM Lab Michelle Lacombe 301 286-2157 [email protected]

APPENDIX G: Contact List for Observatory I&T

Facility Contact Phone E-mail AddressI&T Control Center ASIST

E.J. Bickley 301 286-6232 [email protected]

I&T AIA T&C Jerry Drake 650 424-3404 [email protected]&T HMI T&C Jerry Drake 650 424-3404 [email protected]&T EVE T&C Karen Bryant 303 492-4496 [email protected] Chris VanDyke 301 286-1914 [email protected] Lab - C&DH Dan Berry 301 286-0060 [email protected] Lab - ACS Lisa Hoge 301 286-5686 [email protected] Lab - FlatSat I&T

E.J. Bickley 301 286-6232 [email protected]

FSW Lab - FlatSat FSW Testing

Dan Berry 301 286-0060 [email protected]

DDS/DSIM Lab Michelle Lacombe 301 286-2157 [email protected] John Kim 301 286-7140 [email protected] DBA Maureen Suckling 301-286-0566 [email protected]

APPENDIX H: Database Release Milestones

Note: Dates listed here are for information only. Refer to the SDO Project schedule maintained on SDOMIS for current dates corresponding to the milesatones listed below.

DB Release Date Mission Milestone or Driver

0.0 Dec-05 MOC Release-11.0 Mar-06 MOC Release-22.0 Sep-06 MOC Release-33.0 Nov-06 Initial Observatory I&T Release4.0 Mar-07 MOC Release-45.0 Jun-07 Pre-Instrument Integration (EVE, HMI, and AIA)6.0 Jul-07 Pre-CPT #1 (post observatory integration)7.0 Aug-07 Post-CPT #18.0 Jan-08 Pre-Thermal Vacuum 9.0 Mar-08 Post-Thermal Vacuum

10.0 May-08 Database FREEZE (Launch minus 90 days)N/A Aug-08 Launch

APPENDIX I: ASIST Database Directory Description

ASIST T&C users manage the T&C database on one or more ASIST workstations. In addition, the Project DBA uses ASIST to verify the Project Database.

Each ASIST workstation has access to a database directory definition from four different directories: System, Configured, Global, and Local, as described below:

System - This directory contains all executables, configuration files, procedures, and pages required by the ASIST system to run. This is a restricted directory. Users are not permitted to modify anything in this area.

Configured - This directory contains configured RDL files, Telemetry Page Displays, and STOL procedures. It contains the directory structure used to store released database files. This is a read only directory. Users must copy files to the Global and/or Local accounts in order to make modifications.

Global - This directory contains laboratory approved RDL files, STOL procedures, telemetry page displays, and configuration files and is maintained by the lab managers. It is associated with the login account ”asist”. This is the normal account for running in the real-time STOL environment using a laboratory-approved database. It is expected that the files resident in a laboratory’s Global area are delivered for use as the Configuration files.

Local (not necessarily named local) - This directory (if created) contains RDL files, STOL procedures, telemetry page displays, and configuration files in an account managed at a level below global. The account has read/write capabilities, and can be used as a working directory for database development, workstation-specific pseudo telemetry calculations, and running in the STOL environment. New database entries can be tested in this account before being promoted upward into the global account.

APPENDIX J: Acronyms

Term Definition

ACE Attitude Control Electronics

ACS Attitude Control System

AIA Atmospheric Imaging Assembly

APID Application Id

ASIST Advanced Spacecraft Integration and System Test

C&DH Command and Data Handling

CCB Configuration Control Board

CCSDS Consultative Committee For Space Data Standards

CLCW Command Link Control Word

CMO Configuration Management Office

CPT Comprehensive Performance Test

DDO Dynamic Display Object

DDS Data Distribution System

DTF Dump Transfer Format

EGSE Electrical Ground Support Equipment

EVE Extreme Ultraviolet Variability Experiment

FDS Flight Dynamics System

FOT Flight Operations Team

FSW Flight Software

FTP File Transfer Protocol

GCE Gimbal Control Electronics

GPIB General Purpose Interface Bus

GSE Ground Support Equipment

GSFC Goddard Space Flight Center

HGA High Gain Antenna

HMI Helioseismic and Magnetic Imager

I&T Integration and Test

ICD Interface Control Document

IGSE Instrument Ground Support Equipment

ITPS Integrated Trending and Plotting System

KSC/CCAS Kennedy Space Center and Cape Canaveral Air Station

LASP Laboratory For Atmospheric and Space Physics

LMSAL Lockheed-Martin Solar and Astrophysics Laboratory

MOC Mission Operations Center

MOCR Mission Operations Change Request

NASA National Aeronautics and Space Administration

NFS Network File Sharing

OASIS-CC Operations and Science Instrument Support – Command and Control

PDL Product Development Lead

PSE Power System Electronics

PSR Pre-ship Review

PSS Portable Spacecraft Simulator

RF Radio Frequency

SDO Solar Dynamics Observatory

SDOGS Solar Dynamics Observatory Ground Station

SFDU Standard Formatted Data Unit

SSL Secure Socket Layer

SOC Science Operations Center

SOS Science Operations Support

STOL Spacecraft Test And Operations Language

T&C Telemetry and Command

TBD To Be Defined

TBR To Be Resolved

TC test conductor

TDQ data query tool

TSM Telemetry and Statistics Monitor

VCDU Virtual Channel Data Unit

WOA Work Order Authorization

WSC White Sands Complex

SDO Database Format Control Document...

Documents

Transcript of SDO Database Format Control Document...