Aoss_582_09_CDH_Tech_Talk

8/7/2019 Aoss_582_09_CDH_Tech_Talk

1/57

AOSS582Tech PaperC&DH and Spacecraft Computers

Vidya Sagar Reddy Avuthu, Chase Estrin, Kok Cheung Li

10/23/2009


2/57

2

Table of Contents

Introduction to C&DH System ....................................................................................................................... 5

C&DH System Sizing ...................................................................................................................................... 6

System Architecture ...................................................................................................................................... 9

Central Architecture .................................................................................................................................. 9

Ring Architecture ...................................................................................................................................... 9

Bus Architecture...................................................................................................................................... 10

Architecture for nano-satellites .............................................................................................................. 11

Spacecraft Command System ..................................................................................................................... 11

Receiver / Demodulator .......................................................................................................................... 11

Command Decoder ................................................................................................................................. 11

Arbitration Schemes and Command Output Types ............................................................................ 13

Command Messages ........................................................................................................................... 13

Command Logic and Handling ............................................................................................................ 13

Command Receipt and Verification .................................................................................................... 14

Encryption ........................................................................................................................................... 14

Command Handling and Execution ..................................................................................................... 15

Local Commands ................................................................................................................................. 15

Interface Circuitry ................................................................................................................................... 15

Data system................................................................................................................................................. 16

1) Disk ...................................................................................................................................................... 16

2) Solid State Memory ............................................................................................................................ 17

Data Handling Unit ...................................................................................................................................... 19

TELEMETRY.................................................................................................................................................. 20

Analog-to-digital conversion ................................................................................................................... 21

Onboard Computer Systems ....................................................................................................................... 25

Central Processing Unit ........................................................................................................................... 28

PC/104 ..................................................................................................................................................... 31

Data Bus .................................................................................................................................................. 31

Computer System Requirements ............................................................................................................ 34

Watchdog Timers .................................................................................................................................... 35

Flight Software ........................................................................................................................................ 39


3/57

3

Operating Systems .................................................................................................................................. 44

Computer Selection ................................................................................................................................ 46

Cubesat C&DH Examples: ........................................................................................................................... 52

Reference .................................................................................................................................................... 56

Figure 1: C&DH block diagram.................................................................................................................... 6

Figure 2: Central Architecture ...................................................................................................................... 9

Figure 3: Ring Architecture ........................................................................................................................ 10

Figure 4: Bus Architecture .......................................................................................................................... 10

Figure 5: Spacecraft Command System...................................................................................................... 11

Figure 8: Command Decoder...................................................................................................................... 12

Figure 9: Cross-Strapping ........................................................................................................................... 12

Figure 10: Disk Storage .............................................................................................................................. 17

Figure 11: 1.8 inch Solid State Memory ..................................................................................................... 18

Figure 12: Data Handling Unit Block Diagram .......................................................................................... 19

Figure 13: Data Processing Block Diagram................................................................................................ 21

Figure 14: ADC Process ............................................................................................................................. 22

Figure 15: Formatting for telemetry packets............................................................................................... 23

Figure 16: State diagram ............................................................................................................................. 27

Figure 17: Typical OBC.............................................................................................................................. 28

Figure 18 : Serial I/O .................................................................................................................................. 29

Figure 19: Parallel IO.................................................................................................................................. 29

Figure 20: Basic Mechanical Dimensions of PC/104 ................................................................................. 31

Figure 21: Skew .......................................................................................................................................... 32

Figure 22: WDT explanation ...................................................................................................................... 36

Figure 23: External WDT explanation........................................................................................................ 37

Figure 24: example of watching multiple tasks .......................................................................................... 38

Figure 25 Block Diagram of Maxim DS1374C external timer................................................................... 38

Figure 26: NASA graph showing SLOC .................................................................................................... 40

Figure 27: SOS Process Diagram................................................................................................................ 47

Figure 28 RAD 6000................................................................................................................................... 49

Figure 29: Mongoose-V .............................................................................................................................. 49

Figure 30: SA-1110 Block Diagram ........................................................................................................... 51

Table 1: Example of setting branch mark..................................................................................................... 7

Table 2: Sample complexity determination process ..................................................................................... 8

Table 3: Example of data storage on nano-satellite .................................................................................... 18

Table 4: Quantization error as a function of bit per sample........................................................................ 23

Table 5:System Drivers............................................................................................................................... 26


4/57

4

Table 6: Pros and cons of programming languages .................................................................................... 40

Table 7: Benchmark programs used to test hardware architectures............................................................ 41

Table 8: Conversion from HOL to assembly .............................................................................................. 42

Table 9: Generic software estimates for onboard applications ................................................................... 43

Table 10: CPU used in different spacecraft ................................................................................................ 50

Table 11: SA-1110 Feature Summary ........................................................................................................ 52

Table 12: ASTREC-1 C&DH system ......................................................................................................... 53

Table 13: ION-F C&DH system ................................................................................................................. 54

Table 14: CanX-2 C&DH system ............................................................................................................... 54


5/57

5

Introduction to C&DH System

What is it? What does it do?

In general, the C&DH system is the sub-system of spacecraft that controls the spacecraft bycommands from the ground station and onboard computer, manages data, and monitors the

health and status of the spacecraft. It acts as the nervous system as well as the brain of the

spacecraft by connecting and directing the spacecraft sub-systems. The size of the C&DH system

is normally proportional to the spacecraft complexity because of the fact that the more

components each sub-system has, the more powerful the C&DH system must be.

C&DH system can be divided to 4 sub-systems: Command sub-system, Data sub-system,

Onboard Computer (OBC), and Telemetry system.

The command sub-system of the C&DH system is the central control of the spacecraft. It directs

every single activity on spacecraft from receiving, validating, decoding, and distributing

commands to other sub-system. The commands that the command sub-system obtain can

originate from the onboard computer or ground station. Once the command is received, the

command sub-system validates the command to make sure the command is correct and

recognized by the system. If a command passes the validation process, it will then be decoded

and executed. The command sub-system also includes data converters to convert data from

analog to digital or digital to analog to accommodate the data specification of different spacecraft

sub-systems.

The data sub-system collects science data from the sensors or other data acquiring systems.

Science data is the data obtained by the spacecraft payload, and it is usually one of the objectives

of the mission. For example, the science data of the Hubble Telescope is the photos that it takes.

Because a high quality of science data is always demanded, the science data usually has the

highest data rate. Once data is collected, data will either be directly stored in the storage device

or processed and formatted on the onboard computer for storage or downlink.

Telemetry sub-system is the spacecraft system monitors the health of all spacecraft components

and the payload and determines the status of spacecraft. It acquires engineering data from all

spacecraft sub-systems, and then pushes that data to a data system for log keeping and to

onboard computer for troubleshooting and error correction. The telemetry system is essential as

it provides feedback to the ground station and onboard computer for all commands they gave,

and it also provide tracking of the spacecraft

All the autonomous decision marking, data processing, and error response on spacecraft is done

by the onboard computer. Onboard computers are like a virtual spacecraft operator commanding

the spacecraft routines, and it can relieve part of the job of ground station. The onboard computer

is mainly composed of the central processing unit, RAM, ROM, and communication ports.


6/57

6

Combining the hardware with flight software, onboard computers can make the spacecraft more

autonomous and robust.

Figure 1: C&DH block diagram

In this paper, we will discuss sizing of the C&DH system, how the C&DH system integrates into

