Conference and Exhibit on International Space Station ... Remote... · automated and does not require a person to define, initiate and terminate the telemetry delivery ... (PDL) Command

(c)2001 American Institute of Aeronautics & Astronautics or Published with Permission of Author(s) and/or Author(s)' Sponsoring Organization.

Conference and Exhibit on InternationalSpace Station Utilization - 2001,

Cape Canaveral, FL, Oct. 15-18, 2001 A01-42915 AIAA 2001-5029

PAYLOAD OPERATIONS INTEGRATION CENTER REMOTE OPERATIONS CAPABILITIESMichelle Schneider, NASA, Marshall Space Flight Center

Catherine C. Lapenta, NASA, Marshall Space Flight Center

ABSTRACTThe Payload Operations Integration Center (POIC)provides the capability for International SpaceStation (ISS) payload users to operate theirpayloads at their home sites. The capabilitiesinclude the ability to send commands and receivetelemetry from their ISS payload. In addition, thePOIC provides a software toolkit entitledTelescience Resource Kit (TReK). TReK providesboth local ground support system services and aninterface to utilize remote services provided by thePayload Operations Integration Center (POIC).Both the POIC remote capabilities and the TReKcapabilities are discussed in this paper.

INTRODUCTIONThe Payload Operations Integration Center (POIC)is an International Space Station (ISS) groundsystem that manages the execution of on-orbit ISSpayloads and payload support systems incoordination with the Space Station Control Center(SSCC), the distributed International Partner (IP)Payload Control Centers (PCC), TelescienceSupport Centers (TSC's), and other remote userfacilities. The POIC contains several data andnetwork systems that provide various capabilitiesto the remote user community. These systemsare the Payload Data Services System (PDSS),the Enhanced Huntsville Operations SupportCenter (HOSC) System (EHS), and the PayloadPlanning System (PPS). PDSS acquires, stores,and distributes ISS telemetry to the POIC cadre,International Partners, Telescience SupportCenters and other remote user facilities. The EHSperforms command processing and real-time andnear real-time telemetry processing for simulation,training, and flight operations. The PPS providesa set of software tools to automate planning andscheduling of payload activities. These systemswork in concert, as depicted in Figure 1, to allowremote users the ability to send commands andreceive telemetry from their ISS payloads.

Copyright © 2001 by the American Institute of Aeronautics andAstronautics, Inc. No copyright is asserted in the United Statesunder Title 17, U.S. Government has a royalty-free license toexercise all rights under the copyright claimed herein forGovernment Purposes. All other rights are reserved by thecopyright owner.

Figure 1 Overview of ISS Payload Telemetry andCommand Flow

POIC REMOTE TELEMETRY DISTRIBUTIONCAPABILITIES

Figure 2 depicts the ISS telemetry flow from theISS to the remote user sites along with thedifferent packet formats that are available to theremote user. The PDSS distributes packetizeddata in the PDSS Payload Consultative Committeeon Space Data Systems (CCSDS) format. PDSSutilizes User Datagram Protocol (UDP) to deliverthe packets to the remote user site. Detailsregarding the packet format can be found insection 8 of the POIC to Generic User InterfaceDefinition Document Volume 1, Revision B (SSP50305). Associated with the PDSS PayloadCCSDS packet is the PDSS User Data SummaryMessage (UDSM). The UDSM is transmitted tothe remote user when there is a Loss of Signal(LOS) condition between White Sands and thePOIC or between ISS and White Sands. TheUDSM contains data quality information for theremote user such as the number of CCSDSpackets transmitted during the last reportingperiod and number of packet sequence counterrors. The PDSS UDSM is also transported to theremote user site using UDP.

1American Institute of Aeronautics and Astronautics


SpaceShuttle

PC"IIP

PDSS

EHS-<-

1 »

0— 2 — »•-7—*

RemoteSite (I.P.,

TSC, or P.I.Site)

1. PDSS Payload & UDSM Packets (UDP)2. User Defined GSE Packets (UDP)

3. Custom Data Packets (TCP)

Figure 2 ISS Telemetry Flow and Available PacketTypes

Remote users receive their payload science datain the PDSS Payload CCSDS format. Remoteusers may also choose to receive from PDSS theISS payload health and status packets that containpayload health and status parameters from allactive payloads onboard the ISS. PDSS alsodistributes the ISS flight ancillary data packets thatcontain information about onboard systems andthe onboard environment. However, both thepayload health and status packets and the ISSflight ancillary packets contain tens of thousandsof parameters that the remote user may notrequire thus using the remote user's limitedbandwidth and processing power needlessly. ThePOIC has developed within the EHS two telemetrydistribution mechanisms to allow the remote userto create a user-defined packet that contains asubset of telemetry parameters. The first telemetrydistribution mechanism is the Ground SupportEquipment (GSE) packet. Users logon to the EHSsystem via a web interface to create the content ofthe GSE packet. Users can select parametersfrom the EHS telemetry database to be placed intheir GSE packet. Most parameters that are in theEHS telemetry database are available to all users.Typical parameters include the remote user'spayload health and status parameters and useful

flight ancillary data like cabin temperature orpressure or whatever is of value to the user'sexperiment. Once the user's GSE packet isdefined, a file is created that contains informationthat will help the user extract the parameters fromthe GSE packet. The remote user will use the filetransfer protocol to send this file to their remotecomputer so that it can be incorporated in theremote user's local telemetry processing software.After the remote user's system is ready to acceptthe GSE packet, the user can initiate the GSEpacket generation and distribution via the EHSweb interface. The GSE packet is sent to theuser via UDP. The GSE packet definition fileformat and the GSE packet format is described inthe POIC to Generic User Interface DefinitionDocument Volume 1, Revision B (SSP 50305).

The other telemetry distribution mechanism is theCustom Data Packet (CDP). Like the GSE packet,a CDP can contain any telemetry parameter fromthe EHS telemetry database that the user hasaccess to. However, a CDP is defined, generatedand distributed in an entirely different manner thanthe GSE packet. A CDP is defined, generated anddistributed to the remote user's site by the remoteuser's software sending a series of formattedmessages to the EHS. The CDP process is thusautomated and does not require a person todefine, initiate and terminate the telemetry deliveryprocess. It does however require that the remoteuser program their system to send and receive theappropriate messages. The CDP message andpacket formats are described in the POIC toGeneric User Interface Definition DocumentVolume 1, Revision B (SSP 50305). The CDP issent to the remote user using TransmissionControl Protocol (TCP) not UDP.

POIC REMOTE COMMAND CAPABILITIESThe POIC provides remote commandingcapabilities that allow a remote user the ability tosend commands to their ISS payloads, andreceive command responses, POIC commandsystem status, and POIC command configurationinformation. All remote user commands,responses and command information flow over thecommand connection between the remote usersite and the POIC as depicted in Figure 3. Once acommand reaches the POIC, it is sent from thePOIC to the SSCC and then to the ISS.

American Institute of Aeronautics and Astronautics


SpaceShuttle

PC)IC

