[IEEE 2008 Second International Conference on Electrical Engineering (ICEE) - Lahore, Pakistan...

transcript

Second International Conference on Electrical Engineering

25-26 March 2008

University of Engineering and Technology, Lahore (Pakistan)

Systems Design of an Economical and General-Purpose

On-Board Computer for Low-Earth-Orbit Micro-Satellites

Muhammad Naeem Ayyaz

University of Engineering and

Technology, Lahore, Pakistan

mna@uet.edu.pk

M. Riaz Suddle

SUPARCO, Lahore, Pakistan

sclhr@brain.net.pk

Shakeel Zahid

SUPARCO, Lahore, Pakistan

sclhr@brain.net.pk

Abstract

An On-Board Computer (OBC) is the brain of any

satellite. This sophisticated piece of equipment monitors and

controls each and every function of the satellite. It is generally

a very expensive device, with cost amounting to hundreds of

thousands of dollars. The problem we have addressed in this

research is to conceive and design an economical, general-

purpose and adaptable OBC, for use in general-purpose low-

earth-orbit (LEO) micro-satellites. The hardware and

software design of this OBC is based upon open and flexible

design architecture. The idea is that the design can be used in

or adapted for a variety of small LEO micro-satellites with

minimal modifications. Keeping these goals in view, a

complete architecture of the OBC has been developed. The

design is based on the Intel 80386EX microprocessor

technology. In addition, requirements for the on-board and

ground station software have been identified and concrete

guidelines for design and implementation of the related

software have been provided.

1. Introduction

An on-board computer is especially designed to monitor

and control the real time operation of a satellite in real-time. It

takes control of the satellite immediately after its launch, and

remains in command until the end of the operating life of the

satellite. The primary role of the OBC is autonomous control

of all subsystems of the satellite. The OBC employs complex

hardware and software to communicate with the on-board

subsystems and the ground station. When the satellite is not in

the view of the ground station, all critical operational decisions

and actions are taken by the OBC. It collects information from

different subsystems of the satellite, analyses the information,

and takes necessary and appropriate decisions as and when

required.

The OBC is a special-purpose computer, and is different

in many respects from the conventional PCs and workstations.

An OBC may have a number of interfaces, both serial and

parallel, for communication with the other subsystems of the

satellite. The serial interface may be synchronous or

asynchronous. The software running on the OBC is real-time

software and typically carries out monitoring/controlling

functions. Some satellites also contain an on-board data

handling system (OBDH) for handling large volumes of high-

speed data; this system however does not have the controlling

authority. In small satellites, the OBC may also perform

various other functions, such as storing and forwarding

messages, gathering telemetry and executing

telecommands etc., which in larger satellites are

performed mainly by dedicated subsystems.

The OBC contains circuitry to convert information

received from different subsystems in the form of currents

and voltages into number formats understandable for the

ground station. This data is packetized and transmitted to

the ground station. In this way the OBC is used to send

telemetry information–the health monitor of the satellite–

down to the ground station. The OBC similarly receives

control commands, called telecommands, from the ground

station. It decodes these commands and on-board executes

them to perform the desired functions. Figure 1 depicts a

simplified high-level block diagram of an OBC.

Figure 1. A simplified high-level block diagram of an OBC

The OBC can direct the Power Conditioning System

(PCS) (not shown in the Fig) to turn on/off any subsystem

(except the power system and itself) to save battery power.

For example, at any moment during its flight the satellite

may experience high temperatures in the sunlit region. It

can similarly be subjected to increased radiation

bombardments due to an increase in the solar activity.

These factors may destroy on-board electronic

Main Processor

Program

Memory

Serial

Interface

Parallel

Interface

Any Specialized

Interface, such as

MIL-STD-1553

OBC Bus

components or at least cause some malfunctioning. Given

appropriate electronics on-board, the OBC can continuously

monitor the radiation bombardment and its effects on the

health of the satellite. A subsystem for that reason may be

temporarily turned off to save the subsystem from high

temperatures and radiation bombardment.

The OBC also monitors and controls attitude of the

satellite with the help of the Attitude Control Subsystem

(ACS). The attitude means the current position of the satellite,

its side presently facing the sun and the spin of the satellite.

This information is required by the OBC because it needs to

turn its battery power on when the satellite is in eclipse

(behind the earth, away from the sunlight) and turn it off when

the satellite starts drawing the power directly from the solar

panels.

Different architectural paradigms could be employed for

designing OBCs meant for different kinds of satellite

missions. They may range from centralized architectures to the

fully distributed ones. Different design architectures of the

OBC would thus bear different functionalities for the satellite.

We have explored a general-purpose and flexible

hardware/software architecture which results in an OBC that

can be used in, or adapted for, almost any LEO micro-satellite.

The design of this OBC is based upon the idea of open-bus

architecture and it has been implemented around an Intel

80386EX microprocessor. This microprocessor has a proven

track record of use in general space applications. For example,

it has been used by Surrey Satellite Technology Limited in its

UoSAT series of satellites [1]. Similarly, it has been used in

the OBC of the Malaysian satellite TiungSAT-1 [2] and South

African SUNSAT [10]. An Intel 80386EX can handle all the

requirements of an on-board computer for LEO micro-

satellites. Due to the simplicity of its design, the OBC can be

very economically built, both in terms of hardware and

software. The resulting designs are not only completely

functional but also very robust. The later microprocessor

families–such as the Pentiums–have not been successfully

used in space applications, because their space-qualified

versions are not freely available in the market. Besides, the

designers usually do not take risk with the newer

microprocessors.

2. Major functions of the OBC

An OBC needs on-board data to help control the satellite. This

data is gathered in real-time from different subsystems of the

satellite. On analyzing the data, the OBC makes controlling

decisions with the help of on-board system software. Some

core functions implemented by an OBC for LEO micro-

satellites are described as under.

2.1. Transmitting telemetry data

Telemetry data means the information pertaining to the state

of each specific subsystem of the satellite. This information is

received from the satellite at the ground station with the help

of the OBC and decoded to determine whether a given

subsystem is currently ON or OFF and whether it is properly

functioning or not. The telemetry data includes information

related to voltage and current supplied to each subsystem and

the temperatures at different points of the satellite, etc.

At present, there are different formats in use for the

telemetry packets. Some are specific to the particular satellites

and they are decided by the designers working on the

project. We choose the packet formats specified by the

Consultative Committee for Space Data Systems

(CCSDS) [3,11] that have proven to be robust and

immune to errors. This format has been adapted by the

whole European space industry also. A telemetry packet

contains the current date, the current time in UTC

(Universal Time Coordinates) format, and the numeric

values corresponding to the current, voltage and the

temperature information associated with each channel.

The channel means a particular information stream

related to any subsystem. If there are n pieces of different

telemetry information for the whole satellite, then there

will be n channels required in the telemetry packet to

carry the full telemetry data to the ground station. At the

ground station it is known beforehand that which channel

corresponds to telemetry information from which

particular subsystem. For instance, channel 1 may

correspond to current being drawn by the receiver,

channel 2 may represent the current drawn by the

transmitter, and so on. At ground station, a calibration

equation translates each decimal number, delivered as

part of the telemetry packet, into a form that depicts

whether this information pertains to voltage, current or

temperature. The packet may also contain a checksum so

that the ground station could determine whether the

packet is received error-free or not.

1) Voltage Monitoring: The voltage is monitored at