the spacecraft (the architecture of spacecraft connecting the sub-systems and C&DH system), thecommand and data handling process, onboard computers and their components, and the C&DH

system application for nano-satellites.

C&DH System Sizing

In order to obtain the desired performance with minimum weight, size, and power consumption,

system sizing process is needed.

There are 5 major steps of the sizing process:

1. Identify the functions of the system

2. Identify constraints

3. Determine complexity of each function

4. Determine complexity to overall system

5. Estimate size, weight, power consumption of components and overall


7/57

7

Identify the functions of the system

Depending on the mission, certain function must be able to perform by the C&DH system. In

general, these functions includes: Command process, data storage, telemetry process, watchdog,

attitude control, time. We must first identify all functions that have to be including in the C&DH

system, and then set bench marks for the system.

Data Storage

Types of storage Solid State

Capacity 2 Gb

Write Speed 15Mb/s

Read Speed 20Mb/s

Table 1: Example of setting bench mark

Identify constraints

Constraints from other systems and operating environments prevent us from reaching our desired

function and bench mark of the system. Constraints include the size, weight, cost, and power

supply, radiation effect, unproven of technology. Sometimes, we need to reset the system bench

marks because of the constraints.

Determine complexity of each function

After the consideration of constraints, complexity must be assigned for the initial design. In this

process, we need to have estimations to the capability of each function for 3 complexity areas of

the system: Simple, Typical, and Complex. We then choose the complexity of the function based

on the mission requirements.


8/57

8

Table 2: Sample complexity determination process

Determine complexity to overall system

This is essentially the same process as the step before but in the overall system level.

Estimate size, weight, power consumption of components and overall

With the bench marks of the system and the components, size, weight, power consumption can

be estimated by the similar existing parts or data from previous missions.


9/57

9

System Architecture

How well the sub-systems connect to each other is a key factor for an efficient system. The way

sub-systems connect is the system architecture. As for spacecraft applications, there are 3 major

types of architectures for connecting the C&DH system to other spacecraft sub-systems: Central,Ring, and Bus. Each of these architectures has their pros and cons, and architectures merit can

be judged by reliability, size, weight and efficiency of data transmission.

Central Architecture

For a central architecture, the C&DH system placed at the center of the spacecraft acquiring andreleasing information to and from different spacecraft sub-systems. C&DH system acts just like anetwork router, and all commands and data must go through the C&DH system. Spacecraft sub-systems only connect to the C&DH system and do not have direct communication between each

other.This stops failures with one sub-system from affecting other sub-systems, and thusreliability increases. However, because all the systems are connected directly to the centralprocessor, this architecture requires more physical space and wires, thus increasing the size andweight of the spacecraft.

Figure 2: Central Architecture

Ring Architecture

Contrasted to the central architecture, with the ring architecture, the spacecraft sub-systemsconnects with the C&DH system in series, which means, sub-systems connects to each other andthe C&DH system one by one in a ring formation. The unique feature of this architecture is that

C&DH System

Communication

Sensors

Payload

Power

Structures

Actuators

Thermal


10/57

10

data is passed from one sub-system to the C&DH system through other systems. Thisarchitecture saves space and hardware addition to each sub-system, but in the mean time, it isalso relatively less reliable because of the fact that if one sub-system has error, other sub-systemsmay not be able to pass its data to the C&DH system.

Figure 3: Ring Architecture

Bus Architecture

In the bus architecture, sub-systems connect to each other with a central structure called a bus.You can imagine the bus as a main road and each sub-system is like houses located on smallstreets just off the main road. With such architecture, all sub-systems can be addressed

individually increasing the efficiency for data inter-communication. However, the reliability ofthe bus is crucial because if the bus fails, the communication of the sub-systems would beparalyzed.

Figure 4: Bus Architecture

C&DH SystemPayload Communication Thermal

Sensors Structures ActuatorsPower

CommunicationThermal

Sensors

Structures

Payload

Power

ActuatorsC&DH System


11/57

11

Architecture for nano-satellites

The main constraints for nano-satellites are the size and weight, and thus we need to choose anarchitecture that would allow the lightest, smallest design. From the 3 types of architectures, thering and bus architectures allows for less hardware, so these two architectures allow lighter and

smaller spacecraft comparatively. To choose between these two architectures, we need to lookinto the next important criteria: reliability. For the ring architecture, data require to pass throughother sub-systems, and so all the connections and sub-systems design must be reliable becauseany of these components is broken can result to paralyze of the whole spacecraft. On the otherhand, the bus architecture allows sub-system works individually and not depends on other sub-systems for passing data to C&DH system. And with the only concern is the bus reliability, busarchitecture is more reliable compare to ring architecture. With the best size, weight andreliability among the 3 types of architecture, the bus architecture is recommended for nano-satellite application.

Spacecraft Command System

Figure 5: Spacecraft Command System

Once the communications process has finished and the spacecraft has received a recognizable

signal, it has another process to begin. The signal is first sent to a receiver for demodulation andamplification, resulting in a command. This command is decoded and its validity is determined.If the command system decides that the command comes from a valid source, the now-decodedcommand is passed through the command logic. Inside the command logic sub-system the typeof the command is determined and what actions are required from it accordingly. Lastly, the finalinstructions are passed to the appropriate sub-systems via the interface circuitry.

Receiver / Demodulator

The command receiver amplifies and demodulates the signal from the communications sub-

system. Amplification of the signal is necessary because the signal strength is low by the timethe RF carrier reaches the satellite. The receiver takes the RF energy and reproduces the originalsignal. The demodulation process is different for the AM, FM, and PM modulations. AM is thesimplest form, but FM usually has a lower SNR and therefore usually outperforms AM.

Command Decoder


12/57

12

Figure 6: Command DecoderThe purpose of the command decoder is to detect the encoding of a subcarrier signal, which is

usually sent from a receiver/demodulator sub-system, and reconstruct the original commandmessage. The command message is nothing more than a set of instructions for performing aspecific task, such as changing the orbit of the spacecraft or deploying the payload. Commandscan also come from the on-board computer (OBC) and the hardline test interface.

A command system will typically have two redundant decoders and two receivers, either oneof which is capable of decoding commands. This is failsafe measure that allows one decoder totake over in the event that the other malfunctions or fails completely. The two receivers and thetwo decoders are cross-strapped so that all four sub-systems are active simultaneously.

Sometimes the command message will specify the decoder to be used by including a decoderaddress in the spacecraft address field. The spacecraft address is simply a group of bits thatidentifies the particular spacecraft to which the command is directed.

Figure 7:Cross-Strapping


13/57

13

Arbitration Schemes and Command Output Types

With so many possible sources from which the decoder can receive commands, there has to bean arbitration scheme to prevent the command system from being bogged down. Typicallyuplink commands, or commands that come from ground stations, have priority over the other

sources. Computer commands are delayed until a time slot is available. However, if a spacevehicle that is not expected to receive frequent input commands from a ground station, or if itintended to perform mostly preprogrammed tasks, then the OBC may be given first priority. Thehardline test interface is not active during flight and when in use overrides the other commandsources.

Command Messages

As stated in the previous section, the command decoder outputs the reconstructed commandmessage to the command logic in the form of a digital stream of bit and it is the job of thecommand logic to interpret the command message. A typical command message contains some,

if not all, of the following components:

1. Input checkerboard bits2. Synchronization (Barker word) bits3. Command bits4. Error detection bits