EHS-<-

CommandConnection

RemoteSite (I.P.,

TSC, or P.I.Site)

Figure 3 ISS Command Flow

The POIC provides three types of commandrequests: a remotely generated commandrequest, a remotely initiated command request,and an update command request. The remotelygenerated command request allows the remoteuser to send the entire command uplink bit-patternto the POIC. The entire command uplink bit-pattern includes a predefined header and amodifiable data field. This allows flexibility on theremote user side by allowing the user to changethe data field of the command at their remote sitewithin their ground support equipment.

The remote user can also send a remotely initiatedcommand. Unlike the remotely generatedcommand, the remotely initiated commandcontains a predefined header and the name of thecommand mnemonic that is to be uplinked to theISS. Upon receipt of this type of commandrequest, the EHS will build the remote user'scommand uplink bit-pattern from the information inthe EHS command database. Remote usersprovide this information in the Payload DataLibrary's (PDL) Command and Data Handlingdataset during the pre-flight preparation process.If the remote user selects the option to use theremotely initiated command and the command hasmodifiable fields, the user can update these fieldsfrom their remote site using the update commandrequest capability. The remote user sends themodifiable field definitions to the EHS commanddatabase prior to initiation of the remotely initiated

command.

No matter which method is selected, the remoteuser receives command responses. Commandresponses indicate whether the remote user'scommand is successfully uplinked through to thePOIC, SSCC, ISS and their payload. In addition tocommand responses, the remote user receivescommand system status, command configuration,and command system configuration informationfrom the POIC. Examples of the type ofinformation available within these messagesinclude whether the remote user is enabled tocommand, a listing of all commands available tothe user and their enablement status, and detailson the configuration of the POIC command server.The POIC to Generic User Interface DefinitionDocument (SSP 50305), Volume 2 describes indetail the remote commanding interface.