the power-input pins of a subsystem. This voltage is

converted into a number, usually a decimal value, by an

A/D converter (ADC). The value is recorded by the OBC

and transmitted to the ground station. Another task is to

just sense (rather than measure) voltages at the power

input pins of the subsystems and thus determine the

ON/OFF status of a subsystem. OBC senses these

voltages using its parallel ports. This test result is

produced as one-bit information; if the bit is 1 (0) the

subsystem is ON (OFF). This information is called digital

status of the subsystem.

2) Current Monitoring: The information regarding

the current drawn by a particular subsystem is picked

from the PCS, whose job is to monitor current drawn by

each subsystem of the satellite. The PCS converts this

information into a corresponding voltage level, which is

then transformed by the A/D converter into a number

value. The OBC receives and packs this number into a

telemetry packet for onward transmission to the ground

station.

3) Temperature Monitoring: Temperature sensors

located at different corners of the satellite monitor

temperature levels. Most of the temperature sensors

currently used in satellites convert these voltage changes

into corresponding current changes [4]. The OBC

contains current-to-voltage converters to convert each

such current level into a corresponding voltage level. The

ADC then converts this voltage into an equivalent

decimal number, which is then packed by the OBC into

its telemetry packet.

Separate calibration equations are developed at the

ground station for decoding information related to each

voltage, current, and temperature. A separate equation is

needed for each different subsystem of the satellite because

the current-to-voltage graph function may be different for each

given subsystem. Finding a voltage or current value from the

decimal value using the calibration equation is a reverse

process of conversion of these values into the decimal

numbers. For a given decimal number, the equation would

determine the value for the corresponding voltage, current, or

temperature in question. For example, for A, B, C, and D as

constants:

voltage1 = A decimal value

current1 = B decimal value

current2 = C decimal value

temperature = D decimal value

2.2. Decoding and executing telecommands

The telecommands from the ground station are used to

issue instructions to different subsystems of the satellite, via

the OBC, to perform different tasks. The commands, for

example, may be meant for the power subsystem to switch

ON/OFF any other subsystem, or these may be issued to a

camera so as to take a snap of the earth and store the image in

the OBC RAM. Similarly, Attitude Control System (ACS) may be issued commands to adjust position of the satellite.

ACS may also be commanded to send attitude related data,

such as sun sensor readings, to the ground station. Some

telecommands are meant explicitly for the OBC to, for

example, make it stop sending telemetry or to download the

photograph stored in the OBC RAM.

A telecommand connector is provided in the OBC on

whose pins a permanent-high or permanent-low signal would