Only the first two components, input checkerboard bits and synchronization bits are needed bythe command decoder. The input checkerboard is a sequence of alternating 1s and 0s, whosepurpose is to provide the bit detector and command decoder time to acquire, or lock on to, themodulated subcarrier signal. The input checkerboard does not contain any data, therefore,

nothing important is lost if some of the bits are missed or improperly decoded. Once the decoderlocks on to the subcarrier, it sends out a lock signal. The lock signal informs the command logicthat a new command message is imminent. For command systems that do not use inputcheckerboard, a synchronization word will be at the beginning of the command message. Thissynchronization word, or Barker word, is a pseudorandom bit-or frame pattern that performs theexact same function as the input checkerboard-it acquires and verifies that the command decoderhas properly locked on to the transmitted command signal. If both an input checkerboard and asynchronization word are present, the decoder will only use the input checkerboard to acquire alock on the signal. The synchronization word also performs its secondary function: preventingfalse commands from being executed by the command logic.

Command Logic and Handling

The Earth-to-space command link provides all ground control for the satellite and requires thehighest security and reliability. Clearly, the execution of incorrect or unauthorized commandscan be catastrophic. To guard against this, command handling system passes all commandsreceived over the link through a robust validation process to ensure their authenticity and error-free reception.


14/57

14

Command Receipt and Verification

The implementation of secure and robust command logic is vital to the operation of any satellite.The command logic interprets the decoded command word, verifies its authenticity andcorrectness, and executes verified commands. The system safeguards the satellite from

unauthorized commands and unintended operation of a control due to errors in receivedcommands. Once the system receives and verifies commands, it may execute them immediately,or in the case of delayed commands, queue them along with a timestamp for later execution.

When the system receives a command from the command decoder, it begins a validation processto ensure the command is properly interpreted. First, the system checks for the proper spacecraftaddress code, and bitwise error detection and correction are applied, enabling to receivecommands over error prone links. The time of transmission is evaluated to ensure that thecommand was received in a reasonable amount of time for the given data rate. If the commandtook too long or too short a period to receive completely, then it cannot be a valid command andis rejected. Next, a command received and verified thus far is matched against the internal

command operation code table. This table is a one-to-one index of command words andoperation codes that is generally not numbered contiguously. Rather, the commands arenumbered throughout the numerable range of values for the allocated command word size; sothat no single bit error may result in one transmitted command being received and interpreted asanother, which would be possible if command operation code were contiguously numbered. Thischeck also helps prevent false commanding resulting from errors in command encoding on theground. Then an authenticity check is performed. Commands sent over encrypted links aregenerally considered self-authenticating and no further confirmation is performed, because onlyan authorized source will know how to encrypt the message properly. Many methods of moderndigital encryption allow messages to be signed and authenticated with a private key that need notbe transmitted with the message. The public key which matches that private key may be shared

openly and can only be used to decrypt messages encrypted with the private key. The public keywill only encrypt message encrypted with the private key, so any message properly decryptedwith that public key can only be from a holder of the private key.

Encryption

Encryption is the process of embedding a message in a stream of data that is difficult to decipherand/or forge without corresponding cryptographic keys. It is used both to protect sensitive datatransmitted from the satellite from eavesdropping and to protect the satellite command systemfrom unauthorized commands. This is distinct from encoding, which is merely the conversion ofa message into a format suitable for transmission over a particular medium, in this case a low

bandwidth (2,000 - 8,000 bps) high frequency digital link. Any message must be encoded fortransmission, but if it is not encrypted it may be easily forged. For this reason, commands sentover unencrypted links are verified by retransmission to the ground station over the telemetrylink. If the ground station verifies that the correct command was received by the satellite, anexecute command is sent. Because of the limited communication data rate available to thecommand and telemetry links, this process may take several seconds, but is necessary to ensureonly authorized commands are executed. This process ensures that the probability of acceptingand executing a false command is minimized, generally around 1 in 1018 to 1 in 1022.


15/57

15

Critical commands may require even lower probabilities which are generally achieved by usinglonger operation codes, or splitting the command across multiple operation codes.

Command Handling and Execution

Nearly all modern command systems are microprocessor based. The processor receivescommands from the decoder, interprets them according to some internal program, and outputsthe results to the interface circuitry. The inputs are the decoded commands which may or maynot be partially validated. The processor may then complete the validation, and will interpret andcontrol execution of the command. The most critical property of any microprocessor basedcommand system is reliability. The system must be fault tolerant and highly resistant to thehazards of the space environment. Errors in the command system can jeopardize the mission, andcomplete failure of the entire system will almost always result in loss of the spacecraft. Thisapplies to both the hardware and software comprising the command system. While complexsoftware can never be guaranteed to be error-free, its design must provide a high degree ofredundancy so that errors in the command handling program do not result in unintended

command execution.

Local Commands

Whereas the ground station is the primary source of command data for the spacecraft, theonboard systems may generate their own commands. A finite amount of time is required for theground station to observe a condition and command a response. Often, the response is required inless time than the generation, transmission, and validation of that command may take. Situationsalso occur where the spacecraft would be required to generate a response autonomously.Generally, these situations occur during the launch and transfer orbit phase of a mission, whenthe communication system is not operating in its normal.

Interface Circuitry

Interface circuitry is the final link in the spacecraft command system. Once a valid command isdetected, the command logic drives the command to the appropriate interface circuitry, which inturn executes the command. The type of interface circuitry that is driven varies with the type ofcommand sent to the command logic. The four major commands relay, pulse, level and data,each possess their own type of interface circuitry.

Relay Commands

Every spacecraft command system has relay commands. A relay command is ostensibly an on-off command, turning a specific system or device on or off, or switching a component of adevice from one state to another. Relay commands work by activating an electromagnetic relayin the central power switching unit. There are typically two electromagnets, one that switches thecontact into the on position, and one which pulls it into the off position. To activate one coil orthe other, the command logic sends a pulse to that coil, typically in the range or 50 to 300 am.Primarily, relay commands switch power to the different sub-systems on the spacecraft. While itwould be beneficial if the system could directly drive the relay coil currents, integrated circuits


16/57

16

(ICs) are incapable of driving more than a few mill amperes. This adds another requirement ofpower-driving interface hardware to run the relays. Typically, this hardware is set up in an arrayof source drivers and sink drivers. This has the added benefit of protecting against accidentalrelay activation. One single source/sink combination could not activate a relay on its own, somultiple drivers must be activated at once to ensure the relay goes active. This protection can be

furthered by requiring additional enable signals before the coil can be activated.

Pulse Commands

A pulse command is a short set of pulses sent to a sub-system with durations lasting from 1 to100 milliseconds (ms). The pulses drive small relays or logic latches in the sub-system.Depending on what the pulse drives, it is referred to differently. If the pulses drive a small relay,then it is called a remote relay command. If used to drive a logic latch or logic gate system, thenthe pulses are called logic pulse commands.

Level Commands

Level commands are the same as pulse commands, except that instead of varying the timeduration of the pulse the power level is varied. Level commands act as toggle switches for logic,changing the gate from a 1 to a 0 or vice versa. The other way to handle level commands is tohave two discrete commands, one forcing a 1 on the logic, the other a 0. This is currently thepreferred method, as the previous state of the logic need not be known.

Data Commands

Data commands require the most bandwidth of all the types of commands. Data commands sendwhole words, in the binary sense, to sub-systems. These commands may range in size from aword (8 bits) to 64 kilobits and more. This transfer of data is accomplished in one of two major

