Standardization concepts for CubeSat applications
Tomasz Szewczyk, Kostas Marinis
European Space Agency (ESA), Noordwijk, The Netherlands
Abstract—Due to physical/power/financial constraints of
CubeSats, classical improvements of reliability in area of
satellite avionics and data-handling (i.e. redundant subsystems,
cross-strapping) are not usually possible. On top of that,
CubeSat development rarely follows technical standards, and is
usually based on COTS solutions additionally questioning
reliability figures.
This article proposes the use of concepts implemented
usually on “bigger” satellites migrated into the world of
CubeSat applications. Those concepts are described in SAVOIR
working group, which standardises certain data-handling
functionalities expected to be present in “mature” satellite. By
applying specific engineering solutions and guidelines, most of
the SAVOIR functions can be implemented in CubeSat,
therefore increasing the reliability.
Keywords—cubesat, SAVOIR, reliability, data-handling,
avionics
I. INTRODUCTION
CubeSats have increased significantly in popularity in
recent years, as they allow an easy access to space
applications. Although the CubeSat revolution started in
Universities and small institutes and labs, commercial
companies also started exploring this area and found an
increasing number of space application that can be
implemented using relatively small satellite platforms.
Although building a CubeSat might seem, in theory, like a
simple and straightforward assembly of functional building
blocks, reality is usually quite different. In fact, the assembly
and integration of the different subsystems and modules is
only streamlined if all the components are sourced from a
single supplier. Among different suppliers only the physical
form factor of the boards may actually be compatible. All the
other technical aspects, e.g., common connectors and headers,
data interfaces, communication protocols etc., are usually
different and might require effort to be used in the same
satellite system.
Due to their small sizes, CubeSats suffer from a lack of
resources: available area and volume are limited, available
power is reduced, communication bandwidth is limited. In
addition, due to financial constraints, CubeSats are based on
Commercial off the Shelf (COTS) components, and rarely
follow any kind of “space” standardization, screening, or
qualification. For that reason, on one hand the reliability of
Figure 1: Example reference CubeSat architecture.
Digest for the EDHPC 2023
censed use limited to: MINISTERE DE L'ENSEIGNEMENT SUPERIEUR ET DE LA RECHERCHE SCIENTIFIQUE. Downloaded on February 15,2024 at 09:58:25 UTC from IEEE Xplore. Restri
such developments is questionable, especially for deep-space
missions. On the other hand, each company or student team
designs the system in very specific way, with reliability not
commonly being one of the main driving factors.
This article will describe engineering guidelines and
principles based on concepts followed and applied in larger
satellite systems, that could be of a benefit if adopted in
CubeSat applications.
II. REFERENCE CUBESAT ARCHITECTURE
For the purposes of this article, an indicative architecture
of a CubeSat avionics system is shown on Figure 1. This
architecture will be used as a reference to present potential
reliability improvements coming with introduction of various
standards and specifications and applied in larger satellite
systems.
The following can be noted regarding the reference
architecture in Figure 1:
• All the satellite platform subsystems are connected
through a single bus, preferably CAN. Although other
busses could be used (i.e., I2C), CAN has proved it’s
robustness.
• Redundancy of busses is rather not foreseen due to the
hardware constrains of COTS devices. As an example,
finding COTS microcontroller with double CAN
interface might be problematic.
• Some crucial sub-systems can be duplicated for
redundancy. Nevertheless, those should be connected to
the common CAN bus.
• Payload and platform buses are decoupled – this allows
to split ‘reliable’ core subsystems from potentially less
reliable payload units.
• Payloads processing/interfaces may be handled by a
dedicated unit (i.e. Payload Interface Unit). This
approach allows independent testing/validation of
platform and payload units.
 Figure 2: SAVOIR Functional Reference Architecture and mapping to CubeSat functional blocks
