Controlebordonanossatélites Alves 2019

U NIVERSIDADE F EDERAL DO R IO G RANDE DO N ORTE
C ENTRO DE T ECNOLOGIA
P ROGRAMA DE P ÓS -G RADUAÇÃO EM E NGENHARIA
UNIVERSIDADE FEDERAL DO RIO GRANDE DO NORTE
M ECATRÔNICA
Controle de Bordo para Nanossatélites:

Desenvolvimento e Aplicação ao Projeto
CONASAT
Alex Carlos Rodrigues Alves
Orientador: Prof. Dr. Samaherni Morais Dias
Co-orientador: Prof. Dr. Kurios Iuri Pinheiro de Melo Queiroz
Dissertação de Mestrado apresentada ao

Programa de Pós-Graduação em Engenharia
Mecatrônica da UFRN (área de concentra-
ção: Sistemas Mecatrônicos) como parte dos
requisitos para obtenção do título de Mestre
em Engenharia Mecatrônica.
Número de ordem PEM: M020

Natal, RN, setembro de 2019
Universidade Federal do Rio Grande do Norte - UFRN
Sistema de Bibliotecas - SISBI
Catalogação de Publicação na Fonte. UFRN - Biblioteca Central Zila Mamede
Alves, Alex Carlos Rodrigues.

Controle de bordo para nanossatélites: desenvolvimento e
aplicação ao projeto CONASAT / Alex Carlos Rodrigues Alves. -
2019.
82 f.: il.
Dissertação (mestrado) - Universidade Federal do Rio Grande

do Norte, Centro de Tecnologia, Programa de Pós-Graduação em
Engenharia Mecatrônica, Natal, RN, 2019.
Orientador: Prof. Dr. Samaherni Morais Dias.
Coorientador: Prof. Dr. Kurios Iuri Pinheiro de Melo Queiroz.
1. Controle de bordo - Dissertação. 2. INPE/CRN -

Dissertação. 3. CubeSat - Dissertação. 4. Computador de bordo -
Dissertação. 5. OBC - Dissertação. 6. CONASAT - Dissertação. I.
Dias, Samaherni Morais. II. Queiroz, Kurios Iuri Pinheiro de
Melo. III. Título.
RN/UF/BCZM CDU 621.865.8
Elaborado por Ana Cristina Cavalcanti Tinôco - CRB-15/262

Aos meus avós, Creuza (in
memorian) e José (in memorian),
por fazerem parte da minha
formação e me ensinarem a não
desistir dos meus sonhos.
Agradecimentos
Aos meus pais, Paulo Alves e Maria Miriam (in memorian), por todo amor, dedicação e
esforço para que seus filhos tivessem a oportunidade de alcançar seus objetivos.
Ao meu irmão, Paulo Roberto, pelos conselhos e conhecimentos compartilhados.
Aos amigos do Edifício Delos, Tarcísio, Arthur, Kleber, Miguel, Bruno, Marcus e Victor,
por todas as conversas e pelo apoio nos momentos longe da família.
À minha namorada, Angelica, por todo carinho e paciência, e por acreditar em mim em
momentos em que desacreditei.
À toda minha família e amigos pelo apoio durante esta caminhada.
Ao meu orientador, professor Samaherni, por toda orientação, paciência e atenção, e por
colaborar com minha visão enquanto pesquisador.
Ao meu co-orientador, professor Kurios, sou grato pela disponibilidade e pela colaboração
durante minha trajetória acadêmica.
Aos colegas do INPE/CRN e do projeto CONASAT pela enorme colaboração no desen-

volvimento deste trabalho.
À Coordenação de Aperfeiçomento de Pessoal de Nível Superior (CAPES), pelo apoio

financeiro.
"Não basta ensinar ao homem uma especialidade,
porque se tornará assim uma máquina utilizável,
mas não uma personalidade. É necessário que
adquira um sentimento, um senso prático daquilo
que vale a pena ser empreendido, daquilo que é belo,
do que é moralmente correto. A não ser assim, ele se
assemelhará, com seus conhecimentos profissionais,
mais a um cão ensinado do que a uma criatura
harmoniosamente desenvolvida. Deve aprender a
compreender as motivações dos homens, suas
quimeras e suas angústias para determinar com
exatidão seu lugar exato em relação a seus próximos
e à comunidade."
Albert Einstein
Resumo
Desde o lançamento da Sputnik I em 1957, a indústria de satélites experimentou gran-

des avanços tecnológicos. Inicialmente, os recursos para execução de missões com saté-
lites se concentravam em grandes entidades comerciais e organizações governamentais.
Porém, ao oferecer uma solução de baixo custo e com menor tempo de desenvolvimento,
o padrão CubeSat permitiu que diversas instituições e organizações fossem capazes de de-
senvolver missões com nanossatélites. No Brasil, o Centro Regional do Nordeste (CRN)
do Instituto Nacional de Pesquisas Espaciais (INPE) tem desenvolvido, em parceria com
a Universidade Federal do Rio Grande do Norte (UFRN), o projeto CONASAT com o
objetivo de desenvolver uma constelação de nanossatélites para o Sistema Brasileiro de
Coleta de Dados Ambientais (SBCDA). Atualmente, tem sido desenvolvido o CubeSat
denominado CONASAT-0 (o primeiro da constelação), para o qual faz-se necessária a
implementação de um sistema de controle de bordo capaz de satisfazer os requisitos do
projeto CONASAT. Diante desse contexto, neste trabalho, é apresentada a primeira versão
do sistema de controle de bordo para o CONASAT-0. Além disso, nesta dissertação são
apresentados os testes realizados com o sistema desenvolvido e os resultados obtidos. Por
fim, são apresentadas proposições para trabalhos futuros.
Palavras-chave: Controle de bordo, INPE/CRN, CubeSat, Computador de bordo,

OBC, CONASAT.
Abstract
Since the launch of Sputnik I in 1957, the satellite industry has experienced great te-
chnological advances. Initially, the resources for satellite missions were concentrated on
large commercial entities and government organizations. However, by offering a low-cost
solution with shorter development time, the CubeSat standard allowed several instituti-
ons and organizations to be able to develop missions with nanosatellites. In Brazil, the
Northeast Regional Center (CRN) of the National Institute of Space Research (INPE)
has developed, along with the Federal University of Rio Grande do Norte (UFRN), the
CONASAT project with the objective of developing a constellation of nanosatellites to
the Brazilian Environmental Data Collection System (SBCDA). Currently, it has been
developed the CubeSat called CONASAT-0 (first of the constellation), which needs the
implementation of an on-board control system capable of meeting requirements of the
CONASAT project. In this context, this work presents the first version of the on-board
control system for CONASAT-0. Moreover, in this dissertation are presented the tests
performed with the developed system and the results obtained. Finally, propositions for
future works are presented.
Keywords: On-board control, INPE/CRN, CubeSat, On-board computer, OBC, CO-

NASAT.
Sumário
Sumário i
Lista de Figuras iii
Lista de Tabelas v
Lista de Símbolos e Abreviaturas vi
1 Introdução 1
1.1 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.2 Contribuições . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3 Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.4 Organização do texto . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2 Fundamentação Teórica 10
2.1 Revisão sobre Pequenos Satélites . . . . . . . . . . . . . . . . . . . . . . 10
2.1.1 A Indústria de Pequenos Satélites . . . . . . . . . . . . . . . . . 13
2.1.2 Desafios no Projeto de Pequenos Satélites . . . . . . . . . . . . . 15
2.2 CubeSats: Uma Visão Geral . . . . . . . . . . . . . . . . . . . . . . . . 16
2.2.1 CubeSats no Brasil . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.2.2 CubeSats no Ambiente Espacial . . . . . . . . . . . . . . . . . . 19
2.3 Computadores de Bordo em Pequenos Satélites . . . . . . . . . . . . . . 20
2.3.1 Arquitetura de Processamento . . . . . . . . . . . . . . . . . . . 21
2.3.2 Técnicas de Tolerância a Falhas . . . . . . . . . . . . . . . . . . 22
i
3 Projeto e Desenvolvimento do Sistema 24
3.1 O CONASAT-0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.1.1 Subsistemas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.1.2 Computador de Bordo . . . . . . . . . . . . . . . . . . . . . . . 27
3.1.3 Carga Útil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.2 Ambiente de Desenvolvimento . . . . . . . . . . . . . . . . . . . . . . . 30
3.2.1 Plataforma de Desenvolvimento . . . . . . . . . . . . . . . . . . 32
3.2.2 Framework para Software de Voo . . . . . . . . . . . . . . . . . 32
3.3 Sistema de Controle de Bordo . . . . . . . . . . . . . . . . . . . . . . . 35
3.3.1 Modos de Operação . . . . . . . . . . . . . . . . . . . . . . . . 36
3.3.2 Aplicações Principais . . . . . . . . . . . . . . . . . . . . . . . . 37
3.3.3 Aplicações de Modos de Operação . . . . . . . . . . . . . . . . . 38
4 Experimentos e Resultados 40
4.1 Testes dos Subsistemas de Energia e Comunicação . . . . . . . . . . . . 41
4.2 Teste das Aplicações HK-APP e TTEC-APP . . . . . . . . . . . . . . . . 45
4.3 Teste da MODE-APP e de Modos de Operação . . . . . . . . . . . . . . 48
4.4 Produção Intelectual . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
5 Conclusões e Proposições Futuras 54

5.1 Proposições Futuras . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Referências bibliográficas 57
A Dados de Housekeeping, Telemetria e Telecomando 64

Lista de Figuras
1.1 Algumas categorias de satélites de acordo com a sua massa . . . . . . . . 3

1.2 Número de lançamentos de CubeSats . . . . . . . . . . . . . . . . . . . . 5
1.3 Etapas do trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1 Lançamentos de nanossatélites . . . . . . . . . . . . . . . . . . . . . . . 17

2.2 Possíveis configurações de CubeSats . . . . . . . . . . . . . . . . . . . . 18
2.3 Processamento descentralizado . . . . . . . . . . . . . . . . . . . . . . . 22
3.1 Computador de bordo iOBC . . . . . . . . . . . . . . . . . . . . . . . . 29

3.2 Diagrama de comunicação iOBC-Computador . . . . . . . . . . . . . . . 31
3.3 Plataforma de desenvolvimento . . . . . . . . . . . . . . . . . . . . . . . 33
3.4 Arquitetura do Framework . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.5 SDK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.6 Arquitetura modular . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.7 Interação entre aplicações e banco de dados . . . . . . . . . . . . . . . . 37
4.1 Esquema utilizado durante os testes . . . . . . . . . . . . . . . . . . . . 40

4.2 Teste tensão do sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.3 Teste do subsistema TT&C . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.4 Execução programa EPS . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.5 Teste subsistemas EPS e TT&C (código Rust) . . . . . . . . . . . . . . . 45
4.6 Teste HK-APP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.7 Teste TT&C-APP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.8 Teste tensão e corrente do sistema . . . . . . . . . . . . . . . . . . . . . 48
iii
4.9 Teste MODE-APP e modos de operação . . . . . . . . . . . . . . . . . . 50
4.10 Lista de processos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Lista de Tabelas
2.1 Algumas aplicações de pequenos satélites . . . . . . . . . . . . . . . . . 12

2.2 Companhias fornecedoras de serviços e produtos para pequenos satélites . 14
2.3 Desafios técnicos, áreas promissoras de pequisa e artigos relacionados . . 16
3.1 Comparação entre o iOBC e CubeComputerV3 . . . . . . . . . . . . . . 27

3.2 Transição entre os modos de operação. . . . . . . . . . . . . . . . . . . . 37
A.1 Dados de housekeeping . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

A.2 Telecomando e telemetria . . . . . . . . . . . . . . . . . . . . . . . . . . 67
v
Lista de Símbolos e Abreviaturas
ADCS: Attitude and Determination Control System
BSP: Board Support Package
CRN: Centro Regional do Nordeste
EPS: Electrical Power System
ESL: Electronic Systems Laboratory
EUA: Estados Unidos da América
I2 C: Inter-Integrated Circuit
INPE: Instituto Nacional de Pesquisas Espaciais
ISIS: Innovative Solutions In Space
LEO: Low Earth Orbit
MEMS: MicroElectroMechanical Systems
OBC: On-Board Computer
PCDs: Plataformas de Coleta de Dados Ambientais
SBCDA: Sistema Brasileiro de Coleta de Dados Ambientais
SDK: Software Development Kit
SDR: Software Defined Radio
vi
SDRAM: Synchronous Dynamic Random-Access Memory
SEL: Single Event Latchup
SEU: Single Event Upset
TT&C: Telemetry, Tracking & Command
UFRN: Universidade Federal do Rio Grande do Norte
UHF: Ultra High Frequency
VHF: Very High Frequency

Capítulo 1
Introdução
O período histórico entre os anos de 1957 e 1975 ficou conhecido mundialmente como
Corrida Espacial. Em linhas gerais, essa corrida representou uma disputa tecnológica,
econômica e política entre os Estados Unidos da América (EUA) e a União das Repúbli-
cas Socialistas Soviéticas (URSS) em busca da exploração espacial e, eventualmente, do
conhecimento capaz de lançar o homem à Lua.
O marco inicial desse período foi o lançamento do primeiro satélite artificial do mundo,
o Sputnik I, pela União Soviética. A resposta americana veio no ano seguinte, em 31 de
janeiro de 1958, com o lançamento do satélite Explorer I e a corrida pela conquista do es-
paço perdurou por cerca de 18 anos, quando, em 1975, as duas superpotências realizaram
em conjunto o projeto Apollo-Soyuz.
O primeiro satélite artificial operado pelo Brasil foi lançado em 8 de fevereiro de 1985
e recebeu o nome de Brasilsat A1. Ele foi construído por uma empresa canadense e tornou
possível a independência no setor de telecomunicações do nosso país. Com o passar dos
anos, outros satélites operados pelo Brasil foram colocados em órbita e, paralelamente,
foram obtidos o conhecimento e a tecnologia necessária para que fossem construídos
objetos desse tipo em território nacional (de Melo & Winter 2007).
Nos anos de 1993 e 1998, foram lançados os Satélites de Coleta de Dados, SCD-1
e SCD-2, respectivamente. Ambos foram produzidos pelo Instituto Nacional de Pesqui-
sas Espaciais (INPE), em São José dos Campos, e representaram as bases para o desen-
CAPÍTULO 1. INTRODUÇÃO 2
volvimento da tecnologia para a construção de satélites e seus veículos lançadores no