forms, via serial or parallel bus. In a serial bus the system can either send or receive data, but notboth at the same time. In a parallel bus the system can both send and receive data at the sametime. Data commands are used to modify the memory, either the RAM or the ROM. Thesecommands are ultimately used to load new programs or patch systems which are malfunctioning,among other things.

Data system

Spacecraft acquire large quantity of data from scientific data to system operation log. Often, the

data quantity is so huge that sending it downlink is not possible, and in that case, data acquired

must be stored onboard. Modern spacecraft data storage system includes disk storage and solid

state memory

1) Disk

Here digital information is stored as magnetic flux changes in a thin film on a disk-shaped

medium that rotates under moveable read/write heads. Random access to any datum can be


17/57

17

achieved in milliseconds. A disk storage unit that occupies 4X6X12.5 may store as much as

200 GB (1.6 Trillion bits) of data.

One problem with disk storage is that the mechanical devices necessary to drive the disks and

read/write heads are not as reliable as the rest of the components in the data processing system.

In particular, the R/W heads are so fragile that even when they are parked properly, are unlikelyto survive the vibration of the launch. Another problem with disks is that the mechanical motion

of the medium introduces momentum and vibration that may upset the spacecraft attitude

control. There is also undesirable Torques when the disk assembly is started or stopped. For

these reasons, disk storage is seldom used in small spacecraft. One solution is to use optical,

laser written disks used for archival write-only mass storage in spacecraft with short mission

durations.

Another drawback of this type of storage is that it is no radiation resistance. As mentioned

before, disk drives store data by magnetic flux, which means any magnetic flux can change the

existing data. If the disk drives happen to encounter magnetic flux in the environment, the dataon the drive might be affected. There is no way to avoid this situation except putting shielding

around the drives, and that would add too much weight and space.

Figure 8: Disk Storage

2) Solid State Memory

An alternative to magnetic surface memory is solid-state mass storage. With its approach, large

banks of RAM ICs are inter-connected to implement the mass storage. This method requireshigher power, but offers high speed and density. For reasonable volume and power, the storage

capacity of RAM mass memory may be as large as 4 GB. The cost of RAM is relatively high

compared to that of Magnetic disks.

Memory technology used for solid-state data recorders includes Synchronous Dynamic RAM

(SDRAM) and FLASH memory (high density, high speed, low power, non-volatile RAM). Flash


18/57

18

memory has limited total-dose radiation immunity-approximately 20krad maximum when using

Silicon, but offers the advantage of non-volatility.

Use of phase changes in amorphous semiconducting materials may soon provide a high capacity,

non-volatile, very radiation-immune random access storage medium for mass storage of

spaceflight computers.

Compared to disk drives, solid state memory can be more radiation resistant. Solid state memory

is basically a kind of silicon chip, and thus they can be radiation hardened through SOS and other

radiation hardening process. A radiation hardened solid state memory can take more than 10krad

dose of radiation

Figure 9: 1.8 inch Solid State Memory

For data storage of nano-satellite, using solid state memory has numerous advantages over disk

storage. First of all, solid state memory is physically more fit to nano-satellite applicationbecause it is so light and small; a solid state memory can weigh for less than a pound and just a

size of a palm without requiring additional shielding. Moreover even with such smaller size and

less weight, the storage capacity is still large enough for small spacecraft like nano-satellite.

More importantly, because solid state memory has no moving part, it is less fragile and thus be

much more reliable over disk storage.

Satellite EEPROM SDRAM Flash SRAM

ION-1 256Kb 1 MB 8 MB

UWE-1 512 KB 4 MB 8 MB

CUTE-1 256 KB 4 MB

AAUSAT 2 8 MB

Cute-1.7+APD

128 MB

Table 3:Example of data storage on nano-satellite


19/57

19

Data Handling Unit

Albeit, the terms Data Handling and telemetry are often used interchangeably, Data Handling is

more just than Telemetry. IEEE Standard 100 offers this definition of Telemetry:

Measurement with the aid of intermediate means that permit the measurement to be interpreted

at a distance from the primary detector. The distinctive feature of Telemetering is the nature of

the translating means, which includes provision for converting the measurand into a

representative quantity of another kind that can be transmitted conveniently for measurement at

a distance. The actual distance is irrelevant.

Data Handling combines Telemetry from multiple sources and provides it for downlink or

internal spacecraft use. Most Data Handling systems are of the Time Division Multiplexed type.

These systems sequence through their inputs in a predominant order, then organize them in a

fixed output format. Sample rate (Nyquist) of two times the greatest frequency componentpresent in the signal. Data from all inputs is converted to digital form and formatted into a serial

stream of continuous data for downlink. The data rate is the sum of all input sample rates plus

some bandwidth for insertion of synchronization codes and a frame identification counter.

Figure 10: Data Handling Unit Block Diagram

The Data Handling system may also supply Telemetry to an On-Board computer. The computer

sends its request to the data handling system which processes the input and returns Telemetry

data. This operation is interleaved with downlink telemetry gathering which is usuallycontinuous. Analog Telemetry data comes to the data handling equipment in many forms. Often,

direct Transducer outputs require signal conditioning prior to conversion from analog to digital

form. Data handling hardware is simplified, however, when input signals are pre-conditioned or

fall in some of the general categories.

1). High-level Analog


20/57

20

A telemetry channel with information encoded as an analog voltage, typically in the range of 0 to

5.2 V. These are active analog inputs in that the command and data handling system does not

provide measurement excitation. Data handling equipment converts this information into digital

form.

2). Low-level Analog

A telemetry channel with information encoded as an analog voltage. The signal range is low

enough to require amplification before the information is encoded into digital form. Typical gain

values fall in between 100 to 300. Because of the signals low voltage range, it is subject to

Noise contamination and thus uses an interface in which the telemetry information is the

difference between signal and reference inputs to the command and data handling system. This is

differential or double-ended interface.

3). Passive Analog

A telemetry channel with information encoded as a resistance. The C& DH supplies a constant

current to the resistive sensor and encodes the resulting IR voltage into a digital word.

All analog telemetry is converted to digital form within the C&DH system. The system

determines data resolution by the number of Quantization levels.

4). Bi-Level (Discrete) Input

A telemetry channel conveying two sate information. Information is encoded as voltages, but

may be encoded as a resistance or the presence or absence of a signal. Typically, logic 0 is

equivalent to 0 to 1V, and logic 1 is equivalent to 3 to 5V (or even 3 to 28V).

5). Serial Telemetry (Digital) Interface

A 3-signal interface used to transfer digital data from an external source to the Data Handling

unit. The C&DH provides a shift clock and an interface enable signal to control data transfer.

Interface circuits may be differential line drivers or single ended. Serial rather than parallel

interfaces are preferred on spacecraft, because they simplify cable design and require fewer

interface circuits.

TELEMETRYThe telemetry system in a spacecraft is in charge of acquisition, processing, and transmission of

housekeeping data to the ground station. Housekeeping data includes:

temperatures

pressures voltages


21/57

21

currents

Status bits from equipment

This is important because you want to monitor the overall health of your system remotely. Data

acquisition is taken from the payload and any sensors that data is requested from. The data is

then conditioned (amplified, filtered) to ensure that it is in the correct format. It is thenconverted to a digital format. The data is then processed to, potentially, cut down on the size.

The amount of pre-processing that can be done is based on the computer speed. The last part of

the process involves getting the encoded, modulated, and sending the data to a ground station.

Analog vs. digital signals

An analog signal is a continuous electrical signal that varies with time. There are different

formats of analog data: high-level, low-level, and passive. High-level analog signals typically