appear when a particular command is received and decoded

by the OBC. These commands are called bi-level

telecommands. They are decoded into two distinct voltage

levels, where a high voltage level is meant for turning a

subsystem ON and a low voltage level is meant for turning it

OFF. The pins of the telecommand connector of the OBC (on

which bi-level commands appear) are connected through a

cable to the telecommand connector of the PCS. These

telecommands are thus used to switch ON/OFF any

subsystem by way of the PCS. The other type of

telecommands is the pulse telecommands. In this case, a pulse

is generated instead of a permanent-low or permanent-high

signal. This type of command is used to set off execution of

one-time operations such as taking a snapshot with camera, or

some other task which requires a triggering pulse for

execution.

The commands may also be time-tagged in advance,

especially for the camera, so that the camera could take a snap

while the satellite is not in view of the ground station. In this

case, the OBC retains the command in its memory after

decoding and, when the stipulated time is reached, a request is

issued to the camera subsystem for taking the picture.

2.3. Orbit and attitude control

The OBC monitors and adjusts the attitude of the satellite

with the help of a special circuitry, called Attitude Control

Subsystem (ACS). ACS contains sensors, which acquire data

pertaining to the attitude and orbit of the satellite at a

particular moment of time. In some satellites, special DSP-

based cards are employed in the ACS, which process this

data, using specialized algorithms, to determine the

attitude and orbit of the satellite. If some adjustments in

the attitude or orbit are required, the ACS can command

the actuators to adjust the orbit and/or attitude of the

satellite. Concurrently, the information received from the

sensors is also sent to the ground station, where similar

calculations, as those being done in ACS, are performed.

In case of failure on part of the ACS, the corrective

measure command is sent to the satellite by the ground

station. In some cases, OBC has the capability to obtain

the orbit and attitude data directly from the sensors and

make decisions to adjust the orbit and attitude. The

algorithms for controlling the orbit and attitude are a part

of the OBC software. This capability is required because

in LEO satellites the OBC should have the authority to

itself adjust its orbit and attitude when it is not in the view

of the ground station. However, when the satellite is being

tracked by the ground station, this function could be

performed by the ground station through the

telecommands.

2.4. Store and forward experiment (SAFE)

OBC can also operate in SAFE mode. In this mode

the OBC can store/forward messages from/to the ground

station. A part of the OBC RAM is reserved for storing

the messages on-board that have been sent from one

ground station to another.

The SAFE mode has STORE, DOWNLOAD,

MESSAGE LIST, and DELETE commands defined for it.

The STORE command is used to store a pre-defined

message sent from the ground station into the OBC RAM.

The DOWNLOAD command downloads a message from

the OBC to the ground station. The MESSAGE LIST

command provides the list of all messages currently

stored on-board. The DELETE command deletes the

message whose number is given in the command. When

SAFE operation is over, the OBC can be returned back to

the telemetry mode.

Figure 2. Main functions of an OBC

Telecommand

execution

Communication with

ground stations

Communication

with subsystems

Decisions on the

basis of data

analysis

Telemetry

gathering

On-board

memory

storage

3. A general-purpose OBC

Different satellites fall into different categories, i.e., nano-

satellites, micro-satellites, mini-satellites, and large satellites.

The subsystems‟ number in the satellites also varies

accordingly. Designing a general-purpose OBC for any given

category is a nontrivial task. Such an OBC should be able to

work with as many different subsystems in the satellite

category as possible. The problem we are addressing is to

architect and design a general-purpose Intel 80386EX-based

OBC for the LEO micro-satellite category. These satellites are

of several different kinds, e.g., experimental, communication,

earth observation, weather, and search and rescue satellites

(such as those built for international COSPAS-SARSAT

program).

If the number of peripheral subsystems for the LEO

micro-satellite is permitted to increase across its category,

then the OBC design should be flexible enough to

accommodate the extra interfaces for communication with

these subsystems. Another feature required in this case would

be the allowance of software routines for executing new

telecommands and processing the extra telemetry information.

Our design is flexible enough to accommodate an ample

amount of interfaces that may be generally essential in case of

LEO micro-satellites. It is possible to interface any new

subsystem with this OBC design using serial or parallel ports.

The software routines can easily be modified, if necessary, to

provide additional telemetry and telecommand capabilities.

The OBC would also have the capacity to accommodate

software routines to carry out special tasks required for the

specific mission for which the OBC is being adapted. Since

all the components used in the design of this OBC are of

CMOS technology, the logic level 0 may be set anywhere

between –12V and 0V and logic level 1 can be set between

+2V and +12V. This provides flexibility in interfacing with

other subsystems. The voltage levels and the number of serial

and parallel interfaces of the OBC may therefore be set

keeping in view the needs and requirements of the particular

satellite into which the OBC will be integrated.

4. Implementation of the design of a general-

purpose OBC

Figure 3 shows the basic functional diagram of our OBC.

There are six computers involved in this design. The first

three are the Telemetry, Telecommand, and Attitude Control