REMOTE USER OPERATING LOCATIONSThe POIC resides at the Marshall Space FlightCenter within the Huntsville Operations SupportCenter (HOSC). The United States OperationsCenter (USOC) also resides within the HOSC andprovides an ISS host facility where payload userscan choose to control and monitor the operationsof their onboard payloads instead of being locatedremotely. The USOC users are provided withEHS workstations, access to POIC networks,facility space, and POIC voice and video systems.However this option is not the preferred option forISS payload operations. The POIC and the SpaceStation Utilization program are emphasizingremote operations. Users choosing remoteoperations are provided several data systemoptions for performing telemetry processing andcommanding at their location. The options are:

a. Use the Telescience Resource Kit (TReK)software as described in the followingsections.

b. Develop software on payload-uniqueGround Support Equipment using thePOIC to Generic User Interface DefinitionDocument (SSP 50305) to developtelemetry and command interfaces.

c. Combination of the two options.Regardless of what option the remote userselects, all remote users will use the POIC webapplications to perform a variety of payloadoperations tasks. These POIC web applicationsinclude:

• Payload Information Management System(PIMS)

• Payload Planning System



• Initiating/Terminating GSE packets• Defining GSE packets• Detailed listing of commands uplinked

through the POIC• Real-time display of commands recently

uplinked• ISS Ground Track Display• Acquisition of Signal (AOS)/Loss of Signal

(LOS) DisplayAdditional information about each of thesecapabilities can be found in the POIC CapabilitiesDocument (SSP 50304).

TELESCIENCE RESOURCE KITThe Telescience Resource Kit (TReK) is a suite ofPC-based software applications that can be usedto monitor and control a payload on board theInternational Space Station (ISS). TReK providesboth local ground support system services and aninterface to utilize remote services provided by thePayload Operations Integration Center (POIC).For example, TReK can be used to receivepayload data distributed by the POIC and toperform local data functions such as processingthe data, storing it in local files, and forwarding it toother computer systems. The TReK software isavailable free of charge from the Marshall SpaceFlight Center.

TELEMETRY SOURCESTReK can receive and process data from severaldifferent sources. As shown in Figure 4, TReKtypically receives data from the POIC, theSuitcase Simulator, and the TReK TrainingSimulator application. The POIC distributes PDSSPayload packets, PDSS UDSM packets, CDPpackets, and GSE packets. TReK can alsoreceive CCSDS packets from a Suitcase Simulatorsystem. Since data sources such as the POICand Suitcase Simulator are not always available,TReK includes a telemetry simulator tool (TrainingSimulator application) that can be used togenerate data. TReK can receive data from all ofthese sources simultaneously.

Payload Operation IntegrationCenter (POIC)

PDSS EHS(CDP/GSE)

PDSS Payload PacketsPDSS UDSM PacketsCustom Data Packets

GSE Packets

SuitcaseSimulator

TReK

TrainingSimulator

CCSDS Packets