arrive at the system with a range of 0 to 5.2 V. These signals can be dealt with in their raw form

as the voltage is fairly high. Low-level analog signals arrive in a fairly low voltage and usuallyrequiring a gain of 100 to 300 to be encoded into digital form. Passive analog involves

information encoded as a resistance. The channel supplies a constant current and looks at the

change in resistance to calculate a voltage.

A digital signal is one in which is non-continuous. A bi-level digital signal is expressed as a 1 or

a 0. A logic 0 usually varies between 0 and 1 and a logic 1 usually varies between 3 to 5 or 28

volts. This type of information can also be encoded as a resistance. There is also serial

telemetry. This is a 3-signal interface used to transfer digital data from an external source to the

data handling unit. Serial connections, versus parallel connections, are preferred as they have cut

down on wires and require fewer interface circuits.

Steps in processing a signal:

Figure 11: Data Processing Block Diagram

The above diagram outlines the steps that the system goes through when it receives data from

sensors.

Signal-processing

Once the data is received, it is processed and formatted. Part of the signal processing is

converting all of the information into a digital signal.

Analog-to-digital conversion

SignalSignal-processing,

formattingEncoding Encryption

Modulation,

send


22/57

22

Since the system will be handling the information using bits, output as a continuous function

does no good for the system. In order to accomplish this, an analog-to-digital converter (ADC)

must be implemented. The steps involved include sampling, quantizing the bits, and expressing

the sample into a digital word. An example of what an ADC does can be seen below.

Figure 12: ADC Process

The sampling the rate of the system is based on the frequency of the component. If the

component runs at a frequency of 50 Hz, this means it is taking 50 samples every second. There

is a theory in data conversions called the Nyquist frequency. There is a phenomenon that

plagues some systems called aliasing. Aliasing is when not enough data points are being taken

and the signal may come out wrong. The Nyquist theory says that the number of measurements

that can be taken without aliasing occurring is equal to twice the frequency. One way to account

for this is to add a low-pass filter to the ADC that only takes every other sample.

Quantizing the bits is a process where the frequency values are converted to a digital number.

The problem with this is essentially rounding. If you have a value that is 4.2, the quantizer will

convert it to 4. This means you have a quantization error of .2. An n bit word can discriminate

2n levels. To minimize the quantization error, it is required that the number of bits looked at

increase. A table showing quantization error as a function of bits per sample is shown below.


23/57

23

Table 4: Quantization error as a function of bit per sample

Signal processing can reduce the number of bits required for transmission. This process is calleddata compression. There are several compression techniques that can be used on spacecraft.

One is called lossy compression. Lossy compression is where the significant figures of digits are

cut down to minimize the amount of data per bit. This is essentially rounding. Another process

of doing this is by carrying out computations to reduce the amount of data that will need to be

down linked. This can be done with the help of a computer coprocessor. This is when there are

multiple processors, one for the master and another that gets data handed to it for processing.

Formatting

Formatting of the data is where it is put into a packet. This involves putting the data into an

organized fashion that will be recognized by the ground station once it is sent. There are two

standards that are used when formatting data, the Consultative Committee for Space Data

Systems (CCSDS) and the European Cooperation on Space Standardization (ECSS). CCSDS is

the type of formatting that is used in NASA across the Deep Space Network. A general format

for telemetry packets can be seen below in Figure 15.

Figure 13: Formatting for telemetry packets

To expand upon this, the syncword is a 16-bit code that works to synchronize data. This is done

by putting a string of bits that cannot occur anywhere else. This allows for the spacecraft and

ground station computers to synchronize. The frame counter tells the receiver the packet length

in bits. The spacecraft ID tells the ground station what it is receiving data from. If multiple

systems are beaming down data and it gets mixed up, it is possible to determine where the packet

came from. The frame format ID tells the ground station what information is being passed. The

Syncword FrameCounter

SpacecraftID

Spacecrafttime

Telemetrydata frame

Tail

sequence

Frameformat ID


24/57

24

spacecraft time allows for the ground station to determine how old the information is. This is

generally good practice. The telemetry data frame contains the actual data. This is the largest

part of the packet as it contains the most important information. The tail sequence is a sequence

of random data that represents the end of the packet.

Encoding

The next step in processing is encoding. Encoding is important because it allows for the data to

be setup in a way that lends itself to be corrected if errors occur when sending the data. Due to

the distance and medium which the data is being sent through, it is likely that data loss will

occur. Some methods of error correction include cyclic redundancy checking, forward error

correction, and Vertibi coding.

Cyclic redundancy checking (CRC) involves applying a CRC code to the output message. This

code alters the message for each block of tat and sends them together. When the message is

received, each block of code is recalculated. If the new CRC does not match the old CRC, anerror has occurred. This system is a simple code so the correctness of the code can be trusted but

not the integrity. This is a good encoding method to use because it adds no information to the

data.

Forward error correction (FEC) is a method where redundant data is added to a message. Every

bit will have the same value given to it a certain number of times. For instance, a digital 1 may

be transmitted as 111. When the data is decoded and processed by the ground station, if the

value is 101 chances are the value that belongs is a 1. This logic follows that the chance of 3

bits being flipped is not very probable. This allows the receiver to detect and correct errors more

easily. By correcting errors when they are detected, the need for retransmission is lower. Thetrade-off, however, is that more data must be sent which leads to more power from the

transmitter.

Vertibi decoding processes FEC encoded data. This uses a soft-decision algorithm to determine

the true values. Vertibi decoding is used to decode convolutional FEC codes. It uses an

algorithm that computes the probability of a sequence of observed events.

Encryption

An optional part of the telemetry process is encryption. Encryption is when you create a cipher

that is known to you and the receiver that allows for the translation of data. This is done throughthe software. This is optional because it depends on the type of data that is being sent. There are

systems available that have keys and radios interfaced. One such system is the CCS-110 Cubesat

Communications Suite.

Modulation


25/57

25

The last step in this process is to modulate the data and send it to the ground station. This is

done through digital modulation techniques. Once the packet has been sent to the ground station,

this process is done in reverse. The ground station receiver demodulates, deciphers, decodes,

archives, and eventually analyzes the data.

Onboard Computer Systems

Onboard spacecraft, computers are becoming an integral part of the overall system. Computers

are found in just about every sub-system. Because of this, estimating the computer resources

required is beginning to take on a larger scope than in the past.

In designing a spacecraft computer system, the main goal is optimization of the capability,

flexibility, reliability, and availability of the system while minimizing cost. The objective is to

meet system and mission requirements. It is important to keep the system simple at the lowest

level to ensure and build up the capabilities to meet top-level mission requirements. An increasein complexity leads to an increased need for testing.

When defining the computer system, it is broken up into three categories: hardware, software,

and documentation. The hardware consists of the CPU, the data bus, and logic, discrete, and

analog components. The software consists of the operating system and computer software. The

documentation is requirements, design documents, and interface control documents. We will be

focusing on the hardware and software.

Design Drivers

The design drivers can be broken up into several areas: mission requirements, system levelprocessing requirements, computer level requirements, and additional requirements. These are

found in table 5 below.


26/57

26

Table 5:System Drivers

Mission requirements are the top-level requirements that must be set before any action is taken.

When talking to the customer, you want to figure out what kinds of needs they have. By

defining the overall objectives, the mission requirements should follow. Considerations such as

the number of satellites and level of autonomy will govern how complicated the system will be.

These drivers span most of the system leading to the most influential on cost and risk. For

