Satellite and Nano Satellite Communication

Space segment for nano satellite

EXTC – BE –OPTICAL COMMUNICATION AND NETWORKS

Ms. Vandana Sawant

Assistant Professor
Dept. of Electronics & Telecommunication Engineering,
SIES Graduate School of Technology

Ms. Vandana Sawant SIESGST 1

 OBJECTIVES OF LECTURE
• Students should be able to
- Explore basics of nano satellite
6.1 Thermal control system (TCS) implementation in nano satellite and it’s testing for
verification of TCS. Power system design for nano satellite.
6.2 Function and design consideration of Deployment mechanisms, Critical elements in
deployment mechanisms, Overview of types of deployment mechanisms.
6.3 On board Computer and digital electronics (OBC): Block diagram of typical OBC,
Overview of OBC Software and hardware, Telemetry and telecommand, Attitude
control electronics
6.4 Quality, Quality assurance, product assurance and reliability analysis for Nano
satellite

Ms. Vandana Sawant SIESGST 2

 Thermal control system (TCS)
• 7.2 State-of-the-Art – Passive Systems
• Passive thermal control maintains component temperatures without
using powered equipment. Passive systems are typically associated
with low cost, volume, weight, and risk, and are advantageous to
spacecraft with limited, mass, volume, and power, like SmallSats and
especially CubeSats. MLI, coatings/surface finishes, interface
conductance, heat pipes, sunshades, thermal straps, interface materials,
and louvers are some examples of passive thermal control technology.
• In addition to passive thermal control technology, structural and
electrical design methods also contribute to managing the thermal
environment, passively. These design methods include:

Ms. Vandana Sawant SIESGST 3

 Thermal control system (TCS)
• Material selection
• Structural component materials chosen based on needed heat transfer
through the structure. A high or low thermal conductivity may be more
advantageous based on the application.
• Spacecraft orientation
• If orientation is not dictated by science objectives, changing the
orientation of the spacecraft can help maintain temperatures.

Ms. Vandana Sawant SIESGST 4

 Thermal control system (TCS)
• Changing orientation may only be needed during certain mission phases, such as
science operation if larger amounts of heat are dissipated.
• This method is often used in conjunction with other thermal control methods, such
as orienting the spacecraft so that the radiator area can face deep space.
• Thermal interfaces:
• Definition of the thermal contact between components through specific mounting
methods can thermally isolate components or allow more heat to be transferred to
a structural element (or radiator area) when each is needed. For example:
• Heat transfer can be reduced by mounting a component through multiple stacked
washers with low thermal conductivity.
• Heat transfer can be increased by mounting components with more fasteners (if
applicable) and can be further increased by using thermal interface materials
between a component and mounting surface.

Ms. Vandana Sawant SIESGST 5

 Thermal control system (TCS)
• Circuit board design considerations, include:
• Copper layers within each board can be increased, in number or thickness, to conduct heat
away from electrical components through the boards to their structural connection points.
• Circuit boards can be mounted to increase heat transfer away from the boards to the
structure, such as by mounting with wedge locks.
• Table 7-2 is a list of current passive thermal control technology as applied to Small Sats.
One key factor to consider when choosing thermal control technology, both passive and
active, is the temperature limits of the technology itself.
• The goal is to use the appropriate technology to maintain the temperatures of spacecraft
components within their limits, but the technology used to achieve this also has limits.
• It is recommended to verify that the technology used is applicable to the given design not
only with respect to needed function, but to the environment (temperature limits) as well.

Ms. Vandana Sawant SIESGST 6

Thermal control system (TCS)

Ms. Vandana Sawant SIESGST 7

Thermal control system (TCS)

Ms. Vandana Sawant SIESGST 8

 Thermal control system (TCS)
• State-of-the-Art – Active Systems
• Active thermal control methods rely on input power for operation
and have been shown to be more effective in maintaining tighter
temperature control for components with stricter temperature
requirements or higher heat loads .
• Typical active thermal devices used on large-scale spacecraft include
electrical resistance heaters, cryocoolers, thermoelectric coolers, and
fluid loops.
• Electrical heaters are usually easily integrated into SmallSat
architectures as they do not typically use much mass or volume.
Ms. Vandana Sawant SIESGST 9
 Thermal control system (TCS)