• Most of the platform sub-systems are based on
microcontrollers, meaning that those can implement
some kind of processing functions if needed.
III. SAVOIR
The Space AVionics Open Interface aRchitecture
(SAVOIR) [1] is an initiative to raise the level of
standardization in the spacecraft avionics systems in order to
increase efficiency, and to reduce development times and
costs. Stakeholders include ESA, European space industry
primes and space agencies, also in cooperation with
standardization working groups such as ECSS [ref] and
CCSDS [2]. SAVOIR is organized in a number of specialized
working groups, addressing topics such as Software, Fault
Detection, Isolation and Recovery (FDIR), Integrated
Modular Avionics (IMA), among others. Several technical
notes and dossiers, generic specifications, and handbooks
were produced as a result of this work, covering a wide range
of avionics subjects to a significant depth. All this
documentation is publicly available.
SAVOIR defines a Functional Reference Architecture
(FRA), breaking down the elementary functions provided by
the spacecraft avionics. This FRA is shown in Figure 2, and
consists of the following spacecraft platform functions:
• Telecommand reception, decoding and distribution.
• Telemetry Transfer Frame generation and coding.
• Essential TM function, collecting essential data and
generating data packets for the TM Encoder (Optional
function).
• Essential TC function, distributing pulse commands to
control vital spacecraft functions.
• Security function, that protects the spacecraft from
receiving unauthorized commands and that provides
censed use limited to: MINISTERE DE L'ENSEIGNEMENT SUPERIEUR ET DE LA RECHERCHE SCIENTIFIQUE. Downloaded on February 15,2024 at 09:58:25 UTC from IEEE Xplore. Restri
optional decryption and encryption of data sent on the
TM/TC link (Optional function).
• Processing capability, to store and execute Execution
Platform and Application software.
• Reconfiguration function, that maintains the operation of
the processing function even in case of errors.
• Safeguard Memory function, for storage of vital
spacecraft data that is needed by the processing function.
• On-Board Time management, providing a time counter
and generating synchronisation events.
• Time Reference function, that provides accurate
synchronisation and absolute time from for instance a
Global Navigation Satellite System (GNSS)
• Platform Data Storage function, for storage of data
needed for the spacecraft operation.
• Communication, separated into Mission Data and
Command & Control communication systems, allowing
the processing function to communicate with platform
sensors and actuators and with the spacecraft payload.
• Data Concentrator function, for handling the monitoring
of spacecraft sensors.
• Sensor and Actuator Interfaces, for interfacing the
physical sensors and actuators.
• Parallel I/O, to support the acquisition of discrete
essential spacecraft data.
The following payload functions are shown for
information:
• Payload data routing function for routing monitoring
and control communication to and from payload units
 • Payload Data Storage function, for storage of