computers. They are single-function micro-controller-based

computers, which do not have to perform complex

computations. They collect data from the associated

subsystems and pass it on to a Central Computer. They

similarly pass on commands from the Central Computer to the

subsystems. The Central Computer is where the main

computations are performed, such as decoding the

telecommands, bus control, and communication with the

ground station. Three Central Computers have been used so as

to allow for redundancy.

The telemetry computer (TMY) gathers telemetry

information from other subsystems, such as the PCS, ACS,

and communication subsystem etc. It prepares a packet with

32 analog and 24 digital status signals and sends it over to the

OBC bus–a MIL-STD-1553 bus widely used in the aerospace

industry.

The telecommand computer executes telecommands

on behalf of the Central Computer where they were first

depacketized and decoded. The telecommand computer

simply changes the logic level at one of the pins of one of

the programmable peripheral interface (PPI) attached to

it. Our design provides for 48 telecommands, 44 of which

are bi-level commands and the remaining are pulse

commands. The PPI actually generates only bi-level

commands, which may be converted when needed to

pulse form with the help of a mono-stable multi-vibrator.

The attitude control computer gathers the orbit and

attitude data from the orbit and attitude sensors, performs

A/D conversions, and sends the data to the Central

Computer for analysis and/or onward transmission to the

ground station. Similarly, it receives commands in digital

form from the Central Computer, interprets them, and

then coverts them to analog form to dispatch to one of the

actuators to adjust the orbit or attitude of the satellite.

Figure 3. Basic Functional diagram of an OBC

4.1. Telemetry computer design

In this design, telemetry is gathered into the

telemetry computer through the various subsystems

(mentioned earlier) and the AD590 temperature sensors

located at different points in the satellite. The block

diagram of the analog portion of the telemetry computer

is shown in Figure 4. The microcontroller used is the

89C52, which can process up to 128 analog channels.

There are two 4067 analog 16x1 multiplexers used in the

design (shown as MUX 1‟s), where each one can gather

inputs from up to 16 analog channels. These inputs come

from the different sensors placed in other subsystems.

These include voltage, current, and temperature sensors.

This setup can be easily enhanced to accommodate 64

analog channels, in which case four of the 4067s would

be necessary. The Digital Status, that is the sensing of

voltages at different pins of various connectors, is read by

the 8255 Parallel Peripheral Interface (PPI). The

multiplexers are scanned by the microcontroller in round

robin fashion. The outputs of the two 4067 multiplexers

are fed into a 4051 8x1 analog multiplexer (shown as

MUX 2) whose output is fed into a 0804 ADC. The ADC

converts the analog input into digital form to be read by

the microcontroller. The microcontroller stores these

Telemetry

Computer

Telecommand

Computer

Attitude

Computer

Central

Computer 1

Central

Computer

Central

Computer

PCS Other AD590

TMY TMY TMY

Subsystems

Attitude Attitude

Sensors Actuators

values temporarily in its internal RAM and, when all the 32

analog and 24 digital status lines have been read, a telemetry

packet is formed and stored in the external RAM. A 32 KB of

external RAM would be sufficient for this purpose. When the

Central Computer would ask for the telemetry, the telemetry

computer would then transmit these packets to it via the OBC

Figure 4. Block diagram of Telemetry Computer

4.2. Telecommand computer design

The telecommand computer, Figure 5, has a simpler

design than the telemetry computer. The design includes a

microcontroller, two 8255 PPIs, and one mono-stable multi-

vibrator. This design accommodates a total of 48

telecommands, out of these 44 are bi-level commands and the

remaining are pulse commands. For 48 telecommands, two

PPIs are required to generate 0V or 5V voltage levels, so as to

be considered as bi-level commands. The 5V level is usually

meant to switch ON any relay or solid-state switch, whereas

the 0V level means setting them OFF. The PPIs are connected

to the data bus of the microcontroller. The microcontroller

generates bi-level commands that are executed through the

PPI. The PPIs are selected one at a time by the

microcontroller as required. The output of the PPI is either

logic 1 or logic 0. These are used to turn ON/OFF any

subsystem via the PCS. The PCS is, therefore, usually placed

near the OBC. If the logic level of a given PPI pin is 1, the

associated subsystem would stay ON till when the logic level

returns to 0.

The pulse commands are generated using the mono-stable

multi-vibrator. When the status of the PPI pins connected to

the input of this multi-vibrator change from logic 0 to logic 1,

the multi-vibrator would generate a pulse. The pulse is

generated when the logic level at the output of the

concerned pin changes from 0 to 1 and then back to 0. The

duration of this pulse can be adjusted by using external

resistors and capacitors.

The telecommand is first received, depacketized, and

decoded by the Central Computer. The Central Computer

then generates a two-byte telecommand for the

Telecommand Computer. The first byte contains data

regarding the name of the subsystem to be turned ON or

OFF, while the second byte contains the actual command.

Both bytes collectively tell the Telecommand Computer

about which pin of the PPI1 or PPI2 should be turned to