TReK SimulatorPackets (PDSSPayload andCCSDS)

Figure 4 TReK Telemetry Sources

TELEMETRY SOFTWAREFigure 5 shows an overview of the TReK telemetrysoftware. There are three applications and onelibrary that provide telemetry services: TrainingSimulator, Telemetry Processing, TelemetryDatabase, and the Telemetry ApplicationProgramming Interface (API) library.



TReK Computer

Flow ofdata b

TReKData

StorageFile(s)

A L

TelemetryProcessingApplication

/— N

A

TLM API

TLM API

User Products

Visual C++ ®Application

Visual Basic ®Application

TLM APIOther UserApplication

ForwardedData

Figure 5 TReK Telemetry Software

TRAINING SIMULATORThe Training Simulator application is a trainingtool. It is used to simulate telemetry data fortraining purposes. This application can generatevarious types of telemetry packets such as PDSSPayload packets, GSE packets, and SuitcaseSimulator packets. This application can be usefulwhen learning how to use the TReK software. Itcan simulate a data source when the real datasource is unavailable. In some cases it can alsobe used to simulate a particular payload's datastream.

TELEMETRY PROCESSINGThe Telemetry Processing application is used toconfigure and control all TReK telemetry services.It is used to identify incoming data streams and tospecify what should be done with the data when itarrives. There are a variety of services availablesuch as data processing, data recording, datadisplay, data monitoring, and data forwarding.

DATA RECEIPTThe Telemetry Processing application can beconfigured to receive different types of data fromthe same data source simultaneously. Forexample, it is likely that most payload teams will

receive PDSS Payload packets and GSE packetsfrom the POIC at the same time. Additionally, thesame data stream can also arrive in different datamodes at the same time. When the ISS cannottransmit data to the ground, data is recorded on-board. Later, when transmission becomespossible, the recorded data is transmittedsimultaneously with real-time data. The recordeddata is labeled "dump data". The TelemetryProcessing application can be configured toreceive both the real-time data and dump datastreams simultaneously.

As mentioned earlier, it is also possible to receivedata from different data sources simultaneously.For example, the Telemetry Processingapplication can be configured to receive data fromthe POIC, Suitcase Simulator, and the TReKTraining Simulator application simultaneously.

Data can be received via the User DatagramProtocol (UDP) or the Transmission ControlProtocol (TCP). Multicast data is supported anddata can be received on multiple network cardssimultaneously.

DATA PROCESSINGThe Telemetry Processing application providesseveral different data processing options: Off,Pass Thru, and Process Entire Packet. Dataprocessing can be turned off. This can be useful ifa computer needs to be configured for a purposeother than processing. For example, somepayload teams set up a computer to receive dataand record it but nothing more. The Pass-Thrudata processing option specifies that incomingpackets should be retrieved from the network andstored in memory, but no further processingshould be performed. This option provides a wayto take advantage of network and real-time datastorage services without using the processingservice. The TReK software can be used toretrieve the data from the network, store the datain memory, and then hand-off the data to a user-developed program. The Process Entire Packetoption provides full data processing services. Ifthis option is selected, incoming packets will beretrieved from the network and the packet will bedecomposed into individual parameters. Forexample, suppose an incoming packet contains 4parameters (2 temperatures and 2 pressures).When the packet is processed, the entire packetand each of the 4 parameters will be stored inmemory. These values can then be retrievedusing the TReK User Application ProgrammingInterface library.



PARAMETER PROCESSINGOnce an unprocessed parameter (i.e., raw binarydata) has been extracted from an incomingtelemetry packet it can be converted, calibrated,and/or limit/expected state sensed. Conversionrefers to the translation of a binary pattern to anative PC data type such as an integer or a string.Calibration is the transformation of a parameter toa desired physical unit or text state code. Forexample, a converted value can be input into apolynomial equation thereby producing a"calibrated" value. These calibrated parameterscan then be "sensed" for limit, delta, or expectedstate violations. For example, limit sensing checksto see if a value is within a particular range ofvalues.