instance, a high level of autonomy will require a more extensive software code and more

processing which translates into a higher cost for development and testing as well as risk.

The system level requirements are more mission specific. These are dealing more with what you

want your spacecraft computers to do. An important question across any system is the

processing that will be done on-board the spacecraft versus on the ground. If your spacecraft is

beaming back a large amount of raw data or you have a window that you need to limit your total

information being sent, you can process the data and potentially condense the total size of the

total information. This will require more processing power from the CPU which translates into a

higher cost.

The computer level requirements follow from the system level requirements. After estimating

the amount of data that the system will be dealing with, the specific requirements follow. These

would be things such as the amount of memory required on the computer, the processer size

required, and the type of software that is needed.

Computer System Specification

There are typically several steps taken when defining the computer system.

1. Allocate missions and system requirements to computer system


27/57

27

2. Define the computer systems operational modes and states

3. Define where the processing will be done

4. Select a baseline architecture

5. Form baseline system form the above requirements

This is an iterative process that occurs frequently because requirements are often contradictory.Also, requirements can either be too narrow or broad in scope. These problems become

exponentially more expensive to fix once the spacecraft design moves farther along.

Defining System Requirements

When defining system requirements it is important to ask basic questions:

What must the system do?

Why must it be done?

How can it be achieved and what are the alternatives?

Is the system testable?

These allow the user to determine what types of requirements are needed to achieve the goals set

forth by the customer. One way of determining this is to create a state diagram. A state diagram

shows the possible states of the system (such as off, launch, stand-by, etc). An example of this

can be found below in Figure 16.

Figure 14: State diagram

It is important that the system be able to support the possible states. Depending on your system,

you may have several possible substates such as fail-safe conditions. Depending on how the

system got into this state, there may be multiple ways to handle it.

Another way to define system requirements is through functional partitioning. This is a method

by which requirements are broken down into their lowest functional component. This allows for

grouping of similar functions.


28/57

28

Central Processing Unit

Introduction

CPU, in general, access memory locations, interprets instructions, implements instructions, and

perform logical computations. The CPU in the C&DH system of a spacecraft is no different thanthose in your personal computers, but the specifications of them are totally different mainly due

to the harsh operation environment and other cruel constraints of the space mission.

There are two main types of CPU for space applications; Embedded CPU and General Purpose

CPU.

Embedded CPUs are built-in unit of a larger system, and they are designed to control and

response to specific components of the system such as actuator, sensors. As embedded CPUs are

designed specifically for certain applications, they can do something general purpose CPU

cannot do; provide extra functionality beyond data processing. Another characteristic ofembedded CPUs is that as the major purpose of embedded CPUs is to make the system to be

autonomous and robotic, and so often, they are harder to reprogram with no user interface.

On the other hand, General Purpose CPUs are function just as its name; execute general data

processing, computations, and commands. In contrast to embedded CPUs, they are not designed

for specific function, but with proper programming, it can virtually do any generic computations.

Figure 15: Typical OBC

Input/Output

Input / Output devices are the connection between the CPU and the data bus, transferring data

back and forth. It transfers data to and from the data bus in two ways: Serial and parallel.

CPU


29/57

29

Serial Input/Output

Serial I/O transfer data bit by bit and it is usually used only with small data transfer rate.

Although the data transfer rate allowed is less, serial I/O gives advantage of requiring less pins,

and thus reduce size and weight. Application of serial I/O in C&DH includes command transfer

and telemetry data.

Figure 16 : Serial I/O

Parallel Input/Output

Contrasting to serial I/O, parallel I/O transfer data with several bits at one time over several

parallel channels. As it sends several bits at one time, and more bits mean more transfer rate, it is

transfer data much fast than serial I/O, and thus it is required when large data transfer rate is

needed; for example, transfer scientific data. Because of the parallel channel construction, more

pins is required for parallel I/O.

Figure 17: Parallel IO

Memory

Spacecraft computer systems employ a wide variety of memory devices and architectures. These

include Read Only Memory (ROM), Random Access Memory (RAM), and special purpose

memories such as multiport memory, First-In First-Out (FIFO) memory, Cache memory, Content

Addressable memory (CAM), associative memory, and high speed table look-up memory.

Memory types and their architectures are tailored to the specific processor application.


30/57

30

Read Only Memory

This device stores the data permanently. The programs, constants and look-up tables are placed

by the designer in ROM and are valid for the duration of the mission. The stored data may be

read but not altered. These devices are non-volatile i.e., when power to these devices is lost, the

data is not lost. Normally ROM is used to store programs and sub-system parameters. Theprograms are read out of ROM into RAM from which individual instructions are fetched for

execution. Sometimes instruction data are fetched and executed immediately out of ROM. In the

later case, no program may be self-modifying, because the physical program storage is not

alterable. Parameters are loaded into RAM from ROM and are then used to control the functions

of the Software.

Other forms of ROM include Electrically Alterable ROM (EAROM) and Electrically Erasable

ROM (EEROM). These types of memory are referred to under the generic category Read Mostly

Memory. Both are non-volatile; however, individual words of EAROM may be changed, while

with EEROM an entire integrated circuit, or a significant block of it, must be erased at oncebefore new data may be stored. Electrically Erasable Programmable ROM (EEPROM) that may

be programmed by the user, even after the spacecraft had been launched. It is more vulnerable to

Single Event Upsets during its write cycle. A typical spacecraft computer sub-system has from

1M to 64 M bytes of ROM, usually in form of EEPROM.

Random Access Memory (RAM)

When not implemented with magnetic cores, RAM is volatile i.e., the data is lost whenever the

power to the device is lost. RAM is the fastest kind of memory and is Read/Write memory in

which any word may be addressed at any time. Words of data stored in RAM do not have to beaccessed sequentially or in blocks or tracks; the user has fast random access to the memory

contents. A typical spacecraft sub-system will have from 4M to 256M bytes of RAM. The Rule

of Thumb is that a single CPU spacecraft computer system will need to have approximately 512

KB of local RAM for each Million Instructions per Second (MIPS) of throughput that is used.

For missions that have a requirement for high immunity towards Radiation effects, it is often

quite difficult to meet this requirement for RAM capacity.

Special-Purpose Memory

Some memory devices are used for unusual or special purposes.; Multiport memory is used for

inter-processor communication; cache memory is used for high speed table look-up and data

accessing, particularly by CPUs; fast multiply accumulate memory is used to hold partial results

in digital signal processing operations. Content-addressable memory is used for cache

directories, translation look-aside buffers, statistical computation and format matching. Other

special-purpose memories include energy spectrum accumulators, auto correlators, and video

frame grabbers for image processing.


31/57


32/57

32

The data bus is in charge of delivering information from the CPU to the rest of the system.

There are generally two types of buses available: parallel and serial. There are also internal and

external buses. A bus is mainly a standard that defines the way that hardware is attached to the

system. This is important when taking system compatibility into account.

Internal vs. External Buses

The way to describe an internal versus external bus is defined by the domain that it deals with. If

the bus only connects computer components with a motherboard, the bus is considered internal.

If the bus is connecting the CPU to other devices such as a camera or the communications

system, it is considered external. We will be concerning ourselves with external buses as we

want to see how to communicate between components.

Parallel Bus

A parallel bus is where information is sent over a large number of wires at the same time.

Systems typically send information out in multiples of 8 bits (8 bits = 1 byte) over channels.

Typical channel sizes include 8, 16, and 32 bit. The way to calculate the speed across a parallel