Brasil (de Melo & Winter 2007).
A partir dos anos 60, milhares de satélites foram postos em órbita em todo o mundo.
Eles podem ser divididos em dois grandes grupos de acordo com suas aplicações: civis
ou militares. Usados para fins pacíficos, os satélites civis, hoje em dia, são fundamentais
a um grande número de atividades humanas, entre elas: telecomunicações, previsões me-
tereológicas, levantamento de recursos minerais e testes de novas tecnologias. Enquanto
isso, os satélites militares são utilizados para fins de espionagem e segurança (de Melo &
Winter 2007).
O cenário crescente de missões espaciais baseadas em satélites acarretou no aumento
do custo e do tempo de desenvolvimento destes artefatos, o que representava um problema
para pesquisadores e estudantes interessados na ciência e exploração espacial (CGEE
2018). Como forma de contornar esse problema, em 1999, os professores Jordi Puig-Suari
da Universidade Politécnica da Califórnia e Bob Twiggs da Universidade de Stanford
propuseram o padrão CubeSat (ISIS 2018).
Ao permitir que grupos de estudantes e pesquisadores rapidamente implementassem
pequenas missões espaciais, o padrão CubeSat se tornou popular e passou a ser também
desenvolvido por empresas privadas e organizações governamentais (ISIS 2018).
Dentro da classe conhecida como satélites de pequeno porte, os CubeSats fazem
parte, principalmente, das categorias de picossatélite e nanossatélite, as quais especifi-
cam objetos com massa entre 0,1 kg e 1 kg e entre 1 kg e 10 kg, respectivamente (Fi-
gura 1.1) (Razzaghi 2012). Entre as aplicações desses tipos de satélites, destacam-se:
sensoriamento remoto da Terra, telecomunicações, ciência de um modo geral, defesa e
treinamento de estudantes e profissionais da área espacial (CGEE 2018).
Seguindo a tendência mundial na pesquisa de CubeSats, o Centro Regional Sul (CRS)
do INPE desenvolveu, em parceria com a Universidade Federal de Santa Maria (UFSM),
o primeiro CubeSat brasileiro, chamado de NanosatC-BR1, o qual foi lançado no ano
Figura 1.1: Algumas categorias de satélites de acordo com a sua massa
Fonte: (CGEE 2018)
de 2014. Anos antes do lançamento desse nanossatélite, o Centro Regional do Nordeste

(CRN) do INPE, com sede em Natal, iniciou os estudos relacionados à CubeSats que
resultaram na elaboração do projeto intitulado Constelação de Nanossatélites para Coleta
de Dados Ambientais (CONASAT).
Por meio de uma constelação de nanossatélites, o projeto CONASAT tem como obje-
tivo oferecer uma alternativa com custos mais reduzidos e tecnologicamente mais avan-
çada para garantir a continuidade do Sistema Brasileiro de Coleta de Dados Ambientais
(SBCDA), uma vez que os satélites SCD-1 e SCD-2, responsáveis pelo monitoramento
ambiental em nosso país, encontram-se em operação há anos e o primeiro já apresenta
algumas restrições. Busca-se, então, uma melhora na qualidade do serviço, no que se
refere à capacidade, abrangência geográfica e tempos de revisita (Carvalho et al. 2013).
Além disso, o projeto procura atrair estudantes e pesquisadores da Universidade Federal
do Rio Grande do Norte (UFRN), de modo a agregar diversas competências técnicas e
científicas para o desenvolvimento de uma constelação de nanossatélites de baixo custo e
para a capacitação no setor espacial (INPE 2018).
Além do SCD-1 e do SCD-2, o SBCDA é composto, atualmente, pelo satélite CBERS-
4, pela rede de Plataformas de Coleta de Dados (PCDs) espalhadas no território nacional
e no mar, pelas Estações de Recepção de Alcântara e de Cuiabá e pelo centro de mis-
são chamado Sistema Nacional de Dados Ambientais (SINDA) localizado no INPE/CRN

(Santos et al. 2013). O objetivo do SBCDA é coletar os dados ambientais (como tempe-
ratura e umidade) provenientes das PCDs e disponibilizá-los no SINDA para que possam
ser acessados por diversos usuários (Carvalho et al. 2013).
Entre os subsistemas que compõem os CubeSats a serem desenvolvidos no projeto
CONASAT, tem-se:
• Subsistema estrutural;
• Subsistema de energia elétrica (EPS, do inglês, Electrical Power System);
• Subsistema de determinação e controle de atitude (ADCS, do inglês, Attitude and
Determination Control System);
• Subsistema de telemetria e telecomando (TT&C, do inglês, Telemetry, Tracking &
Command);
• Subsistema de controle de bordo;
• Carga útil.
Cada um desses subsistemas desempenha uma função específica no nanossatélite e é

de fundamental importância para o sucesso da missão espacial. Destaca-se aqui o sub-
sistema de controle de bordo, cujo elemento principal é o computador de bordo (OBC,
do inglês, On-Board Computer), responsável pelo processamento das informações trans-
mitidas ao satélite e pelo gerenciamento e controle dos dados entre os demais subsiste-
mas (Razzaghi 2012).
Atualmente, o INPE/CRN tem desenvolvido, em parceria com a UFRN, um modelo
1U (cubo com 10 cm de aresta e até 1,33 kg) de CubeSat denominado CONASAT-0.
Desse modo, considerando os diferentes hardwares de OBCs disponíveis para utilização
nesse CubeSat, faz-se necessário o desenvolvimento de um sistema de controle de bordo
capaz de satisfazer os requisitos do projeto CONASAT, permitir o gerenciamento e con-
trole de dados dos subsistemas presentes no nanossatélite e assegurar o sucesso da missão,
sendo capaz de detectar e corrigir eventuais erros em órbita.

Observa-se que, anos após o início da era espacial, as pesquisas e tecnologias na área
espacial continuam em crescente desenvolvimento em todo o mundo. Porém, o Brasil
parece estar um pouco defasado na atual corrida pela exploração do espaço, uma vez que,
leva-se um tempo considerável para o desenvolvimento e lançamento de nanossatélites no
país. Segundo dados apresentados em CGEE (2018), desde o ano de 2005 até 31 de maio
de 2018, tivemos apenas três CubeSats colocados em órbita pelo Brasil, enquanto os EUA
lançaram, só em 2018, quarenta e dois objetos desse tipo (Figura 1.2). Essa defasagem
brasileira acontece por diversos fatores, os quais fogem do escopo deste trabalho.
Figura 1.2: Número de lançamentos de CubeSats
Fonte: Adaptado de (CGEE 2018)
Considerando o cenário atual no desenvolvimento de CubeSats no Brasil e as deman-

das do projeto CONASAT, este trabalho tem como proposta o desenvolvimento de uma
primeira versão do sistema de controle de bordo para o CubeSat CONASAT-0. Desse
modo, busca-se contribuir com o projeto, oferecendo uma solução de acordo com os re-
quisitos da missão espacial e do CubeSat em construção.
1.1 Objetivos
O objetivo geral deste trabalho é desenvolver a primeira versão do sistema de controle

de bordo para o CONASAT-0. Considerando os requisitos do projeto e os OBCs disponí-
veis, o sistema deverá ser capaz de gerenciar, controlar e armazenar os dados provenientes
da dos diferentes subsistemas que compõem o CONASAT-0.
Além disso, este trabalho tem como objetivos específicos:
• Elaborar uma estratégia para monitoramento de corrente e tensão no nanossatélite;

• Analisar protocolo de comunicação para aplicação no gerenciamento dos subsiste-
mas;
• Determinar técnica de redundância por software a ser utilizada para tolerância a
falhas.
1.2 Contribuições
Este trabalho visa contribuir com o projeto CONASAT por meio da elaboração de um
sistema de controle de bordo para o CubeSat em desenvolvimento. Ademais, procura-
se auxiliar na continuidade do projeto, de modo a fomentar o interesse pelo estudo da
engenharia espacial por parte de pesquisadores e estudantes da UFRN em parceria com
o INPE/CRN. Espera-se, ainda, colaborar com o atual cenário de desenvolvimento de
nanossatélites, em especial no Brasil, através dos resultados da pesquisa.
1.3 Metodologia
O trabalho foi desenvolvido seguindo diversas etapas com o intuito de alcançar os

objetivos propostos. Na Figura 1.3, é apresentado o fluxograma com as etapas do trabalho,
as quais são descritas a seguir.
Figura 1.3: Etapas do trabalho
Revisão Bibliográfica
Testes Iniciais (OBC)
Verificação dos
Subsistemas
Análise dos Testes
Desenvolvimento
do OBC (software)
Testes dos softwa-

res desenvolvidos
Elaboração do Texto
1. Revisão bibliográfica: nesta etapa, foi realizada uma revisão bibliográfica sobre
satélites de pequeno porte, em especial os nanossatélites e o padrão CubeSat. Os
estudos abrangeram os computadores de bordo (OBCs) utilizados em CubeSats e
encontrados na literatura. Além disso, foram buscadas estratégias para medição
de corrente e tensão em nanossatélites, bem como, técnicas de tolerância a falhas
por software. Para isso, foram pesquisados artigos em plataformas como Google
Scholar e IEEE Xplore Digital Library por meio de palavras-chave, tais como: on-
board computer, CubeSat, OBC, nanosatellite, small satellite, fault tolerance;
2. Testes iniciais com o OBC: após a revisão bibliográfica, foram efetuados testes com
o computador de bordo a ser utilizado no CONASAT. Para isso, foram verificados os
drivers dos periféricos da placa utilizando a plataforma (ver Capítulo 3) localizada
no laboratório do CONASAT no INPE/CRN;
3. Verificação dos subsistemas: nesta etapa, foi verificado o funcionamento dos sub-
sistemas do CONASAT, disponíveis no INPE/CRN, por meio de testes de hardware
e, eventualmente, software;
4. Análise dos testes: após a verificação dos subsistemas, foi realizada uma análise
dos resultados obtidos. Desse modo, buscou-se evitar erros de software e hardware
no desenvolvimento do trabalho;
5. Desenvolvimento do OBC (software): nesta etapa, foram desenvolvidos os softwa-
res responsáveis pelo controle e gerenciamento de dados de alguns dos subsistemas
do nanossatélite. Durante o desenvolvimento, foram considerados os testes efe-
tuados anteriormente, tal como, referências encontradas na literatura. Por fim, os
softwares foram depurados e embarcados no OBC para testes futuros;
6. Testes dos softwares desenvolvidos: por meio dos softwares desenvolvidos, foram
testados os subsistemas do nanossatélite com o intuito de verificar e corrigir possí-
veis erros. Além disso, foi testada a comunicação por radiofrequência entre o Cu-
beSat e um rádio definido por software (SDR, Software Defined Radio) localizado
no INPE/CRN. Para tal, foi utilizado o subsistema de telemetria e telecomando;
7. Elaboração do texto: por fim, foi elaborado o texto de dissertação contendo refe-
rências bibliográficas, descrição detalhada do sistema desenvolvido, apresentação
e análise dos resultados obtidos durante os diversos testes realizados, conclusões e
perspectivas do trabalho.
1.4 Organização do texto
No Capítulo 2, é apresentada a fundamentação teórica utilizada como base para a com-

preensão e elaboração do trabalho, começando com uma revisão sobre pequenos satélites
e CubeSats, até um estudo sobre os OBCs usados em nanossatélites.
O Capítulo 3 introduz o CONASAT-0 e o ambiente de desenvolvimento da primeira
versão do sistema de controle de bordo, bem como as aplicações desenvolvidas para o
sistema e os modos de operação no satélite.
Os testes dos subsistemas e das aplicações são descritos no Capítulo 4, assim como os
resultados obtidos ao final de cada teste.
Por fim, no Capítulo 5, estão dispostas as conclusões do trabalho e proposições para
trabalhos futuros.
Capítulo 2
Fundamentação Teórica
Neste Capítulo, será apresentada uma revisão sobre pequenos satélites, considerando
suas classificações de acordo com a massa e algumas das suas possíveis aplicações. Em
seguida, serão descritos alguns aspectos da indústria de pequenos satélites e os desafios
no projeto desses objetos.
O Capítulo seguirá com uma visão geral sobre os CubeSats. Serão apresentados al-
guns projetos de CubeSats desenvolvidos no Brasil e os efeitos da exposição desses obje-
tos ao ambiente espacial.
Por fim, será considerada a importância dos computadores de bordo em um Cubesat
e as técnicas de tolerância a falha implementadas com o intuito de reduzir os efeito da
radiação sobre o OBC.
2.1 Revisão sobre Pequenos Satélites
No início da Era Espacial, devido às capacidades limitadas dos primeiros veículos de

lançamento, havia uma tendência de que todos os satélites fossem pequenos. Com a evo-
lução dos lançadores e o desenvolvimento de satélites experimentais projetados para su-
portar missões mais sofisticadas, os satélites se tornaram maiores (Jakhu & Pelton 2014).
O aumento em tamanho e massa desses objetos causou uma elevação nos custos de
projeto e desenvolvimento de missões (Razzaghi 2012). Além disso, a necessidade de ca-
CAPÍTULO 2. FUNDAMENTAÇÃO TEÓRICA 11
pital intelectual especializado e treinado também passou a ser maior. Esses fatores fizeram
com que apenas grandes entidades comerciais e organizações governamentais possuíssem
recursos para a execução de missões com satélites. Contudo, a expansão tecnológica per-
mitiu o aparecimento de atividades espaciais envolvendo o uso de pequenos satélites, o
que, segundo Palkovitz (2016), representou uma revolução e um desafio aos paradigmas
que dominavam a indústria espacial tradicional.
Segundo Gao, Sweeting, Nakasuka & Worden (2018, p. 1, tradução livre)1 ,
Pequenos satélites indicam uma nova geração de satélites miniaturiza-

dos que, tomando vantagens de tecnologias modernas (p. ex., circuitos inte-
grados, processamento digital de sinais, MEMS, e fabricação aditiva), pode
alcançar uma significante redução em volume, massa, tempo de desenvolvi-
mento, e custo de satélites.
A definição sobre o termo “pequenos satélites” (em inglês, small satellites) é um

pouco controversa, de modo que não há um consenso internacional sobre ela. Geral-
mente, os satélites são classificados de acordo com a sua massa (Koudelka 2016). Alguns
textos consideram pequenos satélites os objetos com massa inferior a 500 kg, como pode
ser visto em Razzaghi (2012). Contudo, é possível encontrar, na literatura, o uso do termo
para caracterizar satélites que possuem massa menor do que 1000 kg, como em Jakhu &
Pelton (2014) e Palkovitz (2016).
Considerando pequeno satélite como sendo qualquer satélite com massa inferior a 500
kg, tem-se, de acordo com a massa, a seguinte subdivisão (Kulu 2019b):
• Minissatélites: 100 kg à 500 kg;

• Microssatélites: 10 kg à 100 kg;
• Nanossatélites: 1 kg à 10 kg;
1 Smallsatellites denote a new generation of miniaturized satellites which, by taking advantages of mo-
dern technologies (e.g., integrated circuits, digital signal processing, MEMS, and additive manufacturing),
can achieve a significant reduction in volume, mass, development time, and cost of satellites.
• Picossatélites: 100 g à 1 kg;