PARAMETER RECORDING (RELEASE 2)As parameters are extracted from an incomingpacket, they can be recorded in an unprocessed,converted, calibrated, or limit/expected statesensed format. The data is stored in a comma (orother) delimited ASCII file. This file can then beused in conjunction with a commercial softwareproduct such as Microsoft Excel® to analyze thedata.

DATA RECORDINGAs telemetry packets arrive they can be recorded.This recording feature stores the entireunprocessed packet (binary data) as soon as itarrives. The location of the "data recording files" isuser specified. The unprocessed packets storedin these files can be "played back" at a later time(as soon as the file is closed). When the data isplayed back, it is given a special playback datamode to differentiate it from other incoming datasuch as real-time data or dump data. The datarecording feature is useful for storing all incomingdata for analysis and troubleshooting purposes.

DATA FORWARDINGAs telemetry packets arrive they can be forwardedto one or more computers using UDP or TCP(TCP will be supported in Release 2). Theunprocessed packets can be forwarded to one ormore unicast or multicast addresses. When themachine has multiple network cards, the user canspecify what network card to use when forwardingdata.

DATA MONITORINGAs incoming telemetry packets are processed, theindividual parameters in the packet can be

monitored for limit/expected state violations.Monitoring can be performed for one or moreparameters. (This feature can be used only ifTReK is processing the packet). If monitoring hasbeen turned on for a parameter and the parameterarrives out of range or not in an expected state, auser-defined text message is generated anddisplayed in a window. Monitoring services can beturned on and off on a parameter basis.

DATA DISPLAYAs incoming telemetry packets are processed, theprocessed parameters can be displayed. Aparameter's unprocessed, converted, or calibratedvalue can be displayed (or any combinationthereof). The information displayed can alsoindicate limit/expected state sensing information.The parameter values are arranged in a textformat in a user-defined order. The display can becustomized using font and color properties. Whilethis is a simplistic data display tool, it can beuseful when it is necessary to generate a displayvery quickly and can be helpful with data analysisand troubleshooting.

DATA PLAYBACKOnce incoming data has been recorded using thedata recording feature, the data can be playedback. Data recording files are named according tocontent. For example, each file has a basefilename (a meaningful name to identify what dataresides in the file) and a start time and a stop timeto indicate the time associated with the data storedin the file. The timestamp used can be a TReKReceipt Time (the GMT corresponding to the timethe data arrived at the TReK system) or aSpacecraft Time (the time the data was generatedon-board the ISS). When configuring theTelemetry Processing application to perform aplayback, the user indicates what segment of datashould be played back using the start time andstop time. All the data can be played back, or justa segment of the data can be played back.Additionally, all other services are available. Thedata can be processed, recorded (again), orforwarded to other computers. The playbackfeature is useful for analyzing data or trouble-shooting.

Since most data arrives via the user datagramprotocol, it is possible for data to arrive out oforder. When data is played back, the user canspecify to re-order the data so it is played back inthe correct order based on the data's timestamp.(Release 2)



As mentioned earlier, it is possible to receive real-time data and dump data simultaneously. Thedata playback service provides a way to play thisdata back at the same time and merge the twodata streams. This provides a way to re-createthe data stream as it was output by the payloadon-board the ISS. When this merge is performed,there may be duplicate packets. For example,when data is recorded on-board the ISS, recordingoften starts while real-time data is still beingtransmitted. Therefore the same packet may bedownlinked twice, once in a real-time stream andonce in a dump stream. If TReK is recording thereal-time stream and the dump stream this meansthe same packet will appear in the real-time datarecording files and the dump data recording files.The data playback service provides a way tohandle this situation. When specifying a playbackthat contains both real-time data and dump datathe user can specify to remove duplicates. Thisprovides a way to merge the real-time stream andthe dump stream and to avoid playing back aduplicate packet that was stored in both sets ofrecording files.