• Heaters are frequently used in all space applications, including small and
large satellites, so they are often included as passive thermal control
technology.
• Other active systems are challenging to integrate into CubeSats and other
small satellites because of the power, mass, and volume needs associated
with each given technology.
• Until spacecraft designers can miniaturize existing actively controlled
thermal techniques and reduce power requirements or increase available
spacecraft power, the use of active thermal systems in small spacecraft will
be limited.
• Current state-of-the-art active thermal technologies for SmallSats are
shown in Table 7-4.
Ms. Vandana Sawant SIESGST 10
Thermal control system (TCS)

Ms. Vandana Sawant SIESGST 11

 Deployment Systems
• The key to the success of the Cubesat concept is to be able to use an
in-orbit deployment system that meets a number of requirements,
namely :
• The deployment system must protect the launcher and the primary
load against any mechanical, electrical or magnetic interference from
Cubesats which are considered secondary loads.
• The Cubesats must be able to be released from the deployment system
using the minimum number of springs to minimize the probability of
collision with the launcher and with the other Cubesats

Ms. Vandana Sawant SIESGST 12

 Deployment Systems
• All Cubesat components must remain attached during the launch and
deployment process. No additional space debris should be created.
• The most used solution is a “container” called P-POD (Poly
Picosatellite Orbital Deployer), developed by the Polytechnic
University of the State of California (Cal Poly). Certified by a large
number of launchers, the P-POD Mark III provides an enclosure
strong enough to withstand a structural failure of the three Cubesats it
can contain, while acting as a Faraday cage to protect the launcher
primary payload: la charge utile primaire du lanceur

Ms. Vandana Sawant SIESGST 13

Deployment Systems

Ms. Vandana Sawant SIESGST 14

 Deployment Systems
• Figure 5: P-POD deployment system :
• It should be noted that since the year 2008, the deployment of
Cubesats from the International Space Station (ISS), which is located
at an altitude of approximately 400 km, is possible thanks to the
“KiboCUBE” module developed by the Japanese agency Aerospace
Exploration (JAXA).
• This system is composed of an airlock and a robotic arm as shown in
Figure 6:

Ms. Vandana Sawant SIESGST 15

Deployment Systems

Ms. Vandana Sawant SIESGST 16

 An overview of on-board computer (OBC)
• An OBC primarily consists of a microprocessor, memory banks and
interfacing chip to connect the computer to other sub-systems.
• A range of standard and non-standard interface formats are in use
(e.g. RS485, CAN, SpaceWire, SPI and I2C) and the OBC itself can be
provided as an integrated unit in the satellite bus and avionics system,
or as a modular device capable of working with various other pieces
of multi-vendor equipment.

Ms. Vandana Sawant SIESGST 17

 An overview of on-board computer (OBC)
• The OBC plays several roles in the effective operation of a spacecraft
or satellite. These functions usually include:
• Altitude and orbit control,
• Telemetry data management,
• Telecommunication actions,
• System housekeeping,
• On-board time synchronisation, and
• Failure detection, isolation and recovery.

Ms. Vandana Sawant SIESGST 18

 An overview of on-board computer (OBC)
• Selecting the right on-board computer for your needs
• Increasing modularisation and standardisation of space technology is leading to
greater options for suppliers all over the world.
• In addition, the miniaturization of electronic components are making it possible
to develop new hardware concepts for space missions.
• With this greater choice available, engineers need to ensure they select the best
option for the mission requirements, and we recommend considering the
following key performance criteria when making a decision:
• Processing capability – the computing unit must be able to handle the processing
capacity needed to operate the payload and the sub-systems supporting it (e.g.
attitude control, communication, power distribution, etc.).
• Memory (storage and RAM) – both the capacity and memory format should be
chosen to meet your needs. An OBC typically includes both volatile and non-
volatile memories with differing capacities.
Ms. Vandana Sawant SIESGST 19
 An overview of on-board computer (OBC)
• Interoperability and interfacing capabilities – as a central controlling unit it
is vital that the OBC can work effectively with the required interfaces (e.g.
USB, I2C etc.) and has enough capacity and ports for the external sub-
systems it will connect to.
• Reliability of software – the OBC needs to have reliable software running
on it in order to be able handle event sequencing, monitor health and
performance of all systems, and handle any problems on orbit.
• Power requirements – although OBC power requirements are generally low
compared to other sub-systems, it is important to factor in what power is
needed to your overall calculations.
• Size and weight – the system you choose needs to fit into your current
mass and volume budget to avoid more extensive redesigns.
Ms. Vandana Sawant SIESGST 20
An overview of on-board computer (OBC)