• Femtossatélites: 10 g à 100 g.
Entre as aplicações desses tipos de satélites, destacam-se o uso para: telecomunica-

ções, retransmissão de dados, rádio amador, sensoriamento remoto, retransmissão de sis-
temas terrestres, meteorologia, experimentos científicos e experimentos estudantis (Madry
et al. 2018). Na Tabela 2.1 são apresentadas algumas dessas aplicações e sua frequência
de utilização de acordo com o tipo de satélite.
Tabela 2.1: Algumas aplicações de pequenos satélites
Tipo Retrans. Meteorologia Exp. Exp.

Telecom.
(massa) de Dados Científicos Estudantis
Mini (100 Típico Típico Típico Típico Raro

à 500 kg)
Micro (20 -
Ocasional Típico Frequente Frequente
à 99 kg)
CubeSats -
- Raro Raro Típico
(1 à 25 kg)
Nano, Pico
ou Femto Ocasional
- - - Típico
(10 g à 1
kg)
Fonte: Adaptado de (Madry et al. 2018)
Grande parte dos pequenos satélites são implantados em Órbita Terrestre Baixa (LEO,
do inglês, Low Earth Orbit) (Jakhu & Pelton 2014), que corresponde a uma distância en-
tre 160 km e 2000 km acima da superfície terrestre. Contudo, há a possibilidade de
implantação de constelações de pequenos satélites em outras órbitas, como a geossín-
crona (acompanha a órbita da terra em torno do seu próprio eixo) e a Órbita Terrestre
Média (Jakhu & Pelton 2014).
Embora proporcione grandes benefícios à comunidade científica e, mesmo que indi-
retamente, à população em geral, o crescente número de pequenos satélites implantados
em LEO desperta preocupação. Isso ocorre pelo consequente acúmulo de lixo espacial,
o que chama atenção para a possibilidade de ocorrência da chamada síndrome de Kess-
ler (Madry et al. 2018). Essa síndrome, descrita pelo cientista da NASA Donald J. Kessler,
prevê que a colisão em cascata de detritos espaciais causaria explosões e impossibilitaria
atividades espaciais e uso de satélites por gerações (Ratner 2018).
Atualmente, os cientistas têm se empenhado no desenvolvimento de tecnologias ca-
pazes de auxiliar na remoção de detritos espaciais. Deste modo, eles buscam estratégias
que minimizem os efeitos causados pela crescente quantidade de pequenos satélites em
LEO.
2.1.1 A Indústria de Pequenos Satélites
As atividades espaciais que envolvem a utilização de pequenos satélites, geralmente,

apresentam um “baixo custo” (Palkovitz 2016). Esse custo reduzido, de acordo com Wo-
ellert et al. (2011), tem estimulado programas de desenvolvimento de pequenos satélites
por parte de indústrias, organizações governamentais e instituições acadêmicas em todo o
mundo.
Na esfera industrial, os pequenos satélites representam uma inovação que vai além
do campo técnico. A própria indústria de pequenos satélites se diferencia da indústria
espacial já estabelecida. Essa diferença implica não apenas na utilização de processos,
materiais e tecnologias distintas durante a produção do satélite, mas também no gerenci-
amento de outros aspectos de maneira econômica (Palkovitz 2016).
Os nanossatélites, incluindo o padrão Cubesat, representam boa parte dos pequenos
satélites desenvolvidos e colocados em órbita. De acordo com Rotteveel et al. (2014),
o avanço desses objetos permitiu que empresas de pequeno porte - geralmente inseri-
das em um nicho altamente especializado da indústria espacial - passassem a desempe-
nhar uma função mais bem definida. Surgiram, então, pequenas empresas responsáveis
pelo fornecimento de componentes, serviços de lançamento e pequenos satélites comple-
tos (Woellert et al. 2011).

Na Tabela 2.2, são apresentadas algumas empresas da indústria de pequenos satélites.
Além disso, são descritos serviços e/ou produtos fornecidos por essas companhias, bem
como, o ano de fundação e o país de origem.
Tabela 2.2: Companhias fornecedoras de serviços e produtos para pequenos satélites
Companhia Produtos e/ou Serviços Ano de fundação, país

Surrey Space, Ltd. Pequenos satélites 1985, Reino Unido
Produtos e tecnologias
Tethers Unlimited para o espaço (tecnologias 1994, EUA
tether)
SpaceQuest, Inc. Componentes de Cubesat 1994, EUA
Kits de Cubesat e serviços
Pumpkin, Inc. 1995, EUA
de integração
Determinação e controle de
Sinclair Interplanetary 2001, Canada
atitude para pequenos sat.
MicroSpace Micropropulsores MEMS 2002, Itália
Dobson Space Telescope Telescópios e aparelhos de
2002, Alemanha
GbR imagem para pequenos sat.
Componentes para Cubesat
Clyde Space 2005, Reino Unido
e serviços de projeto
Serviços de integração de
TristSept Corp lançamento de pequenos 2006, EUA
sat.
Pequenos satélites e servi-
ISIS ços de integração de lança- 2006, Holanda
mento
GOMSpace Pequenos Satélites 2007, Dinamarca
Componentes para Nanos-
CubeSpace 2015, África do Sul
satélites
Fonte: Adaptado de (Woellert et al. 2011)
Algumas das companhias apresentadas na Tabela 2.2 surgiram como spin-offs de pro-
jetos de nanossatélites realizados por instituições acadêmicas. Como exemplos, tem-se

as empresas ISIS (Innovative Solutions In Space), GomSpace (Rotteveel et al. 2014) e
CubeSpace.
Atualmente, o número de empresas ativas que desenvolvem atividades relacionadas
com nanossatélites chega a trezentos e cinquenta e um, de acordo com dados apresentados
em Kulu (2019a). Nesse banco de dados, podem ser verificadas companhias provedoras
de serviços e produtos no mercado de nanossatélites.
Segundo Palkovitz (2016), devido à crescente demanda por pequenos satélites, as em-
presas inseridas nesse mercado, assim como a indústria espacial como um todo, precisam
obedecer normas e regulamentos, o que representa um desafio no projeto de satélites de
pequeno porte.
2.1.2 Desafios no Projeto de Pequenos Satélites
O aumento da popularidade dos pequenos satélites, resultado da elaboração de pa-

drões, acarretou no aparecimento de desafios no projeto e implementação desses objetos.
Alguns desafios surgiram pelas restrições de tamanho impostas aos pequenos satélites.
Por exemplo, a produção reduzida de energia elétrica, por parte de painéis solares peque-
nos, impossibilitava o processamento de bordo. Isso acontecia pelo fato dos componentes
eletrônicos, 15 à 20 anos atrás, serem menos eficientes do que os encontrados na atuali-
dade. Essa eficiência foi alcançada graças ao avanço da tecnologia móvel, o que permitiu
a criação de processadores capazes de operar em baixa potência (Razzaghi 2012).
Segundo Jakhu & Pelton (2014), os desafios no projeto de pequenos satélites podem
ser divididos em duas categorias: técnica e operacional; e preocupações legais, regula-
mentares e de responsabilidade.
Os desafios técnicos e operacionais correspondem à busca de novas tecnologias ca-
pazes de auxiliar na confiabilidade e baixo custo de pequenos satélites (Jakhu & Pelton
2014). O exemplo da capacidade de geração de energia elétrica por parte de painéis sola-
res se enquadra nessa categoria.

Parte dos desafios técnicos descritos em Jakhu & Pelton (2014) são apresentados na
Tabela 2.3. Adicionalmente, são destacadas áreas promissoras para pesquisa e artigos
relacionados com cada tipo de desafio indicado.
Tabela 2.3: Desafios técnicos, áreas promissoras de pequisa e artigos relacionados
Desafios Técnicos Área(s) Promissora(s) Trabalhos Relacionados
- Tecnologia de ponto Energy Storage Technolo-

Sistemas de Energia quântico e células fo- gies for Small Satellite
tovoltaicas de junção Applications (Chin et al.
múltipla 2018)
Advanced Antennas for
Small Satellites (Gao,
Sistemas de Antenas - Antenas infláveis
Rahmat-Samii, Hodges &
Yang 2018)
De-orbiting Small
Satellites Using In-
Sistemas de Desorbita - Sistemas infláveis
flatables (Chandra &
Thangavelautham 2018)
Space Propulsion Techno-
Sistemas de Posiciona- - Uso de água ou álcool
logy for Small Spacecraft
mento para propulsão
(Krejci & Lozano 2018)
Fonte: Adaptado de (Jakhu & Pelton 2014)
2.2 CubeSats: Uma Visão Geral
A criação de padrões de nanossatélites possibilitou o acesso ao espaço por parte de

diversas organizações e instituições. Por meio deles, as universidades passaram a desen-
volver pesquisas e capacitar estudantes na construção e aplicação de pequenos satélites
de maneira mais rápida e barata.
Deste modo, a expansão de atividades espaciais com nanossatélites fez com que um
considerável número de objetos desse tipo fosse lançado. Estimativas disponíveis em

Kulu (2019a) mostram que o número de lançamentos tende a aumentar pelos próximos
anos (Figura 2.1).
Figura 2.1: Lançamentos de nanossatélites
Fonte: Adaptado de (Kulu 2019a)
Satélites do tipo Cubesat representam a maior parte dos lançamentos apresentados

na Figura 2.1. Segundo Kulu (2019a), até outubro de 2018, oitocentos e setenta e oito
CubeSats haviam sido lançados.
O padrão Cubesat contém especificações de dimensão, formato e massa para nano e
picossatélites. Ele surgiu, em 1999, como resultado da colaboração entre os professores
Jordi Puig-Suari da Universidade Politécnica da California (Cal Poly), San Luis Bispo,
e Bob Twiggs da Universidade da California (CalPoly 2015). De acordo com o docu-
mento Cubesat Design Specification (CalPoly 2015), a dimensão básica de um Cubesat é
10x10x11,35 cm (em alguns textos, descrito como sendo um cubo com 10 cm de aresta),
que corresponde a uma unidade (1U) com massa de até 1,33 kg. Várias unidades podem
ser colocadas juntas para formar configurações de satélites maiores como 2U, 3U, 6U, 8U
e 12U. Na Figura 2.2, são ilustradas algumas configurações possíveis.
Figura 2.2: Possíveis configurações de CubeSats
Fonte: (CGEE 2018)
O programa CubeSat nasceu com o intuito de reduzir o custo e tempo de desenvolvi-

mento de picossatélites (CalPoly 2015). As diversas configurações possíveis e o conse-
quente aumento na massa dos CubeSats, fez com que eles passassem a ser classificados
também como nanossatélites.
Atualmente, muitas universidades e organizações possuem um programa espacial gra-
ças aos CubeSats. Isso pode ser verificado não apenas em grandes universidades, mas
também em escolas de ensino médio, universidades de pequeno porte, agências governa-
mentais e grupos comerciais espalhados pelo mundo (NASA 2017).
2.2.1 CubeSats no Brasil
Até o presente momento, o Brasil lançou e desenvolveu quatro CubeSats. O NanosatC-

BR1 foi o primeiro a ser lançado no ano de 2014. Esse CubeSat adotou o modelo 1U e foi
colocado em órbita com o objetivo de medir a intensidade do campo magnético da Terra
e testar a resistência à radiação de uma tecnologia de circuitos integrados desenvolvidos
no país (CGEE 2018).
Outros dois CubeSats foram lançados no ano de 2015. O Serpens adotou a configura-
ção 3U e o AESP-14 foi projetado seguindo o modelo 1U. O primeiro levou como carga
útil um transponder para coleta de dados ambientais, além de um experimento de pro-
pulsão de plasma pulsado e um transponder digital para radioamadores. Enquanto isso,
o AESP-14 teve como objetivo a qualificação de engenheiros, pesquisadores e estudantes
no Brasil (CGEE 2018).
Alguns CubeSats têm sido desenvolvidos em diferentes regiões do país. Entre eles, po-
dem ser citados o ITASAT, desenvolvido no Instituto Tecnológico de Aeronáutica (ITA),
e o CONASAT, uma parceria entre o INPE/CRN e a UFRN. O ITASAT foi lançado em
2018 e tem como carga útil principal um transponder que recebe e transmite dados am-
bientais coletados por plataformas localizadas na terra (Carrara et al. 2017). Segundo
Carrara et al. (2014), o projeto CONASAT têm sido projetado com o objetivo de cole-
tar dados ambientais provenientes de plataformas remotas terrestres e retransmiti-los ao
centro da missão. Tais plataformas são denominadas Plataformas para Coleta de Dados
Ambientais (PCDs) e fazem parte do SBCDA. Alguns dos dados a serem coletados são:
volume de chuva; temperatura; umidade; poluição do ar; correntes oceânicas e perigos
ambientais.
2.2.2 CubeSats no Ambiente Espacial
O ambiente espacial é um lugar perigoso para satélites uma vez que os expõe à radi-
ação eletromagnética, fluxos densos de plasma, espécies altamente reativas e densidades
de gás neutro variável (Anderson & Mitchell 2005).
Em Lumbwe (2013), são descritos alguns dos distúrbios aos quais estão sujeitos os
CubeSats em ambiente espacial. Entre eles, tem-se: arrasto atmosférico e oxigênio atô-
mico; ventos solares e erupções solares; ondas eletromagnéticas em espaço livre; exposi-
ção de componentes semicondutores à radiação e mudanças extremas de temperatura; e,
detritos espaciais.
Os principais efeitos da radiação sobre os componentes eletrônicos dos CubeSats são
a Dose Total Ionizante (TID, do inglês, Total Ionizing Dose) e Efeitos de Evento Único
(SEE, do inglês, Single Event Effects). De acordo com LaBel et al. (1996) as principais
fontes de partículas energizadas que causam esses efeitos são: prótons e elétrons presos
nos cinturões de Van Allen; prótons de raio cósmico e íons pesados; e, prótons e íons
pesados provenientes de erupções solares.
O efeito TID é consequência do acúmulo de energia depositada em um material du-
rante um longo período de tempo, o que causa uma degradação dos componentes eletrô-
nicos. São exemplos de defeitos causados por TID: variações na corrente de fuga e tensão
de limiar e falhas funcionais (LaBel et al. 1996).
Quando energia suficiente é depositada em um dispositivo por meio do impacto de
um único íon, diz-se que ocorreu um SEE. Os efeitos desse tipo podem ser divididos em
duas categorias principais: erros permanentes (hard errors) e erros não permanentes (soft
errors). Um exemplo de hard error é o chamado SEL (em inglês, Single Event Latchup),
que envolve elementos parasitas do circuito e pode ser potencialmente destrutivo. Durante
um SEL, a corrente do dispositivo excede os limites especificados e, a fim de corrigir o
problema, é preciso reiniciar a energia do aparelho (LaBel et al. 1996).
O SEU é caracterizado por um pulso transitório ou bitflip, atingindo elementos de
memória como latchs e registradores. A taxa de erro decorrentes de SEU independe da
frequência de clock do circuito (Gadlage et al. 2004). Esse tipo de erro pode ser corrigido
ao reiniciar o dispositivo ou por meio da reescrita de dados (LaBel et al. 1996).
2.3 Computadores de Bordo em Pequenos Satélites
O computador de bordo é o elemento central em um CubeSat. Por meio da inte-

