Srarensen - Ntrs.nasa.gov
G.4E. M. SrarensenEuropean Space operations Centre, Dannstadt, GermanyTRACTThe European Retrieval Carrier (EURECA) waslaunched on its first flight on the 31st July 1992 bythe Space Shuttle Atlantis. EURECA ischaracter&& by several new on-board features,most notable Packet Telemetry and a partialimplementation of Packet Telmmmanding usingan early version of the Command Operationprocedure (COP-1) PO OCO . EURECA h a alsovery low contact time with its Ground Station, witha consequent high number of out-of-visibility onboard operations. This paper concentrates on theimplementation and opational experience with theCOP-1 Protocol and the effect the short groundcontact time has on the design of the CommandingSystem. Another interesting feature is that theCOP-1 is implemented at the Control Centre ratherthan at the Ground Station. The COP-1 protocolalso successfully supported the mission during theLaunch where commmds were sent via NASCOMand the Shuttle.Key Words: Packet Telmmmanding, COP-1protocol. Command Verification.1. INTRODUCTIONThe EuFopean Retrievable Carrier (EURECA) is areusable platform supplyingpower. coolig, groundcommunications and data prooessing services to avariety of independently-operated payloads (ref 1).Fifteen experimental facilities are carried to supportmore than fifty individual experiments, mostrelying on the microgravitationalenvironment. Theoperational altitude is 500 Km. The OperationsControl Centre (OCC)is at ESA's European Spaceoperations Centre (ESOC) in Dannstadt,Germany. The primary groundstations are atMaspalomas in the Canary Islands and Kourou atFrench Guinea. During the deployment andretrieval phases contact is maintained via theNASA Communications Network and the STS.513At ESOC, operational data procesSing is carriedout on the Eureca Dedicated Computer System(EDCS) that hosts the mission-configuredSpacecraft Control and Operations System (SCOS)(ref 2) and the Eureca-Specific Software (ESS)applications.The Eureca-A1 mission has characteristicsdifferingquite considerably from those of missions hithertosupported at ESOC. One of these is the use ofPacket Telemetry and Packet Commanding. Eurecais the first ESA application of Packet Telemetryand TRYEureca's telemetry is packetised Bccoliding tostandards based on a Recommendation of theConsultative Committee for Space Data Systems(CCSDS), ref. 3.The Packet telemetry recommendation (ref. 3) usestwo principal data structures, the source packet m dpackets beingthe Transfer Frame, somultiplexed within transfer frames. Each on-boardsource must label its data packets using CCSDSdefined headers. The transfer frames are of fixedlength, optimised for high-pedormancetransfer tothe ground. For Telecommand veri6cation eachTransfer Frame has attached a Command Linkconttol Word (CLWthat is used by the COP-1Protocol. The CLCW is essentially meant to beused in automated trrmsmissidretransmissionprocesses. Therefwe, CLCW data must bedelivered error free to the sending end of theTelmmmanding system. The protocol infonnationcontained in the CLCW is such that it is notrequired that the Telemewy Transfer Frame ratematch the Telmmmand Block Rate. However,some minimum CLCW sampling rate must beestablished for the p r o p operation of the COP-1protocol.
the way it has been implemented on board.Command decoders using the old standard havebeen used as a basis, but the extra services of thepacket commanding have been built into theOn-Board Computer (OBC). Thus when the OBCis nominally activated, the commanding system actslike a packet command system, using a subset ofCOP-1 of the standard (ref. 5). If the OBC is off,the old standard has to be used.3.COP-1 PROTOCOLNOTE: In this section, although the word COP-1is used, EURECA has only implemented a subsetof the COP-1. The EURECA terminology endservices are not completely compatible with thelatest issue of the CCSDS recommendation.COP-1 is a closed-loop Telecommand P r o t m l thatutilises sequential ("go-back-n") retransmissiontechniques to coect Telecommand Blocks thatwere rejected by the spacecraft because of error.COP-1 allows Telecommand Blocks to be acceptedby the spacecraft only if they are received in strictsequential order. This is controlled by thenecessary presence of a standard return data reportin the telemetry downlink, the command LinkControl Word (CLCW). A timer is used to causeretransmission of a Telecommand Block if theexpected response is not received, with a limit onthe number of automatic retransmissions allowedbefore the higher layer is notified that there areproblems in sending Telecommend Blocks. Theretransmission mechanism e suresthat:Figure 3.14.EURECA COP-1 ProtocolIMPLEMENTATION OF THE COP-1PROTOCOLThe EURECA Commanding system only uses asmall subset of the COP-1 services and the commanding system was designed before the COP-1standard was available. In the event, it provedimpossible to develop this general infrastructureequipment containing the EURECA standard andthe COP-1 in the required time scale. It was therefon, decided to use a Mark II Telecommanddecoder (supporting the old ESA standard) andimplement all the necessary packet block buildingand p r o t m l execution in software within thespacecraft control system at the Control Centre.Figure 4.1 gives an overview of the EDCSimplementation of the COP-1 Protocol whencommanding via an ESA Ground Station.No Telecommand Block is lostNo Telecommand Block is duplicatedNo TeleGommand Block is delivered outof sequenceThe COP-1 protocol has also an expedited service.This service is used for exceptional spacecraftcommunications.Typically, this service is requiredfor recovery in abseace of telemetry downlink (Leno CLCW). or during unexpected situationsrequiting unimpaired access to the spaceaaft datamanagement system.Figure 3.1 gives a simplified overview of theEURECA COP-1 Protocol.514The basic principle is that all the additional packetblock building and protocol execution ass0ciatedwith the packet Telecommand Standard areperformed within the spacecraft control system atthe OCC. The ground network and stationequipment is only used to traolsport these datasmctures from the control centre to the spaceaaft.4.1COP-1 VIA NASCOMFor Eureca the possibilities exist to transmittelecommaads via NASA facilities(NASCOMMCC) and via ESA ground stations.The first is only oeeded during the launch and earlyorbit phase and retrieval. The latter is in additionneeded for the routine phase. The commanding via
PROTOCOLFigure 4.1 EURECA Implementationof the COP- 1ProtocolNASA facilities is complex, for two C BSMIS:firstthe difFezent NASA ground system forcommanding. seoondly, the users required acommand interface that looked the same as that forcommanding via ESA statioos (except possibly forresponse times); they require for example a similarmanual command interface and automatic commanding; where real-time telemetry is availableon-line they also require common verification.Figure 4.2 gives an overview of the EDCSimplementation of the COP-1 protocol whencommanding via NASA.COP-1 I M P M E N T A (VIAN NASA)The COP-1 protocol is only designed to provide theservices between two COP-1 protocol machiies oneon-ground and one on-board.In terms of networklayem the COP-1 protocol can by classified as atransport layer. The COP-1 does not provide anend-to-end transport service. It is the responsibilityof the implementer to develop any required HigherLayer protocols using the underlying services ofthe COP-1 protocol. Additional protocols may alsorequired when multiple sources on the ground areaccessing the same COP-1 machime.B e COP-1 Sequeuce-Controlled Service isnormally initiated by means of Service Directives.However in case of ground failures it may benecessary to include additional higher layerprotoo01 elements to initiate the COP-1 servicesproper. This is also required to resynbetween multiple ground users and on-boardusas.To allow EURECA to operate autonomously,EURECA executes commands from its on-boardMaster Schedule. To support the uplink of theMaster Sddule EUREKA has implemented acommand insert counter which is reported in theHousekeeping Telemetry. This counter is used inoperational pracedures to restsat the uplink of theMaster Schedule in case of any ground failure.4.3OPERATIONALEXPERIENCE WITHCOP-1There have been a number of occasion where thehas xessfullyrecoveredCOP-1 1error. These cases all coneems link degradation,and involved the following circumstances:1.During the Deployment phase with a badRF link between the Shuttle and EURECA2.During the Deploymeat phase where theEDCS did not receive a CommandAcceptance Pattern (CAP)from NASA.3.Figure 4.2 EURECA implementationof COP-1 viaNASAwrong antennae.4.515During ESA ground station passes wherethe spaceaaft was configured with theDuring ESA ground passes wherecommanding was executed down to 00
5.6.aTelecommand buffer (due to anoverload condition).OBCAlthough not all of the above cases were foreseenin the design of the COP-1protocol (in particularcase 2 and 6) the COP-1 protocol has alwayssuccessfully recovered the error with a maximumof two re?ries. It is also important that duringEURECA routine operations with a n m d linkbudget the COP-1protocol has never been in retry(i.e no trausmission mors).5.LOW CONTACT RATIO5.1MAIN DRIVER REQUIREMENTS ONCOMMANDING SYSTEMThis delay result in three significant requirementson the grouad system.1.The Master Schedule's acceptance of timetagged commands and their subsequentrelease to end users must be emulated.This on-ground maintained image of theon-board commanding provides theoperatioas staff an iadired presentation ofthe oa-board commanding activities andthe status of verification.2.Before e&pass the commanding systemshall prepare, an 'expected status of thespaemaft' using a defined subset ofhousekeepingparametexs.Thisispreparedunder the assumption that all commandsnot known to have f d e d have sucoeeded.As the telemetry parameters are receivedthey are compared with the expectedvalues, alarms beiig raised whendifferences are detected. This 'quick look'approach may deted c o d failuresThe majority of EURECA's operations areexecuted outside contact periods. Thus a commanduplinked at time T may be time-tagged forexecution at T 10 Hours and so will be held onthe on-board master schedule. The relevantneoessary telemetry to verify the execution of thiscommand might not be downlinked until T 18H o w , and subsequently processed to yield thefinal verification result at T 19 Hours. This isillustrated schematic in figure 5.1.hours before traditional verification cantake place sod permit correczive actiotls tobe taken within the same pass.3.The commanding system must be able toverifycommsllcIsusingReal-TimeT e l m and Playback Telemetry. ForWRECA playback telemetry will neverAvailability of Spacecraft Telemetry- raftarrive interleaved with real-time telemetry.However playback must arrive inchronological order, but the time ofarrival is not significant.tlnr5.2COMMAND VERIFICATIONTbe basic mechanism for command verification isthat all commands to be verified will have averification window. The start of this window isthe earliest time that the telemetry could be af t?ctedby the execution of the oommand and the end ofthe window is the time at which, if the commandFigure 5.1 Relation between spaaxraft generateddata and the arrival at the OCC.Figure 5.1 shows an example of five passes startingwith a short pass folluwed by three long passes andending with a short pass. During this pass sequeucethe on-board mass memory unit is dumped twice516executes successfully. the telemetry must have beenaffected. If the verification criteria are met in thetelemetry during the time window then thecommand is passed successfully; if the aditionshave not been met at the end of the window thenthe next telemetry received decides pass or fail ofthecommand.
eatiothe mBter schedule.Verification of delivery at on-boarddestination using the end user generatedAcknowledgement packets.2.3.Execution Verification usingEURECA Report Packets.4.Execution VerificationHousekeeping Packets.6.1COP-1 PROTOCOL1.The COP-1 protocol has proven to be veryreliable and is able to recover transmissionetMc with minimal operational impact.2.It is possible to implement the COP-1protocol at the control centre usingexisting infnrstnrcture such Bs the ESAMARK II Telecommand Controller andthe NASCOM Remote CommandFecilities3.The design of the Control Centre mustconsider e n d - t o a d protocols and provideelements that make it possible to recoverin case of ground failures. The designmust also consider the infrastructure to bespecialusingtheFigure 5.2 illustrates the EURECA n of Packet Telemetry andTelecommand is a major step towardsstandardisation of on-board and groundsystems. To fully archive this goal it willbe necessary to define standards governingend-to-end protocols such as File TransferProtocol that are required to maintain onboard Master Schedules, and to supporton-board software maintenance.5.The distribution of protocol handlingWoundSystemFigure 5.2 VerificationCommand verification is theFefore described by avector, rather than a simple success/fail indication.Thus an example; could be 'uplink successful',acknowledged in real time', report packetreceived', 'housekeeping confirmation not yetavailable'. Some 26 such combinations acepossible. command verification also involvespFocessing of various special packets associatedwith commanding, namely Acknowledge, Reportand Exception packets, as well as traditionalverification based upon changes in telemetryparameters. These may be found in real-timeTelemetry andor Playback Telemetry, whicharrives at the OCC at different times.517between the Ground Station and theConaol Centre has to be considered takinginto account the mission requiremeots. Inthe E U R E U case where commanding isvia ESA ground stations and via NASA itis desirable to implement the protocol atthe control centre. This implementationalso allows the COP-1 to recover in caseof ground link e rops. In other cases itmight be considered to close the COP-1protocol at the Ground Station. This mightbe attractive if commanding is consideredtime critical because all time criticalfunctions are mcentrated in the f r o n t a dGround Stations. This is particularly truefor the closed-loop operations of the COP1 protocol.
6.1.delay may be introduced whenprotocol performs retries.COP-12.pd Control System- SCOS," 1988, ESA Bulletin 56.LOW CONTACT RATIO1.The expected status is proven to be veryuseful. It gives the operational st& aprewarning and often triggeis anemergency dump Of on-board Storedtelemetry necessaryfor furtherinvestigation of the problem.3.The EURECA verification implementationis based on one Verification window percommand. However this w i n k can bec l d by the arrival of any TelesnetryPacket. This has caused p b l e m s becausesome on-board users have problemsmaintaining time synchronisation with theOBC and their local clock have thereforedrifted into the future. The arrival of apacket with future time causes verificationwindows for other commands be falselyclosed. It should therefore be consideredto make the closing of the commandverification window telemetry packetSpecific.7.J-F and Mazza C., "A NewGeneration of S622.KaufelerCONCLUSIONAt the time of writing (October 1992) EURECAhas beea successfulIy supported by the Controlcentre for 3 months. During this time the EDCShas successfully received and pmcased over 10million telemetry packets and over 60000c o m m w has been sent. The COP-1 protocol hasp e n to be very reliable and given the operationalstaff much confidence in the EURECAcommanding system.The low contact ratio for EURECA has p v e n notto be a major problem. Tbe functions p v i d e d bythe EDCS gives the operational staf sufficientinformation for quick assessment of the status ofthe spaaxraft during the short pctsses.5184.Consultative Gommittee for Space DataSystems, 1984,'Recommendaton forSpace Data System Standaads: PacketTelemetry', "Blue Book".pcMTelecommandstaodardlEsAPSS-45Issue 1 April 19785.Consultative Committee for Space DataSystems, 1986, 'Recommendation forSpace Data System Standards: Telecommand, Part-2: Data Routing Servive, Architectural Specification'. "Blue Book".
Packet Telemetry and Commanding. Eureca is the first ESA application of Packet Telemetry and Commanding. 2. PACKET TELEMETRY AND C0MMAM)ING 2.1 TELEMETRY Eureca's telemetry is packetised Bccoliding to standards based on a Recommendation of the Consu
to the NASA Technical Report Server—Registered (NTRS Reg) and NASA Technical Report Server— Public (NTRS) thus providing one of the largest collections of aeronautical and space science STI in the world. Results are published in both non-NASA channels and by NASA in the NASA STI Report Series, wh
to the NASA Technical Report Server—Registered (NTRS Reg) and NASA Technical Report Server— Public (NTRS) thus providing one of the largest collections of aeronautical and space science STI in the world. Results are published in both non-NASA channels and by NASA in the NASA STI Report Series, wh
The NASA STI program provides access to the NTRS Registered and its public interface, the NASA Technical Reports Server, thus providing one of the largest collections of aeronautical and space science STI in the world. Results are published in both non-NASA channels and by NASA in the NASA STI Report Series, which includes the following report
The NASA STI Program operates under the auspices of the Agency Chief Information Officer. It collects, organizes, provides for archiving, and disseminates NASA’s STI. The NASA STI Program provides access to the NASA Technical Report Server—Registered (NTRS Reg) and NASA Technical Report Server
NASA’s STI. The NASA STI program provides access to the NTRS Registered and its public interface, the NASA Technical Reports Server, thus providing one of the largest collections of aeronautical and space science STI in the world. Results are published in both non-NASA channels and by NASA
Page 3; RBSP CDF Training SPDF Names and Roles Bob McGuire (Project scientist) robert.e.mcguire@nasa.gov John Cooper (Chief scientist) john.f.cooper@nasa.gov Bobby Candey (Lead system architect) robert.m.candey@nasa.gov Tami Kovalick (Lead system s/w developer) tamara.j.kovalick@nasa.gov Science - Dieter Bilitza (ITM discipline scientist), dieter.bilitza@nasa.gov
2016 nasa 0 29 nasa-std-8739.4 rev a cha workmanship standard for crimping, interconnecting cables, harnesses, and wiring 2016 nasa 0 30 nasa-hdbk-4008 w/chg 1 programmable logic devices (pld) handbook 2016 nasa 0 31 nasa-std-6016 rev a standard materials and processes requirements for spacecraft 2016 nasa 0 32
Reading: Literature Second Grade Key Ideas and Details Range of Reading and Level of Text Complexity Craft and Structure Integration of Knowledge and Ideas. Indicator Date Taught Date Retaught Date Reviewed Date Assessed Date Re-Assessed CCSS.ELA-LITERACY.RI.2.1 I can ask and answer who, what, where, when, why and how questions to show that I understand nonfiction. CCSS.ELA-LITERACY.RI.2.2 I .