PARAMETER EXTRACTION (RELEASE 2)While the playback service provides a way to playback the entire packet, parameter extractionprovides a way to retrieve individual parametersfrom one or more data recording files. Whenspecifying which parameters to retrieve, the usercan also specify whether the values should beunprocessed, converted, or calibrated values.Limit/expected state sensed information can alsobe requested. Once the parameters are retrievedfrom the data recording files, they are placed in acomma (or other) delimited ASCII file. This filecan then be used with a commercial softwareproduct such as Microsoft Excel® to analyze thedata.

TELEMETRY PACKET VIEWING(RELEASE 2)

Telemetry Packet viewing is available for all typesof telemetry packets. This capability provides away to view the contents of an incoming packet ina text/hexadecimal format

TELEMETRY PROCESSING STATISTICSTelemetry Statistics are collected and madeavailable for viewing. The statistics cover a varietyof information including the number of packetsreceived, the number of packets recorded, themaximum packet rate, and the number of

sequence errors that occurred.

TELEMETRY DATABASE APPLICATIONThe Telemetry Database application is a front-endfor the TReK Telemetry Database. The TReKTelemetry Database is a Microsoft Access®database that contains packet definitions andother information about how to process incomingdata. Packet definitions can be downloaded fromthe POIC and imported into the TelemetryDatabase. This includes PDSS Payload packetdefinitions and GSE Packet definitions. Databaseinformation can be viewed and modified using theTelemetry Database application or MicrosoftAccess®.

TELEMETRY APPLICATIONPROGRAMMING INTERFACE

The Telemetry Application Programming Interface(API) is a dynamic link library that contains over 70ANSI C functions. This library can be linked into acommercial software product and used to retrievetelemetry data in a variety of ways. For example,there are functions to retrieve an entire packet andfunctions to retrieve individual parametersextracted from a packet. When retrieving anindividual parameter, the value can be retrievedunprocessed, converted, or calibrated.Limit/expected state sensing information can alsobe retrieved. The API provides two types ofretrieval mechanisms: polling and signaling.Users can retrieve data by polling at a user-defined rate or can request to be signaled whendata arrives.

The API is important becomes it providesflexibility. Since it can be linked into anycommercial software product that supports anANSI C interface, it is possible to use the API witha variety of commercial software products such asMicrosoft Visual C++®, Microsoft Visual Basic®,Borland C++®, and Labview®. By using this libraryit is possible to create user-developed softwareprograms that access telemetry data beingprocessed by TReK. This provides an easy wayto create custom telemetry displays and otherprograms that perform data manipulation.