bus is seen below:

= #

This sounds like it would be a fast system considering so much information can be sent at once.

The information can only be processed when all information from each byte is received at the

other end. Several problems occur including skew and crosstalk across wires.

Skew

Skew is when propagation delays occur across each line. The information at the receiving end

must be complete before anything can be processed. A visual example of skew can be found

below in Figure 21.

Figure 19: Skew


33/57

33

This is important because an increase in clock speed requires less skew. There are several ways

to combat skew. One popular solution is a parallel-to-serial converter. This involves converting

the bits into a byte and transmitting the information in serial form. The other end would be

required to have a converter to covert back to parallel form. This is not as fast as a serial

connection because of the time taken to arrange the bits to be sent out.

Crosstalk

A problem that occurs for any system is crosstalk. Crosstalk is coupling energy from one line to

another. There is forward and reverse crosstalk. Forward crosstalk occurs between data being

sent in the same direction. This can be calculated by:

=

Where is the capacitively coupled current and is the inductively induced current. Reverse

crosstalk occurs between data being sent in opposite directions. This can be calculated by:

= +

Reverse crosstalk is considered to be more of a problem than forward crosstalk due to the

additive nature of the affect. One way to mitigate the effects of crosstalk is to space the wires as

far apart as possible. By keeping this space, less energy is introduced into the system.

Serial Bus

A serial bus sends a single bit is sent at one type across a wire. This sound like it would be

slower and less efficient than using a parallel bus; however, this is not the case. Since the bits

are sent one at a time, skew is not a problem. All of the information arrives in the order that is

has to. Also, fewer connecting cables are required because you are not forced to send a certain

number of bits at once. Fewer connecting cables lead to less crosstalk and less space taken up.

Also because there are fewer connections, fewer pins are needed at each juncture making the

parts themselves cheaper.

Bus Options

There are a lot of bus connections used in the space industry. Three of the most common ones

are SpaceWire, PCI, and I2C.

SpaceWire is a serial communications network that was developed by the European Space

Agency (ESA) and is used on ESA, NASA, and JAXA missions. The data transfer rates vary

from 2 Mbit/s to 400 Mbit/s over 4 wires. The skew is defined to be no more than .1 nsec/m.

SpaceWire is based on the IEEE 1355 standard for heterogeneous interconnect. SpaceWire has

an extensive heritage on space missions. It is currently being implemented in the James Webb


34/57

34

Space Telescope, Mars Express, GOES, the Lunar Reconnaissance Orbiter, and many other

missions.

PCI is a parallel connection that is used on a number of internal buses. Since the connections

internal to a CPU do not travel far, skew and cross-talk will not be considered a problem. Data

transfer with a PCI connection is found to be around 133MB/s with the 32-bit version. PCI isfound in the STEREO satellite to communicate within the OBC.

I2C is a two-wire connection with typical voltages between 3.3 and 5. Data can be transferred at

rates varying from10 kbit/s to 3.4 Mbit/s. Due to the design, 112 devices can be controlled on

the same bus. The design is supported heavily by Linux and eCos operating systems.

Nanosat applications

A bus type commonly found on cubesats is I2C. This type of connection is found on PLUME

and CP2. PCI type buses are commonly found inside the CPU. This is alright because the data

has very little distance to travel meaning skew and cross-talk is not a problem.

Computer System Requirements

After determining the top-level requirements, state diagram, and system architecture, it is time to

select the system. The drivers that should drive this include the orbit, expected operating time,

level of autonomy and any other issues that will affect the hardware and software development.

The orbit will determine the radiation environment that the hardware must be able to withstand.

The expecting operating time will affect how robust the system must be. This will also lead to

more testing. Depending on how critical the mission is, commercial off-the-shelf (COTS) partscan be used. Also, the lower the number of operating states, the less complex the software and

preflight testing. High performance requirements on the spacecraft computer lead to increased

performance requirements for both hardware and software. For instance, a high-data rate

payload may lead to the need for a higher bandwidth data bus.

Other Considerations

One issue that arises with software is how single event upsets (SEU) can disrupt operations.

This is due to the fact that software runs on random access memory (RAM). Firmware is the

answer to this problem. Firmware is stored on read only memory (ROM) which is much less

susceptible to SEUs. This is often the best place to store critical processes as it is more robust.

Fault Toleration

No computer system is perfect. There will be faults associated with every system that must be

accounted for. There are several ways to mitigate this. One is redundancy. This can be done by

duplicating equipment, having a back-up capability, performing the same task on the ground and


35/57

35

on-board the spacecraft, or using a bus network that allows the data to be sent to multiple

applications. This fault protection is fairly easy to test as it usually requires testing the same

system twice. The problem with this is it usually requires additional weight, power, and cost. A

second method is distributed processing. This allows for multiple processors to take different

software functions and distribute the work. This can allow for an increase in overall processing

efficiency if carried out correctly. The problem is that this can be a very tricky system to test. It

also requires additional software to determine what to distribute to what part of the system.

Watchdog Timers

If your spacecraft is near Mars and the computer system gets lost in an infinite loop and you have

no way to communicate with it, what are you supposed to do? The watchdog timer (WDT) is the

key to recovery. A WDT is a hardware timing device that triggers a system reset, or similar

action, to be taken after a certain amount of time has elapsed. WDTs are not meant to catch

every problem that occurs but you can mitigate the probability of total system failure. There areseveral considerations to take into account such as the time interval and whether your want to use

the internal CPU watchdog or also have an external one.

How a Watchdog Timer Works

A WDT is essentially a timer that needs to be reset after a certain amount of time to avoid

actions being taken. The WDT has a timer that counts down from some set interval or to a set

value. The timer will run until the task that it is monitoring resets it. If the timer gets to the

defined value and the software has not sent a response, a number of actions can be taken (an

alarm is sounded, a device is disabled, the system is reset). This idea is illustrated in Figure 22below. This works to ensure that any glitch is averted. It is important that a status bit is sent to

the operators to allow for the problem to be pinpointed. If the problem area is never found, the

software cannot be upgraded properly and the problem will continue to occur. The timers also

have the ability to look at the voltage going to the system. If this voltage drops below a certain

value the timer can kick in and reset the system.


36/57

36

Figure 20: WDT explanation

Choosing a Time Interval

An important decision to make with your timer is the time interval between resets. If your time

interval is too short, the process that needs to reset the timer will never complete and the system

will constantly be reset. This would be hard to diagnose the problem to see if the failure is real

or if the interval is too short. If the interval is too long, you may find that your system is not

being reset enough and major errors will occur. Several seconds is usually considered robust for

a watchdog timer. One way to judge the time interval is to decide how long it takes for the

software to run to the reset point and add some time on to that. This way, if you do not get a

response in the expected length, you will have an accurate way of judging what it should be.

One thing to consider is that the recovery length (the time it takes to reset the computer) is WDT

timeout plus the time it takes for the system to reset. This could be crucial seconds for your

mission which is why the time interval is of such importance.

Internal vs. External Watchdog Timers

Internal WDTs are found on all computer processors. These types of timers are controlled using

the software. Internal WDTs are considered less reliable because, since they are programmed

into the flight software, if the software gets lost in an infinite loop, it could easily freeze theWDT and the user would never know. Since internal WDTs are in the software, they cut down

on space as no external chips are needed.

External WDTs are either added to a microcontroller or made on its own board all together. The

way that external WDTs reset the system is an I/O pin that goes straight into the CPU. A simple