logic 0 or logic 1.

Figure 5. The Telecommand Computer

4.3. Attitude control computer design

As described above, the main function of the Attitude

Computer is to gather attitude data from sensors and

transmit it to the Central Computer. The Central

Computer performs necessary calculations on this data

and issues commands back to the Attitude Computer to

apply control functions on actuators. During satellite pass

this information may be uploaded to the ground stations

for retaining history of orbit/attitude of the satellite.

4.4. The design of the central computers

Central Computers are built around the Intel

80386EX microprocessors [5]. A simplified diagram of

the Central Computer is shown in Figure 6. The computer

has 512 Kbytes (128 Kbytes x 4) of RAM, implemented

with 431000 chips, and 256 Kbytes (128 Kbytes x 2) of

ROM. It is configured using a 29C010. E2PROM is used

to keep the possibility of on-board re-programming and

erasing of the program memory to keep room for code-

patching during the mission flight. The microprocessor

contains many units, which are otherwise used as

peripherals such as serial ports, chip select units, and

interrupt control unit, etc. This decreases the number of

components on board and simplifies its design.

Analog Telemetry

(16 Channels)

Digital

Output

Analog Telemetry

16 Channels

µCont.

Digital Status Lines

(24 Lines)

89C52 Microcontroller

8255 PPI 1

8255 PPI 2

TC from GS

Different

Subsystems’

Relays/Switches

Commands

Figure 6. Simplified Diagram of the Central Computer

The telemetry computer sends two types of telemetry

packets to the Central Computer over the system bus. The

first kind is the real-time telemetry data, which consists of

packets that are dispatched during the satellite pass over the

ground station. These are transmitted either regularly at

predefined intervals of, say, one minute or activated through a

telecommand. The Central Computer translates the packets

into CCSDS standard form. These are then passed to the

satellite transmitter for onward transmission to the ground

station. The second type is the whole-orbit telemetry packets

required at ground station to know the behavior of the satellite

when it is not in the view of ground station. These packets

contain a special mark in their header and are sent to the

Central Computer every five minutes. They are held in the

Central Computer RAM and are transmitted to the ground

station when a request in the form of a telecommand is

received.

Table 1. Specifications of MIL-STD-1553 data bus

Data rate 1 MHz

Word length 20 bits

Data bits/word 16 bits

Message length Maximum of 32 data words

Transmission technique Half duplex

Operation Asynchronous

Encoding Manchester II bi-phase

Protocol Command/response

Bus control Single or multiple

Fault tolerance Typically dual redundant,

second bus in “Hot

Backup” status

Message formats Controller to terminal

Terminal to controller

Terminal to terminal

Broadcast

System control

Number of remote terminals Maximum of 31

Terminal types Remote terminal

Bus controller

Bus monitor

Transmission media Twisted shielded pair

Coupling Transformer and direct

The Central Computer is responsible for control of

the data bus which is done according to the MIL-STD-

1553 standard. The specifications of this data bus are

summarized in Table 1 [6].

The data bus standard defines four hardware

elements: the transmission media, remote terminals, bus

controllers, and bus monitors. There are only three

functional modes allowed on the bus: the bus controller

mode, the bus monitor mode, and the remote terminal

mode. The Central Computer, the Telemetry Computer,

the Telecommand Computer, and the Attitude Computer

are capable of working in more than one modes. The

Central Computer acts as the Bus Controller, and the

Telemetry, Telecommand and Attitude computers would

act as Remote Terminals. Figure 6 illustrates a typical bus

configuration.

Bus Controller – The bus controller is the terminal

that initiates information transfer on the data bus. It

sends commands to remote terminals. The remote

terminals act in response to the command. The bus

can support multiple controllers, but only one may be

active at a time. Other requirements for bus controller

as per 1553 standard are: (a) it is “the key part of the

data bus system” and (b) “the sole control of

information transmission on the bus shall reside with

the bus controller.”

Bus Monitor – Bus monitors are frequently used for

instrumentation. The 1553 standard defines the bus

monitor as “the terminal assigned the task of

receiving bus traffic and extracting selected

information to be used at a later time.”

Remote Terminal – Any terminal not operating in

either the bus controller or bus monitor mode is then

operating in the Remote Terminal (RT) mode.

Remote terminals are the largest group of bus

components [8,9]. 1553 BUS STRUCTURE

BusController

RemoteTerminal

MonitorM

RemoteTerminal

Shielded Two-wire CableBus

Figure 6. MIL-STD-1553 Bus Structure

The unit of communication measurement on the Bus

is in words. A word in MIL-STD-1553 is a sequence of

20 bits, with 3 bits for sync waveform, 16 bits for data,

and 1 bit for parity-check. 1553 terminals add the sync

and parity bits before transmission and remove them on

reception.

There are three types of words: command word, data

word, and status word. Figure 7 shows word formats for

MIL-STD-1553 data bus [9].

Intel 80386EX

Microprocessor

431000

29C010

E2PROM

1553 WORD FORMAT

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