ração com todos os subsistemas e carga útil do satélite, o OBC fornece serviços como
comando e manipulação de dados, monitoramento de condições internas e marcação de
tempo (Heunis 2014).
O subsistema de controle de bordo é comumente considerado como Subsistema de

Comandos e Manipulação de Dados (CDHS, do inglês, Command and Data Handling
System) (INPE 2012). Segundo Wertz & Larson (1999), o CDHS tem como funções
principais: recepção, validação, decodificação e distribuição de comandos aos outros sub-
sistemas do satélite; e, coleta, processamento e formatação de dados a serem enviados à
estação terrestre.
Além disso, algumas características que o OBC deve possuir são: robustez mecâ-
nica para suportar as vibrações no momento de lançamento; resistência às condições
eletromagnéticas; resistência às condições de temperatura; resistência às altas doses de
radiação provenientes de partículas energizadas em órbita; e, baixo consumo de ener-
gia (Eickhoff 2011).
2.3.1 Arquitetura de Processamento
Uma das arquiteturas de processamento de dados utilizada em CubeSats é a arquite-

tura descentralizada. Nesse tipo de arquitetura, o computador de bordo (nó central) se
conecta aos demais subsistemas e componentes externos por meio de um barramento.
O processamento de dados é realizado de forma independente em cada subsistema e a
comunicação é realizada com auxílio do protocolo de comunicação I2 C (em inglês, Inter-
Integrated Circuit) (INPE 2012). Na Figura 2.3, é ilustrada a arquitetura descentralizada.
Uma das vantagens desse tipo de arquitetura é o fato das atividades serem dividas entre
várias unidades de processamento. Isso faz com que os pontos de falha sejam isolados
e, consequentemente, a falha em um dos subsistemas não compromete a operação do
sistema como um todo (Mota 2017).
Figura 2.3: Processamento descentralizado
TT&C Carga útil
I2 C I2 C
I2 C I2 C I2 C
OBC EPS ADCS
2.3.2 Técnicas de Tolerância a Falhas
As técnicas de tolerância a falhas são utilizadas em computadores de bordo com o in-

tuito de reduzir os efeitos da radiação sobre os componentes eletrônicos que os compõem.
Elas podem ser implementadas tanto em hardware quanto em software. A seguir, serão
descritas algumas dessas técnicas.
Hardware
Em nível de hardware, algumas das técnicas de tolerância a falhas utilizadas são: re-
dundância fria (em inglês, cold redundancy); redundância quente (em inglês, hot redun-
dancy); e, redundância de módulo triplo (TMR, do inglês, Triple Modular Redundancy).
A redundância fria é utilizada como forma de aumentar a confiabilidade do sistema.
Para isso, são usados componentes redundantes, inicialmente desligados, que se encon-
tram separados do sistema principal. Ao ser detectada uma falha, o elemento redundante
é ativado e passa a substituir o componente defeituoso (Coit 2001).
Na redundância quente, são utilizados dois dispositivos exatamente iguais, com clocks
sincronizados e efetuando as mesmas operações. Quando os valores de saída no proces-
sador diferem, são detectados erros que podem ser do tipo SEU. Como forma de correção
do erro, o sistema pode reiniciar (Razzaghi 2012).
TMR é uma técnica de tolerância a falhas em que três elementos idênticos são co-
locados no satélite. Eles efetuam as mesmas tarefas de modo simultâneo e um circuito
votador fica encarregado de checar as saídas de cada elemento. Caso a saída de um deles
seja diferente da dos demais, o resultado é considerado como sendo a saída apresentada
pela maioria (Moore 2005).
Software
As técnicas de tolerância a falhas por software podem ser aplicadas em nível de arqui-
tetura e em nível de aplicação.
Um dos métodos aplicados em nível de arquitetura é o desenvolvimento de uma ar-
quitetura modular. Nesse método, o sistema é desenvolvido com uma baixa dependência
entre os módulos, o que aumenta a tolerância a falhas, uma vez que os erros em um único
módulo não se propagam por todo o sistema (Heunis 2014).
Em nível de aplicação, podem ser utilizadas técnicas com uma única versão de soft-
ware e várias versões de software. Nas técnicas com versão única, a tolerância a falha é
aumentada por meio de mecanismos capazes de detectar e isolar o erro, bem como, recu-
perar processos. Por outro lado, as técnicas que fazem uso de várias versões de software
são implementadas através da execução sequencial ou em paralelo de várias versões de
software, de modo a assegurar que a falha em uma das versões não irá causar problemas
em todo o sistema (Heunis 2014).
Capítulo 3
Projeto e Desenvolvimento do Sistema
Neste capítulo, o computador de bordo utilizado no desenvolvimento do trabalho será

apresentado. Em seguida, será feita uma breve descrição dos possíveis subsistemas uti-
lizados no CONASAT-0, bem como sua carga útil, observando a comunicação de cada
um deles com o OBC. Além disso, será apresentado o ambiente de desenvolvimento da
primeira versão do sistema, o qual é composto por uma plataforma de desenvolvimento
2U disponível no laboratório do INPE/CRN e por ferramentas que integram o framework
de software de voo para satélites escolhido para a realização deste trabalho. Por fim, serão
descritas as aplicações de missão desenvolvidas para o sistema de controle de bordo.
3.1 O CONASAT-0
Ao longo dos anos, com o desenvolvimento de novas tecnologias, foram ocorrendo

modificações nas definições do projeto CONASAT. Por exemplo, inicialmente foi definida
a utilização do modelo CubeSat 8U no projeto. Contudo, atualmente, encontra-se em
desenvolvimento um modelo 1U de CubeSat chamado CONASAT-0.
O CONASAT-0 tem sido desenvolvido com base em componentes e subsistemas de
algumas das empresas apresentadas na Tabela 2.2. O laboratório do projeto CONASAT,
localizado na sede do INPE/CRN em Natal, possui diversos dispositivos projetados espe-
cificamente para o estudo e desenvolvimento de CubeSats. Entre os subsistemas dispo-
CAPÍTULO 3. PROJETO E DESENVOLVIMENTO DO SISTEMA 25
niveis, tem-se: computador de bordo CubeComputerV3 da ESL (hoje desenvolvido pela

CubeSpace); computador de bordo iOBC (Isis On-Board Computer) da ISIS; subsistema
de energia Nanopower do fabricante Gomspace; subsistema de telecomando e telemetria
TRXUV da empresa ISIS; modelo de engenharia do sistema de antenas, fabricado pela
ISIS; e, estrutura CubeSat 2U da ISIS.
A seguir, serão descritos os subsistemas utilizados durante o desenvolvimento da pri-
meira versão do sistema de controle de bordo do CONASAT-0, bem como possíveis sub-
sistemas desse CubeSat. Além disso, são apresentados o OBC escolhido para o desenvol-
vimento deste trabalho e a carga útil a ser utilizada no CONASAT-0.
3.1.1 Subsistemas
Energia
O subsistema de energia elétrica tem como função principal o fornecimento de energia

para o funcionamento do nanosatélite. Nesse sistema, a energia é gerada, controlada,
armazenada e distribuída para os demais subsistemas do CubeSat (INPE 2011).
Entre os componentes desse subsistema, tem-se (INPE 2012):
• Painéis solares encarregados da conversão de energia solar em elétrica;

• Baterias utilizadas para o armazenamento de energia;
• Conversores DC/DC capazes de gerar as tensões de trabalho.
Durante os testes com o OBC, foi utilizada a placa NanoPower P31U da GomSpace.
Projetada com capacidade de gerar de 1 à 30 Watts de potência, essa placa é compatível
com o padrão CubeSat e foi desenvolvida para pequenos satélites de baixo custo. A co-
municação entre o NanoPower e o computador de bordo é realizada através de barramento
I2 C (ISIS 2015).
Determinação e Controle de Atitude
O subsistema de determinação e controle de atitude (ADCS, do inglês, Attitude Deter-

mination and Control System) tem como função medir a orientação do CubeSat e ajustá-la
ou mantê-la de acordo com os requisitos da missão (Woellert et al. 2011). Além disso, o
subsistema permite que sejam realizadas previsões das órbitas futuras para rastreio do na-
nossatélite. Para isso, são fornecidos dados orbitais a cada passagem do satélite (períodos
em que há visada entre o satélite e a estação terrestre) (INPE 2012).
O ADCS a ser utilizado em um CubeSat depende dos requisitos da missão. Esse sub-
sistema pode conter: sensores magnéticos (magnetômetros); sensor rastreador de estrelas,
sensor de sol; giroscópio e sensor de posicionamento GPS (INPE 2012). No que se refere
ao ADCS do CONASAT-0, alguns estudos estão sendo realizados para determinar o con-
trole de atitude a ser implementado, de modo que há uma opção de integrá-lo ao próprio
computador de bordo da missão.
Telemetria e Telecomando
O subsistema de telemetria e telecomando tem por finalidade permitir a comunicação

entre o CubeSat e a estação terrestre. Essa comunicação ocorre por meio da transmissão
de pacotes de telemetria e recebimento de pacotes de telecomando (Heunis 2014). Deste
modo, a equipe localizada na estação de controle de missão é capaz de receber informa-
ções e dados do CubeSat e transmitir comandos quando ele está em órbita.
Durante os testes de comunicação por radiofrequência, foi utilizada a placa TRXUV
da ISIS. Ela permite que o CubeSat possua um sistema full duplex com telemetria e tele-
comando. A placa utiliza UHF (Ultra High Frequency) para a recepção de comandos da
estação terrestre e VHF (Very High Frequency) para envio de dados à estação. Ela possui
dois microcontroladores que processam dados internos da placa e codificam e decodificam
os frames AX.25 transmitidos na comunicação por radiofrequência. Esses microcontro-
ladores interagem com o OBC por meio de barramento I2 C e estão associados ao receptor
e ao transmissor da placa. Sendo assim, um dos microcontroladores armazena, em um

buffer, telecomandos recebidos pelo receptor, enquanto o outro utiliza um buffer para ar-
mazenar as telemetrias a serem enviadas pelo transmissor. Cada buffer é do tipo FIFO
(First In First Out).
3.1.2 Computador de Bordo
O computador de bordo utilizado neste trabalho foi escolhido após análise e compara-
ção entre os OBCs pertencentes ao INPE/CRN. Os dois OBCs disponíveis no laboratório
do projeto CONASAT são o iOBC e o CubeComputerV3. As principais características de
ambos são apresentadas na Tabela 3.1.
Tabela 3.1: Comparação entre o iOBC e CubeComputerV3
OBC
Característica
iOBC CubeComputerV3
Processador ARM Cortex-M3 32-bit 4-48

ARM9 32-bit 400 MHz
MHz
Memória RAM 64 MB SDRAM 2x1 MB SRAM
Sistema Opera- FreeRTOS / Linux FreeRTOS
cional
Armazenamento Flash NOR 1 MB Flash 4 MB
de Código
Armazenamento 2 slots SD (até 32 GB) MicroSD 2 GB
de Dados
Interfaces de I2 C, UART, SPI I2 C, UART, SPI, CAN
Comunicação
O CubeComputer3V foi fornecido ao INPE/CRN com um pacote de suporte à placa

(BSP, do inglês, Board Support Package), o qual possui bibliotecas com drivers para
os vários periféricos da placa. Nesse pacote podem ser encontradas, por exemplo, bi-
bliotecas para: controle do módulo ADC (Analog-Digital Converter), controle do bar-
ramento I2C, controle do RTC (Real Time Clock), inicialização e utilização dos canais
UART (Universal Asynchronous Receiver/Transmitter), controle do temporizador do Wat-
chdog (Heunis 2014).
Como etapa inicial para escolha do OBC utilizado no desenvolvimento deste traba-
lho, foram realizados experimentos para a verificação do funcionamento do driver I2 C e
de canais UART do CubeComputerV3. Além disso, o FreeRTOS foi “instalado” nesse
OBC e foram executados testes com os recursos do sistema operacional, como criação e
interação entre tasks. No FreeRTOS, as tasks (ou tarefas) são funções implementadas em
linguagem de programação C que funcionam como pequenos programas e executam de
forma independete de outras aplicações do sistema (Barry 2016, FreeRTOS 2019).
Após a realização dos testes, concluiu-se que, dadas as especificidades do FreeRTOS,
a manutenção do sistema poderia se tornar complexa, o que dificultaria o trabalho dos
pesquisadores e estudantes no desenvolvimento do CONASAT-0. Além disso, uma vez
que o BSP do CubeComputerV3 não possui funções específicas para interação com sub-
sistemas, verificou-se que seria necessária a implementação de drivers e bibliotecas para
interação com os subsistemas a serem utilizados. Consequentemente, o tempo de desen-
volvimento do sistema de controle de bordo com o CubeComputerV3 poderia ultrapassar
o estipulado pela equipe do projeto CONASAT. Sendo assim, foi feita uma análise do
iOBC com o intuito de compará-lo ao CubeComputerV3 e, dessa forma, determinar o
OBC utilizado no desenvolvimento do trabalho.
Na Tabela 3.1, observa-se que o iOBC (Figura 3.1) tem uma capacidade de proces-
samento superior ao CubeComputerV3. Além disso, ele oferece suporte aos sistemas
operacionais FreeRTOS e Linux e permite a utilização de cartões SD de até 32 GB para
armazenamento de dados. O sistema operacional Linux tem sido amplamente utilizado
em sistemas embarcados por apresentar portabilidade, vasta documentação, comunidade
ativa de desenvolvedores, suporte a diferentes famílias de processadores, disponibilidade
de drivers para dispositivos e um grande número de softwares existentes. Além disso,
estudantes têm uma maior familiaridade com esse sistema operacional, o que faz com que
o trabalho com ambientes de desenvolvimento e produção tomem menos esforços quando
comparados a sistemas menos comuns (Razzaghi 2012, Javanainen 2016).
Figura 3.1: Computador de bordo iOBC
Fonte: (ISIS 2019)
Além das características apresentadas na Tabela 3.1, o iOBC possui os seguintes peri-
féricos: 8 canais ADC de 10 bits; 6 canais PWM (Pulse Width Modulation); JTAG (Joint
Test Access Group) para programação e depuração e pinos de entrada e saída para uso ge-
ral (GPIO). O iOBC foi fornecido ao INPE/CRN com um pacote de suporte que contém
drivers para periféricos, sistema operacional FreeRTOS e bibliotecas com funções para
interação com alguns dos subsistemas descritos anteriormente.
Com base nessas informações, o iOBC foi escolhido para o desenvolvimento deste
trabalho. Ademais, no laboratório do projeto CONASAT, há uma plataforma (descrita
adiante) em que o iOBC se encontra acoplado a alguns dos subsistemas descritos anteri-
ormente.
As técnicas de tolerância a falhas por hardware apresentadas no Capítulo 2 não foram
aplicadas ao iOBC, uma vez que ele apresenta apenas um processador e a utilização de
dois computadores de bordo no CONASAT-0 se torna inviável devido às limitações de
espaço disponível no padrão 1U. Contudo, por haver dois slots de cartão SD no iOBC,
é possível a instalação de sistemas idênticos em dois cartões, que podem ser acoplados
ao iOBC. Desse modo, caso ocorra erro de inicialização do sistema armazenado em um
dos cartões, o outro pode ser utilizado para inicialização. No que se refere às técnicas de
tolerância a falhas por software, foi utilizada uma abordagem de desenvolvimento de uma
arquitetura modular. Os detalhes do sistema serão descritos adiante.
3.1.3 Carga Útil
Em um CubeSat, a carga útil (em inglês, payload) representa o software e hardware