diagram of how they work can be found in Figure 23 below.


37/57


38/57

38

Figure 22:example of watching multiple tasks

The WDT looks for a flag from every task. If all tasks send a flag, the timer is completely reset.

If a flag is not returned, the WDT receives a bit saying where it was hung up and resets the

system. This allows the system to account for where the problem occurred.

Nanosatellite Applications

As all satellites have a CPU, every nanosat will have a WDT on it. The question that will drive

whether or not you have an external WDT for redundancy is based on a few things. One issue is

the amount of space you have on your satellite. If you are at capacity for size, adding an external

timer may not be an option. As most of these chips cost on the order of $10, cost is usually not

an issue. Another consideration is how much testing your software code has undergone. If you

have a lot of faith in your code and believe it will never freeze up, you will not need an external

timer.

The M-Cubed satellite being built at the University of Michigan is using an external WDT that isbeing attached to their communications board. They decided to go with the Maxim DS1374C

external timer.

Figure 23 Block Diagram ofMaxim DS1374C external timer

The specs on it are:

Cost: $6.95

Average Power Consumption: .6 mW

Size = 15 mm2

Includes internal 32-bit clock

This is a viable option on most missions. By adding this chip, the chances of a total system

failure are significantly decreased.

Another option is making your own. Quakesat, a cubesat built at Stanford University, created

their own WDT. They made it using a PIC controller and a WDT chip on a board.


39/57

39

For a detailed explanation of WDTs and a list of Maxim WDTs, visit:

http://www.maxim-ic.com/appnotes.cfm/an_pk/1926

Error Detection and Correction (EDAC) circuitry is hardware that provides bit error tolerance.

This is helpful for single event upsets. EDAC corrects a single bit in a word when a SEU isdetected. This only works for a single error in a single word. If this does occur, it is possible to

run a memory scrubber. A scrubber scrubs all single bit errors as it reads each word. This is

available through the operating system. The one parameter that is able to be controller by the

user is the time between scrubbing. The scrubbing time can be determined based on the rate of

upsets.

Flight Software

Software often falls into three classes, control, system management, and mission-data system

software.

Control system software takes care of attitude determination and responds by changing the state

of the system. It is very mathematically intensive requiring high accuracy and timeliness. This

takes up most of the CPU power.

System management software entails fault detection and correction, long duration even

schedulers, and payload system management. This is logically intensive as it deals with flow

trees. This is usually not very complicated as it there are very little calculations involved.

Mission-data software carries out calculations and compresses data as it is collected. This often

requires special system architectures as well as large storage capacity. This is the data associated

with the payload.

Programming Languages

A programming language defines is a collection of commands, functions, and statements that are

the building blocks for software. There are two levels of programming languages used, assembly

and higher-order languages (HOL). Assembly language is the most basic programming that can

be done. Each computer has its own unique assembly language. Programming in assemblyrequires a detailed understanding of a particular computer. HOLs use sophisticated commands

and functions that are set by standards. They are easier to understand by anyone who has done

programming in that particular langauge. Some examples of languages include C, JAVA,

FORTRAN, Visual Basic, and Python. HOLs require a compiler to step them down to assembly

language before the computer can understand them. Pros and cons of both language types can be

seen below.


40/57

40

Language Type Pros Cons

Assembly - Corresponds one-to-one with hardware

- Code is compact

- Very cryptic, mustknow well tounderstand

HOL - Easily understood byany programmer - Compiler required

Table 6: Pros and cons of programming languages

Estimating Software Size

Through the years, flight software has greatly increased in complexity. Below is a graph

showing the number of source lines of code (SLOC) from Apollo to the CEV.

Figure 24: NASA graph showing SLOC

There are several steps in estimating size of the software that you will be using. They are:

1. List all application functions allocated to the computer

2. Break down the functions into basic elements

3. Define the real-time execution frequency for each element

4. Estimate the total source lines of code

5. Estimate the throughput

6. Determine the operating system and overhead requirements by similarity

7. Determine the margins for growth and on-orbit spare

The main aspects that will be focused on will be steps four and five.

There are two things to estimate, the software size and throughput. Software size is the total

lines of code. The throughput is the processing time required expressed in instructions per

second. These estimates are important in determining if there is enough spare processing power


41/57

41

to run the software during the mission. This is also an estimate of cost as developing and testing

the software is not free.

Determining the throughput can be done using the following equation:

=

[( ) + (+1 +1)]

where Tis the total throughput in instructions per second S is the CPU speed in Hertz,Xis the

percentage of the type of throughput, and Csis the number of clock cycles required for this

instruction. This allows us to determine how much information the system can process.

In order to determine if the hardware architecture will meet the processing needs of the system,

there are benchmark programs. The benchmarks can be seen in Table 7 below.

Table 7: Benchmark programs used to test hardware architectures

Certain benchmarks are used depending on the type of system that is being tested. If the system

under test is mathematically intensive, we will use a test such as the Linpack. If the hardware

focuses on integer math, the Dhrystone will be used.

There is a simple method to use in determining if there is enough RAM available in the system

under consideration.

1. Estimate the lines of code2. Convert the lines of code into digital words

3. Estimate the words of data

4. Compare software size and data storage needed to the available RAM

If the software that you are using is coded using a HOL, the lines of code must be converted to

approximately what the equivalent code would be in assembly. Figure X below shows a

conversion between some more popular languages.


42/57

42

Table 8: Conversion from HOL to assembly

This estimate is the most helpful when the code is the least understood.

Similarity vs. Bottoms-up Estimating

Similarity is an estimation method where software functions, at the lowest levels, are comparedto previously developed software. The idea is that based on the complexity, the code can be

scaled and a good estimate can be made. When doing this, the differences between each project

should be taken into account.

Bottoms-up estimating is where each function is broken up and looked at from the lowest level.

Each element size is estimated and summed together will all the other pieces. This allows for an

estimate of the total amount of lines of code or throughput.

Computer Size Example

An example of a bottoms-up software budget can be found in Table 9 below.


43/57

43

Table 9: Generic software estimates for onboard applications

Nanosat Applications

Nanosats are small and thus have a need for only the most minimal of software. More software

means more memory/processing power which leads to a higher cost and more space being used.

Also, most nanosats are being built by universities around the world. Because of this, the

software is mostly programmed for each individual mission. This ensures that no superfluous

applications are included on the processor. Because of the complexity associated with assemblylanguages, most of these missions are coded in a HOL (mostly C). Genesat-1 and M-cubed are

both having their programming done in C by students.

There are companies that can provide software. VxWorks is popular among NASA and has an

extensive heritage. VxWorks has hundreds of preexisting applications that can be used. They

also have a program called Tornado that allows for the user to create their own programs using


44/57


45/57

45

Stability is another important issue. If your system crashes, how will it recover? Some OSs will

take a long time to boot up. In this reboot time much damage can potentially be done to the

spacecraft.

Choosing a good file system is also important. A file system is how you handle large amounts of

data. For instance, Salvo, the RTOS found on the Pumpkin cubesat kit, does not have a filesystem. All the data is stored in memory and RAM, not a dedicated hard drive. In order to gain

one, you must buy a library that plugs into the system via an SD card. This ends up being a huge

memory drain. An OS like Windows or Linux has a file system built in.

Multitasking

Every RTOS employs multitasking. Multitasking is a method by which multiple tasks are run at

one sharing processing resources. The com

Aoss_582_09_CDH_Tech_Talk

Documents

Transcript of Aoss_582_09_CDH_Tech_Talk