SDO Database Format Control Document...
-
Upload
phunghuong -
Category
Documents
-
view
221 -
download
2
Transcript of 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
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
464-GS-PLAN-0042Revision A
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
464-GS-PLAN-0042Revision A
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
464-GS-PLAN-0042Revision A
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
464-GS-PLAN-0042Revision A
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
464-GS-PLAN-0042Revision A
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
The above example is interpreted as:
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
The above example is interpreted as:
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 lists acceptable values for each 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 lists acceptable values for each 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
The above example is interpreted as:
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 = Component DBACDBA = Component DBA
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
CDBA = Component DBACDBA = Component DBA
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.
Telemetry_rdl_Distribution |___ DB_Release_0.0 | |____ sdo_tlm_acea.rdl | |____ sdo_ptlm_acea.rdl | |____ sdo_ttlm_acea.rdl | |____ sdo_gtlm_cdh.rdl | |____ etc… |___ DB_Release_1.0 |____ sdo_tlm_acea.rdl |____ sdo_ptlm_acea.rdl |____ sdo_ttlm_acea.rdl |____ sdo_gtlm_cdh.rdl |____ etc… Command_rdl_Distribution |___ DB_Release_0.0 | |____ sdo_cmd_acea.rdl | |____ sdo_cmd_aceb.rdl | |____ sdo_gcmd_cdh.rdl | |____ etc… |___ DB_Release_1.0 |____ sdo_cmd_acea.rdl |____ sdo_gcmd_cdh.rdl |____ etc… Telemetry_Report_Distribution |___ DB_Release_0.0 | |____ sdo_pss_tlm_1.txt | |____ sdo_pss_tlm_2.rdl | |____ etc… |___ DB_Release_1.0 |____ sdo_pss_tlm_1.txt |____ sdo_pss_tlm_2.rdl |____ etc… Command_Report_Distribution |___ DB_Release_0.0 | |____ sdo_pss_cmd.txt | |____ etc… |___ DB_Release_1.0 |____ sdo_pss_cmd.txt |____ etc… Display_Page_Distribution |___ DB_Release_0.0 |___ DB_Release_1.0 STOL_Procedure_Distribution |___ DB_Release_0.0 | |____ acs_rwa1on | |____ etc… |___ DB_Release_1.0 |____ acs_rwa1on |____ etc…
Figure 8-7 Database Distribution Directory Structure
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
Appendix-A: Recommended Abbreviations and Acronyms for RDL, Telemetry and Command Naming Conventions
Abbreviation / Acronym Description Applicable
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
Appendix-A: Recommended Abbreviations and Acronyms for RDL, Telemetry and Command Naming Conventions
Abbreviation / Acronym Description Applicable
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
Appendix-A: Recommended Abbreviations and Acronyms for RDL, Telemetry and Command Naming Conventions
Abbreviation / Acronym Description Applicable
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
Appendix-A: Recommended Abbreviations and Acronyms for RDL, Telemetry and Command Naming Conventions
Abbreviation / Acronym Description Applicable
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
Abbreviation / Acronym Description Applicable
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
Abbreviation / Acronym Description Applicable
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
Abbreviation / Acronym Description Applicable
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
Abbreviation / Acronym Description Applicable
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
Abbreviation / Acronym Description Applicable
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
Abbreviation / Acronym Description Applicable
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