payload TM data during periods of no ground station
contact (Optional function).
Figure 2 also shows the redundancy concept for the
functions. To avoid single-point failures of the system, all
functions are internally redundant. Redundancy can be applied
in three different ways:
• Cold redundancy:
In cold redundancy there is one Active part of a function
that is operating, and its redundant part is not operating. This
means that the redundant part can be powered or unpowered,
the latter case being also physical cold redundancy.
An example is the Telemetry function where there is only
one TM Encoder that generates data to the RF system, but
where the other TM Encoder does nothing but may be
powered or unpowered depending on the selected physical
implementation.
• Warm redundancy
In warm redundancy there is one Active part of a function
that is operating, and its redundant part is operating but with
reduced functionality, possibly as a back-up that is ready to
take over in case the Active part fails.
An example can be a back-up data storage that is used to
store a copy of critical TM data but as long as the Active data
storage operates correctly data is never downloaded from the
back-up memory.
• Hot redundancy
In hot redundancy there are two or more simultaneously
active parts that operate in parallel and that can even produce
parallel outputs.
An example is the TC Decoders which operate in parallel
on the received data. If they both have the same Virtual
Channel (VC) ID they could actually also output data in
parallel.
IV. SAVOIR IN CUBESATS
In most medium to large scale satellite systems, majority
of the functions in the “Platform” side of Figure 2 are
implemented in the on-board computer (OBC), and partly in
the Remote Terminal Unit (RTU), of the satellite, with the
redundancy schemes shown in the figure. However, in
CubeSat applications the allocation and implementation of
these functions differs significantly. Since most of the
subsystems and modules in CubeSats contain at least one
processing function, e.g. a microcontroller, the SAVOIR
functions can actually be distributed among different units. In
Figure 2 an indicative mapping of the functions defined in the
SAVOIR FRA has been indicated versus the functional blocks
or modules of a representative CubeSat architecture, such as
the one in Figure 1:
- The CubeSat OBC implements the following functions
(highlighted in blue on Figure 2):
• Processing and Platform/Payload Data Storage
• On-Board Time management
• Command & Control Data Links, and mission links
• Parallel I/O (partial)
• Reconfiguration function (partial)
censed use limited to: MINISTERE DE L'ENSEIGNEMENT SUPERIEUR ET DE LA RECHERCHE SCIENTIFIQUE. Downloaded on February 15,2024 at 09:58:25 UTC from IEEE Xplore. Restri
- The CubeSat Communications module (COMMS)
commonly features a processing function, e.g. a
microcontroller, and is connected to the common bus
(CAN). It handles the following functions (red in Figure
2):
• Telecommand and Platform Telemetry.
Payload Telemetry (optional)
• Essential Telecommand and Telemetry
• Security (optional) since it represents a boundary
of the common CAN bus.
- The CubeSat AOCS module could implement the
following functions (orange on Figure 2):
• Time reference, coming from a GNSS receiver.
• Platform sensors and actuators.
- The CubeSat Power Conditioning and Distribution
Module (PCDM), thanks to its embedded processing
function and common CAN bus, may also implement the
following functions:
• Reconfiguration, by monitoring the common bus
(CAN) and detecting potential issues with the other
of platform sub-systems.
The Data Concentrator function in the SAVOIR FRA is
rather dispersed in a CubeSat architecture. Most of the
CubeSat subsystems take care of their own sensors. The same
goes for the Actuator interfaces, they are distributed among
the various subsystems: the COMMS module takes care of the
antenna deployment, the PCDU takes care of solar array
deployment.
The Safe-Guard Memory (SGM) would be expected to be
implemented in the On-Board Computer. On the other hand,
in a CubeSat context it may be stored in other sub-systems
with small internal memories, e.g. the COMMS module.
The following conclusions can be drawn from the
functional mapping above:
- Due to the smaller number of modules in a CubeSat, there
is an extensive grouping of functions.
- Some of the functions in the SAVOIR FRA are either
distributed in several modules in a CubeSat, or they don’t
have a direct mapping at all. For example, the Data
Concentrator function in SAVOIR, typically implemented
in Remote Terminal Units (RTUs), is distributed among
several modules in a CubeSat. On the other hand, while
there is no direct and discrete mapping of a reconfiguration
function in a CubeSat architecture, mainly due to the
reduced or non-existent redundancy schemes, a limited
form of reconfiguration and FDIR can be partially
implemented in the PCDM and COMMS modules. The
Safeguard Memory (SGM) and Payload Security
functions are typically not implemented in CubeSat
architectures.
- Most importantly, implementation of concepts and
functional block from SAVOIR FRA can significantly
improve reliability of CubeSats. The biggest benefits of
engineering guidelines presented in next chapter can be
achieved when implemented at early phase of the project.
 V. CUBESATS ENGINEERING GUIDELINES