1111111115 3

BIT Times

Command

Status

Remote Terminal

Address

T/R Subaddress / Mode Data Word Count /

Mode Code

Remote Terminal

Address

uest Reserved

inal F

Parity

Status

T/R - Transmit / Receive

P - Parity

Figure 7. MIL-STD-1553 word format

The primary purpose of the data bus is to provide a shared

medium for exchange of data messages between subsystems.

A message format is shown in Figure 8. Message

transmissions can be done in ten different formats, all of

which are based on the three word formats just mentioned [9].

The information transfer formats are based on the

command/response philosophy, in which all error-free

transmissions received by a remote terminal are followed by

transmission of a status word from the terminal to the bus

controller. This handshaking validates receipt of the message

by the remote terminal.

1553 DATA MESSAGE FORMAT

ReceiveCommand Word

DataWordData

StatusWord

StatusWord**

CommandWord#

From RT Next Sequence

TransmitWord

DataWord Word

DataWord

WordData

WordCommand

Next Sequence

From Controller

From RT

Controller

Transfer

Controller

Command

From Controller

Receive TransmitCommand WordWord

Transmitting RT

Status DataWordData

WordData

**StatusWord

FromReceiving RT

#Transfer

RT to RT

RT=Remote Terminal ** # = End of overall sequence= End of transmission from that unit

Figure 8: MIL-STD-1553 data message format

The Central Computer, acting as bus controller, broadcasts a

command word, which all three microcontroller-based

computers would receive. The particular computer for which

it is meant would then take control of the bus and send an

acknowledgement. This computer transmits the same number

of bytes of the requisite data as mentioned in the command

word sent by the Central Computer. When this computer

releases the bus, the Central Computer would take the control

The Central Computer also broadcasts a keep-alive message

on the bus every five minutes, which is received by the other

two Central Computers. In case the Central Computer #1

fails, and the other two do not receive such packet within next

five minutes, the Central Computer #2 would automatically

take control of the bus and start sending keep-alive messages

of its own. If the Central Computer #2 had failed prior to the

failure of Central Computer #1, then the Central Computer #3

would not receive a keep-alive message from Central

Computer #2 after the stoppage of keep-alive messages

from Central Computer #1. The Central Computer #3,

after waiting for 10 minutes, would thus take charge of

the bus. During this time no activity would however be

performed by the OBC.

5. Telecommand execution

The hardware setup required for telecommand execution

of the telecommand has already been explained. Two

options are available for the designers for packetizing the

telecommand; either to follow the CCSDS standard of the

European Space Agency (ESA)–which we recommend–or

to design their own standard. Following the CCSDS

standard would make the system practically prone to

transmission errors. If the designers opt for the CCSDS

standard, the following guidelines would prove to be

helpful for designing the software. [7,12]. The

telecommand packet structure is shown in figure 9 below.

Packet Header (48 bits) Packet Data Field (Variable)

Packet ID Packet SequenceControl Length

Packet Data Fieldheader

(optional)Data

Application Paket Errorcontrol

(optional)

Version#

Type Data

FieldHeader

Application

Process ID

1 1 11

Sequence

16 Variable Variable 16

TC Packet

PUS Version

Checksum

Ack Service

Service

Sub-Type

3 1 4 8 8

Data Field Header format

Figure 9. Telecommand Packet Structure

The CCSDS recommendations and terms for

telecommand packet are shown in Table 2. The column

values marked TBD are to be decided by the design

engineers, as they would vary from mission to mission.

Table 2. CCSDS packet structure 1. Sub-carrier frequencies, modulation and

waveform

8 or 16 KHz, PSK,

Sine wave

2. Choice of TC data waveform NRZ-L, M

3. Range of TC bit rates 4000/2n, n=0,1, ...,9

4. Medium-rate modulation; range of TC

bit rates

PCM/PM/Bi-Φ

4000*2n; n=1,2,…,6

5. Largest possible length of TC packet 65542 Bytes / Octets

6. Largest possible TC transfer frame

length

1024 Bytes/ Octets

7. Data field header TBD

8. APIDs TBD

9. Application data (No. of bytes, Type) TBD

10. Packet error control TBD

11. Packet segmentation TBD

12. MAPS MAP0 and MAP1

13. Spacecraft ID 123 (TBD)

14. Service types and sub-service types TBD

If the designers wish to implement their own

telecommand system, the following guidelines together

with the recommended software execution steps should

prove helpful. The OBC by default operates in telemetry mode. To

switch it to telecommand mode, an interrupt consisting of

two characters (BY) is sent to it from the ground station.

After switching to the telecommand mode, the OBC

would send one character ( ) to the ground station as an

acknowledgement of the interrupt. If the interrupt characters

reach the satellite in corrupted form, no action is taken there.

If an acknowledgment is not received at the ground station for

30 seconds, the ground station would send the interrupt and

waits for another 30 seconds. If the interrupt characters are

accepted by the OBC and the acknowledgement is

successfully received at the ground station, the ground station