que desempenha a tarefa principal durante a missão (Heunis 2014). Deste modo, ela é
considerada como sendo o motivo pelo qual uma missão foi desenvolvida. Alguns exem-
plos de carga útil são instrumentos de observação, sistemas de comunicação e experimen-
tos científicos (Heunis 2014).
A carga útil a ser utilizada na missão do CONASAT-0 será um dispositivo denomi-
nado Environmental Data Collector (EDC) (Queiroz et al. 2018). Tal dispositivo tem
sido desenvolvido e aprimorado no INPE/CRN e tem como objetivo receber e decodificar
os sinais das PCDs espalhadas no território nacional e no mar. Além disso, o EDC dispo-
nibiliza as mensagens decodificadas para o OBC por meio da interface I2 C ou UART. A
verificação do funcionamento do EDC é o principal objetivo da missão CONASAT-0.
3.2 Ambiente de Desenvolvimento
A primeira versão do sistema de controle de bordo do projeto CONASAT foi elabo-

rada considerando a disponibilidade dos subsistemas apresentados anteriormente. Sendo
assim, os softwares que compõem o sistema foram desenvolvidos para assegurar a comu-
nicação entre o iOBC e os subsistemas, permitindo o gerenciamento e o armazenamento
dos dados transmitidos pelo barramento I2 C.
As etapas de testes e desenvolvimento do sistema foram realizadas com auxílio de
uma plataforma de desenvolvimento de CubeSats, a qual se encontra instalada no labo-

ratório do INPE/CRN. Além dessa plataforma, foram utilizados outros equipamentos do
laboratório, como computadores, fontes de alimentação, multímetros e equipamentos para
testes de comunicação por radiofrequência.
Os softwares foram desenvolvidos em computadores com sistema operacional Linux.
Os códigos foram transferidos para o iOBC através de um adaptador que, ao ser acoplado
ao iOBC, oferece uma interface de comunicação USB/Serial com o PC. O diagrama da
Figura 3.2 representa a comunicação entre o iOBC e o computador utilizado para desen-
volvimento de códigos e aplicações.
Figura 3.2: Diagrama de comunicação iOBC-Computador

USB/Serial
iOBC Adaptador Computador
Considerando a flexibilidade no desenvolvimento do software e as características cita-

das anteriormente, o Linux embarcado foi escolhido como sistema operacional a ser utili-
zado no iOBC. Desse modo, esse sistema foi instalado em um cartão SD que em seguida
foi acoplado a um dos slots disponíveis no iOBC. Foi utilizada uma distribuição Linux
que compõe um framework de código aberto específico para criação de softwares de voo
para satélites (KUBOS 2019a). Além da distribuição Linux, tal framework oferece APIs
(Application Programming Interface) para subsistemas, pacotes de protocolos de comu-
nicação, kit de desenvolvimento de software (SDK, do inglês, Software Development Kit)
e documentação para desenvolvedores.
A distribuição Linux instalada no iOBC possui suporte às linguagens de programação
C/C++ e Rust, a qual é uma linguagem relativamente nova que possui entre suas caracte-
rísticas segurança de memória e garantia, recursos de tratamento de erros irrecuperáveis,
suporte para programação concorrente e tipos de dados complexos (Jones 2018). Essa
linguagem permite ainda a integração com funções e códigos escritos na linguagem C
(Klabnik & Nichols 2018). Segundo Javanainen (2016), devido a suas características que
buscam eliminar muitos erros comuns em códigos escritos em C, a linguagem Rust pode
ser uma boa escolha para o desenvolvimento de softwares para nanossatélites. Uma vez
que muitos serviços disponíveis no framework utilizado foram desenvolvidos em Rust, a
primeira versão do sistema de controle de bordo do CONASAT-0 foi desenvolvida com
base nessa linguagem. Sendo assim, buscou-se aproveitar ao máximo as ferramentas e
APIs do framework de modo a tornar o tempo de desenvolvimento do software menor.
3.2.1 Plataforma de Desenvolvimento
O laboratório do projeto CONASAT possui algumas plataformas de desenvolvimento

que dão suporte para realização de testes com subsistemas do CubeSat. Entre essas pla-
taformas, tem-se um modelo de desenvolvimento 2U (Figura 3.3) que está equipado, na
parte superior, com o iOBC da ISIS e alguns dos subsistemas apresentados anteriormente.
Na parte inferior do modelo, está acoplado um transponder desenvolvido no INPE/CRN.
Essa plataforma foi utilizada durante os testes e o desenvolvimento da primeira versão do
sistema de controle de bordo do CONASAT-0.
3.2.2 Framework para Software de Voo
Arquitetura
Na Figura 3.4, pode ser observada a arquitetura do framework utilizado. A camada

de mais baixo nível corresponde ao hardware do OBC, que neste caso é o iOBC. A ca-
mada do sistema operacional se encarrega do gerenciamento dos recursos do hardware
e possui os drivers para os periféricos do iOBC. A camada de serviços oferece um con-
junto de serviços que permite ao usuário a realização de tarefas típicas do software de
voo, como armazenamento de telemetria, gerenciamento de arquivos e interação com
hardware. Acima dessa camada estão as aplicações de missão, que correspondem aos
programas do usuário que são específicos da missão, como por exemplo: aplicações para
Figura 3.3: Plataforma de desenvolvimento
monitoramento de energia do sistema e para envio de telemetria para estações de controle

da missão (KUBOS 2019b).
Figura 3.4: Arquitetura do Framework
Aplicações de Missão
Serviços
Sistema Operacional
Hardware do OBC
Fonte: Adaptado de (KUBOS 2019b)
Os serviços funcionam como endpoints HTTP que recebem requisições por linguagem
de consulta (GraphQL 2019) e retornam respostas em JSON (JavaScript Object Notation)
(KUBOS 2019b). Desse modo, os programas desenvolvidos por usuários podem se comu-
nicar com os serviços para obter e armazenar informações. Entre esses serviços, tem-se
o serviço de banco de dados de telemetria, o qual pode ser utilizado para inserir e coletar
dados de um banco de dados leve e rápido (SQLite 2019) que se encontra implementado
no sistema operacional.
Software Development Kit
O framework possui um SDK para desenvolvimento, compilação e transferência de

códigos para o sistema Linux instalado no iOBC. Esse SDK é composto por um ambiente
de desenvolvimento em máquina virtual (Vagrant 2019) que contém as ferramentas e bi-
bliotecas necessárias para construção de projetos. Com auxílio das ferramentas do SDK
é possível executar a cross-compilação dos códigos escritos em C ou em Rust. Uma vez
que os códigos são cross-compilados, o arquivo binário resultante da operação pode ser
transferido para o iOBC por meio do adaptador citado anteriormente. O acesso ao SDK e
sua utilização acontece por meio do terminal Linux do computador utilizado para o desen-
volvimento do sistema de controle de bordo. Na Figura 3.5, observa-se a interação entre
o usuário, o SDK e o sistema operacional do OBC.
Figura 3.5: SDK
Fonte: Adaptado de (KUBOS 2019c)
A transferência de arquivos e o acesso ao sistema Linux do iOBC ocorrem através

do adaptador citado anteriormente com a utilização de um programa para comunicação
serial chamado minicom (Ubuntu 2019). Uma vez estabelecida a comunicação, é feito o
login no sistema com nome de usuário e senha pré-definidos. Em seguida, o usuário pode
utilizar os recursos do Linux embarcado no iOBC.
3.3 Sistema de Controle de Bordo
A primeira versão do sistema de controle de bordo, desenvolvida neste trabalho, é

composta pelo computador de bordo iOBC com Linux embarcado e por aplicações de
missão que executam tarefas específicas, como armazenamento e leitura de informações
dos subsistemas que compõem o nanossatélite.
O processo de inicialização do sistema começa assim que o iOBC é alimentado por
uma fonte de energia elétrica (como por exemplo, o EPS). Nesse momento, o bootloader
presente na memória Flash NOR carrega o U-Boot (Universal Boot Loader) – bootloa-
der específico para dispositivos embarcados – da memória Flash NOR para a memória
SDRAM. O U-Boot, por sua vez, carrega o kernel do sistema operacional, instalado no
cartão SD, na SDRAM. Além disso, esse bootloader fornece uma interface de linha de
comando (CLI, do inglês, Command-Line Interface) que permite a depuração e configu-
ração do kernel antes que ele seja carregado na memória SDRAM. Após esse processo,
o Linux embarcado é capaz de executar aplicações que tenham sido configuradas para
iniciar após o boot do sistema.
As aplicações foram desenvolvidas com baixa dependência, segundo a técnica de to-
lerância a falhas por arquitetura modular. Na Figura 3.6, observa-se um exemplo de im-
plementação da arquitetura modular. As aplicações HK-APP, MODE-APP, e TT&C-APP
correspondem a softwares desenvolvidos separadamente e que são executados concorren-
temente pelo sistema operacional.
Figura 3.6: Arquitetura modular
3.3.1 Modos de Operação
O CONASAT têm sido projetado para operar em seis modos distintos:
• Safe: modo de segurança ativado sempre que ocorrer algum problema no satélite;
• Idle: modo de funcionamento padrão;
• Detumbling: modo para atenuar o momento angular do satélite;
• Nominal: modo de operação com todas as funcionalidades ativas (ADCS, carga útil,
etc);
• Payload: modo em que apenas a carga útil permanece ativa;
• ADCS1 : modo de operação apenas do ADCS.
As transições entre os modos de operação são apresentadas na Tabela 3.2. Nessa ta-
bela, TC caracteriza a mudança de estados por meio de telecomandos. Na primeira versão
do sistema de controle de bordo foi testada apenas transições por telecomando. Con-
tudo, o CONASAT-0 deve ser capaz de mudar para o modo Safe automaticamente, caso o
sistema detecte alguma falha ou alguma condição crítica para o sistema, como por exem-
plo, níveis de tensão menores do que o necessário para manter o correto funcionamento
do satélite. Cada modo apresentado na tabela foi implementado como uma aplicação de
missão.
1 Ao longo deste trabalho, o modo de operação será grafado em itálico para evitar confusão com o
subsistema ADCS.
Tabela 3.2: Transição entre os modos de operação.
DE PARA
Safe Idle Detumbling Nominal Payload ADCS
Safe - Tc Tc Tc Tc Tc
Idle Tc - Tc Tc Tc Tc
Detumbling Tc Tc - Tc Tc Tc
Nominal Tc Tc Tc - Tc Tc
Payload Tc Tc Tc Tc - Tc
ADCS Tc Tc Tc Tc Tc -
3.3.2 Aplicações Principais
A princípio, foram desenvolvidas três aplicações principais: HK-APP, MODE-APP e

TT&C-APP. Essas aplicações constituem o núcleo do sistema de controle de bordo e de-
sempenham funções específicas. A maneira como as três aplicações principais interagem
com o banco de dados pode ser observada na Figura 3.7. A aplicação HK-APP apenas
insere dados de housekeeping – dados de “saúde” do sistema – no banco, enquanto a
aplicação TT&C-APP coleta e insere dados para alteração do modo de operação do na-
nossatélite. A aplicação MODE-APP armazena o modo de operação inicial e coleta os
modos alterados pela TT&C-APP.
Figura 3.7: Interação entre aplicações e banco de dados
HK-APP TT&C-APP
DB
MODE-APP
A HK-APP se encarrega da obtenção do housekeeping do EPS e do TT&C e do arma-

zenamento dessas informações no banco de dados disponível no sistema operacional. Na
Tabela A.1 do Apêndice A, estão descritos os dados de housekeeping manipulados por
essa aplicação.
A aplicação MODE-APP tem a função de controlar os modos de operação do CONA-
SAT-0. Para isso, ao iniciar, a aplicação limpa os modos anteriormente salvos no banco
de dados e em seguida insere o modo Safe para que o nanossatélite opere nesse modo
assim que é ligado. Após a inicialização, a aplicação passa a verificar a cada 30 segundos
o modo armazenado no banco de dados, o qual pode ser alterado pela TT&C-APP ao
receber telecomando específico. Caso o modo no banco seja diferente do modo atual,
uma função é chamada para que possa ser encerrada a aplicação correspondente ao modo
atual. Em seguida, é iniciada a aplicação correspondente ao modo coletado no banco de
dados. Mais detalhes serão apresentados no próximo Capítulo.
A aplicação TT&C-APP foi desenvolvida para tratar os telecomandos recebidos por
radiofrequência pelo subsistema TT&C. Quando um telecomando válido é recebido, essa
aplicação armazena ou coleta dados do banco de dados e retorna o dado solicitado ou
alguma mensagem de erro ou uma mensagem que indica que um modo de operação foi
salvo no banco. Os possíveis telecomandos e os dados de telemetria retornados podem
ser verificados na Tabela A.2 do Apêndice A.
As aplicações principais foram implementadas com uma estrutura de laço infinito.
Sendo assim, as instruções são executadas repetidamente pelo sistema e podem ser finali-
zada com a utilização de comandos específicos do sistema operacional Linux.
3.3.3 Aplicações de Modos de Operação
Considerando os modos de operação do nanossatélite (Tabela 3.2), foram desenvolvi-

das cinco aplicações: IDLE-MODE-APP, DET-MODE-APP, ADCS-MODE-APP, PLD-
MODE-APP e NOM-MODE-APP. Essas aplicações correspondem, respectivamente, aos
modos Idle, Detumbling, ADCS, Payload e Nominal. No modo Safe, permanecem ativas
apenas as aplicações principais. Quando o modo é alterado por telecomando, a aplicação
correspondente é iniciada e permanece ativa em conjunto com as aplicações principais.
Na primeira versão do sistema de controle de bordo, as aplicações de modos de ope-

