Telecommand and Telemetry Components for Today and …

1 Telecommand AND Telemetry COMPONENTSFOR Today AND TOMORROWP. Sinander, S. HabincControl, Data and Power Division, Directorate of Technical and Operational Support European Space Agency, PO. Box 299, NL-2200 AG, The Netherlandsphone: +31-71-565 65 65, fax: +31-71-565 4295 e-mail: CCSDS Telecommand (TC) and Telemetry (TM)standards are Today being employed for a large number ofscientific and commercial spacecraft. Using this standardallows reduced costs for on-board, ground and testequipment, as well as for spacecraft testing and in-orbitoperation. This paper introduces the CCSDS/ESA standards,and presents the supporting standard Components developedby ESA and a typical TM/TC system based on thesecomponents. Some examples of spacecraft using thesecomponents are then round off the paper a new concept for essential telemetryretrieval is introduced.

2 Some issues for future developmentsof TM/TC Components are listed, intended as a first input fordiscussions on the development approach and priorities. Theobjective would be to allow significant reduction inspacecraft cost by higher level of integration and by allowingthe same equipment to be used for commercial and PACKET TELECOMMANDThe purpose of Telecommand is to control the spacecraftbehaviour from a remote location, usually being a groundstation. The fundamental capabilities include a direct controlof the critical spacecraft functions, referred to as DirectTelecommand, and the provision of commands and data tothe Data Handling computer and/or other subsystems on-board the ESA/CCSDS standardThe ESA Packet Telecommand Standard [1] is directlyderived from the corresponding CCSDS standard, and definesthe requirements on error detection and correction, protocolsfor the data transfer, etc.

3 The accompanying TelecommandDecoder Specification [2] specifies standard interfaces forthe TC Decoder, as well as complementary functions such asthe Command Pulse Distribution Unit (CPDU) and aprocedure for authentication of the Telecommand Packet Telecommand (TC) Frame has a variable length,each TC Frame containing exactly one TC Segment. A TCSegment consists of a one-byte Segment Header followed bythe rest of the segment, which can be a (part of a) Packet, oranother type of data structure. Packets and data structureslonger than 249 bytes must be transmitted using several TCFrames. The five-byte TC Frame Header contains theSpacecraft Identifier, the sequence count etc. The completeTC Frame is protected against data corruption using a 16-bitCyclic Redundancy Check (CRC) improve the frame rejection ratio the TC Frame is splitinto seven-byte parts, each part having an added one-byteerror correcting Bose-Chaudhuri-Hocquenghem (BCH) code,together forming a number of eight-byte Code Blocks.

4 Thelast Code Block is normally completed with a fill patternafter the last byte of the TC Frame, in order to obtain exactlyeight bytes. All Code Blocks making up one TC Framepreceded with a 16-bit Start Sequence and ended with a TailSequence (a Code Block with multiple errors) are called aCommand Link Transfer Unit (CLTU), shown in figure 1: Telecommand CLTU2 bytes1 to 249 bytesHeaderFrame data field5 bytes CRC2 bytes7 bytesStartSequenceData BCHData BCHTailSequenceFillpatternData BCH BCH18 bytes8 bytes8 bytesThere are three types of TC Frames: AD ("Automated Data") Frames utilise a protocol withsequence verification and automatic retransmissioncalled COP-1, ensuring that the TC Segments arereceived in the correct order; BC ("Bypass Control") Frames are used to control the on-board part of the COP-1 protocol machine.

5 BD ("Bypass Data") Frames are accepted without thesequence order for the COP-1 protocol to work properly theCommand Link Control Word (CLCW) is provided to theground as part of the TM Frame trailer. In case of down-linkfailure, BD Frames can be used bypassing the automaticsequence The Packet Telecommand Decoder (PTCD)The Packet Telecommand Decoder (PTCD) is a radiationhard, latch-up free single-chip implementation of a TCDecoder core. The PTCD is a full implementation of, andfully compliant with, the relevant ESA standards [1] [2]. It ismanufactured in the MITEL SOS5 CMOS/SOS technology,having low power consumption and very low Single EventUpset (SEU) sensitivity. It is packaged in a 132-pin ceramicquad flat-pack. The PTCD will be available as an ApplicationSpecific Standard Product (ASSP) from MITELS emiconductor under device number MS13545 in PTCD replaces the MA28140 PTD device discontinuedby GEC-Plessey Semiconductors in the beginning of 1998.