is next required to send the password for the telecommand

(AJS). The OBC (after having sent the interrupt

acknowledgement) waits for the password for one minute. If

the password is not received within one minute, the OBC

would return to the telemetry mode. OBC can accept or reject

the password. If the password is accepted, OBC sends a

character ( ) which means that the OBC is ready for receiving

the telecommand. If the password is rejected, OBC sends two

characters ( ) to tell that the password is rejected and should

be sent again. The OBC waits for 2 minutes for a second try of

the password. If the password is received within this time and

is acceptable, the OBC becomes ready for receiving the

telecommand. If the password is not received the second time

within 2 minutes or is again rejected, OBC sends two

characters (½à) to tell that it is reverting to the telemetry

mode. On finally successfully receiving the telecommand

packet, the OBC checks whether the command is meant to be

executed immediately or is it a time-tagged telecommand. The

17-byte configuration of telecommand packet is shown in

figure 10.

Date Time

Command

Tagged/No

Tagged

CRC End of

Packet

1 byte 1 byte 2

1 byte

Figure 10. Configuration of telecommand packet

When a telecommand is successfully executed, OBC

sends a two-characters verification ( ) to the ground

station. This verification is also stored in the OBC RAM to be

later sent to the ground station. Sometimes there is a

requirement that the status of all the commands executed on-

board during the past, say, one week be shown. These

verifications would then prove to be helpful. Ten such

verifications (20 bytes) can be stored in the RAM one after

another, after which they will be overwritten by the

subsequent verification bytes. After executing a telecommand,

the OBC waits for one minute for the next commnad. If it is

not received within this time, it returns automatically to the

telemetry mode. OBC can also be explicitly returned from the

telecommand mode to the telemetry mode by sending it the

characters ( ).

If the CRC check for the telecommand packet shows that

the packet is corrupted, OBC sends two characters (¿§) to the

ground station showing that the telecommand packet received

was corrupted and should be sent again. The verification or

the ARQ is sent three times with a gap of 5 seconds to make

sure that it does reach the ground station in case of any loss

during transmission. The telecommand packet is retransmitted

two times, if required. In case all the three tries fail, the OBC

returns to the telemetry mode automatically.

Once the OBC is interrupted from the telemetry

mode, it can be switched to SAFE mode also. The

password for the SAFE mode consists of two characters

( ). When the password is accepted, the OBC sends

down one character confirmation ( ) to the ground

station. If the password is rejected, OBC sends down two

characters ( ), showing that the password has been

rejected and should be sent again. In this case also OBC

waits for two minutes for the next password try, otherwise

it reverts to the telemetry mode automatically. If the

password is rejected for the second time also, OBC

similarly returns to the telemetry mode. OBC gives five

minutes to the user to perform the SAFE operation after

sending its password acceptance to the ground station.

After five minutes, OBC would return to the telemetry

mode automatically.

6. System software design

6.1. On-board software

The on-board software of OBC is a complete

operating system. It performs the following functions:

a) Initialization of microprocessors and

microcontrollers and their peripherals.

b) Gathering of telemetry, done through the

Telemetry Computer. Packetizing telemetry

information. Storing telemetry packets in OBC

RAM and uploading them to the ground station.

Telemetry mode is the default mode; the OBC

Central Computer has to be interrupted for

switching to telecommand mode.

c) Analyzing the telemetry data received from

different subsystems through the Telemetry

Computer and then making decisions regarding

switching ON/OFF any subsystem.

d) Receiving, decoding, and executing

telecommands. SAFE mode is a part of

telecommand mode.

The detail of the telemetry packet, as suggested by

CCSDS, can be seen in [3,11].

Telemetry packets are usually sent by the OBC with

a time gap of 5 seconds between each packet. For the

duration of the gap, idle packets (with 0s padded in the

data field) are sent to the ground station so that

synchronization between the satellite and ground station

is not lost.

If the software designers instead of using the CCSDS

standard wish to implement their own telemetry packet

system (for any practical reason), the following guidelines

would be helpful.

The telemetry packet should hold at least the

following information. The information to be transmitted

in the packet may vary from mission to mission and its

requirements. The following shows some examples.

1) Satellite identity.

2) Date and time.

3) Packet number: This number will start from 1 and go

up to 256. After 256, the number gets reset and start

from 1 again.

4) Information regarding whether the packet is a real-

time packet (i.e., when the satellite is in the view of

the ground station) or is it the packet which was

previously stored in the OBC RAM (the whole orbit

telemetry).

5) Analogue telemetry: This contains 32 channels. 160 bytes

would be required to send information contained in these

32 channels. Two bytes are reserved for the channel

number and three bytes for the analog value being sent in

that channel. This analog value is sent as a digital number,

as explained earlier. The digital number is sent to the

ground station after conversion into ASCII codes.

6) Digital status. This contains 24 digital status inputs,

represented in three channels. A channel number is

indicated with the help of the first two of these three

bytes, whereas the value is represented as a hexadecimal