ração foram implementadas apenas para o teste da transição dos modos. Sendo assim,
elas não desempenham nenhuma ação no sistema. Contudo, a estrutura do código pode
ser reutilizada para o desenvolvimento futuro dos modos de operação do CONASAT-0.
Essas aplicações podem ser executadas no boot do sistema ou inicializadas por um pro-
cesso (programa em execução). No primeiro caso, a aplicação apenas inicializa e finaliza
sem executar nenhuma função. No segundo caso, foi implementada uma estrutura em
laço infinito que mantém a aplicação em execução até que ela seja finalizada por algum
comando do sistema operacional ou de alguma das aplicações principais. Essa estrutura
de laço pode ser reutilizada para inclusão de funções específicas para cada modo de ope-
ração.
Capítulo 4
Experimentos e Resultados
Este Capítulo irá apresentar os experimentos executados neste trabalho, bem como
os resultados obtidos. Todos os experimentos foram realizados no laboratório do projeto
CONASAT, localizado no INPE/CRN. Na Figura 4.1, podem ser verificados os disposi-
tivos utilizados durante os testes, bem como as interfaces de comunicação entre cada um
deles.
Figura 4.1: Esquema utilizado durante os testes
UHF/VHF
SDR 2U
USB USB/Serial
PC-I PC-II
O PC-I foi utilizado para o envio de telecomando através do SDR e para exibição dos
dados de telemetria recebidos por esse rádio. Para isso, foi utilizado um software especí-
fico fornecido pela ISIS, que permite a configuração das frequências de transmissão UHF
CAPÍTULO 4. EXPERIMENTOS E RESULTADOS 41
e recepção VHF do SDR. Ademais, o software também possibilita o envio das mensagens
de telecomando e a visualização das mensagens de telemetria por meio de uma interface
gráfica. Para comunicação do PC-I com o SDR foi utilizado um cabo USB.
Na Figura 4.1, o 2U corresponde à plataforma de desenvolvimento apresentada no
Capítulo 3. A comunicação do 2U com o SDR acontece por radiofrequência (assim como
quando o nanossatélite está em órbita), de modo que os telecomandos são recebidos na
faixa UHF e as telemetrias são enviadas na faixa VHF. O subsistema responsável por essa
comunicação é o TT&C.
O PC-II foi utilizado para comunicação e interação com o 2U, mais especificamente
com o iOBC. Para isso, foi utilizada a interface USB/Serial oferecida pelo adaptador
citado no Capítulo anterior.
4.1 Testes dos Subsistemas de Energia e Comunicação
Após a instalação e configuração do sistema Linux no iOBC, foram realizados tes-

tes iniciais para verificação do funcionamento do EPS e do TT&C. Sendo assim, foram
utilizadas APIs para esses subsistemas, as quais fazem parte do framework citado anteri-
ormente. Essas APIs utilizam um driver I2 C que possui funções bloqueadas por semáforo.
Esse mecanismo do driver I2 C permite que o barramento seja compartilhado de maneira
segura pelas aplicações desenvolvidas pelo usuário. Uma vez que essas APIs foram im-
plementadas em C, os primeiros códigos de testes foram também escritos em C com o
intuito de validar o funcionamento das funções disponíveis. Os binários gerados após
a compilação desses códigos foram transferidos para o iOBC e executados por meio do
terminal do minicom.
Inicialmente, foram testadas as funções presentes na API do EPS. Para esse teste, foi
implementado um código em C encarregado de: inicializar a comunicação I2 C entre o
iOBC e o EPS; e utilizar uma função para obtenção da tensão e da temperatura da bateria
do subsistema. Ao fim do teste, o valor da tensão foi comparado ao valor medido com
um multímetro e verificou-se que ambos correspondiam. O resultado pode ser verificado
na Figura 4.2, que representa as mensagens exibidas no terminal de comunicação com o
iOBC.
Figura 4.2: Teste tensão do sistema
Um segundo código em C foi implementado com o intuito de testar a API do TT&C.

Durante esse teste, verificou-se que a API foi desenvolvida para um hardware TT&C mais
atual do que aquele disponível no INPE/CRN. Desse modo, foram realizadas algumas
adaptações no código da API para que fosse possível a sua utilização com o subsistema
disponível no laboratório do projeto CONASAT. Com o código implementado, buscou-se
validar a comunicação I2 C entre o iOBC e os dois microcontroladores do TT&C, bem
como a aquisição de dados do subsistema através de comandos I2 C. Além disso, foi utili-
zada uma função da API responsável pelo envio de telemetria por radiofrequência. Ao ser
executado, esse código inicializou a comunicação I2 C entre o iOBC e o TT&C, obteve o
valor da tensão no barramento de alimentação desse subsistema e enviou essa informação
para o SDR. A telemetria foi, então, exibida no software do SDR instalado no PC-I. O
resultado desse teste é apresentado na Figura 4.3.
Figura 4.3: Teste do subsistema TT&C
Após a conclusão do teste inicial do TT&C, um outro programa foi criado para que
pudesse ser testado o envio de telecomandos à plataforma de desenvolvimento. Nesse
programa, foi utilizada uma função da API do TT&C encarregada da requisição, via I2 C,
dos dados recebidos pelo TT&C por radiofrequência. Na Figura 4.4, pode ser observado
o fluxo de execução do programa. Inicialmente, uma função responsável por estabelecer a

comunicação I2 C entre o iOBC e o EPS é chamada. Caso ocorra alguma falha, uma men-
sagem de erro é exibida no terminal e o programa é finalizado. Caso a comunicação seja
estabelecida com sucesso, é chamada uma função para inicialização da comunicação I2 C
entre o iOBC e o TT&C. Uma falha nessa inicialização acarreta na exibição de uma men-
sagem de erro no terminal e, em seguida, o programa é finalizado. Quando ocorre sucesso
na inicialização da comunicação, espera-se 5 segundos até a verificação do recebimento
de telecomando. Caso nenhum telecomando tenha sido recebido, uma mensagem de erro
é exibida e o programa termina. Quando um telecomando é recebido, ele é comparado
com os valores “101” e “102”. Caso seja igual a “101”, o iOBC requisita do EPS, por
I2 C, o valor da tensão da bateria. Esse valor é então enviado para o TT&C que, por sua
vez, envia-o para o SDR por radiofrequência. Caso o telecomando seja igual a “102”, o
iOBC solicita o valor da temperatura da bateria do EPS via I2 C e o envia para o TT&C
que o transmite para o SDR. Caso o telecomando seja diferente dos valores descritos
anteriormente, a telemetria enviada ao SDR é “Telemetria Invalida”.
Embora os primeiros códigos tenham sido desenvolvidos em C, os principais serviços
e APIs do framework foram escritos em Rust. Desse modo, as APIs do EPS e do TT&C
foram adaptadas para o uso em Rust. Para isso, foi utilizado um mecanismo chamado
interface de função externa (FFI, em inglês, Foreign Function Interface), que permite o
uso de códigos C em Rust (The Rust Team 2019). Para a validação das APIs adaptadas, os
códigos descritos anteriormente foram reescritos em Rust e foram realizados testes seme-
lhantes aos anteriores. Após os testes, concluiu-se que os programas escritos em Rust se
comportaram de maneira similar àqueles implementados em C, inclusive no que se refere
ao tempo de execução. Contudo, uma desvantagem observada diz respeito ao tamanho
dos executáveis gerados após a compilação dos códigos. Por exemplo, um executável em
Rust com a mesma funcionalidade de um executável em C tem um tamanho quase 70 ve-
zes maior. Apesar disso, o uso do Rust se justifica pelos recursos de tratamento de erros
Figura 4.4: Execução programa EPS
Início
Inicia comunicação I2 C com EPS
Exibe mensagem N Inicialização

de erro no terminal OK?
Inicia comunicação I2 C com TT&C
Inicialização
N OK?
S
Espera 5 segundos
Telecomando
N Recebido?
Telecomando S
Telemetria = tensão da bateria
= "101"?
Telecomando S
Telemetria = temperatura da bateria
= "102"?
N
Telemetria = Telecomando Invalido
Envia Telemetria
Finaliza comunicação I2 C
Fim
e segurança de memória que a linguagem oferece, o que caracteriza elementos importan-

tes do sistema de controle de bordo em nanossatélites. Ademais, o cartão SD do iOBC
apresenta um espaço disponível superior a 3 gigabytes, enquanto as maiores aplicações
desenvolvidas neste trabalho apresentaram, em média, 58 megabytes.
Na Figura 4.5, tem-se o resultado da execução da versão em Rust do programa re-
presentado na Figura 4.4. Na Figura 4.5a, são apresentadas a mensagens exibidas no
terminal minicom, as quais foram utilizadas para depuração do código. As mensagens da
Figura 4.5b representam os dados recebidos por radiofrequência, visualizados por meio
do software do SDR.
Figura 4.5: Teste subsistemas EPS e TT&C (código Rust)

(a) Terminal iOBC (b) Telemetria recebida por radiofrequência
4.2 Teste das Aplicações HK-APP e TTEC-APP
Os testes dos subsistemas EPS e TT&C serviram como base para implementação, em
Rust, das aplicações de missão da primeira versão do sistema de controle de bordo. A
aplicação HK-APP foi a primeira a ser implementada e o seu funcionamento foi verifi-
cado a partir da análise do banco de dados. Uma vez que o sistema operacional se en-
contra instalado no cartão SD, as informações no banco continuam armazenadas mesmo

após o desligamento do sistema. Desse modo, a aplicação foi criada para armazenar um
conjunto de informações a cada sessenta segundos e, em seguida, foi executada por al-
guns minutos na plataforma de desenvolvimento. O sistema foi então desligado e o cartão
SD foi inserido no PC-II para que fosse feita a análise do banco. Na Figura 4.6, tem-se
parte dos dados presentes no banco de dados ao final do teste. Nessa figura, os valores
da coluna timestamp são interpretados como segundos fracionários (fractional seconds) e
representam o instante de tempo em que os dados foram inseridos no banco. Observa-se
que, como os dados foram armazenados em conjuntos, várias entradas possuem o mesmo
timestamp. A coluna subsystems contém o nome do subsistema a que corresponde cada
informação e as entradas da coluna value variam de acordo com o parâmetro (para mais
detalhes, consulte o Apêndice A).
Figura 4.6: Teste HK-APP

A partir da análise do banco de dados, verificou-se que as informações foram corre-

tamente armazenadas no intervalo de tempo especificado. Com isso, foi desenvolvida a
aplicação TT&C-APP, a qual foi utilizada para o tratamento dos telecomandos enviados à
plataforma 2U. Inicialmente, essa aplicação foi executada enquanto a aplicação HK-APP
permanecia desativada. Desse modo, buscou-se obter, do banco de dados, as informações
resultantes da última execução da aplicação HK-APP (Figura 4.6). Durante o teste, o
software do SDR foi utilizado para o envio dos telecomandos e para a visualização das
telemetrias recebidas. O resultado desse teste pode ser observado na Figura 4.7, onde
estão destacados, em vermelho, os telecomandos enviados (para mais detalhes, consulte
o Apêndice A). Por meio dessa figura, observa-se que o envio do telecomando EPSP01
resultou na aquisição do valor contido na segunda linha da tabela apresentada na Figura
4.6. Ademais, o envio dos telecomandos EPSP00, EPSP20, EPSP19 e EPSP17 resultou
nas telemetrias das linhas 1, 21, 20 e 18, respectivamente.
Figura 4.7: Teste TT&C-APP
Após esse teste, o código da aplicação TT&C foi alterado para transmitir, como te-
lemetria, um conjunto de trinta dados por telecomando recebido, ao invés de apenas um
dado por telecomando. Assim, foi realizado um experimento onde as aplicações HK-
APP e TT&C-APP foram executadas de maneira concorrente. Durante o experimento,
foram requisitados os dados de corrente e tensão da bateria a cada trinta minutos. Dada
a alteração no código da aplicação TT&C e uma vez que a aplicação HK-APP foi confi-
gurada para armazenar dados no banco a cada minuto, as telemetrias recebidas no SDR
correspondem às informações armazenadas no banco nos trinta minutos anteriores a cada
requisição por telecomando. O tempo total do experimento foi quatro horas e trinta mi-
nutos e, ao final, verificou-se que a corrente na bateria apresentou um valor médio de 72
mA e a tensão teve um decaimento aproximado de 1 mV por minuto. Na Figura 4.8, po-
dem ser visualizados alguns dos conjuntos de dados obtidos em instantes diferentes, bem
como o parâmetro correspondente (tensão ou corrente).
Figura 4.8: Teste tensão e corrente do sistema
4.3 Teste da MODE-APP e de Modos de Operação
Para o teste da aplicação MODE-APP, todas as aplicações foram configuradas para

serem executadas após o boot do sistema operacional e a aplicação TT&C-APP foi alte-
rada para transmitir, por telemetria, apenas um dado por telecomando recebido. Sendo
assim, de acordo com a descrição apresentada no Capítulo 3, após o boot, as aplicações

de modos de operação inicializaram e finalizaram sem desempenhar ações no sistema. No
que se refere às operações principais, elas permaneceram em execução graças à estrutura
de laço infinito implementada.
Com as aplicações MODE-APP, TT&C-APP e HK-APP em execução, foram envia-
dos, sequencialmente, telecomandos específicos para alteração do modo de operação do
satélite. Inicialmente, foi enviado um telecomando para obtenção do modo de operação
em execução após o boot do sistema. Como esperado, a telemetria retornada indicou o
modo Safe. Em seguida, o modo foi alterado, por telecomando (MODE01), para Idle e
foi verificado o modo em execução por meio do telecomando GETM. O procedimento foi
repetido com a alteração e a checagem dos seguintes modos em sequência: Detumbling,
ADCS, Payload, Nominal. Após essas alterações, foi enviado o telecomando MODE06,
que não faz parte do sistema e, por esse motivo, foi retornada a telemetria "Modo In-
valido". Por fim, o modo foi alterado para Safe (MODE00) e o teste foi finalizado. A
sequência de dados de telemetria e telecomando, transmitidos durante o teste, pode ser
observada na Figura 4.9a. Na Figura 4.9b, tem-se parte das mensagens visualizadas no
software do SDR.
No Capítulo 3 foi descrita a aplicação MODE-APP. Essa aplicação controla os mo-
dos de operação e fica encarregada de finalizar e inicializar as aplicações referentes aos
modos. Para inicialização das aplicações, foi utilizado um dos serviços oferecidos pelo
framework. Quando uma aplicação é inicializada pelo serviço de aplicações, ela se torna
um processo do sistema e o número do processo (PID, Process Identification) pode ser
obtido. O PID pode então ser utilizado para “matar” a aplicação por meio do comando kill
-9 PID. Sendo assim, no código da MODE-APP foi incluída uma função responsável por
encerrar as aplicações através do comando citado. Logo, ao verificar que o modo armaze-
nado no banco é diferente do atual, a função é chamada para “matar” a aplicação referente
ao modo anterior e, em seguida, é chamada a função para inicializar a aplicação corres-
Figura 4.9: Teste MODE-APP e modos de operação