Ms. Vandana Sawant SIESGST 21

 An overview of on-board computer (OBC)
• Software implementation
• The OBC is the subsystem at the center of the CubeSat design that interacts
with all the other subsystems. It can thus be viewed as the brain of a
CubeSat.
• However, until now the only link between the OBC and the other
subsystems is a mechanical one that happens through the PC/104
connector.
• A software is therefore required in order to implement the actions of the
OBC.
• This chapter is dedicated to the introduction of this OBC software.
• The first thing while designing the software of an embedded application is
to select a software architecture.

Ms. Vandana Sawant SIESGST 22

 An overview of on-board computer (OBC)
• 3.1 Software architecture
• The choice has been made to develop the software of the OBC following a Real-
Time Operating System (RTOS) architecture.
• An operating system (OS) is the part of the software that manages the interaction
between tasks and the system resources.
• It is composed of a kernel that controls the system and a library of functions that
facilitate its use.
• RTOS is the OS developed for embedded applications.
• Some important features of RTOS need to be introduced.
• An RTOS is made of several tasks each with a given priority and a given state.
Interrupts are also available.
• An interrupt consists in sending a signal asking the processor to suspend the task
currently
Ms. Vandana Sawant SIESGST 23
 An overview of on-board computer (OBC)
• in progress in order to execute an interrupt routine making it possible to
execute urgent operations within them.
• The kernel contains a scheduler that manages the state of the system by
assigning the processor to the tasks.
• Data communications between different tasks is critical and can be handled
with semaphores and message queues.
• Semaphores are objects having a value 0.
• A semaphore can either be given, which increments its value, or taken,
which decrements its value.
• A semaphore can only be taken if its value is > 0. Message queues are
objects used to transfer data between tasks. The number of messages that
a queue can store and the size

Ms. Vandana Sawant SIESGST 24

 An overview of on-board computer (OBC)
• of a single message are fixed by the user. A task trying to read an empty queue
moves to the suspended state.
• Finally, there are five possible states for a task:
• 1. Dormant: The task is not scheduled;
• 2. Active: The task is currently running;
• 3. Executable: The task is ready to perform operations but another task is already
active;
• 4. Blocked: The task is suspended and waits for a signal, or for a resource;
• 5. Interrupted: The task is executing an interrupt routine.
• There are a lot of advantages to the use of RTOS. First, the OS dynamically
controls the execution of non-urgent tasks through the scheduler and can
suspend a task before its completion to execute another one. This allows long
computations to be performed
Ms. Vandana Sawant SIESGST 25
 An overview of on-board computer (OBC)
• while maintaining low latency.
• Then, the structure of the RTOS makes it easy to add new tasks without
having to rethink the whole system. This feature is particularly useful in the
case of this project as the payload of the CubeSat is still to be determined
and therefore additional tasks will need to be implemented and performed
by the OBC.
• On the other hand, drawbacks of RTOS include the difficulties introduced
by data exchange and the consumption of resources by the OS. In addition,
the main difficulty associated with RTOS is the complexity of its
implementation.
• However, this is not a real problem as there already exist open source RTOS
that can be used.
• The one used in this project is FreeRTOS.

Ms. Vandana Sawant SIESGST 26

 An overview of on-board computer (OBC)
• On-Board Computer
• This thesis aims at developing the on-board computer of a CubeSat. The characteristics
• and role of the OBC will therefore be detailed in this section. During the mission,
• data will be collected through sensors and be processed. Communication with the
ground
• station will also happen. Although they usually involve other sub-systems, all these
operations
• are linked at some point to the OBC. An example is the voltage of the batteries
• which is frequently monitored by the EPS board and whose values are then stored in the
• OBC memory. The OBC can thus be represented at the center of a CubeSat diagram.
• This can be seen in Figure 1.2.2 with the subsystems introduced in the previous section.

Ms. Vandana Sawant SIESGST 27

An overview of on-board computer (OBC)

Ms. Vandana Sawant SIESGST 28

 An overview of on-board computer (OBC)
• Figure 1.2.2: Block diagram representing the interconnection between
the main CubeSat subsystems.
• Based on what has been explained above the main components
required by an OBC will now be explored.
• First, a microcontroller is needed. The MCU can be viewed as the
brain of the OBC and more generally of the CubeSat.
• It will handle the different communications happening inside the
CubeSat and will process the data.
• The communications and data processing will be managed through a
software that needs to be implemented.