COMMAND SOFTWARE (RELEASE 21The TReK command software (shown in Figure 6)is a mirror image of the telemetry software. It iscomprised of three applications and one library:Command Trainer, Command Processing,



Command Database, and the Command API.

TReK Computer

Flow ofdata

User Products

Command Database

Figure 6 TReK Command Software

COMMAND TRAINERThe Command Trainer application is a trainingtool. It is used to simulate command servicesprovided by the POIC or a Suitcase Simulator.This is useful when you are learning how to usethe TReK software.

COMMAND PROCESSINGThe Command Processing application is used toconfigure and control all TReK command services.This application can be used to create a commandsession with a particular destination such as thePOIC or a Suitcase Simulator. A user canestablish multiple command sessions to be usedsimultaneously. Once a command session isestablished, any of the services available for thatspecific type of command session (destination)can be used. Services will differ based on thedestination. For example, when a command issent to the POIC one or more commandresponses will be returned. When a command issent to the Suitcase Simulator no commandresponses will be returned since the SuitcaseSimulator does not generate command responses.Each of the capabilities described below willprovide more information about the differencesbetween the POIC and the Suitcase Simulator.

STATUS AND CONFIGURATIONINFORMATION

When a command connection is established with

the POIC, the POIC returns three types ofinformation: status information (e.g. POICcommand system enabled/disabled status),configuration information (e.g. number ofcommand retries), and a list of the commands thatcorrespond to the POIC user ID that was used toestablish the connection. This information isavailable through the Command Processingapplication and the Command API. The SuitcaseSimulator does not provide any type of status orconfiguration information.

REMOTELY INITIATED COMMANDSRemotely Initiated Commands can be sent fromthe Command Processing application or throughthe Command API. This capability is onlyavailable for POIC command sessions. When aremotely initiated command is sent, the POIC usesinformation in the POIC command database togenerate a binary uplink pattern for the command.Therefore, it is important to ensure that thecommand data stored in the POIC database iscorrect. Once the command uplink pattern isgenerated it is sent to the Space Station ControlCenter for uplink.

COMMAND UPDATESThe TReK command software supports two typesof command updates: local updates and POICupdates. If a command definition resides in thelocal TReK command database, a commandupdate can be performed to update the contents ofthe command. Additionally, the POIC provides aremote service to update the contents of acommand that resides in the POIC commanddatabase. Both types of updates can be madefrom the Command Processing application or theCommand API.

COMMAND RESPONSESThe POIC generates six types of commandresponses. When the POIC receives a commandfrom a remote site, one or more of theseresponses are generated and sent back to theremote site. The TReK command softwareprocesses these responses as they are received.Each individual response is available through theCommand Processing application and theCommand API.

COMMAND TRACKINGThe TReK command software tracks allcommands that it sends (regardless ofdestination). Command track information includesthe name of the command, the time the command



was sent, and Information about the number andtype of command responses received for thatcommand. Command track information can besorted and filtered based on any of the criteria justdescribed.

COMMAND SESSION VIEWINGCommand Session viewing is available for bothPOIC and Suitcase Simulator destinations. Thiscapability provides a way to view allcommunication that occurs between TReK and aspecific destination. The output provides atranscript of the command data (commands,responses, etc.) that is exchanged during acommand session.

COMMAND SESSION RECORDINGCommand Session recording is available for bothPOIC and Suitcase Simulator destinations. Thiscapability provides a way to record allcommunication that occurs between TReK and thedestination. This data is stored in one or morefiles in a binary format. Each filename iscomposed of a base name, a start time, and astop time. These files can be searched based ona specific time segment and the data can then beviewed in a text/hexadecimal format. This outputprovides a transcript of the command data(commands, responses, etc.) that was exchangedduring a particular timeframe.

COMMAND STATISTICSCommand processing statistics are collected andmade available for viewing. These statisticsprovide information about the number ofcommands sent and the number of responsesreceived.

COMMAND DATABASE APPLICATIONThe Command Database application is a front-endto the TReK Command Database. The TReKCommand Database is a Microsoft Access®database that contains command definitions andother information needed to support commanding.Command data can be downloaded from the POICand imported into the TReK Command Database.It can also be entered using the CommandDatabase application or Microsoft Access®.

COMMAND APPLICATION PROGRAMMINGINTERFACEThe Command API is a dynamic linked library thatcontains ANSI C functions for performingcommand functions. The Command API providesa software interface to perform many of the

functions provided through the CommandProcessing application. For example, theCommand API can be used to retrieve status andconfiguration information for a POIC commandsession, send a remotely initiated commandrequest to the POIC, update a command thatresides in the local TReK database, or update acommand that resides in the POIC commanddatabase. In addition to these functions, the APIcan also be used to send remotely generatedcommands. Unlike remotely initiated commands,remotely generated commands are commandsthat are built by the remote site and then sent to adestination. This type of command request issupported by the POIC and is the only type ofcommand request supported by the SuitcaseSimulator. The TReK command software providesthree different ways to work with remotelygenerated commands: (1) TReK generates thecomplete bit-pattern for the command, (2) TReKgenerates the header portion of the command andthe data zone is provided by a user-developedsoftware program, (3) A user developed softwareprogram generates the complete bit-pattern for thecommand (header and data zone). In option 1,the TReK software uses the command data thatresides in the local TReK command database togenerate the bit-pattern for the command. Thiswill include the header and the data zone. Thisbit-pattern will then be sent to the POIC. In option2, the TReK software uses local command datathat resides in the local TReK database togenerate the command header, but the data zoneportion of the command is passed in from a user-developed software program. In option 3, theuser-developed software program generates thecommand's complete bit-pattern (header and datazone) and the TReK software just passes this onto the POIC without any further processing. Ifoption 3 is used, it is not necessary to store anyinformation about the command in the local TReKcommand database.

COMBINING THE TELEMETRY AND COMMANDAPI LIBRARIESThe Telemetry API and the Command API can becombined and used in a single user-developedprogram to perform both telemetry and commandfunctions.

PERFORMANCE AND DATA RATESTReK performance is based on many differentfactors including processor speed, the amount ofmemory available, the number of data packetsingested simultaneously, whether the packets



ingested are also processed, the number of otherprocesses running on the machine, etc. The datarates that can be supported by a TReK systemmust be quantified with respect to these variables.It is not sufficient to state that a TReK System cansupport a 5Mbit/sec data rate. This value ismeaningless unless it is qualified with informationabout the other variables listed above. Therefore,a suite of tests have been developed that takethese considerations into account. These testshave been run using various hardware andsoftware configurations. The configurations andcorresponding performance data are available onthe TReK Web Site.

CUSTOMER SUPPORTThe TReK development team provides customersupport in a variety of ways: TReK Web Site, BetaSoftware Testing Program, Training Classes,TReK Help Desk, and TReK E-Mail Support.

TREK WEB SITEThe TReK Web Site is an important resource forTReK users. It contains information about theTReK schedule, the content of each TReKrelease, frequently asked questions, hardware andsoftware requirements, and performance data.The web site is also used to distribute the TReKsoftware (beta releases, operational releases, andpatches). All TReK customers, both potential andexisting customers, are highly encouraged to visitthe TReK Web Site (http://trek.msfc.nasa.gov) formore detailed information about TReK.

BETA SOFTWARE TESTING PROGRAMThe Beta Software Testing Program wasestablished to provide a way for potential andexisting TReK customers to test drive the TReKsoftware. This is the best way for customerslocated anywhere in the world to review andprovide inputs on the software. Although this iscalled "beta" software, it is tested quite extensivelybefore it is made available and is alwaysaccompanied by a complete set of documentation.One or more beta releases are made available inthe time period leading up to an operationalrelease. The beta program provides anopportunity for customers to interact directly withTReK developers, and to help guide the directionof the TReK product.

TRAINING CLASSESThe TReK development team provides TReKtraining classes on an as-needed basis. Theseclasses are tailored to the need of the payload

team requesting the training. The classes can beorganized as a one hour overview or an in-depthall day training class.

TREK HELP DESKThe TReK Help Desk is available during normalbusiness hours and provides technical support forthe TReK software. During flight, payload teamsare requested to contact the HOSC Help Desk forassistance since many operational issues are bestfielded by the HOSC.

TREK E-MAIL SUPPORTThe TReK E-Mail Support Line provides a way forcustomers to e-mail in questions, requests forenhancements, comments, or problem reportsabout the TReK software. When an e-mailmessage is sent to the TReK e-mail supportaddress, the message is sent to all developers onthe TReK development team. This ensures atimely response by a knowledgeable teammember.

CONCLUSIONThe POIC provides command and telemetrycapabilities that enable the remote user to performtheir payload operations at their home site. Inaddition, the TReK software makes it even easierfor the remote user as it provides freely availablesoftware to perform both the command andtelemetry functions. For further information orquestions regarding the POIC interfaces, pleasecontact Catherine C. Lapenta(Cathy.Lapenta® msfc.nasa.gov). For furtherinformation or questions regarding the TReKsoftware, please contact Michelle Schneider([email protected]).


Documents

Conference and Exhibit on International Space Station ... Remote... · automated and does not require a person to define, initiate and terminate the telemetry delivery ... (PDL) Command