(a) Sequência de dados (b) Resultado modos de operação
pondente ao modo atual. As aplicações de modo de operação foram configuradas para

executar repetidamente (laço infinito) quando inicializadas pelo serviço do framework e,
ao serem finalizadas pela função especificada, elas geram processos em estado “zumbi”.
Na Figura 4.10, pode ser observada a lista de processos do sistema embarcado no
iOBC após a realização do experimento representado pela Figura 4.9.
Figura 4.10: Lista de processos
Os asteriscos na Figura 4.10 indicam as aplicações de missão inicializadas após o boot

do sistema. Observa-se que, uma vez que essas aplicações finalizaram, elas se tornaram
processos em estado “zumbi” (indicado pela letra “Z” na lista). Os processos “zumbi”
marcados com “x” representam as aplicações inicializadas e finalizadas pela MODE-APP
com auxílio do serviço do framework, ou seja, os processos decorrentes das mudanças de
estados realizadas durante o teste (de acordo com a Figura 4.9a). Além disso, percebe-se
que os processos correspondentes às aplicações principais encontravam-se ativos (núme-
ros 345, 354 e 363 na Figura 4.10) no momento do teste. Sendo assim foi possível verificar
a execução das aplicações sem a ocorrência de falhas no compartilhamento do barramento

I2 C, graças ao mecanismo de semáforo citado anteriormente.
De acordo com Tanenbaum & Woodhull (2008), o estado “zumbi” ocorre quando
um processo é eliminado e o processo “pai” – aquele que o inicializou – não executa a
chamada de sistema conhecida como wait. Nesse estado, o processo continua na tabela
de processos do sistema, mas sua memória é liberada. Sendo assim, não há consumo de
recursos do sistema por parte do processo em estado “zumbi”. Porém, processos desse
tipo, quando em número elevado, podem gerar problemas para memória RAM (Barnes
2018), uma vez que informações da tabela de processos são armazenadas nessa memória.
Neste trabalho, não foram desenvolvidas técnicas para tratar desses processos, uma vez
que a quantidade de “zumbis” gerados no sistema desenvolvido é pequena, considerando
que, quando o satélite está em órbita, as alterações dos modos de operação não acontece
de maneira tão frequente. Tais alterações são realizadas em momentos específicos de
acordo com os requisitos da missão. Apesar disso, a seguir, tem-se possíveis soluções
para o tratamento dos processos em estado “zumbi”:
1. Reinicialização do sistema quando forem detectados um grande número de proces-

sos em estado “zumbi”;
2. Finalização do processo “pai”.
No sistema de controle de bordo desenvolvido, o processo “pai” de todas as aplicações

implementadas é o serviço de aplicações do framework utilizado (processo número 332
na Figura 4.10). Desse modo, a solução apresentada no item 2 não é considerada viável,
uma vez que, ao finalizar esse serviço, todas as aplicações são também finalizadas. Uma
outra maneira de contornar o problema seria manter todas as aplicações sempre ativas,
sem que para mudar o modo de operação fosse necessário matá-las. Para isso, o código
das aplicações de modos de operação deve ser mais robusto, contendo instruções que são
executadas apenas quando determinado modo é selecionado. Por exemplo, a escolha do
modo Safe permitiria a execução de todas as aplicações de modos de operação. Contudo,

todas elas estariam executando instruções que não desempenham ações no sistema (como
por exemplo, um loop que apenas checa o modo atual). Caso fosse selecionado o modo
Idle, a aplicação correspondente a esse modo passaria a desempenhar ações no sistema
por meio da execução de instruções específicas. Embora essa abordagem solucione o
problema, ela pode gerar aplicações que consomem recursos de memória e processador,
pois são mantidas em execução mesmo sem desempenhar ações no sistema de controle de
bordo.
4.4 Produção Intelectual
As pesquisas e testes, realizados durante a execução deste trabalho, foram utilizados

como base para elaboração de trabalhos para apresentação em congressos. A seguir, estão
dispostos os trabalhos aceitos para publicação em anais de congresso:
• ALVES, A. C. R; DIAS, S. M.; QUEIROZ, K. I. P. de M.; DUARTE, J. M. L.;

CARVALHO, M. J. M. CONASAT-0: Visão Geral do Nanossatélite Desenvolvido.
II Congresso Aerospacial Brasileiro, 2019.
• ALVES, A. C. R; DIAS, S. M.; QUEIROZ, K. I. P. Desenvolvimento de um Sistema
para Controle de Bordo de Nanossatélite. XIV Simpósio Brasileiro de Automação
Inteligente, 2019.
Capítulo 5
Conclusões e Proposições Futuras
Nesta dissertação, foi apresentada a primeira versão do sistema de controle de bordo

desenvolvido para o CubeSat CONASAT-0. Nessa versão, foram implementadas aplica-
ções principais responsáveis pelo armazenamento de informações de “saúde” (houseke-
eping) do satélite, pela alteração dos modos de operação e pela transmissão, recepção e
tratamento de telecomandos e telemetrias. Tais aplicações constituem o núcleo do sis-
tema e deverão ser utilizadas em conjunto com as futuras aplicações desenvolvidas para
CONASAT-0.
Para o monitoramento de tensão e corrente no nanossatélite, foram utilizados os recur-
sos da API do EPS. Além disso, a aplicação HK-APP foi implementada para armazenar
os dados de tensão, corrente e housekeeping no banco de dados do sistema operacional.
Para isso, utilizou-se o serviço de banco de dados de telemetria do framework utilizado.
O gerenciamento das informações dos subsistemas foi executado através da comuni-
cação I2 C e por meio dos serviços disponíveis no framework. A interação com os serviços
ocorreu por protocolo HTTP com o uso de requisições por linguagem de consulta.
Com o intuito de minimizar os erros decorrentes da radiação, foi adotada a técnica
de tolerância a falhas por arquitetura modular. Sendo assim, com a baixa dependência
entre as aplicações, buscou-se evitar a propagação de erros entre as diversas aplicações
do sistema. Essa abordagem contribuiu ainda para o desenvolvimento do sistema, uma
vez que: permitiu a inserção de novas aplicações no sistema; possibilitou a substituição
CAPÍTULO 5. CONCLUSÕES E PROPOSIÇÕES FUTURAS 55
ou exclusão de aplicações; e permitiu a atualização das aplicações sem a necessidade de

grandes alterações nos códigos.
Neste trabalho, foram ainda desenvolvidas aplicações para testes dos modos de ope-
ração e, embora elas não desempenhem ações no sistema, a estrutura de código pode ser
reutilizada para implementação das funcionalidades específicas de cada modo de ope-
ração a ser desenvolvido. Os processos em estado “zumbi”, gerados pela execução e
finalização das aplicações de modos de operação, não foram tratados neste trabalho por
não apresentarem grandes problemas para a primeira versão do sistema de controle de
bordo.
Ao final dos testes, verificou-se que os recursos e APIs oferecidas pelo framework
tornaram o tempo de desenvolvimento do trabalho menor, uma vez que não foi necessária
a implementação de drivers para os subsistemas utilizados na plataforma de desenvol-
vimento. Além disso, foi verificada a possibilidade de execução de várias aplicações
concorrentemente sem a ocorrência de problemas de compartilhamento do barramento
I2 C.
5.1 Proposições Futuras
Embora neste trabalho tenha sido desenvolvida uma estrutura base para o sistema de
controle de bordo do CONASAT-0, ainda precisam ser realizados testes, atualizações e
melhoramentos nos softwares que compõem o controle de bordo. Assim, busca-se a ob-
tenção de um sistema cada vez mais robusto e tolerante a falhas acarretadas pelos efeitos
da radiação nos componentes eletrônicos do satélite em órbita. Desse modo, como pro-
posições futuras, tem-se:
• Implementar uma aplicação para carga útil e verificar o seu funcionamento;

• Adicionar uma aplicação para monitoramento da memória utilizada no sistema e do
espaço livre em disco;
CAPÍTULO 5. CONCLUSÕES E PROPOSIÇÕES FUTURAS 56
• Utilizar outras técnicas de tolerância a falhas por software;

• Implementar instruções de código para mudança do modo de operação quando de-
tectada condição crítica no sistema;
• Aplicar estratégia para tratamento dos processos em estado “zumbi”;
• Analisar uma melhor formatação para mensagens de telemetria e telecomando, de
modo a evitar um alto consumo de energia por parte do subsistema de telemetria e
telecomando.
Referências Bibliográficas
Anderson, Brian J. & Donald G. Mitchell (2005), The space environment, em V.Pisacane,
ed., ‘Fundamentals of Space Systems’, Applied Physics Laboratory series in science
and engineering, Oxford University Press.
AsciiTable (2018), ‘Ascii table and description’, http://www.asciitable.com/. Acesso em:

30 nov. 2018.
Barnes, Ricky (2018), ‘What is zombie process in linux’, https://

www.tutorialspoint.com/what-is-zombie-process-in-linux. Acesso
em: 03 set. 2019.
Barry, R. (2016), Mastering the FreeRTOS Real Time Kernel: A Hands-On Tutorial
Guide, Real Time Engineers Ltd.
CalPoly (2015), ‘Cubesat design specification rev. 13’.

URL: http://www.cubesat.org/s/cds_rev13_final2.pdf
Carrara, Valdemir, Hélio Koiti Kuga, Philipe Massad Bringhenti & Manoel J. M. de Car-
valho (2014), Attitude determination, control and operating modes for conasat cube-
sats, em ‘Proceedings...’, International Symposium on Space Flight Dynamics, 24.
(ISSFD). Setores de Atividade: Pesquisa e desenvolvimento científico.
URL: https://dnnpro.outer.jhuapl.edu/issfd2014/Agenda.aspx
Carrara, Valdemir, Rafael Barbosa Januzi, Daniel Hideaki Makita, Luis Felipe de Paula
Santos & Lidia Shibuya Sato (2017), ‘The itasat cubesat development and design’,
Journal of Aerospace Technology and Management 9(2), 147–156.
57
REFERÊNCIAS BIBLIOGRÁFICAS 58
Carvalho, M. J. M. de, J. S. dos S. Lima, L. dos S. Jotha & P. S. de Aquino (2013), Conasat
- constelação de nano satélites para coleta de dados ambientais, em J. C. N.Epiphanio
& L. S.Galvão, eds., ‘Anais...’, Simpósio Brasileiro de Sensoriamento Remoto, 16.
(SBSR), Instituto Nacional de Pesquisas Espaciais (INPE), São José dos Campos,
pp. 9108–9115.
URL: http://urlib.net/dpi.inpe.br/marte2/2013/05.29.00.50.13
CGEE (2018), Cubesats, Resumo executivo, Centro de Gestão e Estudos Estratégicos,

Brasília, DF.
Chandra, A. & J. Thangavelautham (2018), ‘De-orbiting small satellites using inflatables’,

arXiv preprint arXiv:1809.04459 .
Chin, K. B., E. J. Brandon, R. V. Bugga, M. C. Smart, S. C. Jones, F. C. Krause, W. C.

West & G. G. Bolotin (2018), ‘Energy storage technologies for small satellite appli-
cations’, Proceedings of the IEEE 106(3), 419–428.
Coit, David W. (2001), ‘Cold-standby redundancy optimization for nonrepairable sys-

tems’, IIE Transactions 33(6), 471–478.
URL: https://doi.org/10.1023/A:1007689912305
de Melo, Cristiano Fiorilo & Othon Cabo Winter (2007), A era espacial, em O. C. W. E.
A. F. B. D. A.Prado, ed., ‘A Conquista do Espaço do Sputnik a Missão Centenário’,
Editora Livraria da Física.
Eickhoff, J. (2011), Onboard Computers, Onboard Software and Satellite Operations: An

Introduction, Springer Aerospace Technology, Springer Berlin Heidelberg.
FreeRTOS (2019), ‘Tasks and co-routines’, https://www.freertos.org/

taskandcr.html. Acesso em: 18 ago. 2019.
Gadlage, M. J., R. D. Schrimpf, J. M. Benedetto, P. H. Eaton, D. G. Mavis, M. Sibley,

K. Avery & T. L. Turflinger (2004), ‘Single event transient pulse widths in digital
microcircuits’, IEEE Transactions on Nuclear Science 51(6), 3285–3290.
Gao, S., M. N. Sweeting, S. Nakasuka & S. P. Worden (2018), ‘Issue small satellites’,
Proceedings of the IEEE 106(3), 339–342.
Gao, S., Y. Rahmat-Samii, R. E. Hodges & X. Yang (2018), ‘Advanced antennas for small
satellites’, Proceedings of the IEEE 106(3), 391–403.
GraphQL (2019), ‘A query language for your API’, https://help.ubuntu.com/

community/Minicom. Acesso em: 23 ago. 2019.
Heunis, André Emile (2014), Design and inplementation of generic flight software for
a cubesat, Dissertação de mestrado, Department Electrical and Electronic Enginee-
ring, Stellenbosch University, África do Sul.
INPE (2011), Constelação de Nano Satélites para Coleta de Dados Ambientais: Docu-
mento de Descrição da Missão (DDM), Relatório Técnico CNS-DDM-001.
URL: http://www.crn.inpe.br/conasat1/docprojeto.php
INPE (2012), Constelação de Nano Satélites para Coleta de Dados Ambientais: Docu-
mento de Rescrição Preliminares (DRP) - Fase A, Relatório Técnico CNS-DRP-001.
URL: http://www.crn.inpe.br/conasat1/docprojeto.php
INPE (2018), ‘Projeto conasat’, http://www.crn.inpe.br/conasat1/

projconasat.php. Acesso em: 30 out. 2018.
ISIS (2015), CONASAT DM Design Description, Documento Técnico

ISIS.CONASAT.DM.DD.
ISIS (2018), ‘Cubesats’, https://www.isispace.nl/cubesats/. Acesso em: 26 out.

2018.
ISIS (2019), ‘Isis on board computer’, https://www.isispace.nl/product/on-

board-computer/. Acesso em: 11 ago. 2019.
Jakhu, R.S. & J.N. Pelton (2014), Small Satellites and Their Regulation, SpringerBriefs
in Space Development, Springer New York.
Javanainen, Joonas (2016), Reliability evaluation of aalto-1 nanosatellite software archi-

tecture, Dissertação de mestrado, School of Science, Aalto University, Filândia.
Jones, M. T. (2018), ‘Why you should learn the rust programming language’, https:
//developer.ibm.com/articles/os-developers-know-rust/. Acesso em: 13
ago. 2019.
Klabnik, Steve & Carol Nichols (2018), The Rust Programming Language, No Starch
Press.
Koudelka, Otto (2016), Micro/nano/picosatellite-activities: Challenges towards space

