Command & Data Handling
-
Upload
fady-michel -
Category
Documents
-
view
124 -
download
4
description
Transcript of Command & Data Handling
AUC CubeSatCommand and Data Handling Subsystem
Fady M. Morcos
1. System Definition:
The Command and Data Handling subsystem (C&DH) is responsible for running the
spacecraft in an ordered and ‘intelligent’ manner according to its flight program. It is the brain of
the satellite platform.
The C&DH is responsible for the overall management of the spacecraft's activities. The
system has two main functions: reception and execution of commands from the ground station,
and gathering payload and housekeeping data (HK data), to be transmitted to the ground station.
Moreover, the C&DH subsystem provides the main bus for the data exchange between all other
subsystems. The system manages three data streams, each critical to the spacecraft, and each
with distinctive characteristics. Those are:
• mission/scientific data from the payload
• housekeeping (HK) data from spacecraft subsystems
• commands from ground station
The C&DH has to be capable to store those data streams for two main reasons. The first is
that payload and HK data can only be transmitted when there is a communication link with a
ground station, which occurs once every several orbits, depending on spacecraft's orbit.
Furthermore some commands from ground have to be processed at later times, making it
necessary to store those commands, and execute them according to their time tags.
2. Functional Requirements:
The system receives commands from the communications subsystem, performs validation
and decoding of the commands, and distributes the commands to the appropriate spacecraft
subsystems and components. The C&DH also receives housekeeping data and science data from
the other spacecraft subsystems and components, and packages the data for storage or
transmission to the ground via the communication subsystem. The system must also provide
analog-to-digital conversion capabilities for any subsystem components generating analog
signals (e.g. temperature sensor), before being stored or sent to spacecraft bus. Figure 1
illustrates the command and data paths within the satellite, and between the satellite and the
ground station.
Other functions of the C&DH include maintaining the spacecraft clock, state-of-health
monitoring, and managing high-level fault protection and safing routines. In a centralized
architecture, the C&DH system is also responsible for the execution of attitude determination
and control algorithms, as well as power system management algorithms. In a distributed
architecture, however, each of the Attitude (ADCS), Power (EPS), and Communication (COMM)
subsystems has its own PIC controller dedicated to performing the respective subsystem's tasks.
C&DH Functional Requirements
Provide an operating system that controls the spacecraft
Assure and control the data exchange among spacecraft subsystems
Process Received Tele-Commands
Acquire Payload & Housekeeping Data
Provide storage for data and commands
ProvideA/D conversion capabilities
C&DHCommunication
Subsystem
Payload
SpacecraftSubsystems
GroundStation
Command
Science
HK Data
COMM-ANDS
SCIENCE & HOUSEKEEPINGDATA
Command
Command
HK Data
Science Data
Fig.1: C&DH System Operations
Maintain spacecraft clock
State-of-health monitoring
Manage fault protection and safing routines
Centralized Architecture:
Execute ADCS routines – (Sensor Data Acquisition, Attitude Determination, Attitude Control)
Execute EPS routines – (Power Management, Power Distribution)
Execute COMM routines – (Validation, Telemetry Stream Generation, Data Up/Downlink, Mod/Demodulation, En/Decapsulation, … etc)
3. Design Analysis:
The development of the C&DH subsystem requires both hardware and software solutions to
successfully perform all the above mentioned functional requirements.
3.1 Hardware
The hardware is composed of three main constituents:
OnBoard Computer (OBC)
◦ Controls the spacecraft operations in normal mode. It handles the exchange of data
between the payload, subsystems, memory and communication. It is responsible for the
decoding, encoding, and memory storage of commands, payload, and HK data. The
OBC is also responsible for managing fault protection and safing routines. Refer to
table. 1 for a full list of OBC functions.
System Bus
◦ Subsystems communicate with each other via the system bus. The bus assures the data
flow between the different spacecraft subsystems and components. The I2C bus by
Philips is the most commonly used onboard Cubesats. This two-wire bus has a data
wire, and a clock wire to synchronize transfers. Every component connected to the bus
has its own address, like a phone number, and can send/receive data or commands by
following a predefined protocol.
Table.1: C&DH Functional Requirements
External Memory
◦ Flash Memory provides space for payload data, HK data, and commands received from
ground/control station. Flash offers a great advantage over RAM in that it does not
loose stored data even when powered off. Flash memory is also used for storing flight
software and boot loader, as well as flight software updates from the ground station,
which is unachievable using PROM. However, Flash Memory is more prone to
radiation than PROM; thus it is recommended to also use PROM to store the original
boot loader and flight software. If space radiation corrupts the updated version of the
flight software on the Flash memory, the OBC can reset and use the original boot loader
stored on PROM to assure successful operation of the spacecraft.
All the above components will be mounted on a single PCB. The board also holds the
connectors for the payload and other subsystem boards. The PCB and components have to
comply with the size, mass and power constraints of the Cubesat. When choosing components
for the PCB, the rough space environment must also be taken in consideration, particularly
temperature and radiation. Space-tested, Commercially available Off The Shelf (COTS)
components are easily acquired through numerous vendors. Several recommendations from
veteran Cubesat builders are available, and documented in several online resources.
3.2 Software
The flight software is the core element of the C&DH subsystem. It brings the devices ‘to
life’ and utilizes their features. The program code has to accommodate the various mission
modes of the spacecraft, including boot mode, nominal mode and power save mode. During
boot, the micro-control-unit (MCU) of the OBC initializes the other devices and goes into a pre-
defined state. When all devices are initialized, the satellite is said to be in nominal mode, in
which the C&DH interacts with the payload, and all the spacecraft subsystems, namely ADCS,
EPS, and COMM. When in power save mode, the C&DH is turned off. No code will be executed
at this time. As soon as the Electrical Power System (EPS) switches from power save into normal
mode again, the boot procedure is passed through again.
The choice between a real-time operating system (RTOS), or a designated kernel to handle
satellite operations must be made. An RTOS, like VxWorks, enables the programmer to write
code on a highly abstractive level, which does not take into account the final hardware selection,
but rather concentrates on the functions to be carried out. The other way is to write designated
kernels dedicated to the chosen hardware configuration. In this case, the code is usually
furnished much better to the hardware on the lowest level, and the hardware resources can be
fully utilized. Also the code size will remain relatively small compared to an RTOS (however,
the programmer will have to write more lines of code since all low level routines have to be
written as well).1
The software does not only include the operational system of the C&DH, but it is a part of
all other subsystem as well. As mentioned above, in centralized architecture, the OBC will
manage and execute the different subsystem routines, while in distributed architecture, those
routines are executed via the PIC controller on the respective subsystem board. Table 2 below
lists the standard functions required of the different spacecraft modules.
System Software Function
C&DH Command VerificationCommand DistributionData CollectionData FormattingData EncodingData & Command StorageFlight Plan SchedulingFlight Plan Execution
Fault Protection Redundancy ManagementAnomaly Response (e.g. latchups)Error Detection & Correction
Operating System Executive TaskDevice DriversRun-time Kernel
ADCS Sensor Data ProcessingAttitude DeterminationAttitude Control
Power Battery Charge Control Power Management & DistributionOBC Watchdog
1 Scholz, Artur, Design and Development of a CDHS for a Pico Satellite, Aachen University of Applied Sciences
Table 2: Software Functions
4. The Design and Development Process *
Starting with requirement allocation and functional analysis, the design process will result in
a solution architecture, including both hardware and software. The output will describe the
system physically, and in terms of software on the lowest assembly levels, interfaces and
relationships between external and internal components. The subsequent development activities
then cover the production of the system. Figure 2 illustrates the entire subsystem life cycle.
4.1 Requirement Allocation
The first design step is the subsystem requirement allocation. The overall system is divided
into smaller functional blocks, with specific requirements. Although AUC Cubesat might be
composed of the same set of subsystems that another satellite has, the specific requirements of
the particular functional blocks might differ significantly according to the spacecraft mission
objectives. Generally, the requirements can be established by answering the question “What must
the subsystem achieve?”. For example, “C&DH needs to dispatch commands from the ground
station to the different spacecraft subsystems”
4.2 Functional Analysis
The next step is to translate the requirements defined in the previous step into functions.
This is done by finding the answer to the question “How can this requirement be achieved?”. In
other words, functional analysis provide proposed solutions to the questions asked in the
requirement allocation step. The team performs functional analysis to breakdown high-level
functions into lower-level function blocks, and to map low-level functions to physical or
executive components, thereby ensuring that each function has an acknowledged owner. This
also ensures that all necessary tasks and components are listed and that no unnecessary tasks or
components are requested. Building on the example stated above, “Besides the obvious need of
an MCU, the C&DH requires a system through which the different subsystems can communicate
with each other. The C&DH also requires a storage unit to store command, until ready for
transmission. Additionally, the C&DH system will be required to perform command verification
to ensure that it is a legitimate command, schedule the command for execution according to its
time tag, and prepare the data package to be channeled to the intended subsystem.”
* This section is highly influenced by the design process of the German CubeSat, Compass I.
Fig.2: C&DH Design & Development Life Cycle
Subsystem RequirementsAllocation
Functional Analysis
Functions Allocated to Hardware
Functions Allocated to Software
Hardware Definition Software Definition
Circuit Design
PCB Layout & Fabrication
PCB Assembly & Testing
Flow Charts of Modules
Programmingof Modules
Debugging
System Assembly, Integration & Testing
Operation
Disposal
4.3 Function Allocation
Once the system functions are well defined, they are partitioned and allocated to either
hardware components or software solutions. Many times, both hardware and software must be
used to implement a given function. By nature, software tends to be a more flexible solution, as
the designer can make changes, amendments, and updates even at late stages of the project, or
even after launch. Hardware, on the other hand, is very expensive to amend once manufactured.
However, in space, software is more susceptible to malfunctions, due to radiation, than hardware.
It is the decision of the design team how to allocate functions to maximize flexibility, while
minimizing malfunction threats. Building on our example, “To perform the previously stated
example requirement (see section 4.1), the C&DH will need to utilize both hardware and
software solutions. The required hardware components are: an MCU to perform all the data
management and manipulation, a bus system to connect the different subsystems together, and a
memory device to store the command until it is time for dispatching. On the software side, the
C&DH has to first verify that the uplinked command is legitimate, package and prepare the
command to be channeled through the system bus (according to system bus protocol), schedule
the command in the flight plan, store the command in the designated memory location, and
finally initiate and complete the command transfer process.”
4.4 Hardware and Software Definition
Following function allocation, hardware components are selected using trade studies, taking
into account cost, reliability, heritage, availability, … etc. Equivalently, the software structure
needs to be defined. Top-level flowcharts are also developed at this stage, serving as stepping
stones to the subsequent stages. Based on our example, “A specific MCU must be selected, the
bus system also needs to be chosen (e.g. I2C bus), a trade analysis between RAM and Flash
Memory as a candidate to store commands is performed, and a specific memory chip is selected.
The software architecture and interface between the different software modules are designed.
Flowcharts for the Command Verification, Storage, Scheduling and Distribution are also
created.” Figure 3 below depicts the process from Requirement Allocation to HW & SW
Definition.
4.5 Hardware Design & Development
After functions are properly allocated, and the hardware has been defined, the hardware design
and development process starts. This is one of the major tasks of the C&DH team. Figure 4
breaks down those tasks in details.
4.5.1 Circuit Design
The circuit design is the most time-consuming part of the hardware design process. The first
step is to determine how the different devices or components will work together. Then the signal
flow is determined, covering both internal interface and external interface signals (signals
Fig. 3: C&DH Design Process Example
between C&DH and other subsystems). Issues like data structure, physical connection, content
and compatibility must be taken into consideration. The result of the circuit design process
should be a set of schematics showing the logical interconnections between components within
the C&DH subsystem, along with the main bus and other subsystem connections.
4.5.2 PCB Layout
The circuitry created in the previous step needs to be translated into physical tracks. The
process also takes into account any constraints that might be affecting the design, including
mechanical constraints like board size and mounting methods, or points of attachments. Part
placement is also one of the most critical layout activities. The part placement process should try
to minimize radiation threats and extreme temperature variations, for example by placing high
heat emitting components next to low heat emitting components. The process is then followed by
routing, which is the process of laying down tracks to connect components on the PCB.
4.5.3 PCB Fabrication
Once the PCB design is completed, and the design is verified, the layouts can then be sent to
the fabrication or production. Once the board is fabricated, the components can be soldered in
place. The PCB is then inspected and tested for any points of failure.
4.6 Software Design and Development
There are two design approaches that are well established among software engineers,
structured programming and top/down design. Both are mutually important and only the
Circuit Design
PCB Layout
PCB Fabrication
Fig. 4: Hardware Design & Development Process
simultaneous use of both strategies can form an efficient synergy. Structured programming
brings more transparency into the code, which is highly appreciated by other developers wanting
to familiarize themselves with the existing code. It also facilitates later changes and
modifications that might be required to be uplinked to the satellite from the ground station. The
top/down design approach, on the other hand, focuses on the bigger picture first, then elaborates
the subsequent levels into finer details during the design activity.
The application layer covers the high level main application code. The low-level drivers
layer, on the other hand, allows higher-level computer programs to interact with hardware
devices onboard. Obviously, these driver routines are hardware specific, and can only be written
after the specific hardware has been selected. The device interface layer, residing between the
application layer and the low-level drivers, acts as logical representation of the hardware. It is
responsible for translating the functions of the application layer into device-specific functions.
5. Software Architecture
Recall, the C&DH is required to interface with all the hardware and software solutions
onboard on the satellite. Since the Cubesat project is divided among several developer groups, a
highly modular design is desirable. Interfaces between modules need to be clearly defined to
allow different parts of the software to communicate efficiently with each other. As mentioned
before, the I2C bus by Philips is selected for the system bus. The physical domain of the
spacecraft subsystems is shown in figure 6. As shown, the I2C serial bus connects all the
spacecraft subsystems with each other. A master (in this case the MCU of the OBC) is the device
Application Layer
Device Interface Layer
Low Level Drivers Layer
Fig. 5: Software Top-Down Design
that initiates a data transfer on the bus and generates the clock signals to permit transfers. The
addressed device is considered a slave. An I2C protocol needs to be designed on top of the I2C
bus. The complete protocol should include: Start Communication, Address, R/W, Acknowledge
Bit, Header, Error Check (e.g. CRC Checksum), Data or Command, Stop Communication.
Header include the length of data packages, and the specific module contacted in the slave.
5.1 Software Elements
5.1.1 Boot Loader
A few moments after orbit insertion, the satellite is powered-up, marking the beginning of its
mission in space. This is one of the most critical moments in the mission's lifetime. At this
moment, the C&DH runs the boat loader, which configures the OBC, locates and initializes all
the different spacecraft subsystems and peripheral devices, and finally loads and starts the
spacecraft's OS or designated kernels. This process is repeated every time the OBC is restarted,
Fig. 6: Cubesat Physical Domain
as the spacecraft comes out of power save mode, or as a result of a latch-up. If an error occurs
during the boot sequence, the OBC should be designed to automatically reboot using a redundant
software version, thus making the Boot sequence more reliable.
On every start, the OBC should check if there is software updates in Flash memory, or not.
If there is, the boot sequence is executed using the Flash version, if not, the original version is
loaded from PROM. When booting from Flash, a check needs to be done to make sure data is not
corrupted. A watchdog timer should also be implemented during the start-up process. If the OBC
finishes the boot-up sequence, it resets the timer, indicating that the boot sequence was
successful. If the watchdog timer times out, it means that there is a problem in the boot sequence,
and that the current boot-up had failed. In this case, the power unit should turn off the OBC and
restart it. The new boot sequence should then be carried out from a different boot sequence
version. This prevents the the boot loader to enter a “boot loop”, which lets the OBC
continuously boot from a broken operating program.
5.1.2 Hardware Support
5.1.2.1 Hardware Abstraction Layer
A Hardware Abstraction Layer (HAL) is a low-level software that supplies a simple
interface to access hardware features, giving programs direct access to hardware resources. This
will allow application software developers on the Cubesat to write device-independent
applications by providing standard OS calls to hardware. With hardware abstraction, the
programer can write a code that tells the operating system what a given device should do, and the
operating system gives the proper instructions. This means that programmers do not need to
know how the individual devices work, and their program code will be compatible with any
device.
5.1.2.2 Device Drivers
The C&DH should provide the driver software that is used for accessing hardware
components. These create the interface between the OBC hardware, and the C&DH software. A
device driver is a piece of code that allows the operating system or user application to set up,
access and utilize a specific hardware or peripheral device. Drivers are very useful since they
allow an application to access the features of the OBC without any low-level knowledge, such as
registers, protocols and timings. Figure 7 below shows the progression of the different software
layers in the C&DH system.
As shown above, the software driver's interaction with the hardware platform is done
through the Hardware Abstraction Layer. This isolates the driver's implementation from the
hardware platform variations. A driver implementation typically interacts with the hardware
peripheral it is controlling through sequences of register reads and register writes. The
implementation of the HAL translates the read and write requests into the bus transactions
relevant to the hardware platform. This enables programmers to seamlessly reuse code even
when the hardware platform changes.2
5.1.3 Error Detection/Error Correction
The harsh radiation environment of space takes its own toll on the spacecraft. Radiation
particles from solar or galactic origins bombard the spacecraft, posing threats to the onboard
electronics. Because of the short orbital lifetime of cubesats, the total ionizing dose effects are
negligible and can be ignored. However, there is another major source of concern, namely, Single
Event Phenomena (SEP). In this phenomenon, a single particle can penetrate the surface of the
2 Acal Technology, www.acaltechnology.com
Fig. 7: C&DH Supporting Software Layers
spacecraft, targeting electronic components, causing malfunctions. The three major effects of
SEP, in the order of probability of occurrence are:
• Single Event Upsets: This is a logic reversal process, where the radiation particle strikes the hardware component, flipping a single bit from 1 to 0, or vice versa. This can result in numerous side effects, such as erroneous calculations, command and data corruption, erratic software execution, and operation setting changes. Several approaches can be utilized to detect and correct these types of error. Possible solutions include including redundant memory devices, using majority-voting logic, employing hamming codes, and employing checksum algorithms.
• Single Event Latch-up: A latch-up event results in an abnormally high current-flow through a device. This current-flow can be several orders of magnitude larger than the device’s typical operating range, thus it generates an enormous amount of internal heat. Power-cycling the device (turning off the device, then back on) is the only feasible remedy for clearing a latch-up condition. If not promptly performed, permanent damage to the device can result from the excessive heat. The C&DH design must be able to detect high current-flow through each board and cycle power accordingly. Using current monitors, each board within the spacecraft monitors its current-flow. If the current-flow into a board rises above a predetermined reference level, the current monitor signals the OBC via the I2C bus. The OBC determines the board that needs to be reset and provides a reset signal to the EPS, which in turn cycles the power to the board/device. Since the OBC is equally susceptible to latch-ups, the EPS must employ a watchdog timer to monitor the OBC's power, and subsequently cycles power to the entire satellite.3
• Single Event Burnout: This causes a permanent failure to the device. This is very uncommon, and can only be minimized by the proper shielding and hardening techniques. (No software algorithms or subsystem commands can fix it, or avoid it).
5.1.3 System Architecture Modules
As mentioned before, the software architecture is expected to be highly modular, which
means that each module is responsible for performing a specific function on board of the
3 Jensen, J.,C. M. Swenson, Command and Data Handling Subsystem Design for the Ionospheric Observation Nanosatellite Formation (ION-F)
spacecraft. For example, the attitude determination and control algorithms are grouped in one
module, let's call it the ADCS Module. Similarly, the power management and distribution
routines are grouped in another module, EPS Module. Figure 8 presents the spacecraft software
architecture, depicting the different modules onboard the satellite, and the different threads
forming each module.
To facilitate the interface between the different software modules, the C&DH hosts a Flight
Manager (FLT_MNGR) program that controls all the tasks of the spacecraft. FLT_MNGR plays
a central role in data distribution. All spacecraft application modules interface with each other
through the FLT_MNGR. This simplifies the communication paths between the different
modules, and makes the module integration process much more robust.
For instance, the main functions of the C&DH are based on a flight plan, which is a time
scheduler that specifies the execution of tasks or commands onboard of the satellite. Commands
Fig. 8: Spacecraft Software Architecture
are usually transmitted to the satellite via the ground station. Once received, the COMM module
performs command validation, demodulation, and decapsulation of data packets. They are then
forwarded to the FLT_MNGR, which in turn channels the commands to the Flight Plan (FLP)
module. FLP module then schedules the tasks for execution, and saves them in the designated
location on flash memory. Note that drivers for all the different devices will need to be integrated
in the architecture to assure proper interaction with all system devices. Figure 9 shows an
exploded view of the driver architecture onboard of the spacecraft.
6. Integration & Verification
According to several Cubesat team developers, most of the problems occur where the
software meet the hardware. The integration and verification of the C&DH has four main levels:
• Software Level (Application Level)• Subsystem Level (C&DH Level)• System Integration Level (Subsystem Interface Level)• System Level (Spacecraft System Level)
Fig. 9: Application, Driver & Hardware Level Exploded View
The levels and their location in the flow are illustrated in figure 10.4 Note that every time
software is changed, the integration and verification loop has to return to the beginning of the
test flow.
There is a tendency among programmers to use their own programming style, and not to
stick to a specified project format. This practice translates into undesirable redundancies,
inefficient executions, and a hectic interface and integration process. Following a unified coding
format can save the team tremendous time and effort throughout the project lifetime. Keeping up
to date documentation of the design process, design decisions, flowcharts, and detailed system
architecture is also critical to the success of the C&DH team.
Remember, no individual decisions can be taken on this project. One small decision can
have a domino effect on the whole system. Close interaction among team members, as well as
between other subsystem teams will eliminate critical problems on subsystem level, and system
integration level, respectively. Structured meetings will be scheduled to allow all project team
members to interface with each other, and discuss any pending design decisions or
recommendations.
4 Vaartjes, B., R. J. Hamann, R. Amini, Integration and Verification of a Command and Data Handling Subsystem for Nano-Satellite Projects with Critical Time Constraints: Delfi-C3.
Fig. 10: C&DH Integration & Verification Flow