6 Itis a direct transfer of the PTD design, functionally identicalwith two minor enhancements, using the same package andpinout, although with a change from TTL levels to CMOS levels on some inputs. The PTCD is therefore virtually "drop-in" compatible with the previous PTD PTCD has six inputs supporting a maximum bit rate of100 kbit/s, also when authentication (see below) is bit rates are possible, although retransmission couldbe required for worst-case sequences of minimum andmaximum length TC Segments. The PTCD is searching forthe Start Sequence on all inputs simultaneously, until it isdetected at one of the inputs. It then accepts all Code Blocksof a CLTU from that input, correcting single-bit errors whendetected, and removing the error correcting codes. When theTail Sequence is detected, the PTCD resumes searching for anew Start Sequence on all received candidate TC Frame is verified to CRC,frame length, spacecraft identifier etc.

7 If it is an AD Frame, itwill only be accepted if in correct sequence. If necessary,retransmission of missing AD Frames is requested throughthe CLCW. Accepted TC Segments are output through eithera serial Multiplexed Access Point (MAP) interface or a 16-bitCPU-type parallel interface. The MAP identifier contained inthe TC Segment Header is an address for directing the TCSegment to one of 64 different PTCD has an on-chip Authentication Unit (AU), whichwhen enabled prevents unauthorised commanding of thespacecraft. The AU verifies a 5-byte signature placed aftereach TC Segment to be authenticated. The signature iscalculated using a complex "unbreakable" algorithm. WhichMAP addresses require authentication is , an external AU can be connected to the PTCD,in case another authentication algorithm or TC Segmentencryption is PTCD on-chip Command Pulse Distribution Unit(CPDU) is intended for critical control of the spacecraft,referred to as Direct Telecommand .

8 After verifying theCPDU Packet in the TC Segment, the CPDU sequentiallyexecutes the commands contained in it (up to 120 commandsin one CPDU Packet). For each command one of 256 outputsis activated for a specified following status reports are available from the PTCD: Part of the Command Link Control Word (CLCW); The Frame Analysis Report (FAR); The AU Status Report (AUSR); The CPDU Status Report (CPDUSR).The CLCW is required for proper operation of the ADservice, and the PTCD has two redundant serial interfaceswhich are directly compatible with the TM Encoder (seefurther on). The three other reports can be retrieved by theData Handling computer either using a serial interface or thesame parallel interface as for the TC Segments. They arevaluable for subsystem testing on ground and for determiningthe TC Decoder status PTCD automatically starts operating after power-onwithout any programming being needed.

9 All mission specificparameters are stored in an external Programmable ReadOnly Memory (PROM). In addition, an external two KbytesRandom Access Memory (RAM) is needed for temporarystorage of the received TC Frames. Since the TC Decoder isthe only control connection from ground, it must always beoperational and shall never be switched off or reset PACKET TELEMETRYThe purpose of Telemetry is to provide status and data fromthe spacecraft platform and payload to a remote location,usually being a ground ESA/CCSDS standardThe ESA Packet Telemetry Standard [3] is directly derivedfrom the corresponding CCSDS standard. The PacketTelemetry Frame has a fixed, mission-dependent length. Theoriginal CCSDS standard TM Frame length for cross supportis 1115 bytes, but in principle any Frame length is using Reed-Solomon encoding, the TM Frame lengthshould preferably be a multiple of 223 bytes.

10 Since the TMFrame length is fixed and the packets can be of variablelength, the TM Frame Header contains a pointer to where inthe TM Frame the first packet is located. Subsequent packetpositions within the TM Frame can then be found by addingthe packet lengths. Since the packet can be much smaller orlarger than the Frame, a TM Frame can contain many smallpackets, or only a part of one large packet. The six-bytePrimary Header contains Spacecraft Identifier, sequencecounts etc. When enabled, the optional four-byte SecondaryHeader contains an extension to the Virtual Channelsequence a Packet TM/TC system the CLCW from the TC Decoderis transported as part of the TM Frame Trailer. The TMFrame must be error-protected since an error in the CLCW status will disturb the COP-1 protocol.