The work of the SAVOIR consortium was also based on
material from other standardization entities such as the ECSS
[3] and CCSDS [2], both of which have published a very
extensive portfolio of standards, handbooks, guidelines and
technical notes covering all aspects of space engineering -
including hardware, software and components, product
assurance, project management etc. They provide a very wide
and deep body of knowledge, also culminating from
experience and lessons learned. It is highly recommended that,
even if not applied to the full extend, e.g. in terms of
deliverable documents etc, they are at least referred to for the
significant added value they can provide to the designers of
space systems of any size, criticality, and use case. This also
includes the CubeSat community, of course.
Standardisation provides several benefits:
1. Streamlines the design and development of avionics
modules, units, and systems.
2. Reduces integration and assembly times (shorter “time
to flight”)
3. Facilitates and possibly even accelerates the verification
of these elements.
4. Reduces costs and effort for design and verification
cycles, also by design reuse.
5. Improves quality, via adoption and use of engineering
and QA standards.
6. Increases competition and competitiveness.
7. Facilitates cooperation and interoperability.
All the above benefits of standardization could be applied
in CubeSat developments if principles, concepts, guidelines
and requirements from SAVOIR specifications and
ECSS/CCSDS standards were adopted, or at least consulted
more extensively and consistently. Indicative examples of
relevant ECSS standards could be the following (list not
exhaustive, of course):
• ECSS-E-ST-10-03C Rev.1: Testing
• ECSS-M-ST-80C: Risk management
• ECSS-E-ST-10-06C: Technical requirements
specification
• ECSS-Q-HB-60-02A: Techniques for radiation effects
mitigation in ASICs and FPGAs handbook
• ECSS-Q-ST-60-13C Rev.1: Commercial electrical,
electronic, and electromechanical (EEE) components
Reliability requirements of future CubeSat / NanoSat /
MicroSat missions will also increase. For instance, CubeSats
will be used for future Moon and Mars missions, as
companions to other satellites (e.g. HERA [4]). There are
several methods that can be applied to address the increased
reliability requirements of (future) CubeSat missions as
(if/when) needed and applicable, such as:
o Implementing FDIR concepts (Fault Detection,
Isolation and Recovery) more extensively.
o Applying fault tolerance measures:
Mitigation of radiation induced Single Event Effects
(SEE): SEUs (memories, FPGAs), SEFI (SDRAM),
SEL (CMOS devices)
▪ For memories: EDAC/ECC schemes (SEC/DED, R-S,
CRC), scrubbing.
censed use limited to: MINISTERE DE L'ENSEIGNEMENT SUPERIEUR ET DE LA RECHERCHE SCIENTIFIQUE. Downloaded on February 15,2024 at 09:58:25 UTC from IEEE Xplore. Restri
▪ For FPGA logic: Triple Modular Redundancy (TMR).
▪ For software: Watchdogs, dual lock-stepping,
duplicate-and-compare.
▪ For hardware: current monitoring, latchup-up
protection.
o More extensive use of redundancy:
▪ Duplication of modules, components, links.
Some further suggestions and considerations regarding
reliability improvements can be achieved by simple design
choices of CubeSat architecture:
• A common CAN bus allows all subsystems to
communication with each other. This gives significant
benefits where e.g. the COMMS module can poll
telemetry directly bypassing the OBC or the PCDM
monitoring the operation of all the platform subsystems.
With this approach reconfiguration from ground is also
be supported, e.g. by the PCDM detecting a fault or
disruption in the operation of a module and power-
cycling either directly, or via a telecommand from
ground.
• Direct access of COMMS module to any other
subsystem might allow implementation of another level
of FDIR procedure. As an example, direct access to
AOCS module might allow recovery of the satellite in
case orientation needs to be changed without OBC
involvement. Also, software updates of any core
subsystem could be considered useful capability.
• In the architecture diagrams of Figure 1 and Figure 2 it
is also important to notice the interconnections between
the functions as well. Apart from the functions presented
in Figure 2, it is important to also note the
interconnections between these functions. For example,
the direct connection of the Telecommand function in the
COMMS module with all other subsystems allows it to
issue Essential Telecommands (ETC) directly to other
modules, or to read from the SGM bypassing the
Processing Function (OBC). With the common CAN bus
all this is clearly possible.
• The use of the CubeSat Space Protocol (CSP) as a
common, standardized protocol on top of the CAN bus,
will also allow the implementation of the SAVOIR
functions in a coherent way, on top of facilitating the
integration process. For example, standardized access to
TM/TC between all platform modules will enable the
implementation of Essential TM/TC functions.
• By implementing a processing function, e.g. a
microcontroller, in most (if not all) subsystems, certain
FDIR algorithms can be supported. For instance the
PCDM can monitor the state of the CAN bus and act as
Watchdog or supervisor, and in case of erroneous
behaviour applying an FDIR function, e.g. power cycling
or disabling the failing module.
VI. CONCLUSIONS
The paper attempts to apply the SAVOIR Functional
Reference Architecture (FRA) to CubeSat applications.
Thanks to this approach, it is expected that the reliability of
CubeSats can be improved.
A mapping and correlation between the SAVOIR FRA
and a representative CubeSat avionics architecture was
 provided. This could be used as reference for further
consideration and application of SAVOIR concepts in
CubeSat applications to increase efficiency, reliability and
interoperability, and reduce development times and costs.
The benefits of standardisation were presented, and
concepts were proposed for improving the functionality,
reliability, consistency, performance, and product quality,
while also reducing costs and risk in the development of
CubeSats and their avionics systems.
REFERENCES
[1] SAVOIR : https://savoir.estec.esa.int/
[2] CCSDS: https://public.ccsds.org/default.aspx
[3] ECSS: https://ecss.nl/
[4] https://www.heramission.space/
[5] ESA COTS Guidelines : Public release pending.

censed use limited to: MINISTERE DE L'ENSEIGNEMENT SUPERIEUR ET DE LA RECHERCHE SCIENTIFIQUE. Downloaded on February 15,2024 at 09:58:25 UTC from IEEE Xplore. Restri