Ms. Vandana Sawant SIESGST 29

 An overview of on-board computer (OBC)
• Then, connectors are needed to allow communication between the
different subsystems and the OBC.
• It is also important to ensure that the power signals coming from the EPS
board are well regulated in order to avoid a system failure.
• A monitoring of the power consumed by the OBC is also required as power
is limited inside the CubeSat.
• Finally, the OBC will need to have memories in order to store data and the
software.
• Different memory types will be required. Indeed, some information needs
to be stored for a long time while other information will need to be
processed quickly using volatile memory.

Ms. Vandana Sawant SIESGST 30

 Quality Assurance Requirements
• According to ECSS-S-ST-00C Rev.1 - ECSS System
• Description, implementation and general requirements, the
development of a space system is supported by four major branches,
represented by knowledge areas:
• Project Management, Product Assurance, Engineering and Space
Sustainability.
• These areas of knowledge, can be broken down into disciplines.
Figure 1 shows the disciplines of the Product Assurance.

Ms. Vandana Sawant SIESGST 31

Quality Assurance Requirements

Ms. Vandana Sawant SIESGST 32

 Quality Assurance Requirements
• Fig. 1: Development of a Spatial System, with emphasis on disciplines of the Product Assurance,
extracted from [4].According to ECSS-Q-ST-10C Rev. 1, Space product
• assurance - Product assurance [14], Product Assurance
• aims to “ensure that space products meet their defined
• mission objectives, safely, reliably and with desired
• availability”.
• As shown in Figure 1, the Product Assurance
• disciplines are:
• • Product Assurance Management;
• • Quality Assurance;
• • Dependability;
• • Safety;
• • EEE components;

Ms. Vandana Sawant SIESGST 33

 Quality Assurance Requirements
• • EEE components;
• • Materials, Mechanical Parts and Processes; and
• • Software Product Assurance.
• This work focuses on the analysis of the requirements
• of the Quality Assurance discipline, presented in ECSS-QST-
• 20C Rev.2 Space product assurance - Quality
• assurance [13] and the development of a process of
• tailoring of these requirements aimed at to small satellite
• missions.
• The proposed process was developed from the project
• classification, given its complexity and cost, considering
• its exposure to risk related, to the introduced tailoring. The
• process assesses the risk of not using a requirement, using
• the FMEA/FMECA tool, shown in ECSS-Q-ST-30-02C -
• Space product assurance - Failure modes, effects (and
• criticality) analysis (FMEA/FMECA) [15].

Ms. Vandana Sawant SIESGST 34

 Mission Risk Classification
• Table 1 shows the characteristics adopted for the mission risk
classification, based on the Aerospace publication, in which space
projects are divided in four classes: A, B, C or D.
• Table.1: Mission Risk Class Profiles

Ms. Vandana Sawant SIESGST 35

An overview of on-board computer (OBC)

Ms. Vandana Sawant SIESGST 36

An overview of on-board computer (OBC)

Ms. Vandana Sawant SIESGST 37

 An overview of on-board computer (OBC)
• Class A - Extremely critical operating systems, where
• all practical measures must be taken to ensure mission
• success, through a minimal risk profile. These are missions
• with a long-life cycle (typically longer than 7 years), high
• cost and high investment associated with national interest.
• This class includes manned missions;
• • Class B - Critical operating systems, exploratory and
• technical demonstrators, in which only minor adjustments
• are assumed in the application of Mission Assurance
• standards, to balance cost-effectiveness and ensure mission
• success. This is achieved through a low risk profile. These
• are medium lifecycle missions (typically between 4 and 7

Ms. Vandana Sawant SIESGST 38

 An overview of on-board computer (OBC)
• years), high cost and with high to moderate complexity;
• • Class C - Defined as missions of minor national
• importance, exploratory or experimental, with a reduced
• set of Mission Assurance standards applied, resulting in a
• moderate risk profile. These are short lifecycle missions
• (typically between 1 and 4 years), with moderate cost and
• complexity; and
• • Class D - These are missions defined as having low
• national criticality, presenting a higher risk profile. They
• have a very short life cycle (typically less than 1 year), and
• a minimal set of Mission Assurance requirements, with
• low cost and complexity.

Ms. Vandana Sawant SIESGST 39

Thank You!
([email protected])

40