education and utilisation, em I.Marboe, ed., ‘Small Satellites: Regulatory Challen-
ges and Chances’, Studies in space law, Brill Nijhoff.
Krejci, D. & P. Lozano (2018), ‘Space propulsion technology for small spacecraft’, Pro-
ceedings of the IEEE 106(3), 362–378.
KUBOS (2019a), ‘A flight software framework for satellites’, https://www.kubos.com/

kubos/. Acesso em: 12 ago. 2019.
KUBOS (2019b), ‘Kubos ecosystem’, https://docs.kubos.com/1.16.0/ecosystem/

index.html. Acesso em: 12 ago. 2019.
KUBOS (2019c), ‘Kubos sdk docs’, https://docs.kubos.com/1.16.0/sdk-docs/

Kulu, Erik (2019a), ‘Nanosatellite database’, https://www.nanosats.eu. Acesso em: 5

ago. 2019.
Kulu, Erik (2019b), ‘What is cubesat & other picosatellites’, https:

//www.nanosats.eu/cubesat.html. Acesso em: 05 ago. 2019.
LaBel, K. A., M. M. Gates, A. K. Moran, P. W. Marshall, J. Barth, E. G. Stassinopou-

los, C. M. Seidleck & C. J. Dale (1996), Commercial microelectronics technologies
for applications in the satellite radiation environment, em ‘1996 IEEE Aerospace
Applications Conference. Proceedings’, Vol. 1, pp. 375–390 vol.1.
Lumbwe, Lwabanji Tony (2013), Development of an onboard computer (obc) for a cube-
sat, Dissertação de mestrado, Faculty of Engineering, Cape Peninsula University of
Technology, África do Sul.
Madry, S., P. Martinez & R. Laufer (2018), Innovative Design, Manufacturing and Testing
of Small Satellites, Springer Praxis Books, Springer International Publishing.
Moore, Robert C. (2005), Spacecraft computer systems, em V.Pisacane, ed., ‘Fundamen-

tals of Space Systems’, Applied Physics Laboratory series in science and enginee-
ring, Oxford University Press.
Mota, David Freitas Moura (2017), Openobc: uma arquitetura de um computador de

bordo open source e de baixo custo para o padrão cubesat, Dissertação de mestrado,
Centro de Tecnologia, Programa de Pós-Graduação em Engenharia de Teleinformá-
tica, Fortaleza, Brasil.
NASA (2017), ‘Cubesat 101: Basic Concepts and

Processes for First-Time Cubesat Developers’,
https://www.nasa.gov/sites/default/files/atoms/files/nasa_csli_cubesat_101_508.pdf.
Acesso em: 3 dez. 2018.
Palkovitz, Neta (2016), Small satellites: Innovative activities, traditional laws, and the
industry perspective, em I.Marboe, ed., ‘Small Satellites: Regulatory Challenges
and Chances’, Studies in space law, Brill Nijhoff.
Queiroz, K I P M, S M Dias, J M L Duarte & M J M de Carvalho (2018), ‘Uma solução

para o sistema brasileiro de coleta de dados ambientais baseada em nanossatélites’,
HOLOS 7, 132–142.
Ratner, Paul (2018), ‘How the kessler syndrome can end all space exploration and des-
troy modern life’, https://bigthink.com/paul-ratner/how-the-kessler-
syndrome-can-end-all-space-exploration-and-destroy-modern-life.
Acesso em: 21 nov. 2018.
Razzaghi, Elyas (2012), Design and qualification of on-board computer for aalto-1 cu-
besat, Dissertação de mestrado, School of Electrical Engineering, Aalto University,
Filândia.
Rotteveel, Jeroen, Abe Bonnema & Julien Hennequin (2014), Nano-profitability - a re-
view of the financial success of nanosatellite industrial companies, em ‘Proceedings
of the AIAA/USU Conference on Small Satellites’, número SSC14-I-7.
Santos, Marcos Aurélio Ferreira dos, Maria de Fátima Mattiello Francisco & Wilson Ya-
maguti (2013), O sistema nacional de dados ambientais e a coleta de dados por
satélite, em J. C. N.Epiphanio & L. S.Galvão, eds., ‘Anais...’, Simpósio Brasileiro
de Sensoriamento Remoto, 16. (SBSR), Instituto Nacional de Pesquisas Espaciais
(INPE), São José dos Campos, pp. 9116–9123.
SQLite (2019), ‘What is SQLite’, https://www.sqlite.org/index.html. Acesso em:

23 ago. 2019.
Tanenbaum, Andrew S. & Albert S. Woodhull (2008), Sistemas Operacionais: Projeto e

Implementação, 3a edição, Bookman, Porto Alegre.
The Rust Team (2019), ‘Foreign function interface’, https://doc.rust-lang.org/

nomicon/ffi.html. Acesso em: 26 ago. 2019.
Ubuntu (2019), ‘Minicom’, https://help.ubuntu.com/community/Minicom. Acesso

em: 23 ago. 2019.
Vagrant (2019), ‘Introduction to vagrant’, https://www.vagrantup.com/intro/

Wertz, J.R. & W.J. Larson (1999), Space Mission Analysis and Design, Space Technology
Library, Springer Netherlands.
Woellert, Kirk, Pascale Ehrenfreund, Antonio J. Ricco & Henry Hertzfeld (2011), ‘Cube-
sats: Cost-effective science and technology platforms for emerging and developing
nations"’, Advances in Space Research 47(4), 663 – 684.
Apêndice A
Dados de Housekeeping, Telemetria e

Telecomando
O sistema desenvolvido neste trabalho permite a aquisição, por telemetria, de dados

de “saúde” (housekeeping) dos subsitemas que compõem o satélite. Cada dado é trans-
mitido por radiofrequência e interpretado como código ASCII, de modo que cada byte
transmitido representa um caractere segundo a tabela ASCII (AsciiTable 2018).
Para o EPS, podem ser obtidos um total de vinte e um dados. O tamanho de cada
um desses dados varia de acordo com a informação coletada. Por exemplo, a tensão da
bateria (vbatt) possui um tamanho igual a quatro bytes que juntos representam um valor
em milivolts. Por outro lado, o modo da bateria é representado por apenas um byte.
Os dados do TT&C estão em um intervalo de 0 a 1023 e podem ser convertidos para
grandezas físicas (como tensão e corrente) com auxílio de uma tabela de conversão dis-
ponível no datasheet da placa. Considerando o intervalo descrito, esses dados são repre-
sentados por até quatro caracteres ASCII, os quais correspondem a quatro bytes.
Na Tabela A.1, podem ser verificados os dados de housekeeping dos subsistemas EPS
e TT&C. Mais detalhes sobre os dados de ambos os subsistemas podem ser encontrados
nos respectivos datasheets adquiridos pelo INPE/CRN.
Na Tabela A.2, são apresentados os telecomandos que podem ser enviados por radi-
ofrequência para o satélite. Além disso, estão dispostas as telemetrias correspondentes a
APÊNDICE A. DADOS DE HOUSEKEEPING, TELEMETRIA E TELECOMANDO65
Tabela A.1: Dados de housekeeping
Subsistema Dado Descrição

vboost Tensão dos 3 conversores boost da placa em mV
[PV1, PV2, PV3]
vbatt Tensão da bateria em mV
currin Correntes de entrada em mA
currun Corrente dos conversores boost em mA
cursys Corrente de saída da bateria em mA
curout Correntes dos 6 canais de alimentação comutá-
veis em mA
output Estado das saídas [0 = desligado, 1 = ligado]
output_on_delta Tempo até a ativação da saída em segundos
EPS output_off_delta Tempo até o desligamento da saída em segun-
dos
latchup Número de latch-ups
wdt_i2c_time_left Tempo restante para o Watchdog do I2 C em se-
gundos
wdt_gnd_time_left Tempo restante para o Watchdog dedicado em
segundos
wdt_csp_pings_left Pings restantes para o Watchdog CSP
counter_wdt_i2c Número de reinicializações do Watchdog do I2 C
counter_wdt_gnd Número de reinicializações do Watchdog dedi-
cado
counter_wdt_csp Número de reinicializações do Watchdog CSP
counter_boot Número de reinicializações do EPS
temp Temperaturas em o C
boot_cause Causa da última reinicialização do EPS
batt_mode Modo da bateria
ppt_mode Modo do rastreador de ponto de potência
doppler_offset Deslocamento Doppler do sinal no receptor
signal_strength Intensidade do sinal no receptor
RF_reflected Pontência refletida do transmissor
RF_forward Potência direta do transmissor
TT&C
tx_current Consumo de corrente do transmissor
rx_current Consumo de corrente do receptor
temp_power_amp Temperatura do amplificador de potência
supply_voltage Tensão do barramento de energia
cada telecomando enviado. Caso seja enviada uma mensagem de telecomando iniciada
com “MODE” e que não se encontra na tabela, o satélite se encarrega de transmitir a te-
lemetria “Modo Invalido”. A telemetria “Telecomando Invalido” é transmitida quando o
telecomando recebido pelo TT&C é diferente de qualquer valor da tabela e, ao receber
o telecomando “GETM”, a aplicação TT&C-APP retorna o modo de operação atual do
nanossatélite. Os possíveis modos de operação podem ser alterados por telecomando, da
seguinte maneira:
• MODE00: altera para o modo de operação Safe;

• MODE01: altera para o modo de operação Idle;
• MODE02: altera para o modo de operação Detumbling;
• MODE03: altera para o modo de operação ADCS;
• MODE04: altera para o modo de operação Payload;
• MODE05: altera para o modo de operação Nominal.
Tabela A.2: Telecomando e telemetria
Subsistema Telecomando Telemetria

EPSP00 vboost
EPSP01 vbatt
EPSP02 currin
EPSP03 currun
EPSP04 cursys
EPSP05 curout
EPSP06 output
EPSP07 output_on_delta
EPSP08 output_off_delta
EPSP09 latchup
EPS EPSP10 wdt_i2c_time_left
EPSP11 wdt_gnd_time_left
EPSP12 wdt_csp_pings_left
EPSP13 counter_wdt_i2c
EPSP14 counter_wdt_gnd
EPSP15 counter_wdt_csp
EPSP16 counter_boot
EPSP17 temp
EPSP18 boot_cause
EPSP19 batt_mode
EPSP20 ppt_mode
TTEC00 doppler_offset
TTEC01 signal_strength
TTEC02 RF_reflected
TT&C TTEC03 RF_forward
TTEC04 tx_current
TTEC05 rx_current
TTEC06 temp_power_amp
TTEC07 supply_voltage
MODE00
MODE01
MODE02 "Mode saved"
OBC MODE03
MODE04
MODE05
GETM Modo de Operação

Controlebordonanossatélites Alves 2019

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Controlebordonanossatélites Alves 2019

Enviado por

Direitos autorais:

Formatos disponíveis

U NIVERSIDADE F EDERAL DO R IO G RANDE DO N ORTE

Controle de Bordo para Nanossatélites:

Alex Carlos Rodrigues Alves

Orientador: Prof. Dr. Samaherni Morais Dias

Co-orientador: Prof. Dr. Kurios Iuri Pinheiro de Melo Queiroz

Dissertação de Mestrado apresentada ao

Número de ordem PEM: M020

Alves, Alex Carlos Rodrigues.

Dissertação (mestrado) - Universidade Federal do Rio Grande

1. Controle de bordo - Dissertação. 2. INPE/CRN -

RN/UF/BCZM CDU 621.865.8

Elaborado por Ana Cristina Cavalcanti Tinôco - CRB-15/262

Ao meu irmão, Paulo Roberto, pelos conselhos e conhecimentos compartilhados.

À toda minha família e amigos pelo apoio durante esta caminhada.

Aos colegas do INPE/CRN e do projeto CONASAT pela enorme colaboração no desen-

À Coordenação de Aperfeiçomento de Pessoal de Nível Superior (CAPES), pelo apoio

Desde o lançamento da Sputnik I em 1957, a indústria de satélites experimentou gran-

Palavras-chave: Controle de bordo, INPE/CRN, CubeSat, Computador de bordo,

Keywords: On-board control, INPE/CRN, CubeSat, On-board computer, OBC, CO-

Lista de Figuras iii

Lista de Símbolos e Abreviaturas vi

5 Conclusões e Proposições Futuras 54

A Dados de Housekeeping, Telemetria e Telecomando 64

1.1 Algumas categorias de satélites de acordo com a sua massa . . . . . . . . 3

2.1 Lançamentos de nanossatélites . . . . . . . . . . . . . . . . . . . . . . . 17

3.1 Computador de bordo iOBC . . . . . . . . . . . . . . . . . . . . . . . . 29

4.1 Esquema utilizado durante os testes . . . . . . . . . . . . . . . . . . . . 40

2.1 Algumas aplicações de pequenos satélites . . . . . . . . . . . . . . . . . 12

3.1 Comparação entre o iOBC e CubeComputerV3 . . . . . . . . . . . . . . 27

A.1 Dados de housekeeping . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

ADCS: Attitude and Determination Control System

BSP: Board Support Package

CRN: Centro Regional do Nordeste

EPS: Electrical Power System

ESL: Electronic Systems Laboratory

EUA: Estados Unidos da América

INPE: Instituto Nacional de Pesquisas Espaciais

ISIS: Innovative Solutions In Space

LEO: Low Earth Orbit

MEMS: MicroElectroMechanical Systems

OBC: On-Board Computer

PCDs: Plataformas de Coleta de Dados Ambientais

SBCDA: Sistema Brasileiro de Coleta de Dados Ambientais

SDK: Software Development Kit

SDR: Software Defined Radio

SEL: Single Event Latchup

SEU: Single Event Upset

TT&C: Telemetry, Tracking & Command

UFRN: Universidade Federal do Rio Grande do Norte

UHF: Ultra High Frequency

VHF: Very High Frequency

volvimento da tecnologia para a construção de satélites e seus veículos lançadores no

Figura 1.1: Algumas categorias de satélites de acordo com a sua massa

Fonte: (CGEE 2018)

de 2014. Anos antes do lançamento desse nanossatélite, o Centro Regional do Nordeste

são chamado Sistema Nacional de Dados Ambientais (SINDA) localizado no INPE/CRN

Cada um desses subsistemas desempenha uma função específica no nanossatélite e é

sendo capaz de detectar e corrigir eventuais erros em órbita.

Figura 1.2: Número de lançamentos de CubeSats

Fonte: Adaptado de (CGEE 2018)

Considerando o cenário atual no desenvolvimento de CubeSats no Brasil e as deman-

O objetivo geral deste trabalho é desenvolver a primeira versão do sistema de controle

• Elaborar uma estratégia para monitoramento de corrente e tensão no nanossatélite;