number in the last byte. If we receive A3H in a digital

status channel, this would mean 10100011 in binary. So

bit 0, 1, 5 and 7 are ON and the others are OFF. These

bits would represent 5V at different pins of power

connectors of the different subsystems. This means that

there are a total of 35 channels; 32 of these are for

analogue telemetry and 3 are for digital status.

The format of the telemetry packet is shown below.

Satellite

Date Time

Packet

Number

End of

Packet

4 bytes 6

6 bytes 1 byte 1

byte(*)

1 byte

The telemetry data is in the following form.

Channel

Number

bytes)

Decimal

Value (3

bytes)

Channel

Number

(2 bytes)

Decimal

Value (3

bytes)

Channel

Number

(2 bytes)

Decimal

Value (3

bytes)

01 070 02 178 03 234

6.2. Ground Station Software

Following are the main functions of the ground station

software, which has been implemented in the C language.

Three P-IV PCs, connected through a LAN, will be adequate

for running the Ground Station software. One computer is

required for Telemetry, one for Telecommand, and one for

SAFE mode.

i) Receiving and consequently displaying and archiving

the telemetry data from the OBC. When the satellite

is in view of the ground station, each telemetry

packet received is stored primarily in a buffer in the

PC RAM. When the buffer becomes full, the packets

are copied into a file. The file remains open till the

completion of the current pass of the satellite. Data

from each new pass goes into a separate file; the files

are named according to the pass number. This file is

processed by separate software, which unpacks

telemetry packets, applies calibration equations to the

data, and either displays the resulting information or

stores it into archive files.

ii) Generating telecommand packets and scheduling

their retransmission, when necessary.

iii) Receiving, and consequently displaying and storing,

pictures from the on-board camera. The picture is

received as a bit stream and is simultaneously shown

on the display. The picture may also be stored as an

archive file.

iv) Generating packets of the message, which was

already typed when the satellite pass was not in

view, and transmitting them to the satellite for

SAFE operation. Receiving response messages

from the satellite, displaying them, and storing

them in a file. Retransmitting during uplink

transmission the packets previously received in

error at the OBC.

7. Conclusion

The OBC design presented in this paper is simple,

general-purpose, easy to implement, and economical. The

OBC has been designed in such a way that it can be used

in, or adapted to, almost any LEO micro-satellite with

minimal changes. The components used in the design are

inexpensive, generally used, and readily available. No

special components, such as FPGAs or PLAs etc., have

been used. Ample technical literature is available for the

80386EX microprocessor and the other peripheral

components, which focuses on their use, interfacing, and

programming. Development systems are also easily

available for this microprocessor.

The interfaces of the OBC have flexible voltage levels.

Therefore they can be customized to work with a variety

of subsystems. The requirements addressed in the design

for the memory, serial and parallel ports, and analogue

and digital telemetry are completely adequate for a micro-

satellite. However, extra serial and/or parallel ports can be

added to accommodate additional subsystems. An OBC

offering these characteristics should be an excellent choice

for the developing countries to use in their current and

future space projects.

8. References

[1] www.sstl.co.uk/datasheets/subsys_obc386.pdf

[2] Mazlan Othman and Ahmad Sabirin Arshad, “TiungSAT-1:

From Inception to Inauguration,” Astronautic Technology (M)

Sdn. Ghd., 2001.

[3] “Packet Telemetry Standard (ESA PSS-04-106 Issue 1),”

The Standards Approval Board (STAB) for Space Data

Communications, 1988.

[4] Robert F. Coughlin and Robert S, Villanucci, “Introductory

Operational Amplifiers and Linear ICs – Theory and

Experimentation,” Prentice Hall, 1998.

[5] “Intel 80386 EX Embedded Microprocessor User’s

Manual,” Intel Corporation, 1996.

[6] “MIL-STD-1553 Tutorial,” Condor Engineering, Inc., 2000.

[7] “Packet Telecommand Standard (ESA PSS-04-107 Issue 2),”

The Standards Approval Board (STAB) for Space Data

Communications, 1992.

[8] Leroy Earhart, “MIL-STD-1553, Aircraft internal time

division command/response multiple data bus”, Test Systems,

Inc Phoenix, Arizona.

[9] “An Interpretation of MIL-STD-1553B” ver2.0 May 26,

1998.ftp://ftp.sbse.com/web_files/pdf/general/1553Interpretation

[10] A.Schoonwinkel et al, “Pre-flight performance of

SUNSAT,SOUTH AFRICA’s first remote sensing and packet

telecommunication s Microsatellite”, EEE Department,

Stellenbosch University, South Africa.

[11] “Packet Telemetry”, Recommendations CCSDS 102.0-B-5,

Issue 5, „Blue Book‟, Consultative Committee for Space Data

Systems, Nov 2000.

[12] “Packet Utilization Standard”, (ESA PSS-07-101) Issue 1,

May 1994, European Space Agency.

[IEEE 2008 Second International Conference on Electrical Engineering (ICEE) - Lahore, Pakistan...

Documents