Dissertação apresentada à Pró-Reitoria de Pós-Graduação e Pesquisa do Instituto

Tecnológico de Aeronáutica, como parte dos requisitos para obtenção do título de

Mestre em Ciências no Programa de Pós-Graduação em Ciências e Tecnologias
Espaciais, Área de Gestão Tecnológica.

Douglas Estevam Casale

ESTUDO CONCEITUAL DE UMA

CONSTELAÇÃO DE PEQUENOS SATÉLITES DE

COMUNICAÇÕES DE BANDA ESTREITA PARA

O EXÉRCITO BRASILEIRO

Dissertação aprovada em sua versão final pelos abaixo assinados:

Prof. Dr. Luís Eduardo Vergueiro Loures da Costa

Orientador

Prof. Dr. Jonas Bianchini Fulindi

Coorientador

Prof. Dr. Pedro Teixeira Lacava

Pró-Reitor de Pós-Graduação

Campo Montenegro
São José dos Campos, SP – Brasil
2019
Dados Internacionais de Catalogação-na-Publicação (CIP)
Divisão de Informação e Documentação
Casale, Douglas Estevam
Estudo conceitual de uma constelação de pequenos satélites de comunicações de banda estreita para
o Exército Brasileiro/ Douglas Estevam Casale.
São José dos Campos, 2019.
170f.

Dissertação de mestrado – Curso de Ciências e Tecnologias Espaciais, Área de Gestão Tecnológica

– Instituto Tecnológico de Aeronáutica, 2019. Orientador: Prof. Dr-Ing. Luís Eduardo Vergueiro Loures
da Costa. Coorientador: Prof. D. Sc. Jonas Bianchini Fulindi

1. Microssatélites. 2. Sistemas complexos. 3. Partes interessadas. I. Instituto Tecnológico de

Aeronáutica. II. Estudo conceitual de uma constelação de pequenos satélites de comunicações de banda estreita
para o Exército Brasileiro.

REFERÊNCIA BIBLIOGRÁFICA

CASALE, Douglas Estevam. Estudo conceitual de uma constelação de pequenos satélites

de comunicações de banda estreita para o Exército Brasileiro. 2019. 170f. Dissertação de
mestrado em Gestão Tecnológica – Instituto Tecnológico de Aeronáutica, São José dos
Campos.

CESSÃO DE DIREITOS

NOME DO AUTOR: Douglas Estevam Casale

TÍTULO DO TRABALHO: Estudo conceitual de uma constelação de pequenos satélites de
comunicações de banda estreita para o Exército Brasileiro
TIPO DO TRABALHO/ANO : Dissertação / 2019

É concedida ao Instituto Tecnológico de Aeronáutica permissão para reproduzir cópias desta

dissertação e para emprestar ou vender cópias somente para propósitos acadêmicos e
científicos. O autor reserva outros direitos de publicação e nenhuma parte desta dissertação
pode ser reproduzida sem a autorização do autor.

__________________________________
Douglas Estevam Casale Nome Completo do Segundo Autor
Praça Marechal Eduardo Gomes, 50
12228-900, São José dos Campos - SP
 iii

ESTUDO CONCEITUAL DE UMA

CONSTELAÇÃO DE PEQUENOS SATÉLITES DE
COMUNICAÇÕES DE BANDA ESTREITA PARA
O EXÉRCITO BRASILEIRO

Douglas Estevam Casale

Prof. Dr. Olympio Lucchini Coutinho Presidente - ITA

Prof. Dr. Luís Eduardo Vergueiro Loures da Costa Orientador - ITA
Prof. Dr. Jonas Bianchini Fulindi Coorientador - ITA
Prof. Dr. Christopher Scheneider Cerqueira Membro interno - ITA
Prof. Dr. Marco Antônio Chamon Membro externo - INPE

ITA
 iv

Dedico este trabalho ao meu pai, Mário Fortunato Casale,

meu exemplo de vida e caráter, que dedicou a vida aos filhos.
 v

Agradecimentos

Agradeço ao Professor Loures pela orientação, amizade, confiança, conhecimento

transmitido e oportunidades abertas.
Ao meu grande amigo, Professor Jonas, pela orientação, aconselhamento e apoio,
companheiro de todas as horas.
Aos meus pais, Mário (que me ensinou a ler) e Virgínia, e meu tio Beto, que me
propiciaram os estudos que me possibilitaram ingressar no ITA. Ao meu avô, Antônio, que
despertou em mim o interesse pelas ciências exatas e pela carreira das Armas. Aos meus irmãos,
Daphnnie, Dreyphus, Dânae e Dan, e minhas tias Maria e Luiza, por quem tenho tanto amor.
À minha esposa Rafaela, que me apoiou, ensinou, estimulou e orientou. Minha
conselheira de todas as horas, e a primeira pessoa que ouço quando tenho dúvidas. É
maravilhoso passar cada dia com você, meu amor.
Aos meus amigos Renato e Liliam, que nos receberam tão bem em São José dos
Campos, pelo enorme afeto e amizade, e ajuda explicando as matérias também.
Aos meus amigos Santos Amaral e Magno Lopes, devo a vocês meu ingresso no ITA.
Aos amigos Breno, Hélio e Jéssica, integrantes da equipe do projeto que me auxiliou
na aplicação deste trabalho, que tanta me ensinaram desde que ingressei no Centro Espacial
ITA.
Aos demais integrantes do Centro Espacial ITA, Lídia, Linélcio, Emerson, Vinícius,
Prof. Willer, Prof. Christopher Pedro, Marcél, Edward, Makita, Renan, Denis, Prof. Carrara,
Peixoto, Kauê, Enlardenberg e Carol, que compartilharam seus conhecimentos e experiências
ao longo destes dois anos de estágio. A orientação e apoio da equipe, por cujos membros tenho
profunda admiração, bem como sua forma de organização e dinâmica de trabalho me servirão
de referência tanto no nível técnico quanto de gestão e relacionamento de equipes de
engenharia. Uma parte importante de minha formação devo a vocês.
Ao prof. Daniel Basso, pelas grandes contribuições prestadas.
Ao Cel Willian, Ten Cel Diogo e Majores Macedo, Assumpção, Lúcio, Paulo César e
Damy, pelas orientações e apoio ao longo desta jornada.
Aos amigos do Batalhão de Manutenção e Suprimento de Aviação do Exército, pelo
companheirismo e apoio, e ao Exército Brasileiro, que abriu as portas para o início de minha
carreira.
 vi

"Enquanto houver no céu a silhueta de um paraquedista,

haverá sempre a esperança da vitória”.
(Autor desconhecido)
 vii

Resumo

A região amazônica apresenta desafios ao estabelecimento de comunicações militares

confiáveis. Meios convencionais para comunicações a longa distância na selva amazônica
dependem da instalação de antenas repetidoras, o que pode atrasar missões ou comprometer o
sigilo das operações. Novas possibilidades de solução para esta necessidade de comunicação
surgiram com a evolução da tecnologia espacial, que levou ao desenvolvimento de pequenos
satélites apresentando ciclo de desenvolvimento mais rápido, menores custos e capacidade de
desempenhar missões antes restritas aos satélites de maior porte. Paralelamente, a engenharia
de sistemas tem evoluído de uma abordagem baseada em documentação para abordagens
utilizando também modelos (MBSE), adaptadas à estrutura de cada organização
desenvolvedora e às características do sistema. Neste contexto, este trabalho objetiva propor
um método híbrido para realizar o estudo conceitual de sistemas complexos e aplicá-lo ao
desenvolvimento de uma constelação de pequenos satélites de comunicações de banda estreita
para atender a forças táticas móveis do Exército Brasileiro na região amazônica. Este método é
composto por seis etapas. Na primeira etapa são definidas a necessidade de missão do projeto,
seu prazo e orçamento preliminares. A segunda etapa compreende a pesquisa de benchmarking.
Na terceira etapa são levantadas as expectativas dos stakeholders com relação ao sistema e os
objetivos e metas do projeto. A quarta etapa compreende a definição do conceito de operações.
Na quinta etapa são identificadas as arquiteturas funcional e física do sistema de interesse, e na
sexta etapa é realizada a exploração de conceitos. A partir dos resultados obtidos, pôde-se
concluir que o método se mostrou adequado à realização de estudo conceitual de constelações
de pequenos satélites, sendo enxuto, claro, didático e flexível, tendo seus elementos de MBSE
contribuído para deixar a visualização das funções, dos requisitos e suas interações mais
intuitiva.
 viii

Abstract

The Amazon region presents challenges to the establishment of reliable military

communications. Conventional means for long distance communications in the Amazon jungle
depend on the installation of repeater antennas, which can delay missions or compromise the
confidentiality of operations. New possibilities for solving this communication need arose with
the evolution of space technology, which led to the development of smaller satellites with a
faster development cycle, lower costs and ability to perform missions previously restricted to
larger satellites. At the same time, systems engineering has evolved from a documentation-
based approach to approaches using also models (MBSE), adapted to the structure of each
developer organization and the characteristics of the system. In this context, this work aims to
propose a hybrid method to carry out the conceptual study of complex systems and to apply it
to the development of a constellation of small narrow-band communications satellites to serve
the Brazilian Army's mobile tactical forces in the Amazon region. This method consists of six
steps. The first stage defines the need for the project's mission, its preliminary deadline and
budget. The second stage comprises benchmarking research. In the third step, the stakeholders'
expectations regarding the system and the project objectives and goals are raised. The fourth
step includes the definition of the concept of operations. In the fifth stage the functional and
physical architectures of the system of interest are identified, and in the sixth stage the concepts
exploration is performed. From the obtained results, it was possible to conclude that the method
was adequate to the conceptual study of constellations of small satellites, being lean, clear,
didactic and flexible, having its elements of MBSE contributed to leave the visualization of the
functions, requirements and their more intuitive interactions.
 ix

Sumário

1 INTRODUÇÃO .............................................................................................................. 11
1.1 Objetivos .................................................................................................................. 16
1.2 Delimitações do trabalho........................................................................................ 16
1.3 Estrutura do texto ................................................................................................... 17
2 REVISÃO DA LITERATURA...................................................................................... 19
2.1 O processo de desenvolvimento de produtos (PDP) ............................................ 19
2.2 Engenharia de sistemas .......................................................................................... 29
2.2.1 Sistema...................................................................................................................... 29
2.2.2 Definições para engenharia de sistemas ................................................................... 32
2.2.3 Abordagens de engenharia de sistemas .................................................................... 35
2.2.4 Estudo conceitual de sistemas .................................................................................. 41
2.3 Engenharia de sistemas aplicada a sistemas espaciais ........................................ 46
2.4 Pequenos satélites ................................................................................................... 53
2.5 Posicionamento do trabalho .................................................................................. 55
3 MÉTODO ........................................................................................................................ 60
3.1 Etapa 1: Iniciação ................................................................................................... 64
3.1.1 Atividade 1.1: Alinhamento entre os principais stakeholders .................................. 65
3.1.2 Atividade 1.2: Definição e mobilização da equipe de projeto .................................. 66
3.2 Etapa 2: Benchmarking .......................................................................................... 67
3.2.1 Atividade 2.1: Definição dos critérios de benchmarking ......................................... 68
3.2.2 Atividade 2.2: Pesquisa de benchmarking................................................................ 69
3.3 Etapa 3: Objetivos e metas .................................................................................... 71
3.3.1 Atividade 3.1: Síntese das expectativas dos stakeholders ........................................ 72
3.3.2 Atividade 3.2: Definição dos objetivos e metas do projeto ...................................... 73
3.3.3 Atividade 3.3: Captura de requisitos de alto nível.................................................... 74
3.4 Etapa 4: Conceito de operações ............................................................................. 75
3.4.1 Atividade 4.1: Determinação dos parâmetros chave de desempenho (KPPs) .......... 77
3.4.2 Atividade 4.2: Desenvolvimento do contexto e arquitetura operacionais ................ 78
3.4.3 Atividade 4.3: Identificação das condições ambientais ............................................ 79
3.5 Etapa 5: Arquiteturas funcional e física ............................................................... 80
3.5.1 Atividade 5.1: Identificação de funções do sistema ................................................. 82
3.5.2 Atividade 5.2: Definição da arquitetura física .......................................................... 84
 x

3.5.3 Atividade 5.3: Captura de requisitos de baixo nível ................................................. 86

3.6 Etapa 6: Exploração de conceitos.......................................................................... 86
3.6.1 Atividade 6.1: Órbitas e constelações....................................................................... 88
3.6.2 Atividade 6.2: Estudo de desempenho ..................................................................... 90
4 CASO DE ESTUDO ....................................................................................................... 93
4.1 Etapa 1: Iniciação ................................................................................................... 94
4.1.1 Atividade 1.1: Alinhamento entre os principais stakeholders .................................. 94
4.1.2 Atividade 1.2: Definição e mobilização da equipe de projeto .................................. 97
4.2 Etapa 2: Benchmarking .......................................................................................... 98
4.2.1 Atividade 2.1: Definição dos critérios de seleção .................................................... 98
4.2.2 Atividade 2.2: Pesquisa de benchmarking.............................................................. 100
4.3 Etapa 3: Objetivos e metas .................................................................................. 104
4.3.1 Atividade 3.1: Síntese das expectativas dos stakeholders ...................................... 104
4.3.2 Atividade 3.2: Definição dos objetivos e metas do projeto .................................... 108
4.3.3 Atividade 3.3: Captura de requisitos de alto nível.................................................. 110
4.4 Etapa 4: Conceito de operações ........................................................................... 113
4.4.1 Atividade 4.1: Determinação dos parâmetros chave de desempenho (KPPs) ........ 113
4.4.2 Atividade 4.2: Identificação do contexto e arquitetura operacionais ..................... 115
4.4.3 Atividade 4.3: Identificação das condições ambientais .......................................... 124
4.5 Etapa 5: Arquiteturas funcional e física ............................................................. 124
4.5.1 Atividade 5.1: Identificação das funções do sistema .............................................. 125
4.5.2 Atividade 5.2: Definição da arquitetura física ........................................................ 129
4.5.3 Atividade 5.3: Captura de requisitos de baixo nível ............................................... 134
4.6 Etapa 6: Exploração de conceitos........................................................................ 136
4.6.1 Atividade 6.1: Órbitas e constelações..................................................................... 136
4.6.2 Atividade 6.2: Estudo de desempenho ................................................................... 145
4.7 Análise dos resultados .......................................................................................... 154
4.7.1 Etapa 1: Iniciação ................................................................................................... 155
4.7.2 Etapa 2: Benchmarking........................................................................................... 155
4.7.3 Etapa 3: Objetivos e metas ..................................................................................... 156
4.7.4 Etapa 4: Conceito de operações .............................................................................. 157
4.7.5 Etapa 5: Arquiteturas funcional e física ................................................................. 158
4.7.6 Etapa 6: Exploração de conceitos ........................................................................... 159
5 CONCLUSÕES ............................................................................................................. 160
REFERÊNCIAS.................................................................................................................... 163
 11

1 Introdução

Meios eficazes de comunicações são imprescindíveis a todas as forças armadas atuais.

Dadas as dimensões do território brasileiro, o estabelecimento de comunicações confiáveis
constitui-se em um desafio, especialmente em áreas remotas. Estas dificuldades são
reconhecidas pelos comandantes militares, como Oliveira (2017), ex-Comandante Logístico do
Exército Brasileiro, que faz referência à dificuldade de acesso e à falta de estrutura de
comunicações na região amazônica. A importância da presença militar na Amazônia deve-se a
dois aspectos principais. O primeiro relacionado ao combate ao crime organizado e aos crimes
transfronteiriços e ambientais, dos quais tratou Vasconcelos Filho (2014) em seu trabalho sobre
o Sistema Integrado de Monitoramento de Fronteiras (SISFRON). O segundo refere-se a
ameaças externas, como observou Pereira (2008), ex-Comandante Militar da Amazônia.
Os sistemas portáteis de comunicações militares em uso na Amazônia atualmente são
baseados em rádios cuja cobertura é difícil predizer, em função da atenuação devida a
fenômenos como reflexão, difração, refração e absorção (RAPPAPORT, 2001, apud MOURA,
2018), agravados por vegetação densa e topografia irregular, típicos da região amazônica. Desta
forma, a fim de permitir o exercício de Comando e Controle (C2) a longas distâncias com
confiabilidade, costuma-se recorrer à instalação de antenas repetidoras em elevações próximas
à região de operações. Tal medida apresenta desvantagens, entre as quais:
• Riscos para as equipes responsáveis pela instalação das antenas;
• Dificuldade de acesso para instalação de repetidoras em alguns cenários de
operação, especialmente os terrenos acidentados (onde, inclusive, as repetidoras
costumam ser mais necessárias);
• Prejuízo ao sigilo das operações, tendo em vista que indica ao inimigo a intenção ou
preparação de ação militar próxima à área onde as antenas estão sendo colocadas;
• Atraso para iniciar algumas operações e limitação de ações de resposta imediata,
quando se precisa esperar o estabelecimento do sistema de comunicações.
Para contornar estas dificuldades, Moura (2018) propôs a utilização de Veículos Aéreos
Não-Tripulados (VANTs) com rádios e antenas para estabelecimento de rede sem fio. Por meio
desta solução, uma rede de VANTs gerenciados por software e utilizando inteligência artificial
se desloca autonomamente pela área de operações, de acordo com a demanda dos usuários.
 12

Uma vantagem desta solução é o fato de a difusão da radiofrequência ficar restrita a uma
área menor do terreno, com alcance limitado pela potência utilizada nas antenas e pela
sensibilidade dos receptores. Isto favorece as medidas de guerra eletrônica, por diminuir os
riscos de interceptação do sinal pelo inimigo. Por outro lado, isto também se constitui em
desvantagem, por fornecer cobertura apenas local e não permitir a ligação direta com grandes
comandos localizados a maior distância.
Além disso, com o aumento do uso de VANTs para prática de crimes, recentemente
foram desenvolvidos diversos meios para interferir ou derrubar esses veículos, como por meio
de radiofrequência (DEFESANET, 2018), lançadores de redes similares às de pesca
(WALTRICK, 2016), VANTs que perseguem e destroem outros VANTs (ALECRIM, 2016), e
até mesmo águias treinadas (HIRATA, 2017), tornando este tipo de solução vulnerável para
atender à demanda de cobertura persistente em toda a região amazônica, embora possa ter
aplicação militar para operações pontuais, de duração determinada e que demandem a uma área
de cobertura menor.
Desta forma, uma solução possível para o problema de comunicação em locais remotos,
como a região de selva amazônica, é a utilização de comunicações baseadas em satélites
(RAUPP, 2012). Sá (2015) observou que o emprego destes sistemas espaciais contribuirá para
a redução dos custos estatais decorrentes de ações do crime organizado, devido ao aumento
proporcionado na eficiência da vigilância e ações de polícia nas fronteiras.
Alinhado a este contexto, o decreto 6.703, de 18 de dezembro de 2008 (BRASIL, 2008),
que aprovou a Estratégia Nacional de Defesa, prevê a promoção da presença do Estado na
região amazônica e o fomento da atividade espacial, com ênfase em satélites
“geoestacionários”. A Estratégia Nacional de Defesa é vinculada à Estratégia Nacional de
Desenvolvimento, de modo que as questões econômicas e industriais relacionadas aos assuntos
de defesa foram associadas.
Atualmente as Forças Armadas brasileiras utilizam os satélites geossíncronos (GEO) de
empresas privadas, chamados Star One C1 e Star One C2, cuja vida útil se encerrará por volta
de 2020, e o estatal Satélite Geoestacionário de Defesa e Comunicações Estratégicas (SGDC)
(GUNTER’S SPACE, 2018a; BONINO, 2017). Utilizando a banda destinada a emprego militar
(banda X), contudo, o SGDC não atende às tropas que realizem deslocamento a pé pela selva
amazônica. Isto porque equipamento em banda X necessário para comunicação militar com o
SGDC tem dimensões de cerca de um metro cúbico, inviável de ser transportado em mochilas
militares. Em geral, os satélites em operação atualmente são usados para contato com tropas
 13

em bases fixas, mas não atendem usuários em desvantagem (móveis, embarcados, em áreas
remotas) (GUNTER’S SPACE, 2018c), justamente aqueles que estão executando as missões
de patrulhamento de selva e/ou fronteira.
Além disso, a contratação de serviço de comunicações provido por empresas privadas,
como os Star One C1 e Star One C2, apresenta a desvantagem adicional de vulnerabilidade
estratégica reconhecida pela Força Aérea Brasileira (COMISSÃO DE COORDENAÇÃO E
IMPLANTAÇÃO DE SISTEMAS ESPACIAIS, 2017), uma vez que não há garantia de que o
operador do satélite não irá interromper o serviço ou mesmo compartilhar as mensagens com
possíveis oponentes, em caso de conflito. Os altos custos de fabricação e lançamento e o longo
tempo de desenvolvimento são outras desvantagens dos satélites geossíncronos.
No entanto a evolução da tecnologia espacial tem tornado possível a miniaturização dos
outrora grandes e pesados satélites para diversas aplicações, de modo a torná-los mais atrativos
do ponto de vista econômico e de tempo de desenvolvimento, como se pode notar nos trabalhos
de Selva e Krejci (2012), Sandau, Brieß e D'Errico (2010) e Crisp, Smith e Hollingsworth
(2015). Para se ter um comparativo das diferenças dos custos, o SGDC custou R$ 2,8 bilhões
aos cofres públicos (KAFRUNI, 2017), enquanto pequenos satélites de comunicações não-
geossíncronos costumam custar cerca de R$ 2,5 milhões a unidade (GUNTER’S SPACE,
2018c; SKY AND SPACE GLOBAL, [s.d.]; CASALE; LOURES DA COSTA, 2018).
Embora satélites geossíncronos possam comunicar-se com tropas a pé utilizando a
banda UHF, satélites geossíncronos apresentam maior vulnerabilidade eletromagnética em
relação aos satélites de baixa órbita, podendo ser interferidos mais facilmente por possíveis
forças oponentes. Além disso, seu alto custo individual dificulta a construção e lançamento de
mais satélites para se obter resiliência por meio de satélites de reserva em órbita (MINISTÉRIO
DA DEFESA, 2018), visto que países como EUA (TERRA, 2008), China (FOLHA DE SÃO
PAULO, 2007) e Índia (GNIPPER, 2019) já demonstraram capacidade de destruí-los. Os EUA,
inclusive, criaram em 2018 uma Força Espacial em seu Departamento de Defesa (DoD),
visando ao controle militar do espaço (G1 GLOBO, 2018).
Diante, principalmente, das questões relativas à viabilidade econômica, Vital e Kenji
(2012) estimaram os ganhos financeiro e socioeconômico que justificaram o investimento na
implantação de constelações de satélites em baixa órbita (órbita não-geossíncrona) para o
Programa Estratégico de Sistemas Espaciais (PESE), que está inserido no âmbito da Estratégia
Nacional de Defesa.
 14

O PESE é um documento oficial do Ministério da Defesa que estabelece as “diretrizes

básicas e orientações necessárias para implantação de longo prazo dos projetos de sistemas
espaciais de defesa” (MINISTÉRIO DA DEFESA, 2018, p. 15). Cabral (2015) concorda que a
sustentação do PESE precisa ser economicamente viável, e acrescenta que, considerando novas
oportunidades para a indústria espacial civil, podem-se atingir níveis de nacionalização
gradativamente maiores.
O PESE, em seu Apêndice III ao Anexo B, prevê a implementação de um sistema de
comunicações de banda estreita (abaixo de 56 Kbps) para proporcionar enlace de longa
distância com o objetivo principal de apoiar forças táticas móveis, e apresenta que “as
dimensões do território nacional e suas características apontam no sentido do emprego de
sistemas espaciais como um dos principais meios para o exercício do Comando e Controle”
(MINISTÉRIO DA DEFESA, 2018, p. 56). Consta ainda do PESE que o Segmento Orbital
deste sistema de comunicações de banda estreita deve ser composto de uma constelação de
satélites de baixa órbita.
Observa-se, assim, uma mudança de enfoque, pois, embora a Estratégia Nacional de
Defesa originalmente estabeleça prioridade para sistemas geossíncronos, o PESE prioriza os
sistemas não-geossíncronos.
Lemos Junior (2014) acrescenta que a priorização que o PESE atribui aos sistemas não-
geossíncronos permite ao Brasil atingir a meta anual de lançamentos e a demanda para consolidar
a indústria do setor espacial, quando estes apresentarem ciclo de desenvolvimento mais rápido,
favorecendo a maior rotatividade de projetos. Cabe a ressalva de que, conforme observou Lemos
Junior (2014), apesar da priorização, o fator de decisão na concepção do satélite continua sendo
sua funcionalidade, e não o tipo de órbita.
Desta forma, neste trabalho assume-se que o emprego de pequenos satélites não-
geossíncronos pode ser uma solução viável ao problema de comunicações táticas às tropas
móveis na região amazônica. Esta potencialidade é reconhecida pelo PESE, que em sua versão
de 2018 descreve uma constelação de satélites de baixa órbita como solução para atender à
necessidade de comunicações de banda estreita, citando como vantagens a possibilidade de
utilização de terminais mais leves (portanto mais fáceis de serem transportados em região de
selva), a menor latência na transmissão e a possibilidade de uso de UHF (menos suscetível a
atenuação causada pelo clima ou vegetação) (MINISTÉRIO DA DEFESA, 2018).
O sistema de comunicação satelital em baixa órbita pode contribuir ainda para a
integração pretendida no SISFRON, fornecendo uma solução de comunicações que conecte as
 15

diferentes instituições, corporações e órgãos como o Exército Brasileiro, a Força Aérea

Brasileira, a Marinha do Brasil, as Polícias Militares e Civis dos estados, as Polícias Federal e
Rodoviária Federal, a Receita Federal, a Agência Brasileira de Inteligência (ABIN), o Instituto
Brasileiro do Meio Ambiente e dos Recursos Naturais (IBAMA), entre outros.
Neste contexto, este trabalho tem como desafio a exploração de conceitos para
configuração de uma constelação de pequenos satélites não-geossíncronos para prover
comunicações a forças táticas móveis do Exército Brasileiro atuando na região amazônica. O
foco no Exército Brasileiro (EB) se deve ao fato de as tropas a pé e demais forças táticas móveis
do EB que realizam deslocamento na região da selva amazônica serem o usuário crítico do
sistema, por estarem em maiores condições de desvantagem para sua utilização, visto terem a
menor infraestrutura disponível e realizarem as missões com adversidades potencialmente
maiores (ex. restrição de recursos, duração prolongada e longos deslocamentos em terreno de
difícil mobilidade, ações de forças oponentes). Ao desenvolver um sistema capaz de atender a
este usuário é possível realizar o transbordamento de capacidades para atender aos usuários em
condições mais favoráveis, integrando a cobertura.
Para realizar o desenvolvimento deste sistema, identificou-se a necessidade da utilização
de um método estruturado, desde as primeiras etapas do projeto, visto que deficiências nas fases
iniciais do desenvolvimento são apontadas pela literatura como as principais causas de fracasso
ou ineficiência dos sistemas (LARSON et al., 2009; KOSSIAKOFF; SWEET, 2003; INCOSE,
2015; ROZENFELD et al., 2006). Embora a literatura apresente diversas orientações para o
desenvolvimento de sistemas espaciais, a evolução das ferramentas e processos de
desenvolvimento tem levado as organizações a adaptarem seus processos de desenvolvimento
para buscar aumento de taxas de sucesso e redução de custos e prazos. Desta forma, as
organizações desenvolvedoras têm integrado elementos novos e tradicionais de
desenvolvimento de produtos, embora ainda não exista um modelo único para esta integração,
observando-se que existem variações de acordo com as particularidades das organizações e
setores da indústria envolvidos (SEBOK CONTRIBUTORS, 2016; INCOSE, 2014).
Alinhado a este contexto, cresce de importância o estabelecimento de um método
adaptado às características próprias da organização desenvolvedora para orientar o projeto, que
possa ser seguido de forma direta e integre os elementos de desenvolvimento de sistemas mais
genéricos com as atividades mais específicas ligadas aos cálculos e análises próprias do projeto
de constelações de satélites.
 16

Assim, emerge a questão central de pesquisa deste trabalho: como identificar e quais
são os conceitos para configuração de uma constelação de pequenos satélites não-geossíncronos
para prover comunicações a forças táticas móveis do Exército Brasileiro atuando na região
amazônica?

1.1 Objetivos

Tendo em vista a contextualização e a pergunta de pesquisa apresentadas anteriormente,

o objetivo geral deste trabalho é estruturar um método para o estudo conceitual de satélites e
aplicá-lo para o desenvolvimento do conceito de uma constelação de pequenos satélites não-
geossíncronos para prover comunicações de banda estreita a forças táticas móveis do Exército
Brasileiro na região amazônica.
Para a consecução do objetivo geral, foram identificados os seguintes objetivos
específicos:
• Estruturação de um método híbrido de engenharia de sistemas para realização
do estudo conceitual de satélites, combinando elementos das abordagens de
engenharia de sistemas baseada em documentação e baseada em modelos;
• Identificação das necessidades e expectativas dos stakeholders em relação à
constelação de pequenos satélites;
• Análise operacional para a constelação de satélites de comunicações, com a
finalidade de identificar o conceito de operações em que a constelação será
empregada;
• Análise funcional dos satélites, com o objetivo de definir as funções que devem
ser desempenhadas pelos satélites e seus subsistemas;
• Identificação de conceitos para o projeto, com estudo de constelações, órbitas, e
dos principais subsistemas dos satélites.

1.2 Delimitações do trabalho

O processo de engenharia de sistemas com foco em sistemas espaciais apresenta

diversas fases, que englobam desde a análise de necessidades até o fim da vida útil do sistema
e seu descarte (KOSSIAKOFF; SWEET, 2003; LARSON et al., 2009; FORTESCUE;
 17

SWINERD; STARK, 2011; WERTZ, EVERETT E PUSCHELL, 2011). Contudo, este trabalho
tem como cerne o estudo conceitual, abrangendo somente sua análise de necessidades e
exploração de conceitos.
Questões relativas ao planejamento e gerenciamento de projetos, tais como as
apresentadas por PMI (2013), como cronograma, aquisições, contrato, propriedade intelectual
e análise de riscos, não fazem parte do escopo do presente trabalho. Os processos para escolha
de qual modelo de classificação de importância de stakeholders utilizar também não são
objetivo deste trabalho. As revisões de projetos não são contempladas neste trabalho. Ainda, o
processo decisório de se engajar ou não no projeto pode envolver análise do portfólio do
desenvolvedor, seus objetivos e questões políticas, que não são objeto de estudo deste trabalho.
Este trabalho objetiva desenvolver um caso de estudo específico, aplicando o método
proposto para o desenvolvimento de uma constelação de pequenos satélites de comunicações
para o Exército Brasileiro, sem, contudo, pretender realizar o processo de validação do método.
Embora se reconheça que as estações de controle em solo e os equipamentos de
comunicação utilizados pelas forças táticas móveis (rádios) imponham requisitos de interface
ao sistema, este trabalho não visa a tratar destes componentes, e se restringe ao estudo dos
satélites e sua constelação.
A fim de viabilizar o trabalho e como demonstração da proposta, o estudo de caso foi
aplicado apenas ao levantamento de requisitos oriundos do stakeholder principal, o Exército
Brasileiro.

1.3 Estrutura do texto

O presente trabalho foi estruturado em cinco capítulos: introdução, revisão da literatura,

método, caso de estudo e conclusões.
Após descrita em sua introdução, neste primeiro capítulo, a contextualização do
problema, os objetivos, e as delimitações do trabalho, é apresentada uma revisão da literatura,
no capítulo 2, com foco nos principais temas abordados nos capítulos subsequentes: o processo
de desenvolvimento de produtos, com um breve histórico de sua evolução; engenharia de
sistemas, tratando de seus principais conceitos, suas definições, abordagens e foco no estudo
conceitual, em que está inserido este trabalho; engenharia de sistemas aplicada a sistemas
espaciais; pequenos satélites; e, por fim, é discutido o posicionamento do trabalho,
evidenciando a sua contribuição para a literatura.
 18

No capítulo 3 é descrito o método do trabalho, que combina elementos das abordagens

de engenharia de sistemas baseada em documentação e em modelos. Este método é composto
de seis etapas:
• Etapa 1: Iniciação;
• Etapa 2: Benchmarking;
• Etapa 3: Objetivos e metas;
• Etapa 4: Conceito de operações;
• Etapa 5: Arquiteturas funcional e física;
• Etapa 6: Exploração de conceitos.
No capítulo 4 serão mostrados os resultados e discussões de um caso de estudo em que
esse método foi aplicado para a realização de um estudo conceitual de uma constelação de
pequenos satélites para prover comunicações de banda estreita a forças táticas móveis do
Exército Brasileiro na região amazônica.
Finalizando este trabalho, no capítulo 5 constam as conclusões e as propostas para
trabalhos futuros.
 19

2 Revisão da literatura

Este capítulo apresenta a revisão da literatura para os principais temas deste trabalho:
engenharia de sistemas e pequenos satélites.
A primeira seção contextualiza a engenharia de sistemas no processo de
desenvolvimento de produtos, e apresenta um breve histórico do mesmo. A segunda seção
apresenta as principais abordagens e conceitos utilizados em engenharia de sistemas. A terceira
seção refere-se à engenharia de sistemas aplicada a sistemas espaciais. A quarta seção trata de
pequenos satélites. Ao final do capítulo, é discutido o posicionamento do presente trabalho
perante a literatura.

2.1 O processo de desenvolvimento de produtos (PDP)

Back et al. (2008) definem o desenvolvimento de produtos como todo o conjunto de

atividades realizadas para identificar uma demanda, projetar o produto e seu processo de
fabricação e planejar sua distribuição, manutenção e descarte. Estas atividades não são estáticas:
à medida em que o modo de gestão das empresas evolui, evolui também o modo de
gerenciamento do processo de desenvolvimento de produtos (ROZENFELD et al., 2006), como
será demonstrado nesta seção.
Após a Primeira Guerra Mundial, os sistemas de produção industrial evoluíram da
produção artesanal para a produção em massa, que foi introduzida por Henry Ford
(ROZENFELD et al., 2006) e apoiada pelos princípios da administração científica e divisão de
tarefas propostos por Frederick Taylor. Entre as vantagens desta nova forma de produzir os
produtos destacam-se a padronização dos produtos, aumento da produtividade e redução de
custos (PINTO, 2007).
Esta nova forma de produzir resultou em implicações não só na forma como os produtos
eram construídos e montados, mas também no modo como eram projetados. Foi o surgimento
da engenharia tradicional ou desenvolvimento de produtos sequencial, em que as informações
sobre os produtos eram definidas em uma ordem lógica, passando de uma área funcional para
outra. A maneira de gerenciar o projeto se diferenciava dentro de cada uma das áreas, com
culturas e padrões de trabalho próprios (ROZENFELD et al., 2006).
 20

Um exemplo de modelo sequencial utilizado era o waterfall. O nome waterfall faz

alegoria ao fato de a água seguir em sentido contínuo, sempre a jusante, sem revisitar suas
nascentes. Trata-se, portanto, de um modelo linear, segundo o qual fases rígidas devem ser
totalmente definidas para se iniciar o desenvolvimento das posteriores, como mostra a Figura 1
(BELL; THAYER, 1976).

Figura 1 – Representação da abordagem waterfall (adaptado de Bell e Thayer (1976)).

Este modelo sequencial, contudo, recebeu críticas. Sage e Cuppan (2001) apontam que
a abordagem waterfall é apropriada somente quando os requisitos estão claros desde o início
do desenvolvimento. Larson et al. (2009) afirmam que a realização de fases sequenciais não é
adequada, defendendo a adoção de um processo iterativo e com foco variando ao longo do
processo. A representação desta abordagem é apresentada na Figura 2, em que a extensão
horizontal de cada atividade representa sua duração, enquanto a altura representa sua
intensidade ao longo do ciclo. Assim, no início do desenvolvimento o foco está na política. A
política de gerenciamento refere-se ao modo como o projeto será gerido, incluindo os contratos
e suas alterações, e persiste mesmo após o fim das operações, mas com menor foco. Depois da
ênfase inicial em política, o foco vai gradualmente passando aos requisitos e especificações,
bem como ao design. Estas etapas se sobrepõem à integração e testes, e ao final as operações
recebem ênfase.
 21

Figura 2 – Abordagem com foco variável (adaptado de Larson et al. (2009)).

Apesar dos progressos permitidos pelo modelo de desenvolvimento de produtos

sequencial, algumas de suas deficiências foram sendo evidenciadas ao longo do tempo. Uma
deficiência relevante era o baixo nível de interação entre as diferentes áreas de especialização
(ex. marketing, engenharia, produção) envolvidas no desenvolvimento de produtos
(ROZENFELD et al., 2006).
Além disso, em modelos sequenciais, as áreas de especialização interagem apenas no
momento de entrega ou recebimento de resultados. Por exemplo, a área de engenharia
desenvolve o produto sem consultar a equipe de produção. Ao concluir o projeto do produto, a
área de engenharia entrega o resultado à equipe de produção, que só então toma conhecimento
do produto e tem o desafio de viabilizar o processo produtivo. Isto leva a conflitos entre as
diferentes áreas e gera consequências negativas em custos, prazos e qualidade para a empresa.
Desta forma, é como se o desempenho final do sistema dependesse apenas da excelência em
cada área, e não se levando em consideração o relacionamento entre elas (ROZENFELD et al.,
2006; KOSSIAKOFF; SWEET, 2003).
Uma ilustração de como esta premissa falha pode ser vista na Figura 3, em que observa-
se que ao se desenvolver sistemas otimizados para uma área específica da engenharia (ex.
aerodinâmica, propulsão) pode-se deixar de atender às necessidades dos stakeholders. A Figura
3 apresenta entre seus exemplos (propositalmente exagerados, para transmitir mais facilmente
a ideia central) um míssil em que a grande prioridade dada ao guiamento produziu um produto
que não tem capacidade de levar explosivos. Assim, ainda que ele atinja com precisão seus
alvos, será ineficaz, pois não tem capacidade de destruí-los.
 22

Figura 3 – Míssil ideal do ponto de vista de especialistas de diferentes áreas (adaptado de

Kossiakoff e Sweet (2003)).

À medida em que o nível de complexidade dos produtos tecnológicos desenvolvidos

aumentou, foi necessária uma modificação na forma de se pensar o desenvolvimento de
sistemas. O aparecimento de obras de engenharia da Segunda Guerra Mundial, tais como
aeronaves de alto desempenho, mísseis balísticos e o armamento nuclear motivaram o
surgimento, entre o final da década de 40 e início de 50, de uma disciplina focada em produzir
sistemas bem sucedidos, tratando simultaneamente sua relação com fatores externos, tais como
ambiente, interfaces com outros sistemas, agentes externos, bem como a interação entre seus
próprios elementos internos. Esta disciplina, conhecida como engenharia de sistemas, assumiu
tal importância que demandantes de grandes projetos, como o Departamento de Defesa dos
Estados Unidos da América (DoD), passaram a exigir seu uso para desenvolvimentos ou
aquisições em que estivessem envolvidos (BRILL, 1998, apud LOUREIRO, 1999;
KOSSIAKOFF; SWEET, 2003; FULINDI, 2017).
A visão de engenharia de sistemas é de que o desempenho do produto não depende
exclusivamente de sua otimização em cada especialidade, mas principalmente do balanço e
equilíbrio entre elas (KOSSIAKOFF; SWEET, 2003).
Entre 1950 e 1980, em meio à Guerra Fria, o surgimento da computação digital levou a
um novo aumento significativo na complexidade dos sistemas, e os métodos de engenharia de
 23

sistemas disponíveis naquele período atingiram o seu limite, de modo que as taxas de falha dos
sistemas desenvolvidos elevaram-se significativamente (LOUREIRO, 1999; KOSSIAKOFF;
SWEET, 2003). Estudos realizados nos EUA e Inglaterra na década de 1980 indicaram que
deficiências na qualidade de projeto estavam levando a perda na competitividade de seus
produtos (BACK et al., 2008).
Assim, o processo de desenvolvimento de produtos teve de se modernizar para atender
a nova realidade de maiores complexidades econômica, tecnológica, social e regulamentar, e
ainda na década de 1980 surgiu a engenharia simultânea (ROZENFELD et al., 2006), que prevê
o desenvolvimento de produtos de maneira integrada e concomitante. Sua finalidade é permitir
que, desde o início do desenvolvimento do produto, todas as fases do ciclo de vida do produto
sejam consideradas, da concepção ao descarte, englobando também custo, cronograma,
requisitos e qualidade (IDA, 1988, apud LOUREIRO, 1999).
Paralelamente, Cooper (1983, 1988, apud PINTO, 2014) propôs um modelo em que são
previstos momentos de decisão ao longo do projeto para deliberar sobre sua continuidade ou
cancelamento, de acordo com suas perspectivas de retorno. Este modelo, conhecido como
Stage-Gates, contempla desde o pré-projeto até o fim do ciclo de vida, com garantia de
qualidade e monitoramento do pós-lançamento (COOPER e KLEINSCHMIDT, 2001, apud
PINTO, 2014).
Com uma filosofia de priorização de recursos, Wheelwright e Clark (1992)
representaram o processo de seleção de ideias, detalhamento de projetos e desenvolvimento de
produtos como um funil, de modo que, em cada etapa, as alternativas consideradas menos
promissoras sejam descartadas. A abordagem de funil promoveu ainda o alinhamento entre o
processo de desenvolvimento de produtos e o planejamento estratégico da empresa
(ROZENFELD et al., 2006).
Rozenfeld et al. (2006) classificam as abordagens de Cooper, Wheelwright e Clark e a
engenharia simultânea como integrantes da “era do Desenvolvimento Integrado de Produtos”.
Entre as principais características desta era destacadas pelo autor, encontram-se:
• Visão do desenvolvimento de produtos como um processo e também inserido na
estratégia geral e na cultura da empresa;
• Simultaneidade e superposição de informações e atividades;
• Maior intensidade de comunicação entre as áreas;
• Times multifuncionais e maior mobilidade dos profissionais na carreira,
inclusive entre áreas diferentes;
 24

• Envolvimento das diferentes áreas em todas as fases do processo de

desenvolvimento.
Também na década de 1980 iniciou-se a utilização de software para auxílio
computacional a diversas áreas da engenharia, inclusive de sistemas, facilitando o seu
desenvolvimento (PARTH, 1998; MALCOLM; ALFORD, 1993, apud LOUREIRO, 1999;
FULINDI, 2011).
Rozenfeld et al. (2006) alertam, porém, que apesar das vantagens das abordagens de
desenvolvimento integrado de produtos, como aumento na produtividade do desenvolvimento
e qualidade dos produtos e redução do tempo de resposta ao mercado, poucas empresas
conseguem aplicar esta abordagem em sua totalidade.
Em sua obra, Rozenfeld et al. (2006) apresentam uma visão unificada do processo de
desenvolvimento de produtos por meio da estruturação de um modelo de referência. O modelo
abrange todo o ciclo de vida do produto, desde a macrofase de pré-desenvolvimento,
englobando as fases de planejamento estratégico dos produtos e de planejamento do projeto,
passando pela macrofase de desenvolvimento, que abrange do projeto informacional ao
lançamento do produto e por último a macrofase de pós-desenvolvimento, composta pelo
acompanhamento do produto e sua descontinuidade. Apesar das fases serem apresentadas de
maneira sequencial, os autores frisam que pode haver sobreposições, a depender de cada
projeto. O modelo proposto por Rozenfeld et al. (2006) é apresentado na Figura 4.

Figura 4 – Modelo de referência de processo de desenvolvimento de produto adotado em

Rozenfeld et al. (2006).
 25

O modelo proposto por Back et al. (2008), baseado em pesquisas e experiências do

Núcleo de Desenvolvimento Integrado de Produtos (NeDIP), assemelha-se ao de Rozenfeld et
al. (2006), com a fase de projeto detalhado sendo separada em projeto preliminar, em que se
definem a configuração final do produto e sua viabilidade, e projeto detalhado, em que ocorre
aprovação do protótipo, finalização das especificações dos componentes e detalhamento do
plano de manufatura. A Figura 5 representa este modelo.

Figura 5 – Modelo do processo de desenvolvimento integrado de produtos (ROMANO, 2003,

apud BACK et al., 2008).

Back et al. (2008) afirmam que um processo de desenvolvimento de produtos bem-

sucedido reflete na competitividade do produto, indicando a importância das escolhas feitas
durante as fases iniciais do desenvolvimento, que comprometem de 70% a 90% de seu custo
final (BARTON; LOVE; TAYLOR 2001, apud BACK et al., 2008).
Um fator complicador nestas fases iniciais, contudo, é que são estas as fases em que se
possui menos informações sobre o projeto, tornando ainda mais difícil a escolha das melhores
soluções. No caso de ocorrerem escolhas incorretas que demandem alterações durante o projeto,
o custo para estas alterações aumenta em cerca de 10 vezes a cada fase, tornando correções
 26

tardias muitos mais dispendiosas. Por outro lado, os custos já incorridos nas fases iniciais são
baixos em relação ao custo final, conforme pode-se ver na Figura 6. Deste modo nota-se que,
embora representem diretamente um pequeno custo para o projeto, as atividades de
desenvolvimento são determinantes para definir a sua viabilidade futura (ROZENFELD et al.,
2006).

Figura 6 – Curva de comprometimento do custo do produto (ROZENFELD et al., 2006).

O PMI (2013) apresenta um guia para gestão de projetos e descreve o ciclo de vida dos
projetos e da gestão de projetos. Para o PMI (2013), esta gestão é dividida em cinco processos:
• Iniciação: desempenhado para definir um novo projeto ou fase, obtendo
autorização para tal. Compreende a definição dos objetivos do projeto, seu
escopo, a justificativa do projeto escolhido face à necessidade do stakeholder,
além da estimativa de custo e prazo para sua concretização. Assim, o processo
de iniciação é necessário para que se autorize a alocação de recursos
(financeiros, pessoal, estrutura) para um projeto;
• Planejamento: processo de estabelecer as atividades necessárias para definir o
escopo, melhor alinhar os objetivos e estabelecer a linha de ação necessária para
alcançar os objetivos do projeto;
• Execução: processo de execução das atividades estabelecidas nos processos de
iniciação e planejamento;
• Monitoramento e controle: processo referente ao monitoramento e revisão do
projeto, identificando possíveis necessidades de modificações;
 27

• Encerramento: processo de realização das atividades para finalizar fase ou

projeto, podendo incluir o registro de lições aprendidas, atualização dos
processos organizacionais e encerramento de aquisições.
A Figura 7 ilustra como estes processos interagem ao longo do tempo. Pode-se notar
que o modelo não é sequencial, mas sim iterativo.

Figura 7 – Interação dos processos durante projeto ou fase de projeto (PMI, 2013).

Diante dos desafios da globalização, empresas transnacionais e aumento crescente da

complexidade dos projetos de produtos, têm surgido novas abordagens para o processo de
desenvolvimento de produtos, como desenvolvimento enxuto de produtos, design for six sigma,
modelos de maturidade e de gestão do ciclo de vida de produtos (ROZENFELD et al., 2006).
Com relação ao projeto de sistemas espaciais, tanto a agência estadunidense
Administração Nacional de Aeronáutica e Espaço (NASA) quanto a Agência Espacial Europeia
(ESA) dividem seus ciclos de vida em sete fases.
Para a ESA, as três primeiras fases, nomeadas fase 0 (análise de missão/ identificação
das necessidades), fase A (viabilidade) e fase B (definição preliminar), são focadas na
elaboração dos requisitos funcionais e técnicos, exploração de conceitos, identificação dos
recursos e atividades necessários ao desenvolvimento dos segmentos solo e espacial do projeto,
conceito de operações, avaliação de riscos iniciais e atividades de pré-desenvolvimento. As
fases C (definição detalhada) e D (qualificação e produção) englobam as atividades voltadas
ao desenvolvimento e qualificação dos segmentos solo e espacial. A fase E (utilização)
 28

compreende o lançamento e manutenção dos sistemas. Na fase F (disposição) são

desempenhadas as atividades de descarte dos sistemas (ECSS, 2009a). Este ciclo de vida é
apresentado na Figura 8.

Figura 8 – Ciclo de vida de sistemas espaciais segundo a ECSS (2009a). Adaptado pelo autor.

A NASA nomeia sua primeira fase como pré-fase A (estudos conceituais), que tem
basicamente os mesmos objetivos da fase 0 da ESA. As demais fases do ciclo de vida da NASA
(de A a F) também apresentam atividades e objetivos semelhantes às homônimas da ESA. Uma
variação a se destacar é que a NASA considera que as atividades relativas ao lançamento se
enquadram na fase D, juntamente com a montagem, integração e testes (NASA, 2016),
enquanto a ESA as classifica na fase E, com a utilização (ECSS, 2009a).
Kossiakoff e Sweet (2003) afirmam que, devido ao grande esforço envolvido no
desenvolvimento de um novo produto complexo, é necessária uma equipe para liderar e
coordenar sua execução. Esta equipe é dirigida pelo gerente de projeto. Os autores dividem o
gerenciamento de um projeto de desenvolvimento em duas esferas. A primeira esfera é a
engenharia de sistemas, que inclui as atividades mais técnicas, como a definição de arquitetura
do sistema, a coordenação técnica e a integração do sistema. A engenharia de sistemas é assunto
da Seção 2.2 desta revisão da literatura. A segunda esfera é o planejamento e controle de
projetos, integrado pelas atividades de planejamento do projeto, alocação de recursos e
gerenciamento financeiro e de contratos. As atividades de gerenciamento de risco, divisão de
 29

tarefas e interação com os stakeholders são compartilhadas entre ambas as esferas. A Figura 9
apresenta o diagrama de Venn para o gerenciamento de projeto, segundo Kossiakoff e Sweet
(2003).

Figura 9 – Esferas de atividades incluídas no gerenciamento do projeto (adaptado de

Kossiakoff e Sweet, (2003)).

O objetivo desta seção foi apresentar conceitos e modelos de desenvolvimento de

produtos e um breve histórico de sua evolução. A próxima seção tem como foco a engenharia
de sistemas, que, segundo Kossiakoff e Sweet (2003), é uma das componentes no
gerenciamento de um projeto de desenvolvimento de sistema.

2.2 Engenharia de sistemas

Esta seção apresenta definições para sistema, engenharia de sistemas e as suas principais
abordagens e conceitos relacionados. Ao final desta seção é dado enfoque à fase de estudo
conceitual do sistema, por ser a fase na qual o presente trabalho está inserido.

2.2.1 Sistema

O INCOSE (2018) usa a terminologia sistema para um conjunto de elementos

interconectados que juntos produzem resultados (qualidades, propriedades, características,
 30

funções, comportamento e desempenho) não alcançados por nenhum dos elementos isolado.
Blanchard (2003) define sistema como um conjunto de elementos organizados para executar
uma função e assim atender a uma necessidade.
Complementando as definições anteriores, o Departamento de Defesa dos Estados
Unidos da América (DoD) afirma que um sistema é composto por pessoas, produtos e processos
que fornecem a capacidade de satisfazer a uma necessidade ou atender a um objetivo
(DEPARTMENT OF DEFENSE SYSTEMS MANAGEMENT COLLEGE, 2001).
Também de acordo com as definições apresentadas, os sistemas podem ser divididos em
elementos constituintes, compondo uma estrutura hierárquica. Exemplos de estruturas
hierárquicas de sistemas são apresentados por INCOSE (2004), NASA (2018a) e Kossiakoff e
Sweet (2003) na Figura 10.

Figura 10 – Comparativo entre as hierarquias de sistemas sugeridas por INCOSE (2004) (à

esquerda), NASA (2018a) (centro) e Kossiakoff e Sweet (2003) (à direita).

Sistemas são, ainda, delimitados por fronteiras, que definem o que é interno e
pertencente ao mesmo e o que está inserido em um contexto maior. Por exemplo, quando se
trata do sistema de distribuição de combustível (inserido na elipse do sistema de transporte
aéreo), na Figura 11, a elipse que o circunda representa sua fronteira. Os elementos externos a
esta fronteira (ex. sistema de aeroportos, sistema de controle de tráfego aéreo) representam o
contexto maior (KOSSIAKOFF; SWEET, 2003; INCOSE, 2015).
 31

Figura 11 – Exemplo de sistema de transporte (adaptado de Dahmann, (2014, apud INCOSE,

2015)).

Na Figura 11 nota-se também que há vários sistemas representados conectados. Isto

porque sistemas costumam operar se relacionando entre si. Para se manter a clareza sobre a que
se está referindo ao usar a palavra “sistema”, utiliza-se o conceito de sistema de interesse (SoI).
Para o exemplo tratado, a gestão de transporte rodoviário poderia determinar o sistema de
transporte terrestre como sendo o seu sistema de interesse. (INCOSE, 2015).
Um sistema de interesse cujos elementos sejam gerencialmente ou operacionalmente
independentes é definido pelo INCOSE (2015) e por Larson et al. (2009) como um sistema de
sistemas (SoS). Kossiakoff e Sweet (2003) empregam a nomenclatura “supersistema” para este
mesmo conceito. Na Figura 11, exemplos de SoS são o sistema de transporte e o sistema de
transporte aéreo. Pode-se observar que no interior das fronteiras destes dois sistemas estão
compreendidos outros sistemas, como o próprio sistema de transporte aéreo é um sistema
integrante do sistema de transporte.
No contexto deste trabalho, que trata de produtos e sistemas de elevado grau de
complexidade, os termos produtos e sistemas são equivalentes. Também no contexto deste
trabalho, os termos desenvolvimento de produtos e desenvolvimento de sistemas são sinônimos.
 32

2.2.2 Definições para engenharia de sistemas

O termo engenharia de sistemas surgiu provavelmente nos Laboratórios de Telefones

Bell, no início da década de 1940. Naquele período, diversas organizações reconheceram a
necessidade de utilizar uma abordagem holística em seus projetos (HALL, 1962), devido ao
surgimento de sistemas com alto nível de complexidade, como aeronaves de alto desempenho
e radares militares (KOSSIAKOFF; SWEET, 2003).
Douglass (2016) define a engenharia de sistemas como uma atividade interdisciplinar
voltada à produção de sistemas para atender a necessidades complexas. O foco são as
propriedades que os sistemas devem apresentar, as quais não são vinculadas a soluções
específicas. Sillitto et al. (2018) trocam a palavra “interdisciplinar” por “transdisciplinar”, para
enfatizar a importância de se integrar disciplinas diversas, de modo a criar uma abordagem
holística.
Uma definição ainda mais direta é apresentada por Griffin (2009), que a trata como “arte
e ciência de desenvolver sistemas operáveis que atendam a requisitos dentro de restrições
impostas”. Esta menção à arte é feita também por Larson et al. (2009), que intitulam uma seção
de seu livro de “a arte e ciência da engenharia de sistemas”. Segundo estes últimos autores, a
liderança técnica pode ser entendida como a arte da engenharia de sistemas, por equilibrar
domínios de conhecimento amplos, criatividade, liderança e comunicação. O gerenciamento do
sistema é a ciência, com uma abordagem quantitativa, que pode ser repetida e demonstrada. Os
autores afirmam que projetos dominados somente pela ciência costumam resultar em insucesso
em atender aos interessados ou tornam-se excessivamente custosos.
A Cooperação Europeia para Padronização Espacial (ECSS, 2009b) contextualiza a
engenharia de sistemas, apresentando suas interfaces com o gerenciamento, a produção,
operações e logística e garantia de produto (Figura 12). As funções compreendidas em
engenharia de sistemas são:
• Engenharia de requisitos, englobando as atividades de análise e validação,
alocação e manutenção de requisitos;
• Análise, para resolver conflitos nos requisitos, decompô-los e alocá-los durante
a análise funcional, avaliar a eficácia do sistema, além de complementar os testes
e fornecer estudos de mercado;
• Projeto e configuração, que define as características funcionais e a arquitetura
física do sistema;
 33

• Verificação, para verificar se o sistema produzido atende aos requisitos;

• Integração e controle da engenharia de sistemas, para assegurar a integração
das diferentes áreas envolvidas no projeto.

Figura 12 – Fronteiras da engenharia de sistemas (adaptado de ECSS (2009b)).

O objetivo da engenharia de sistemas é, ao fazer a ponte entre as disciplinas tradicionais

de engenharia, atingir resultados para atender aos envolvidos no projeto, os stakeholders
(KOSSIAKOFF; SWEET, 2003; LARSON et al., 2009). Friedman e Miles (2006) observam
que estes stakeholders podem ser pessoas ou organizações.
O principal stakeholder não é necessariamente quem faz o principal aporte financeiro.
Para se estabelecer quais stakeholders são os mais importantes em um determinado projeto,
existem diferentes modelos, cada um adotando diferentes critérios para esta priorização. O PMI
(2013) apresenta os seguintes modelos:
• Grade de Poder/Interesse: baseada nos níveis de autoridade e interesse de cada
envolvido no projeto;
 34

• Grade de Poder/Influência: baseada nos níveis de autoridade e envolvimento;

• Grade de Influência/Impacto: baseada nos níveis de envolvimento e
capacidade de causar alterações no projeto;
• Modelo de saliência: baseada no poder, urgência e legitimidade.
A aplicação de métodos de engenharia de sistemas não se restringe ao desenvolvimento
de produtos, mas também se estende a aquisições de produtos complexos. Entidades que
realizam este tipo de aquisição, como o DoD e a NASA, utilizam modelos estruturados para a
realização de aquisições, cujas atividades são apoiadas pela engenharia de sistemas (SAGE;
ROUSE, 2009). Estas entidades realizam revisões períódicas em seus processos de aquisições
(DEPARTMENT OF DEFENSE, 2001). No contexto brasileiro, as Forças Armadas são um dos
principais adquirintes de produtos de elevado grau de complexidade, o que motivou Amaro
(2012) a propor um modelo de engenharia de sistemas a ser aplicado pelas Forças Armadas
durante seus processos de aquisição.
Para avaliar a importância da aplicação da engenharia de sistemas, um estudo conjunto
da Associação Industrial de Defesa dos EUA (NDIA), do Instituto dos Engenheiros Eletricistas
e Eletrônicos (IEEE) e do Instituto de Engenharia de Software de Carnegie Mellon, buscou
encontrar a relação entre a aplicação das atividades de engenharia de sistemas e o desempenho
dos projetos, baseado em pesquisa de 148 projetos. Os projetos foram classificados em três
níveis de aplicação de engenharia de sistemas, sendo o mais baixo referente à aplicação de
conhecimento de engenharia de sistemas em menor intensidade, e o mais alto aquele em que se
aplicaram com maior habilidade seus princípios. Observou-se que no grupo de nível mais alto
a taxa de alto desempenho foi quase quatro vezes superior à do grupo de nível mais baixo em
engenharia de sistemas (ELM; GOLDENSON, 2012, apud INCOSE, 2015).
Para estimar um valor ponto ótimo para investimento em engenharia de sistemas, Eric
Honour, em conjunto com a Universidade da Austrália Meridional, realizou um estudo
relacionando o percentual de investimento em engenharia de sistemas e a razão entre custos e
prazos totais e planejados do projeto. Os pesquisadores concluíram que a alocação de cerca de
14% do orçamento do projeto em atividades de engenharia de sistemas minimiza tanto o custo
total quanto o tempo demandados pelo mesmo, em relação aos valores previstos. O resultado
para custo consta da Figura 13, em que a curva representa a razão entre o custo real pelo custo
planejado (HONOUR, 2013, apud INCOSE, 2015).
 35

Figura 13 – Custo excedido correlacionado com o esforço de engenharia de sistemas

(HONOUR, 2013, apud INCOSE, 2015).

2.2.3 Abordagens de engenharia de sistemas

Ao longo do tempo, diversas abordagens foram sendo propostas para engenharia de

sistemas, como será apresentado neste tópico.
Hall (1962) apresenta um método para a aplicação de engenharia de sistemas, em uma
obra reconhecida pelo INCOSE (2015) como um marco na origem da engenharia de sistemas
como disciplina. Nesta obra, o trabalho de engenharia de sistemas é dividido em cinco fases,
conforme mostrado na Figura 14.

Figura 14 – Cronologia típica para engenharia de sistemas, pesquisa, desenvolvimento e

produção (adaptado de Hall (1962)).
 36

A primeira fase é chamada de estudos do sistema (ou planejamento do programa), e

compreende os contatos iniciais com stakeholders, alocação e priorização de recursos,
aumentando ou reduzindo os esforços em determinados projetos, além da realização de
pesquisas que se julguem necessárias para fundamentar projetos que possam ser iniciados
posteriormente. Esta fase não é focada em um projeto específico, mas trata de todos os projetos
presentes ou futuros que a organização esteja considerando, e se estende durante todo o trabalho
de engenharia de sistemas.
A segunda fase é chamada de planejamento exploratório (ou planejamento de projeto
I), focada em apenas um projeto, onde são desempenhadas seis funções:
• Definição do problema, na qual se busca identificar a necessidade a ser atendida
e o ambiente em que o sistema opera (ex. sistemas existentes, métodos e normas
em vigor para os sistemas existentes, estrutura organizacional, ambiente físico e
fatores sociais);
• Seleção dos objetivos, na qual se definem os critérios para selecionar um
sistema que atenda à definição do problema;
• Síntese do sistema, na qual se elencam sistemas que sejam alternativas que
possam atingir os objetivos;
• Análise do sistema, na qual são avaliados, entre outros fatores, a qualidade,
desempenho e custo de cada um dos sistemas selecionados como alternativas;
• Seleção do(s) melhor(es) sistema(s), que compreende restringir ao máximo a
lista de alternativas baseado na comparação entre elas, à luz dos objetivos
definidos anteriormente;
• Comunicação de resultados, na qual é finalizada a fase de planejamento
exploratório, concluindo que um projeto específico atende à necessidade
identificada, ou que são necessários estudos adicionais para a seleção de uma
alternativa dentre as possíveis, ou que não se justifica neste momento continuar
os esforços no presente projeto.
A terceira fase é o planejamento de desenvolvimento (ou planejamento de projeto II),
que se inicia após a decisão pelo início do projeto e recapitula a fase anterior. As alternativas
estudadas nesta fase são mais restritas, apenas as consideradas viáveis na segunda fase, e os
estudos são mais detalhados.
 37

A quarta fase compreende os estudos durante o desenvolvimento (ou fase de ação I),
com aumento da equipe envolvida no projeto. Os engenheiros de desenvolvimento assumem
uma carga de trabalho maior e, enquanto é realizado o desenvolvimento de engenharia, o
documento de requisitos continua a evoluir. Nesta fase também ocorre a construção de
protótipos e de testes com participação dos clientes.
A última fase é chamada de engenharia atual (ou fase de ação II), que se inicia quando
é finalizado o desenvolvimento do sistema e iniciada a produção do mesmo, persistindo
enquanto o sistema ainda estiver em uso. Esta fase também compreende o acompanhamento
para atualização ou expansão das funcionalidades do sistema.
A Figura 14 apresenta a relação destas fases com as demais atividades do processo de
desenvolvimento. A pesquisa influencia todo o processo, mas seus efeitos são mais
significativos nas fases iniciais, o que é representado pela seta apontando na diagonal para
baixo. Os estudos do sistema costumam ter intensidade constante, e influenciam pouco a
pesquisa. Apesar de o modelo ser aparentemente sequencial, as fases e atividades representadas
por linhas tracejadas podem se sobrepor, ou seja, podem ser realizadas em paralelo (HALL,
1962).
Ao longo do tempo foram propostas outras abordagens para engenharia de sistemas,
materializadas inclusive por normas como a Militar Standard 499, o Manual de Campo do
Exército dos EUA 770-78 e o ISSO/IEC 15288 (INCOSE, 2015).
Kossiakoff e Sweet (2003) compararam os modelos de ciclo de vida de sistemas das
normas do DoD (série 5000), ISO/IEC 15288, e Sociedade Nacional dos Engenheiros
Profissionais (NSPE), conforme mostrado na Figura 15.
A partir dessa comparação, os autores concluíram que as transições entre os estágios
principais para os três modelos analisados coincidem, embora a nomenclatura possa apresentar
alguma variação. Desta forma, Kossiakoff e Sweet (2003) propuseram o seu modelo, composto
por três estágios, descritos a seguir, e subdivididos em oito fases:
• O primeiro estágio é o desenvolvimento conceitual, cujos objetivos principais são
o estabelecimento da necessidade motivadora para a construção de um sistema
viável de ser produzido, a exploração de possíveis conceitos de sistemas, a validação
de requisitos de desempenho, e a seleção do conceito mais apropriado, definindo
suas características funcionais e planejando os estágios subsequentes.
• O segundo estágio é o desenvolvimento de engenharia, que visa a desenvolver e
validar tecnologias que sejam necessárias ao conceito de sistema selecionado
 38

anteriormente, além de realizar as atividades de engenharia que deixem o sistema

pronto para testes e produção.
• O terceiro estágio é o pós-desenvolvimento, que compreende o acompanhamento e
atualização do sistema e suporte ao longo do restante do ciclo de vida do sistema.

Figura 15 – Comparação de modelos de ciclo de vida de sistemas (KOSSIAKOFF; SWEET,

2003).

As abordagens tradicionais para engenharia de sistemas, como as de Hall (1962) e de

Kossiakoff e Sweet (2003), são baseadas em documentação textual, que é compartilhada entre
stakeholders e desenvolvedores. A ênfase da engenharia de sistemas nestes casos é no controle
da documentação, para garantir sua completude e consistência. (WEILKIENS, 2011, apud
SCHEEREN, 2013; DELLIGATTI, 2014).
Embora esta abordagem produza documentação detalhada sobre o projeto, ela apresenta
limitações, como: gasto elevado de tempo para se pesquisar por informações específicas, alto
custo de gerenciamento da documentação e dificuldade em se manter a consistência de
informação distribuída em diferentes documentos (RAUSCH et al., 2005, apud SCHEEREN,
2013; DELLIGATTI, 2014; MENDES, 2018).
Com a intenção de apresentar uma alternativa à abordagem baseada em documentos e
superar algumas de suas deficiências, surgiu a engenharia de sistemas baseada em modelos
(Model-Based Systems Engineering - MBSE), que é a aplicação formal de princípios, métodos,
 39

ferramentas e linguagens de modelagem ao ciclo de vida de sistemas complexos e

interdisciplinares (MELLOR; CLARK; FUTAGAMI, 2003, apud RAMOS; FERREIRA;
BARCELÓ, 2012). A MBSE transfere o foco da produção e controle de documentos para o
desenvolvimento, gerenciamento e controle do modelo (INCOSE, 2015).
Modelos, na perspectiva de MBSE, são representações de características chave do
sistema. Modelos não contêm todas as informações a respeito da entidade modelada, mas
somente aquelas necessárias para a finalidade e análise que se pretenda realizar, ou seja, são
simplificações que permitem o estudo do sistema, podendo representar sua estrutura,
comportamento ou requisitos (FRIEDENTHAL; MOORE; STEINER, 2015). Sage e Rouse
(2009) acrescentam que o modelo pode utilizar diferentes maneiras para representar o sistema,
por exemplo:
• Representação em linguagem textual, como em Linguagem de Descrição de
Software (VHDL);
• Linguagem gráfica, como usado em diagramas de circuitos;
• Por meio de simulação computacional;
• Física, como um modelo em escala para túnel de vento.
Como vantagens da engenharia de sistemas baseada em modelos, Douglass (2016)
destaca a precisão dos dados de engenharia, a consistência dos dados de engenharia (por meio
de rastreabilidade), melhor visualização dos dados de engenharia e facilidade na integração e
gerenciamento dos dados de engenharia, bem como uma verificação mais precoce da correção
destes dados.
Douglass (2016), em sua obra, foca nos modelos em SysML (linguagem computacional
de modelagem de sistemas), e recomenda uma abordagem baseada no Manifesto Ágil para
implementar a MBSE, que o autor chamou de agile MBSE (aMBSE).
O Manifesto Ágil (Agile Manifesto) foi apresentado em 2001, sendo originalmente
formulado para desenvolvimento de software. Baseado em doze princípios, este manifesto
busca valorizar os indivíduos e suas interações acima dos processos e ferramentas, software
funcionando acima da documentação completa, a colaboração com os stakeholders acima da
negociação de contratos, e a adaptabilidade a mudanças acima de seguir um plano (AGILE,
2001; DOUGLASS, 2016; LOURES DA COSTA; FULINDI, 2018). Diversos modelos de
desenvolvimento de software surgiram em conformidade com o Manifesto Ágil, como o Scrum,
Crystal, a Programação Extrema (XP) e o Desenvolvimento de Software Adaptativo (ASD)
(AGILE, 2001; PINTO, 2014).
 40

Com a finalidade de aplicar o Manifesto Ágil também à área de engenharia de sistemas,

Douglass (2016) reformulou seus doze princípios originais, adaptando-os para o novo contexto.
O resultado é apresentado a seguir:
• A prioridade é satisfazer o stakeholder através da entrega contínua e adiantada
de especificações e sistemas que atendam a suas necessidades;
• Mudanças nos requisitos, ainda que tardias, são vistas positivamente quando
visam à vantagem competitiva para os stakeholders;
• Entregar frequentemente produtos funcionais de engenharia de sistemas, em
intervalos de tempo os menores possíveis;
• A área de negócios e os desenvolvedores devem trabalhar em conjunto
diariamente por todo o projeto;
• A motivação dos indivíduos, a confiança na equipe, o ambiente de trabalho e o
suporte são fatores importantes no desenvolvimento;
• A comunicação presencial é o método mais eficiente e eficaz de
transmitir informações;
• Dados de engenharia verificados são a medida primária de progresso;
• Processos ágeis promovem desenvolvimento sustentado. Os patrocinadores,
desenvolvedores e usuários devem ser capazes de manter um ritmo constante de
desenvolvimento por tempo indefinido;
• A agilidade é beneficiada pela contínua atenção à excelência técnica e pelo bom
design;
• A simplicidade (maximização do trabalho a não ser feito) é essencial;
• Equipes auto-organizáveis produzem as melhores arquiteturas, requisitos e
designs;
• A equipe deve refletir sobre como se tornar mais eficaz, refinar e ajustar
seu comportamento periodicamente.
Embora a MBSE esteja se popularizando, o INCOSE (2014), em sua obra “Visão de
Engenharia de Sistemas para 2025”, afirma que a engenharia de sistemas baseada em modelos
ainda está em estágio inicial de maturidade. Estefan (2008, apud SEBOK CONTRIBUTORS,
2016) menciona que isto se deve ao fato de ainda existirem desafios para a transição da
engenharia de sistemas baseada em documentos para a MBSE, como a melhoria das linguagens,
métodos e ferramentas de modelagem.
 41

Assim, alguns autores relatam que a MBSE vem sendo aplicada de forma limitada aos
projetos, resultando em abordagens mistas de MBSE e engenharia de sistemas baseada em
documentos. Ainda não existe um modelo único para integração destas duas abordagens que
tenha aplicação direta a todos os tipos de projeto, de modo que esta transição tem ocorrido de
forma desigual, de acordo com organizações e setores da indústria envolvidos (SEBOK
CONTRIBUTORS, 2016; INCOSE, 2014).
Neste sentido, Scheeren (2013) realizou um estudo em que apresenta uma comparação
entre diferentes perspectivas de desenvolvimento de sistemas, incluindo o modelo centrado em
documentos, MBSE e engenharia de domínio, além de utilizar aspectos destas abordagens de
maneira integrada. Em relação às abordagens utilizando criação de modelos (MBSE e
engenharia de domínio) o autor concluiu que, embora a modelagem e simulação com SysML
tenha permitido modelar diversos aspectos do sistema, devem-se selecionar as atividades a se
modelar e simular, restringindo-se apenas a partes do projeto onde os modelos podem trazer
benefícios ao funcionamento e reduzir custos do projeto (WEILKIENS, 2011, apud
SCHEEREN, 2013), visto que estes processos demandam muito tempo da equipe. Não se
mostrou viável aplicar a modelagem de modo generalizado. Scheeren (2013, p. 86) afirma,
ainda, que, “mesmo utilizando métodos baseados em modelos, a engenharia de sistemas
necessita de uma etapa de geração de documentos para aquisição ou produção dos
componentes”.
Deste modo, conforme apresentado por INCOSE (2014), Scheeren (2013) e Estefan
(2008, apud SEBOK CONTRIBUTORS, 2016), o surgimento e popularização da engenharia
de sistemas baseada em modelos não fizeram com que a engenharia de sistemas baseada em
documentação fosse considerada obsoleta, mas sim combinada com MBSE, levando ao
emprego de métodos híbridos. Deve-se considerar, contudo, que as abordagens híbridas podem
apresentar problemas relacionados à transcrição das informações de uma linguagem para a outra
(de documento para modelos e vice-versa), o que pode resultar em erros ou desperdício de
tempo devido a essa necessidade de transcrição.

2.2.4 Estudo conceitual de sistemas

O presente tópico visa a apresentar as atividades desenvolvidas durante o estudo

conceitual de um sistema, que é um dos estágios do processo de desenvolvimento de produtos
e foco deste trabalho. O estudo conceitual tem por objetivo definir o conceito do sistema que
 42

será construído, isto é, sua arquitetura física e design (BACK et al., 2008; LARSON et al.,
2009; INCOSE, 2015), incluindo alguns sistemas, subsistemas e componentes (ROZENFELD
et al., 2006). Esta fase é importante pois suas decisões implicam o comprometimento da maior
parte do custo e competitividade do produto, e falhas que impliquem em modificações em fases
posteriores mostram-se dispendiosas (HUTHWAITE; SCHNEBERGER, 1992, apud BACK et
al., 2008).
Antes da realização do estudo conceitual, é necessário que tenham sido desempenhadas
as atividades de pré-desenvolvimento, ligadas ao planejamento estratégico da organização (isto
é, a relação do projeto com os demais projetos do portfólio da organização e suas estratégias de
mercado) (ROZENFELD et al., 2006; HALL, 1962).
Para se iniciar o estudo conceitual, deve-se ter reconhecido uma necessidade devido a
qual se decida pelo desenvolvimento ou modificação de um sistema de interesse (SoI) (ISO/IEC
TR 24748-1, 2010, apud INCOSE, 2015).
Na literatura, encontram-se diferentes modelos para se desenvolver o estudo conceitual.
Em geral, esses modelos são similares em termos de conteúdo, mas apresentam variações na
forma em que são apresentados. Para sistematizar esta análise, foi construída a Figura 16, que
compara diferentes formatos de modelos de estudo conceitual, derivados dos trabalhos dos
autores Larson et al. (2009), Kossiakoff e Sweet (2003), Rozenfeld et al. (2006), Back et al.
(2008), INCOSE (2015) e Hall (1962), evidenciando as sobreposições e equivalências entre as
fases / etapas desses modelos.

Figura 16 - Comparação de modelos de estudo conceitual.

 43

Kossiakoff e Sweet (2003) dividem o estudo (ou desenvolvimento) conceitual em três

fases: análise das necessidades, exploração de conceitos e definição do conceito.
Durante a análise das necessidades é verificado se existe uma necessidade que
justifique o desenvolvimento de um novo sistema (KOSSIAKOFF; SWEET, 2003). Ainda
nesta fase são refinadas e validadas as necessidades expressas pelos stakeholders. O contato
entre stakeholders e a equipe de desenvolvimento é normalmente realizado por meio de
entrevistas e reuniões, e é comum o stakeholder não ter uma visão clara a respeito do que
realmente precisa ou não saber expressar sua necessidade, confundindo problema com solução
(LARSON et al., 2009).
Por exemplo, suponha-se que um fabricante de computadores que reporte à equipe de
engenharia de sistemas que deseja uma bateria com maior capacidade (normalmente mais cara).
Contudo esta mudança na bateria é apenas uma das soluções possíveis, e talvez o aumento de
eficiência de algum dos componentes do computador possa ser uma solução mais viável. Se o
consumidor alvo não demandar desempenho gráfico elevado, pode-se substituir a placa de
vídeo para uma de menor potência, ou mesmo retirá-la do sistema. Desta forma, aquilo que o
fabricante desejava, na verdade, poderia ser aumentar a autonomia de um de seus modelos de
computadores quando fora da tomada.
Para mitigar ocorrências em que o stakeholder confunde problema com solução, como
no exemplo anterior, Larson et al. (2009) propõem que as entrevistas sejam estruturadas de
modo a seguir os seguintes princípios:
• Não influenciar as respostas dos stakeholders, deixando-os livres para se
expressarem à sua maneira
• Fazer perguntas abertas, evitando questões com alternativas que possam
influenciar as respostas ou perguntas do tipo “sim ou não”
• Anotar as respostas na linguagem dos stakeholders
Adicionalmente, Goodwin (2009) apresenta diretrizes para a condução das entrevistas,
entre as quais iniciar por uma revisão das expectativas iniciais e o que é esperado de cada um
dos participantes, solicitar a opinião dos stakeholders a respeito das dificuldades enfrentadas e
quais abordagens lhes parecem ser eficientes ou não.
Uma vez conhecidas as necessidades dos stakeholders, podem-se estabelecer objetivos
e metas, que detalham as expectativas dos stakeholders com relação ao projeto. Os objetivos
são normalmente qualitativos e descritivos, enquanto as metas são quantitativas (LARSON et
 44

al., 2009). Os valores numéricos das metas podem ser relacionados tanto a uma taxa ou
quantidade verificável por “teste, análise, simulação e modelagem, inspeção ou demonstração”
(LARSON et al., 2009, p. 444), ou quanto ao nível de satisfação do stakeholder (FULINDI,
2017). Rozenfeld et al. (2006) e Back et al. (2008) tratam o documento que apresenta a
justificativa para o desenvolvimento do sistema e desempenho que ele deve apresentar (seus
objetivos e metas) como escopo do produto, e em seu modelo este escopo é definido durante a
fase de planejamento do projeto.
Após a definição dos objetivos e metas do projeto, Larson et al. (2009) propõem a
identificação do conceito de operações (ConOps) do sistema. O conceito de operações esclarece
e documenta como os stakeholders utilizarão o sistema em diferentes estágios e ambientes
(INCOSE, 2015), e apresenta o contraste entre como os sistemas atuais se relacionam
operacionalmente e os processos em vigor (“As-is”) e o que se pretende obter uma vez que o
sistema a ser desenvolvido esteja em operação (“To-be”). O conceito de operações é realizado
com intuito de melhorar a qualidade do processo de tradução das necessidades dos stakeholders
em requisitos e entender os requisitos que a arquitetura deve satisfazer, de acordo com
necessidade de missão identificada (LARSON et al., 2009).
O Department of Defense Systems Management College (2001) afirma que o conceito
de operações deve conter as seguintes informações: definição da necessidade de missão, análise
da missão do sistema, linhas do tempo de operação, ambientes operacionais, condições e
eventos a que o sistema deve responder, restrições operacionais, requisitos de desempenho,
funções dos usuários e mantenedores dos sistemas, estrutura das organizações que irão operar
e manter os sistemas e interfaces operacionais com outros sistemas. Larson et al. (2009)
apresentam ainda mais duas sugestões com algumas diferenças para o conteúdo do ConOps,
uma própria e a outra oriunda da norma ANSI/AIAA G-043-1992 (ANSI; AIAA, 1993, apud
LARSON et al., 2009).
Kossiakoff e Sweet (2003) observam que no desenvolvimento de projetos, em geral, a
necessidade que se busca atender é, ao menos em parte, atendida por um sistema já existente.
Desta forma, defende a realização de uma pesquisa e análise de sistemas concorrentes ou
predecessores como atividade auxiliar na exploração de conceitos. Este tipo de pesquisa,
conhecida como benchmarking, é definida por Spendolini (1994, p. 11) como “um processo
contínuo e sistemático para avaliar produtos, serviços e processo de trabalho de organizações
que são reconhecidas como representantes das melhores práticas, com a finalidade de melhoria
organizacional”. Consoante com esta definição, Araújo (2001, p. 185) apresenta que o estudo
 45

de soluções adotadas, inclusive por organizações concorrentes, oferece “alternativas que

aperfeiçoam processos organizacionais, produtos e serviços”.
Ainda na análise das necessidades, segundo Kossiakoff e Sweet (2003), também é
realizada a análise funcional. Os use cases são representações de funções que o sistema deverá
desempenhar do ponto de vista do usuário, como deverá interagir com os atores (outros sistemas
ou pessoas) e como deverá responder. As funções não estabelecem como deve ser a arquitetura
do sistema, mas sim seu comportamento nas diversas funções que deverá desempenhar. Para
definição desta arquitetura, Douglass (2016) apresenta o seguinte fluxograma:
1. Identificação dos subsistemas;
2. Alocação de requisitos aos subsistemas;
3. Alocação de funções aos subsistemas;
4. Criação/atualização do esquema de dados lógicos;
5. Criação/atualização dos requisitos de subsistema;
6. Desenvolvimento das leis de controle;
7. Análise da dependabilidade;
8. Revisão.
Douglass (2016) argumenta que as etapas de 3 a 8 podem ter sua ordem alterada entre
si ou ser simultâneas. Ainda assim, o processo de definição da arquitetura continua iniciando
pela identificação de elementos do sistema, para só depois atribuir-lhes funções, o que é
refutado por Loures da Costa e Fulindi (2018), Friedenthal, Moore e Steiner (2015) e Back et
al. (2008), que defendem que as funções sejam definidas primeiro, e, em seguida, sejam
alocados os elementos que as desempenharão.
Para finalizar a fase de análise das necessidades, Kossiakoff e Sweet (2003) propõem a
definição de viabilidade de implementação, que resulta na descrição de um conceito coerente
para uma implementação física do sistema, e uma validação das necessidades dos stakeholders.
Durante a fase de exploração de conceitos proposta por Kossiakoff e Sweet (2003) são
realizadas as atividades de análise dos requisitos operacionais e formulação dos requisitos de
desempenho. Rozenfeld et al. (2006) e Back et al. (2008) classificam estas atividades,
juntamente com a análise de viabilidade econômica e a revisão do escopo do produto, como
integrantes da fase de projeto informacional.
Kossiakoff e Sweet (2003) acrescentam que, nesta fase, deve ocorrer ainda a exploração
de opções de conceitos viáveis para implementação física do sistema e a validação dos
requisitos de desempenho.
 46

A definição do conceito de Kossiakoff e Sweet (2003) é a fase em que são realizadas a

análise dos requisitos de desempenho, a formulação e análise funcional, a seleção e validação
do conceito (KOSSIAKOFF; SWEET, 2003).
O INCOSE (2015) refere-se à seleção do conceito como o terceiro passo do que nomeia
estágio conceitual, conforme apresentado na Figura 16. Entre as atividades que podem ser
realizadas neste estágio, o INCOSE (2015) lista a definição do conceito de operações, o estudo
de conceitos alternativos, a construção de modelos de engenharia, simulações e protótipos para
elementos críticos, auxiliando na análise de viabilidade dos conceitos.
Após o desenvolvimento conceitual são desenvolvidas outras atividades ligadas ao
detalhamento da documentação do produto e seus componentes, preparação para a produção e
lançamento (ROZENFELD et al., 2006; HALL, 1962; KOSSIAKOFF; SWEET, 2003).

2.3 Engenharia de sistemas aplicada a sistemas espaciais

Diferentes tipos de sistemas complexos (ex. sistemas automotivos, navais e

aeroespaciais) podem apresentar particularidades técnicas que demandem a criação de
processos específicos para o seu desenvolvimento. Para sistemas espaciais, por exemplo,
diversos autores propuseram modelos de desenvolvimento e conceitos próprios. A
nomenclatura e o encadeamento dos conceitos sob a perspectiva desses autores por vezes são
discordantes.
Wertz, Everett e Puschell (2011) modelam o seu processo de desenvolvimento de
sistemas espaciais a partir de uma abordagem de engenharia de missão espacial. Para esses
autores, a engenharia de sistemas se restringe ao processo formal de definição dos requisitos e
verificação se o sistema atende aos requisitos, enquanto a engenharia de missão espacial possui
um propósito mais amplo, englobando o refinamento desses requisitos e a definição dos
parâmetros de missão para se atingir os objetivos de uma dada missão espacial, de modo a
cumprir o cronograma e minimizar custos e riscos, validando os requisitos quanto à satisfação
das necessidades dos stakeholders.
O processo de engenharia de missões espaciais proposto por esses autores é composto
por quatorze passos, sendo os doze primeiros referentes à exploração do conceito (WERTZ;
EVERETT; PUSCHELL, 2011):
1) Definição dos objetivos (qualitativos) e restrições;
2) Definição dos principais stakeholders;
 47

3) Definição do cronograma do programa;

4) Estimativa quantitativa das metas, requisitos e restrições;
5) Definição de arquiteturas alternativas para a missão;
6) Definição de conceitos de operação alternativos para a missão;
7) Definição dos possibilitadores de desempenho do sistema e requisitos críticos;
8) Análise de compromisso e avaliação de desempenho;
9) Análise da utilidade da missão;
10) Definição de conceito de referência;
11) Revisão dos requisitos e restrições quantitativos;
12) Iterações e avaliação de alternativas;
13) Definição dos requisitos de sistema;
14) Alocação dos requisitos nos elementos do sistema.
Embora estes passos sejam numerados sequencialmente, o processo é altamente
iterativo. Os sete primeiros passos podem ser desempenhados por uma abordagem de
engenharia de sistemas, sendo incluídos nos modelos de estudo conceitual dos autores
estudados na Seção 2.2, compreendendo desde a definição das necessidades, objetivos e
restrições do projeto até a definição de requisitos críticos. Assim, pode-se utilizar a utilizar
engenharia de sistemas (ES) para gerar as entradas a serem utilizadas pelo processo que Wertz,
Everett e Puschell (2011) chamam de engenharia de missões espaciais (EME).
Uma vez que se tenha informações referentes aos passos de 1 a 7 (seja pelo emprego de
ES, seja pelo emprego de EME), a engenharia de missões espaciais pode executar os passos de
8 a 14, de modo a se avaliar o desempenho dos conceitos alternativos identificados e se realizar
os cálculos relativos à missão (WERTZ; EVERETT; PUSCHELL, 2011).
Desta forma, a engenharia de sistemas é capaz de fornecer as informações em nível mais
alto do projeto, e com base nestas informações a engenharia de missões espaciais realiza o
estudo de missão e os cálculos próprios à atividade espacial, permitindo comparar diferentes
configurações de missão (órbitas, constelações e dimensionamento de subsistemas, por
exemplo).
Observa-se ainda que o processo proposto por Wertz, Everett e Puschell (2011) não
contempla as tratativas entre a organização desenvolvedora e os demandantes que antecedem
ao início do projeto, as questões relativas à mobilização e preparação da equipe de projeto e as
pesquisas de campo acerca de sistemas similares, seus custos e potencialidades, para permitir
uma melhor preparação para a realização das etapas posteriores do desenvolvimento.
 48

Outros autores, como Larson et al. (2009) e Kossiakoff et al. (2011), por outro lado,
defendem que o processo de validação da satisfação das necessidades dos stakeholders é
abrangido pela engenharia de sistemas no ciclo de vida de um produto (conforme apresentado
no modelo Vee do ciclo de vida de sistemas, representado na Figura 17), evidenciando que há
divergências com relação aos limites de cada campo do conhecimento para diferentes autores.

Figura 17 – Modelo Vee da engenharia de sistemas, incluindo verificação (verifica se o

sistema atende aos requisitos) e validação (valida se o sistema atende às necessidades dos
stakeholders) (adaptado de KOSSIAKOFF et al. (2011)).

Uma obra que, embora apresente conceitos de engenharia de sistemas e projetos de

pequenos satélites, é focada em engenharia aeroespacial (abrangendo seus cálculos, técnicas e
ferramentas), é Spacecraft Systems Engineering, de Fortescue, Swinerd e Stark (2011), que
tratam de análise da missão, segmento solo, lançadores, condições ambientais, mecânica orbital,
montagem, integração e testes, bem como os principais subsistemas presentes em satélites.
Assim, esta obra pode ser utilizada para ambientar engenheiros de sistemas aos conceitos
relativos a sistemas espaciais ou ser um recurso para consulta e revisão por parte dos
especialistas sem, contudo, se propor a ser um guia completo e detalhado de engenharia de
sistemas.
Larson et al. (2009), por outro lado, apresentam uma obra focada em engenharia de
sistemas em que tratam de aspectos relativos ao desenvolvimento de sistemas espaciais e sua
relação com os segmentos envolvidos em seu ciclo de vida, exemplificando com o FireSAT,
 49

um satélite voltado a detecção de incêndios florestais nos EUA e Canadá. O FireSAT, que foi
concebido como estudo de caso didático e não se efetivou em um satélite real, teve seu conceito
explorado inicialmente em Space Mission Analysis and Design (SMAD) (LARSON; WERTZ,
1999) e Understanding Space (SELLERS, 2004).
Posteriormente, em Space Mission Engineering: The New SMAD, Wertz, Everett e
Puschell (2011) voltam a tratar do FireSAT e fazem considerações a respeito de seu elevado
custo, propondo uma abordagem alternativa para viabilizar seu desenvolvimento e lançamento:
o FireSAT II. O FireSAT II foi concebido para atender à mesma necessidade de missão que o
FireSAT original, mas com o objetivo adicional de ser de baixo custo. Para atender a este escopo
de missão, os autores exploram o aumento da capacidade dos pequenos satélites para viabilizar
o FireSAT II, tanto em termos financeiros (menores custos de desenvolvimento, produção e
lançamento) quanto de tempo de desenvolvimento.
Esta capacidade de viabilizar missões espaciais tem causado o aumento na quantidade
de pequenos satélites lançados anualmente, constatado por Ekpo e George (2013). Os autores
afirmam que este aumento demanda uma reavaliação da engenharia de sistemas aplicada a
seus projetos, dadas as condições especiais de desenvolvimento e operação dos pequenos
satélites. Neste sentido, Chang, Hwang e Kang (2007) propuseram a utilização do software
SEDT para reduzir tempo e custo de desenvolvimento de pequenos satélites.
Outro exemplo de missão hipotética oferecido por Wertz, Everett e Puschell (2011) é o
Supplemental Communications System (SCS), que visa a oferecer melhor comunicação a
militares e equipes de resgate em áreas remotas. Questões relativas a seleção de órbita,
lançamento e operações também são tratadas. Com relação aos satélites em si, aborda-se seu
design e seus diferentes subsistemas, com um capítulo dedicado a abordagens alternativas aos
grandes satélites, entre as quais pequenos satélites e CubeSats.
Loureiro (1999) propôs um modelo de referência para o desenvolvimento de sistemas
complexos (Figura 18), a partir de uma abordagem de engenharia simultânea de sistemas,
buscando integrar o sistema, os processos desempenhados ao longo de seu ciclo de vida e as
organizações envolvidas, desde seu desenvolvimento até o descarte. Este modelo evoluiu com
sua aplicação ao longo de vinte anos, principalmente no Laboratório de Engenharia Simultânea
de Sistemas (LSIS) do Instituto Nacional de Pesquisas Espaciais (INPE), onde é aplicado para
o desenvolvimento de sistemas espaciais, e une o escopo de duas abordagens (INPE, [s.d.];
LOUREIRO; PANADÉS; SILVA, 2018):
 50

• Engenharia de sistemas, que originalmente trata da definição da missão, do

conceito de operações e do produto nos diferentes níveis, englobando as
expectativas dos stakeholders, requisitos, funções e implementação (arquitetura
física e software);
• Engenharia simultânea, que originalmente trata do produto e da organização
em seus níveis mais baixos de hierarquia (por exemplo, nível componente para
o produto), quando as decisões de mais alto nível já foram tomadas.

Figura 18 – Modelo de referência para o desenvolvimento de sistemas complexos adaptado de

Loureiro, Panadés e Silva (2018).

Desta forma, o modelo em questão concilia a forma de aplicação da engenharia de

sistemas (que se envolve desde as fases iniciais do projeto) à engenharia simultânea, de
cooperação de times multifuncionais de projeto (LOUREIRO, 1999). Este modelo pode ser
empregado para diversos tipos de sistemas complexos, não sendo específico para sistemas
espaciais. Assim, sua utilização para o desenvolvimento de pequenos satélites demanda
adaptações, para se adequar as atividades ao nível de complexidade destes projetos.
 51

Asundi e Fitz-Coy (2013) defendem a importância da padronização do projeto dos

satélites para aumento de sua taxa de sucesso e confiabilidade. Asundi e Fitz-Coy (2013)
afirmam ainda que a abordagem utilizada para desenvolver satélites de maiores dimensões pode
não ser adequada às particularidades de plataformas com CubeSats. Deste modo, os autores
apresentam um modelo de engenharia de sistemas voltado para CubeSats das classes pico e
nano, baseado no NASA Systems Engineering Handbook (NASA, 2007).
Este modelo, apresentado na Figura 19 e descrito detalhadamente por Asundi (2011),
inicia-se pela definição de missão e dos objetivos primários e secundários. Elementos
gerenciais, elementos externos ao projeto e restrições, como custos, prazos e uma pesquisa de
campo para identificar lições aprendidas em missões anteriores e paralelas também são
considerados. As atividades são decompostas em duas vertentes, uma relacionada à operação
do sistema, que serve de subsídio para o estabelecimento dos modos de operação, e a outra
vertente relacionada à decomposição dos requisitos nos diferentes níveis, desde missão até sua
alocação nos elementos físicos (subsistemas e componentes, representados no interior do
retângulo tracejado Figura 19).
Com relação ao modelo de Asundi (2011), observa-se que os autores, coerentes com a
afirmação de Mendes (2018) acerca do alto grau de conhecimento prévio da arquitetura dos
básica de pequenos satélites, relacionam os nomes dos subsistemas em um retângulo, já
identificando os elementos físicos responsáveis por desempenhar as funções (ADCS, OBDH,
etc.). Desta forma, este modelo, embora facilite o relacionamento das soluções à medida em
que se reduz o nível de abstração, não é resiliente a modificações disruptivas na arquitetura dos
satélites, demandando, neste caso, uma revisão. Os processos de desenvolvimento são enxutos
e simplificados, e não há uma fase própria para exploração de conceitos de diferentes
configurações de órbitas e constelações, o que pode prejudicar o estudo de configurações
alternativas para a missão e um melhor embasamento para realização de análise de
compromisso.
 52

Figura 19 – Modelo de projeto para missões de CubeSat (adaptado de Asundi (2011)).

Eickhoff, Flemming e Fournie (2002) apresentam o processo Model-based development

& verification (MDVP) (desenvolvimento e verificação baseados em modelos), que, utilizando
um ambiente de engenharia de sistemas baseado em simulação (chamado de Model-based
development & verification – MDVE), visa a reduzir tempo e custos de projeto e aumentar o
controle acerca dos riscos do projeto de satélites. Por meio desta abordagem proposta pelos
autores (representada na Figura 20), após as fases iniciais (fase 0/A) de atividades de engenharia
de sistemas baseada em documentação, sejam realizadas as fases B, C, D e, opcionalmente, E,
utilizando modelos, a fim de permitir, por exemplo, a realização de simulação de características
funcionais, avaliações de desempenho do subsistema de controle de atitude, emulação do
computador de bordo e simulações envolvendo componentes físicos dos satélites. Observa-se
que este modelo reflete a estrutura organizacional para a qual o método foi desenvolvido,
corroborando a afirmação apresentada na Seção 2.2.3, de que a engenharia de sistemas baseada
 53

em documentação e a MBSE vem sendo combinadas em modelos híbridos, de acordo com

organizações e setores da indústria envolvidos (SEBOK CONTRIBUTORS, 2016; INCOSE,
2014).

Figura 20 – Modelo proposto por Eickhoff, Flemming e Fournie (2002).

2.4 Pequenos satélites

Conforme apresentado anteriormente, os modelos de desenvolvimento de produtos têm

se transformado para acompanhar a evolução tecnológica. No campo espacial, um exemplo
desta evolução é a miniaturização dos satélites, com o crescimento do número de pequenos
satélites construídos e lançados. São considerados pequenos os satélites com massa até 100 kg.
Há variação nas definições (SCHILLING; BRIEß, 2008, apud SCHMIDT, 2011), mas
usualmente os pequenos satélites são divididos nas seguintes subcategorias:
• Femtossatélite, quando a massa é inferior a 100 g (TRISTANCHO, 2010);
• Picossatélite, com massa entre 100g e 1 kg (TRISTANCHO, 2010);
• Nanossatélites, aqueles com massa compreendida entre 1 e 10 kg
(HAEUSLER; WIEDEMANN, 2008, apud SCHMIDT, 2011; TRISTANCHO,
2010);
• Microssatélites, são aqueles entre 10 e 100 kg (HAEUSLER; WIEDEMANN,
2008, apud SCHMIDT, 2011; TRISTANCHO, 2010).
 54

Uma configuração muito adotada para pequenos satélites é chamada de CubeSat.

CubeSats são baseados em plataformas modulares e padronizadas, cuja filosofia original era de
desenvolvimento de 1 a 2 anos realizado por universidades (WERTZ; EVERETT; PUSCHELL,
2011). O padrão para CubeSats é baseado em unidades cúbicas (Us), de 10 cm de aresta e de
massa inferior a 1,33 kg, tendo sido criado pelos professores Jordi Puig-Suari e Robert Twiggs,
em 1999. O custo de seu desenvolvimento, construção, testes e lançamento somados costuma
variar entre USD 50.000,00 e 200.000,00, dependendo dos equipamentos e instrumentos
embarcados (SELVA; KREJCI, 2012).
Os satélites usualmente são divididos em duas partes principais: cargas úteis e
plataforma. As cargas úteis são os subsistemas e componentes voltados à satisfação da
necessidade dos stakeholders, enquanto a plataforma fornece suporte, energia, apontamento e
comunicações às cargas úteis (FORTESCUE; SWINERD; STARK, 2011; WERTZ,
EVERETT; PUSCHELL, 2011).
Subsistemas de comunicação podem ser tanto integrantes exclusivamente da
plataforma, quanto integrantes da plataforma e também das cargas úteis, a depender da missão
do satélite. Os subsistemas de comunicação permitem o contato entre o satélite e a estação de
solo ou outros satélites, transmitindo tanto dados das cargas úteis quanto da plataforma, além
de receber telecomandos (comandos do solo para o satélite) (POGHOSYAN; GOLKAR, 2017).
Com relação à taxa de transmissão, CubeSats têm atingido de 9,6 kbps a 3 Mbps,
utilizando as bandas UHF e VHF (BOUWMEESTER, 2010; MURI; McNAIR, 2012; FISH et
al., 2012, apud POGHOSYAN; GOLKAR, 2017). Contudo, atualmente estão sendo
desenvolvidos CubeSats de 1,5 U visando a atingir 100 Mbps em banda Ka (NASA, 2018), e
500 Mbps com comunicação óptica (JANSON et al., 2015, apud POGHOSYAN; GOLKAR,
2017).
Schmidt (2011) afirma que, com os avanços tecnológicos realizados na área dos
pequenos satélites, observa-se a tendência de que progressivamente venham a desempenhar
missões antes reservadas aos satélites maiores, com vantagens sobre estes, tais quais: ciclo de
desenvolvimento mais rápido, menores custos de desenvolvimento e lançamento. Geralmente
pequenos satélites são lançados como carga secundária, em conjunto com outros pequenos
satélites e/ou acompanhando um satélite maior. Como Karabeyoglu et al. (2005, apud
SCHMIDT, 2011) ressaltam, o custo para se levar um objeto ao espaço possui uma relação
direta com sua massa, de modo que ao se reduzir a massa do satélite, reduz-se também seu custo
de lançamento (embora, para uma constelação de satélites, se tenha que considerar os custos
 55

advindos do aumento do número de satélites necessários para uma constelação e da necessidade

de um número maior de lançamentos para sua reposição, dentre outros fatores).
Desta forma, Woellert et al. (2011) apresentam em seu trabalho que o desenvolvimento
de pequenos satélites é uma alternativa para países emergentes terem acesso ao espaço, bem
como promoverem seu aprimoramento científico e tecnológico.
Pequenos satélites têm, ainda, sido de interesse para aplicações militares, o que se pode
verificar pelos programas Space Missile Defense Command - Operational Nanosatellite Effect
(SMDC-ONE) e SMDC Nanosatellite Program (SNaP), desenvolvidos pelo Exército do EUA,
visando à realização de estudos relativos ao estabelecimento de comunicações com rádios
militares padrão a distância (GUNTER’S SPACE, 2018b) e ao desenvolvimento de rádios
definidos por software para comunicação além da linha de visada com usuários móveis que
estejam em locais remotos (GUNTER’S SPACE, 2018c), respectivamente.
A partir do que foi apresentado nesta seção, observa-se que há espaço para
implementação de novos desenvolvimentos e melhorias na área de pequenos satélites, e suas
potencialidades permitem vislumbrar que, no futuro, seu campo de aplicações seja ampliado.

2.5 Posicionamento do trabalho

Conforme apresentado no capítulo de introdução deste trabalho, o PESE explicita uma

demanda por comunicações militares confiáveis que atendam a forças táticas móveis na área de
interesse da Defesa (o que inclui a região amazônica) (MINISTÉRIO DA DEFESA, 2018). As
alternativas de solução não baseadas em satélites utilizadas atualmente apresentam deficiência
em cobertura, e mesmo soluções baseadas em VANTs, que têm sido pesquisadas (MOURA,
2018), não são adequadas para cobrir toda a região. As soluções satelitais em uso atualmente
(SGDC, Star One C1 e Star One C2) também são inadequadas para atender às tropas realizando
missões de patrulhamento de selva e/ou fronteira, dadas as dimensões dos equipamentos
utilizados para comunicação em banda X e a maior vulnerabilidade estratégica.
Soluções baseadas em pequenos satélites não-geossíncronos têm demonstrado potencial
para resolver este problema, como já foi relatado anteriormente nesta revisão da literatura.
Neste mesmo sentido, o PESE define que as comunicações de banda estreita para atender a
forças táticas móveis devem ser providas por uma constelação de satélites de baixa órbita.
Contudo a descrição da operação do produto, bem como o estudo conceitual desta constelação,
estão pendentes de definição.
 56

Não foram encontrados trabalhos ou desenvolvimentos acerca de pequenos satélites de

comunicações para atender a tropas móveis na selva amazônica. Embora existam pesquisas
relacionadas a comunicações militares por parte do exército estadunidense, como os programas
SMDC-ONE e SNaP apresentados na Seção 2.4 deste trabalho, tais programas estão ainda no
nível de demonstração de tecnologia, e a simples reutilização de resultados de outros projetos
não se mostra adequada à demanda por comunicações apresentada, pois os stakeholders e suas
necessidades são outros, bem como área de cobertura pretendida, o que interfere em todo o
projeto, incluindo requisitos operacionais e órbitas, por exemplo.
Amparando-se na premissa do potencial de satélites pequenos, o presente trabalho
pretende sanar parte da lacuna apresentada, por meio da realização do estudo conceitual de uma
constelação de pequenos satélites para prover comunicações de banda estreita a forças tática
móveis do Exército Brasileiro, na região amazônica.
Para viabilizar o estudo conceitual da constelação de pequenos satélites de
comunicações de banda estreita para o Exército Brasileiro, identificou-se a necessidade de
utilização de um método sistematizado, com atividades e recursos bem definidos, que suporte
o desenvolvimento do projeto.
Segundo o INCOSE (2014), os modelos que implementam os processos e produtos são
particulares a cada organização. Desta forma, é preciso também que o método esteja alinhado
com as características organizacionais da instituição desenvolvedora. Esta instituição é
composta por uma equipe reduzida, de cerca de 15 (quinze) pesquisadores, e, portanto, adapta
os processos de desenvolvimento à sua realidade organizacional, utilizando princípios presentes
no Manifesto Ágil, como equipes auto-organizáveis, priorização da comunicação presencial e
valorização do relacionamento entre os indivíduos acima de procedimentos burocráticos e
hierarquizados. Esta estrutura e a cultura organizacional do desenvolvedor demandam um
método enxuto (que evite atividades redundantes ou que não agreguem valor ou confiabilidade
ao produto), claro (as atividades, ferramentas, pessoal envolvido, entradas e saídas devem estar
explicitadas para cada etapa) e flexível (cujas atividades possam ser realizadas
concomitantemente, revisadas e alteradas se necessário, sem culminar, obrigatoriamente, em
interrupções do projeto).
A existência de um método estruturado também pode subsidiar um melhor
acompanhamento do projeto por parte de seus stakeholders, facilitando o relacionamento entre
as partes interessadas e contribuindo para a transparência do processo.
 57

Neste trabalho, propõe-se que este método integre atividades de engenharia de sistemas
(pautada nas abordagens baseada em documentação e baseada em modelos), a partir de
abordagens estabelecidas por diferentes autores e adaptado às características do
desenvolvimento de constelações de pequenos satélites.
A aplicação de métodos de engenharia de sistemas é consolidada entre as principais
organizações que realizam desenvolvimento ou aquisição de sistemas complexos, como o DoD,
a NASA e a Agência Espacial Europeia (ESA). Diversos autores, como Sage e Rouse (2009),
Larson et al. (2009), Kossiakoff e Sweet (2003) e INCOSE (2015), defendem sua importância
para assegurar que o sistema desenvolvido efetivamente atenda às necessidades dos
interessados no projeto, além de permitir maior previsibilidade de custos do projeto.
Como já apresentado nesta revisão da literatura (Seção 2.2.3), a engenharia de sistemas
tem passado por uma transição, de um modelo baseado em documentos para modelos baseados
em modelos, como MBSE (DOUGLASS, 2016; DELLIGATTI, 2014; FRIEDENTHAL;
MOORE; STEINER, 2015). No entanto, a MBSE está ainda em um estágio inicial de
maturidade. Em geral, a MBSE não tem sido aplicada de maneira exclusiva, mas sim em
conjunto com processos de engenharia de sistemas tradicional (ESTEFAN, 2008, apud SEBOK
CONTRIBUTORS, 2016; INCOSE, 2014).
Conforme apresentado na Seção 2.3 deste trabalho, diversos autores propuseram
modelos de desenvolvimento de produtos baseados em engenharia de sistemas. A tabela
sinótica (Tabela 1) sintetiza alguns dos principais trabalhos de engenharia de sistemas que
contemplam o estudo conceitual e podem ser aplicados para o desenvolvimento de sistemas
espaciais, comparados quanto aos seguintes critérios:
• Abordagem de engenharia de sistemas: é apresentada a abordagem de
engenharia de sistemas adotada em cada um dos trabalhos (baseada em
documentação, em modelos, combinada com engenharia simultânea, etc.);
• Orientação do modelo: descreve os sistemas para os quais cada modelo foi
desenvolvido;
• Estudo de órbitas, constelações e subsistemas para satélites: indica se o
modelo contempla totalmente, parcialmente ou não contempla o estudo de
órbitas, constelações e subsistemas para satélites.

Tabela 1 – Tabela sinótica dos principais modelos encontrados na literatura e deste trabalho.
Critérios /
Larson et al. (2009)
Autores
Apresentam um método de
desenvolvimento de sistemas
espaciais empregando engenharia de
sistemas baseada em documentação.
Também defendem a possibilidade
Abordagem
de utilização dos requisitos para
de gerar modelos, que auxiliam no
engenharia entendimento do comportamento do
de sistemas sistema e determinação da
completude dos requisitos. Porém
afirmam que os modelos não
eliminam a necessidade de
construção do sistema para verificar
se o mesmo atende aos requisitos
Orientação Orientado ao desenvolvimento de
do modelo satélites e segmento solo em geral
Estudo de
órbitas, Não contemplam. Indicam a
constelações importância do estudo de órbitas e
constelações, mas não apresentam
e as equações pertinentes para tal,
subsistemas
tampouco para o dimensionamento
para
dos subsistemas
satélites
58
Wertz, Everett e Eickhoff, Flemming e
Loureiro (1999) Asundi (2011) Este trabalho
Puschell (2011) Fournie (2002)
Apresenta um modelo
visando à padronização
Apresenta um Apresentam uma abordagem
do projeto de pequenos
modelo de referência que utiliza engenharia de Modelo híbrido de engenharia
Apresentam um método satélites, considerando as
para o sistemas baseada em de sistemas baseada em
de desenvolvimento de particularidades do
desenvolvimento de documentação integrada a um documentação e em modelos,
sistemas espaciais projeto de CubeSats.
produtos, integrando ambiente de simulação e para o estágio de estudo
empregando engenharia Para tal, o autor utiliza a
engenharia de desenvolvimento baseado em conceitual do
de sistemas baseada em abordagem de
sistemas, baseada em modelos para geração de desenvolvimento de satélites,
documentação, bem engenharia de sistemas
documentação e requisitos, análise operacional combinando elementos de
como ambientes de baseada em
também em modelos, e funcional, estudo das trabalhos consolidados na
simulação documentação, aliada a
e engenharia interfaces, testes e apoio a literatura
modelos, como por
simultânea operação
exemplo, para identificar
requisitos de interface
Modelo não
específico para
Orientado ao sistemas espaciais,
Modelo voltado para Orientado ao desenvolvimento
desenvolvimento de podendo ser utilizado Orientado ao desenvolvimento
projeto de CubeSats das de satélites e segmento solo em
satélites e segmento solo para de pequenos satélites
classes pico e nano geral
em geral desenvolvimento de
outros tipos de
sistemas complexos
Não contemplam. Não contemplam. É São
Como o objetivo é apresentadas as atividades que
Contemplam
abranger sistemas de o Ambiente de Contempla parcialmente. O
Contemplam totalmente. parcialmente. O método
diversas naturezas, Desenvolvimento e método proposto neste
Apresentam um método ampara o estudo de
não são mostrados Verificação Baseado em trabalho se restringe a
detalhado, com conceitos subsistemas, mas não são
e equações, que permite
conceitos e equações
apresentados conceitos e
Modelos deve cumprir, mas apresentar conceitos e
pertinentes à não são apresentados conceitos orientações para o estudo de
o estudo da missão por equações pertinentes à
engenharia e equações pertinentes à órbitas, constelações e
completo engenharia aeroespacial
aeroespacial e ao engenharia aeroespacial e ao subsistemas dos satélites
para cálculo de órbita
dimensionamento dimensionamento dos
dos subsistemas subsistemas
 59

Observa-se na Tabela 1 que há métodos pautados de forma predominante em

documentação, podendo ser apoiados ou não por modelagem, e outros que conduzem o
desenvolvimento, necessariamente, por meio do emprego de modelos e ambientes de
simulação. Há ainda autores que focam o trabalho unicamente em engenharia de sistemas,
apenas indicando as atividades que devem ser desempenhadas pelas demais áreas de
engenharia, enquanto outros apresentam os conceitos e equações de engenharia aeroespacial de
modo a servir de base para estudos mais aprofundados acerca da missão.
Neste contexto, a contribuição deste trabalho consiste em apresentar uma proposta de
um método para o estudo conceitual de satélites a partir das melhores práticas identificadas em
obras consolidadas, com as características descritas nos tópicos a seguir, que será detalhado no
próximo capítulo, e aplicá-lo para o desenvolvimento do conceito de uma constelação de
pequenos satélites não-geossíncronos para prover comunicações de banda estreita a forças
táticas móveis do Exército Brasileiro na região amazônica:
• Modelo híbrido de engenharia de sistemas baseada em documentação e em
modelos, para o estágio de estudo conceitual do desenvolvimento de satélites,
combinando elementos de trabalhos consolidados na literatura;
• Orientado ao desenvolvimento de pequenos satélites;
• Contemplando conceitos e orientações para o estudo de órbitas, constelações e
subsistemas;
• Enxuto, com quantidade e complexidade de atividades condizentes com o
desenvolvimento de pequenos satélites e com a organização desenvolvedora;
• Claro, explicitando as atividades, recursos, entradas e saídas de cada etapa;
• Flexível, permitindo a execução simultânea de atividades em uma dinâmica
iterativa.
 60

3 Método

Este capítulo apresenta o método de engenharia de sistemas proposto para realizar o

estudo conceitual de constelações de pequenos satélites, provendo os subsídios de apoio a
decisão para a realização da definição do conceito, isto é, a seleção das configurações de órbita,
constelação e satélites a serem desenvolvidas para atender a uma missão específica. Esta
abordagem híbrida integra elementos de engenharia de sistemas baseada em documentação e
MBSE (engenharia de sistemas baseada em modelos), sendo fundamentada pelas proposições
de Hall (1962); Kossiakoff e Sweet (2003); Rozenfeld et al. (2006); Larson et al. (2009);
Loureiro (1999); Asundi (2011); Eickhoff, Flemming e Fournie (2002); Fortescue, Swinerd e
Stark (2011); Wertz, Everett e Puschell (2011); PMI (2013); INCOSE (2015); Douglass (2016)
e Loures da Costa e Fulindi (2018), e pode ser adaptado para desenvolver, além de pequenos
satélites, mísseis e outros sistemas complexos.
Este trabalho trata do projeto do ponto de vista da organização desenvolvedora, também
referida como “desenvolvedor”, que é a entidade, instituição ou organização responsável por
planejar e executar o projeto, apresentando as características de estrutura enxuta e seguindo os
princípios do Manifesto Ágil, conforme descrito no posicionamento deste trabalho (Seção 2.5).
Por meio da aplicação deste método, a partir de informações preliminares sobre os
stakeholders, suas funções e necessidades, objetiva-se chegar aos conceitos de sistemas, com
órbitas, configurações de constelação e parâmetros de desempenho para os subsistemas (com
identificação dos componentes, se possível). O método foi estruturado para ser enxuto e com
descrição clara e didática das ações, recursos e informações de entrada e saída envolvidas, sendo
dividido em seis etapas, cada uma com as suas respectivas atividades, como é apresentado na
Figura 21.
 61

Figura 21 - Etapas e atividades do método proposto neste trabalho.

A primeira etapa (iniciação) corresponde ao início do projeto, na qual o processo de

desenvolvimento é autorizado pelas organizações envolvidas e são definidas a necessidade de
missão do projeto, seu prazo e orçamento preliminares.
A segunda etapa (benchmarking) compreende a pesquisa comparativa de sistemas
existentes para atender a necessidades semelhantes às apresentadas pelos stakeholders na
iniciação. A partir desta análise, é possível identificar as características de cada sistema
comparado e suas potencialidades e deficiências.
A segunda etapa é também uma preparação para a terceira etapa (objetivos e metas),
na qual se entrevistam os principais stakeholders externos e levantam-se suas expectativas com
relação ao sistema, os objetivos e metas e os requisitos de alto nível do projeto.
Uma vez identificadas as expectativas dos stakeholders, na quarta etapa (conceito de
operações), definem-se as fronteiras do sistema, constroem-se os cenários de operação e
sequências de operações e determinam-se as funções dos nós operacionais.
Na quinta etapa (arquiteturas funcional e física), partindo dos cenários de operações,
é identificada a arquitetura funcional do sistema de interesse e são definidos os elementos
físicos (subsistemas e componentes) necessários para desempenhar as referidas funções, bem
como os requisitos de baixo nível.
A sexta etapa (exploração de conceitos) visa a estudar alternativas de órbitas,
constelações e configurações de satélites para fornecer aos stakeholders informações que lhes
 62

permitirão selecionar o conceito que deverá ser desenvolvido. Assim, as Etapas de 1 a 5 podem
ser aplicadas tanto para o desenvolvimento de satélites, quanto para mísseis e outros sistemas
complexos, enquanto a Etapa 6 é específica para satélites.
Conforme apresentado, o método proposto é híbrido, combinando elementos de
engenharia de sistemas baseada em documentação e engenharia de sistemas baseada em
modelos (MBSE). O emprego de engenharia de sistemas baseada em documentação em
conjunto com MBSE é alinhado com a forma como a MBSE vem sendo aplicada atualmente
(SEBOK CONTRIBUTORS, 2016; INCOSE, 2014). Apesar das vantagens da MBSE
apresentadas na Seção 2.2.3 da revisão da literatura deste trabalho (tais como precisão e
consistência dos dados de engenharia, melhor visualização dos dados de engenharia e facilidade
em seu gerenciamento (DOUGLASS, 2016)), Weilkiens (2011, apud SCHEEREN, 2013)
destaca que o emprego de modelos deve restringir-se apenas a partes do projeto em que pode
reduzir custos ou beneficiar o funcionamento do sistema.
Desta forma, as duas primeiras etapas do método proposto neste trabalho utilizam a
abordagem de engenharia de sistemas baseada em documentação. Para a Etapa 1 (iniciação),
mais ligada ao planejamento e controle do projeto, isto se deve ao fato de as informações
referentes ao projeto ainda serem reduzidas, não demandando modelos e podendo ser expressas
e formalizadas com mais clareza em termos textuais. Este formato textual favorece também a
revisão por parte dos departamentos jurídicos das entidades envolvidas, que provavelmente
serão consultados. Para a definição e mobilização da equipe de projeto, também se julgou que
não haveria aplicabilidade para a utilização de modelos.
Com relação ao benchmarking (Etapa 2), por consistir em uma pesquisa acerca de
características técnicas que, em geral, resulta em tabelas comparativas, não se vislumbram
benefícios que justifiquem o emprego de modelos. Por outro lado, verificou-se que, embora
algumas das obras de engenharia de sistemas estudadas defendessem que fosse realizada a
pesquisa de campo acerca de sistemas semelhantes já desenvolvidos ou em desenvolvimento,
estas obras não estruturavam o modo como se deveria realizar esta atividade. Este trabalho
pretende contribuir para sanar esta lacuna, com um direcionamento sistematizado para realizar
a atividade de benchmarking.
Já para a terceira etapa (objetivos e metas), propõe-se que seus resultados sejam
incorporados aos modelos em SysML gerados para gerenciamento de requisitos, com o objetivo
de manter a consistência e a rastreabilidade nos documentos. Assim, sugere-se a utilização de
 63

elementos de MBSE para contribuir com a segunda e terceira atividades (definição dos
objetivos e metas do projeto e requisitos de alto nível) desempenhadas nesta etapa.
Para a quarta etapa (conceito de operações), propõe-se a utilização de diagramas para
representar os contextos e sequências de operações referentes ao sistema. Embora estes
diagramas sejam modelos, não há consenso na literatura para se classificar esta etapa como uma
abordagem a partir de MBSE. Os próprios autores em que se baseou a estruturação desta etapa,
Larson et al. (2009), apresentam estes diagramas em sua obra sem relacioná-los à MBSE. Desta
forma, neste trabalho, esses diagramas também não foram classificados como integrantes da
abordagem MBSE.
A maneira proposta neste trabalho para estruturar a quinta etapa (arquiteturas
funcional e física) prevê a utilização de elementos de MBSE, na forma dos diagramas de
sequência e em SysML. A intenção ao se utilizar estas ferramentas nesta etapa é beneficiar-se
de uma visualização mais intuitiva da operação do sistema, além da automatização na geração
de representações alternativas (modelos ou textuais) e da rastreabilidade dos requisitos,
melhorando sua consistência e controle, conforme defende Douglass (2016). Por exemplo, no
caso de se excluir um requisito de mais alto nível, os requisitos derivados exclusivamente dele
podem ser excluídos automaticamente, evitando problemas de desatualização devido à presença
de requisitos que tenham perdido sua rationale, isto é, sua razão de existir no projeto.
A sexta etapa se diferencia das demais por ser específica para satélites, exigindo um
elevado apoio técnico das disciplinas específicas de engenharia aeroespacial, não empregando
o que a literatura classifica como MBSE.
Cabe ressaltar que, dado o caráter iterativo dos processos baseados em engenharia de
sistemas, a estruturação em etapas não significa que o modelo seja sequencial. Ocorre, ao longo
do processo de desenvolvimento, flexibilidade para sobreposição de etapas, interação entre os
stakeholders (que não é restrita às entrevistas com os stakeholders) e possíveis mudanças e
alterações que levem à revisão de etapas anteriores.
Assim, o método proposto é alinhado com o Manifesto Ágil (AGILE, 2001), na medida
em que, na busca pelo desenvolvimento eficiente de um pequeno satélite, são valorizados os
indivíduos e suas interações acima dos processos e ferramentas, requisitos corretos e
verificáveis acima da documentação completa, a colaboração entre os stakeholders acima da
negociação de contratos, e a adaptabilidade a mudanças acima de seguir um plano.
 64

3.1 Etapa 1: Iniciação

A fim de se iniciar o projeto, são necessárias informações para definição de seu escopo,
isto é, qual a finalidade do projeto, qual o prazo para lançamento do produto ou início de
operação do sistema e qual a disponibilidade de recursos ou estimativa de custo. Estas
atividades estão contempladas nas obras de Back et al. (2008) e Rozenfeld et al. (2006) na fase
de planejamento do projeto. Estes autores também elencam outras atividades para esta fase,
como definição de cronograma estabelecendo prazos para os principais marcos do processo de
desenvolvimento (datas das revisões de projeto, entre outros), elaboração do plano de gestão de
riscos, plano de segurança, plano de suprimentos e gerenciamento das comunicações. Tendo
em vista que estas últimas atividades estão mais relacionadas ao planejamento e controle do
projeto (na definição de gestão de projetos de Kossiakoff e Sweet (2003), apresentada na Seção
2.1 da revisão da literatura deste trabalho), elas não serão tratadas neste trabalho, que foca nos
aspectos mais vinculados à engenharia de sistemas.
Propõe-se que esta etapa seja dividida em duas atividades, a Atividade 1.1 e a Atividade
1.2. Na Atividade 1.1 é realizado o alinhamento entre os principais stakeholders. A Atividade
1.2 tem como objetivo definir e mobilizar a equipe de projeto. A Tabela 2 apresenta os
objetivos, informações de entrada, métodos e ferramentas, envolvidos e resultados obtidos após
a finalização desta etapa.

Tabela 2 – Descrição dos objetivos, informações de entrada, métodos e ferramentas,

envolvidos no processo e resultados relativos a cada uma das atividades da Etapa 1.

Informações de Métodos e
Atividade Objetivos Envolvidos Resultados
entrada ferramentas
1.1: -Definir o -Informações -Reuniões -Responsáveis -Escopo do
Alinhamen- escopo do preliminares sobre designados projeto
to entre os projeto os stakeholders e pela
principais suas funções organização -Autorização
stakehol- -Decidir desenvolve- para início do
ders pelo início -Informações dora projeto
do projeto preliminares sobre
a necessidade dos -Stakeholders
stakeholders externos
externos
 65

Informações de Métodos e
Atividade Objetivos Envolvidos Resultados
entrada ferramentas
1.2: -Definir a -Escopo do -Reuniões -Responsáveis -Equipe de
Definição e equipe de projeto designados projeto definida
mobilização projeto pela e mobilizada
da equipe do organização
projeto -Mobilizar a desenvolve-
equipe de dora
projeto

3.1.1 Atividade 1.1: Alinhamento entre os principais stakeholders

A identificação da necessidade e o interesse para início do desenvolvimento de um

produto ou processo pode ser manifestado por uma entidade demandante ou provocado pela
organização desenvolvedora, que apresenta àquela oportunidades ou deficiências para se
trabalhar. Assim, a iniciativa pode partir de qualquer um dos atores e de formas tão variadas e
complexas quanto as relações humanas, seja por meio de workshops, visitas a possíveis clientes,
ou mesmo a partir de uma ideia surgida em uma ocasião informal. Essas questões não fazem
parte do escopo do presente trabalho, que visa a tratar do projeto com ênfase nas atividades
mais técnicas, conforme apresentado na introdução (Capítulo 1) deste trabalho.
Os objetivos desta atividade são definir o escopo do projeto, contendo a necessidade de
missão, o tipo de solução, em alto nível, que será desenvolvido no projeto (ex. satélite, veículo
terrestre, máquina de solda), e, se for o caso, a estimativa de prazo e o orçamento preliminar do
projeto. O orçamento e o prazo podem ser mais simples de se definir para projetos acerca dos
quais os stakeholders tenham maior familiaridade. Por vezes, o orçamento e o prazo são
restrições impostas previamente pelos demandantes ou financiadores. Também pode-se
considerar que seja necessário se avançar nos estudos para se obter uma estimativa de
orçamento (informações como a quantidade e o tipo de satélites em órbita, por exemplo,
somente serão identificadas em etapas posteriores). De qualquer forma, tanto orçamento quanto
prazo são informações que devem ser refinadas ao longo de todo o processo de desenvolvimento
do produto. Nesta atividade também se deve decidir pelo início ou não do projeto.
Para este trabalho, assume-se como premissa que já se tem uma ideia preliminar de
quem são os stakeholders e suas funções no projeto e qual é a necessidade motivadora do
projeto. A organização desenvolvedora e os demais interessados no projeto (contratantes,
fornecedores, agências reguladoras, fundações de fomento, etc.) são denominados stakeholders
do projeto. A fim de evitar ambiguidades, neste trabalho a organização desenvolvedora será
 66

denominada como “organização desenvolvedora” ou “desenvolvedor”, enquanto os demais

stakeholders serão chamados de “stakeholders externos”.
Para cumprir esta atividade, sugere-se a realização de reuniões dos colaboradores da
organização desenvolvedora com os stakeholders externos envolvidos no início do projeto. Os
stakeholders externos devem ser estimulados a expressarem livremente suas necessidades,
apresentando os desafios ou oportunidades de negócios que identificaram e motivaram o
contato com o desenvolvedor, conforme defende PMI (2013).
Com base nas necessidades dos stakeholders externos podem-se discutir possíveis
soluções e o desenvolvedor pode apresentar quais competências técnicas detém, de modo que
as partes decidam por uma solução específica para o projeto. Pode ocorrer também um processo
decisório acerca do engajamento ou não da organização desenvolvedora no projeto, envolvendo
análise do portfólio do desenvolvedor, seus objetivos, recursos disponíveis, questões
financeiras e possivelmente políticas (PMI, 2013). Os processos para tomadas das decisões
apresentadas neste parágrafo não são objeto de estudo e aprofundamento deste trabalho, tendo
um caráter de contextualização e sugestão.
Como resultado desta atividade, representantes da organização desenvolvedora e os
demais stakeholders devem estabelecer o escopo do projeto, incluindo a necessidade de missão,
o tipo de solução de projeto, o orçamento preliminar e o prazo de execução. Por último, estando
todos de acordo, deve-se autorizar o início do projeto, por meio da formalização de sua
aprovação e contratação. Não será apresentada neste trabalho a estruturação dos processos de
aprovação e contratação de projetos. Da parte da organização desenvolvedora, devem ser
elencados colaboradores estratégicos para participar dessas reuniões, podendo incluir
presidente, diretor, coordenador, gerente, engenheiro de sistemas, assessor jurídico ou outros.
A definição, mesmo que preliminar, do orçamento e do prazo de execução do projeto são
importantes, pois apresentam restrições que irão se aplicar em decisões ao longo de todo o
desenvolvimento do projeto.

3.1.2 Atividade 1.2: Definição e mobilização da equipe de projeto

Uma vez autorizado o início do projeto e resolvidas as questões contratuais com os

stakeholders, inicia-se a Atividade 1.2, que tem como objetivos selecionar os membros da
equipe desenvolvedora que trabalharão no projeto (também chamada, neste trabalho, de “equipe
de projeto”), além de mobilizá-los, organizá-los e informá-los acerca do escopo do projeto.
 67

Para isso, propõe-se uma reunião entre os decisores da organização desenvolvedora, que
devem determinar as funções (gerente de projeto, engenheiro de sistemas, especialistas, etc.) a
serem desempenhadas pela equipe para o desenvolvimento do projeto e elencar as pessoas da
organização (ou contratar outras pessoas) para assumir cada uma das funções (Tabela 3).
Ressalte-se a importância de se constituir uma equipe de projeto multidisciplinar, para o
desenvolvimento de sistemas complexos.

Tabela 3 – Lista de funções e responsáveis da equipe de projeto.

Função Pessoas responsáveis

Função 1 Pessoas 1
Função 2 Pessoas 2
Função 3 Pessoas 3
Função 4 Pessoas 4

Para finalizar a etapa de iniciação, propõe-se a realização de uma reunião para apresentar
o escopo preliminar do projeto à equipe, as funções de cada pessoa e oficializar o início do
desenvolvimento.

3.2 Etapa 2: Benchmarking

Uma vez iniciado o projeto e conhecido o seu escopo, propõe-se a realização de um

benchmarking na forma de um processo estruturado, alinhado com a definição dos autores
Spendolini (1994) e Araújo (2001). Um processo de benchmarking realizado neste momento
do desenvolvimento pode fornecer uma visão inicial de quais níveis de desempenho podem ou
não ser alcançados e quais os custos para cada nível, permitindo uma melhor preparação para a
realização das etapas posteriores do projeto, de modo que se propõe que o benchmarking seja
realizado como segunda etapa do método. Para os casos em que não se tenha conhecimento
suficiente acerca do tipo de solução a ser utilizado, pode-se adiar a realização do benchmarking,
até o momento em que a arquitetura do sistema seja melhor conhecida. Ressalta-se ainda a
característica iterativa do método, permitindo que os resultados do sejam revisitados e
complementados posteriormente, caso se julgue necessário.
Indica-se, neste trabalho, que esta etapa seja dividida em duas atividades (Tabela 4),
sendo a primeira o estabelecimento dos critérios do benchmarking e a segunda a pesquisa e
 68

comparação dos sistemas e tecnologias. Durante esta etapa ainda é possível levantar restrições
intrínsecas que sistemas similares apresentam, sejam elas devidas a imposições legais ou
normativas, sejam devidas às capacidades tecnológicas do período do desenvolvimento.

Tabela 4 – Descrição dos objetivos, informações de entrada, métodos e ferramentas,

envolvidos no processo e resultados relativos a cada uma das atividades da Etapa 2.

Atividade Objetivos Informaçõ Métodos e Envo- Resultados

es de ferramentas lvidos
entrada
2.1: -Definir os critérios para -Escopo do -Reuniões -Equipe -Critérios de
Definição seleção dos sistemas a projeto de pro- seleção de
dos crité- serem estudados -Métodos jeto sistemas
rios de intuitivos de
benchmar- - Definir as características geração de -Características
king técnicas críticas dos ideias técnicas
sistemas a serem estudados relevantes
2.2: -Realizar a pesquisa de -Escopo do -Pesquisa na -Equipe -Sistemas a
Pesquisa de benchmarking projeto Internet e em de pro- serem estudados
benchmar- bancos de jeto
king -Critérios dados -Comparativo de
de seleção características
de sistemas -Reuniões técnicas
-Caracterís- -Ferramentas -Definição da(s)
ticas colaborativas referência(s)
técnicas de edição de para o projeto
relevantes documentos

3.2.1 Atividade 2.1: Definição dos critérios de benchmarking

Uma vez que a equipe seja informada a respeito do escopo preliminar do projeto,
propõe-se que ela se reúna para estabelecer os critérios de seleção de sistemas a serem
estudados no benchmarking e quais as características técnicas de cada sistema que devem ser
analisadas.
Os critérios de seleção de sistemas são aqueles que estabelecem se um sistema será
usado como modelo comparativo no benchmarking. Um exemplo de critério é a data de
desenvolvimento do sistema, para filtrar apenas soluções mais recentes. Outro critério poderia
ser a quantidade de informações disponíveis a respeito dos sistemas.
Características técnicas relevantes são ligadas à arquitetura ou desempenho dos
sistemas, como massa, alcance de transmissão, tipo de motor utilizado em uma aeronave e de
 69

computador de missão. Estas características servirão para que, após realizar a seleção dos
sistemas alvo de estudo, a equipe possa compreender e comparar cada um deles.
Para a realização desta atividade, propõe-se que sejam empregados métodos intuitivos
de geração de concepções e ideias, como brainstorming (BACK et al., 2008).
Ao final desta atividade deve-se confeccionar uma lista com os critérios para seleção
dos sistemas que serão estudados e uma tabela com as características técnicas julgadas
relevantes, que serão os parâmetros de comparação entre os sistemas elencados. Deve-se ainda
justificar a eleição de cada característica técnica, mostrando sua importância para o sucesso do
sistema. Desta forma, a intenção é estabelecer um ambiente fundamentado para a análise e
comparação das soluções pesquisadas no benchmarking. A Tabela 5 e a Tabela 6 são modelos
de saídas desta atividade.

Tabela 5 – Modelo de lista de critérios para seleção de sistemas a serem estudados no

benchmarking.

Critério de seleção Justificativa

Critério de seleção 1 Justificativa para o critério 1
Critério de seleção 2 Justificativa para o critério 2

Tabela 6 – Modelo de lista de características técnicas a serem levantadas e suas justificativas.

Característica técnica Justificativa

Característica técnica 1 Justificativa para exigir a característica 1
Característica técnica 2 Justificativa para exigir a característica 2
Característica técnica 3 Justificativa para exigir a característica 3

3.2.2 Atividade 2.2: Pesquisa de benchmarking

Uma vez estabelecidos os critérios para o benchmarking na Atividade 2.1, propõe-se

uma busca em bancos de dados e na Internet por sistemas que tenham missões semelhantes às
de interesse do stakeholder principal.
O coordenador da equipe deve então, com o auxílio dos demais membros, confeccionar
uma tabela em que constarão o nome, país e organização desenvolvedora de cada um dos
sistemas que atenderem aos critérios de seleção de benchmarking definidos na Atividade 2.1,
conforme apresentado na Tabela 7. Caso a equipe considere que o número de sistemas
selecionados está muito reduzida, a equipe deverá realizar novamente a Atividade 2.1,
revisando as características técnicas e definindo critérios de benchmarking menos restritivos.
 70

Tabela 7 – Modelo de lista de sistemas selecionados para o benchmarking.

Nome País Desenvolvedor

Sistema A País A Organização A
Sistema B País B Organização B

A importância destas informações é a de identificar com clareza os sistemas

selecionados, de modo a facilitar os passos posteriores. Ainda que dois sistemas porventura
tenham nomes semelhantes, as informações de organização desenvolvedora e nacionalidade
auxiliam a evitar equívocos, além de permitir que a consulta seja realizada direto no portfólio
do desenvolvedor, quando possível.
De posse da relação dos sistemas para estudo, elencados na Tabela 7, propõe-se a divisão
da responsabilidade de pesquisa das características técnicas consolidadas na Tabela 6 de acordo
com a especialidade de cada membro da equipe. Por exemplo, no benchmarking de cargueiros
militares, o especialista em motores deve avaliar as alternativas de motor utilizadas por todos
os objetos de estudo, e assim por diante.
Deste levantamento resultará uma tabela na qual se apresentam as características
técnicas de cada sistema, conforme o exemplo na Tabela 8, além de outras informações que os
membros da equipe de desenvolvimento julgarem importantes.

Tabela 8 – Exemplo de tabela comparativa de características técnicas.

Característica/
Sistema A Sistema B Sistema C
Sistema
Característica Utiliza 2 sensores de Utiliza 3 sensores de
Não utiliza sensores
técnica 1 velocidade velocidade
Característica Possui tratamento Não possui tratamento Não demanda
técnica 2 antichamas antichamas tratamento antichamas
Suporta temperaturas Suporta temperaturas Suporta temperaturas
Característica
entre 1000°C e 1100°C entre 500°C e 530°C por entre 1500°C e 1800°C
técnica 3
por T segundos 2T segundos por 3T segundos

Propõe-se que o os membros de cada área do conhecimento completem os campos

referentes à sua especialidade. Podem ser utilizadas ferramentas colaborativas para esta
finalidade, que permitam a edição e trabalho simultâneo de todos os elementos da equipe. Isto
porque diversos campos são interdisciplinares, e uma visão do sistema por parte dos
especialistas contribui para um trabalho alinhado com a engenharia de sistemas, apresentada
 71

por Larson et al. (2009), antevendo requisitos de interface e restrições impostas pelos demais
subsistemas.
Para consolidar o entendimento sobre os sistemas estudados e finalizar a etapa de
benchmarking, propõe-se a realização de uma reunião da equipe para análise comparativa dos
sistemas selecionados (trade-off analysis) e discussões. Esta análise trade-off é uma abordagem
defendida por Kossiakoff e Sweet (2003), em que os resultados da avaliação de um sistema são
avaliados não exclusivamente pelo nível de desempenho atingido para cada parâmetro, mas
também pelo equilíbrio entre eles, e em geral conduz a soluções mais consistentes e viáveis.

3.3 Etapa 3: Objetivos e metas

A terceira etapa tem como objetivo consolidar o entendimento das necessidades dos
stakeholders, seguindo a característica iterativa do processo de engenharia de sistemas, além de
identificar as expectativas dos stakeholders e definir os objetivos, metas e requisitos de alto
nível do projeto. A importância desta etapa consiste na possibilidade de avaliar
quantitativamente o nível de desempenho requerido do sistema. Para isso, propõe-se a
realização das atividades expostas na Tabela 9.

Tabela 9 – Descrição dos objetivos, informações de entrada, métodos e ferramentas,

envolvidos no processo e resultados relativos a cada uma das atividades da Etapa 3.

Atividade Objetivos Informações de Métodos e ferramentas Envolvi- Resultados

entrada dos
3.1: -Selecionar -Escopo do -Reuniões -Equipe -Expecta-
Síntese stakeholders projeto de projeto tivas dos
das externos para -Entrevista com os stakehol-
expectati- entrevista -Informações stakeholders externos -Stakehol- ders
vas dos sobre os ders
-Identificar as stakeholders e -Métodos intuitivos de externos
stakehol-
expectativas dos suas funções geração de ideias
ders
stakeholders
3.2: -Identificar os -Escopo do -Entrevistas com os -Equipe -Objetivos
Definição objetivos e projeto stakeholders externos de projeto e metas do
dos metas do projeto projeto
objetivos -Expectativas -Consulta a especialistas -Stakehol-
e metas dos stake- ders
holders -Modelagem externos
do projeto
computacional
-Definição da(s)
referência(s)
para o projeto
 72

Atividade Objetivos Informações de Métodos e ferramentas Envolvi- Resultados

entrada dos
3.3: -Capturar os -Objetivos e -Reuniões -Equipe -Requisitos
Captura requisitos de metas do projeto de projeto de missão
de missão -Software para criação
requisitos de modelos -Stakehol- -Requisitos
de alto -Capturar os ders de sistema
nível requisitos de externos
sistema

3.3.1 Atividade 3.1: Síntese das expectativas dos stakeholders

Nesta etapa, bem como ao longo de todo o processo de desenvolvimento, é possível que
sejam excluídos stakeholders (por saírem do projeto, por exemplo) ou identificados novos
stakeholders, demandando atualização da relação de entidades envolvidas no projeto, conforme
propõem Larson et al. (2009). Esta medida reduz a possibilidade de não se envolver todos os
principais stakeholders no processo, o que poderia resultar em uma posterior formulação de
requisitos incompleta.
É possível ainda que as necessidades para alguns dos stakeholders sejam reavaliadas.
Como consequência, pode ser que atividades anteriores tenham de ser realizadas novamente
com os novos stakeholders, ou para esclarecer demandas que tenham surgido, o que está
compreendido no caráter iterativo do método proposto. No entanto, isto não significa que as
etapas posteriores serão adiadas, pois o modelo de desenvolvimento, coerente com o proposto
por Larson et al. (2009) e apresentado na revisão da literatura, é favorável ao desempenho
simultâneo das atividades.
Ainda, conforme apresentado por PMI (2013), é importante que cada alteração na
documentação proposta pelos envolvidos seja registrada, com a indicação de quem foi seu
demandante, para evitar contestações futuras. Isto porque, embora o método utilize princípios
do Manifesto Ágil, aspectos relativos ao cumprimento de contratos e garantias para os
envolvidos no projeto não podem ser negligenciados.
Assim, para a execução da atividade de síntese das expectativas dos stakeholders,
propõe-se que a equipe de projeto, partindo da lista consolidada dos principais stakeholders,
selecione, por meio de reuniões internas, quais deverão ser entrevistados. Isto porque nem todos
os stakeholders precisam, obrigatoriamente, ser consultados.
A equipe de desenvolvimento deve ter consciência de que há diversos interesses
conflitantes durante um projeto, e deve manter contato com os diversos departamentos de sua
 73

organização (incluindo os departamentos jurídico e de marketing) e com os demais

stakeholders, para não comprometer o processo de desenvolvimento. Deve, ainda, monitorar a
existência de stakeholders negativos, e as consequências de suas ações para o projeto (PMI,
2013).
Assim, uma vez selecionados os stakeholders externos a serem entrevistados, propõe-
se a realização de entrevistas estruturadas de modo a seguir aos princípios defendidos por
Goodwin (2009) e Larson et al. (2009), apresentados na revisão da literatura deste trabalho
(Capítulo 2).
Com relação a seu conteúdo, propõe-se que, alinhada com os autores citados acima, a
entrevista inclua ao menos os seguintes tópicos:
1. Apresentar o objetivo da reunião;
2. Apresentar o escopo preliminar do projeto;
3. Questionar a respeito das expectativas do stakeholder para o sistema;
4. Questionar quais os indicadores e parâmetros de sucesso;
5. Quais os sistemas e estruturas já existentes com os quais o sistema deverá ter
interface;
6. Quais outros stakeholders importantes sugere-se entrevistar.
Deste modo, ao final desta atividade, por meio das entrevistas realizadas e da utilização
de métodos intuitivos de geração de ideias, devem-se sintetizar as expectativas de cada
stakeholder do projeto.

3.3.2 Atividade 3.2: Definição dos objetivos e metas do projeto

Uma vez conhecidas as necessidades dos stakeholders propõe-se que, com a finalidade
de esclarecer, detalhar e traduzir em linguagem de engenharia as expectativas dos stakeholders
com o projeto, sejam definidos os objetivos e metas do projeto, conforme defendem Larson et
al. (2009).
Assim, propõe-se que, partindo do escopo do projeto, das informações a respeito das
expectativas dos stakeholders e das referências para o projeto obtidas no benchmarking, a
equipe realize entrevistas com os stakeholders para definir, qualitativamente (objetivos) e
também por meio de valores numéricos (metas), as medidas que expressem a satisfação da
necessidade de missão e das expectativas dos stakeholders. Sugere-se que deve haver um
membro responsável por verificar e gerenciar este documento, de modo a manter o controle
 74

sobre as versões do documento. Larson et al. (2009) propõem que este responsável seja o
engenheiro de sistemas.
Para realizar a definição quantitativa de algumas metas é possível que sejam necessárias
informações e estudos adicionais, demandando consulta a especialistas em diferentes áreas
relacionadas ao projeto e/ou modelagem computacional.
Ao final desta atividade deve-se obter um documento registrando a necessidade de
missão, os objetivos e metas para o projeto, que servirá de base para as etapas posteriores e
poderá ter valor, inclusive para questões contratuais.

3.3.3 Atividade 3.3: Captura de requisitos de alto nível

A partir dos objetivos e metas do projeto, propõe-se que sejam identificados os

requisitos de mais alto nível, referentes a missão e sistema. Esta atividade pode ser auxiliada
pela realização de reuniões entre os envolvidos no projeto.
Para se escrever os requisitos, sugere-se um padrão estruturado, conforme proposto por
Carson (2015):
“O <AGENTE> deve <O QUÊ>, <COMO>, <SOB QUAIS CONDIÇÕES>
Em que o agente (por exemplo: missão e sistema) é a entidade que deve desempenhar
a função; o verbo deve identifica uma assertiva como mandatória, ou seja, um requisito; o quê
é a ação ou característica que o agente deve apresentar; como está relacionado à quantificação
do desempenho da função ou propriedade realizada pelo agente; e sob quais condições refere-
se às condições ambientais, modos e propriedades do agente quando desempenha a função
pretendida e aos eventos iniciadores que fazem com que o agente passe a realizar a ação.
Recomenda-se que os requisitos sejam consolidados pela equipe de engenharia de
sistemas utilizando software de SysML, para automatizar a rastreabilidade e geração de
representações alternativas dos requisitos. Caso não se tenha software disponível para isso,
pode-se gerar os modelos manualmente.
Como os requisitos de mais alto nível tem reflexos em todas as áreas do
desenvolvimento, os mesmos devem estar disponíveis para consulta por toda a equipe e
stakeholders durante todo o projeto.
Por fim, esta atividade de captura e atualização de requisitos prossegue ao longo do
desenvolvimento, sendo refinada à medida em que o nível de conhecimento a respeito do
 75

sistema aumenta. Os requisitos de mais alto nível, em geral, devem ser os primeiros a serem
capturados, sendo decompostos em níveis mais baixos à medida em que o projeto avança.

3.4 Etapa 4: Conceito de operações

Uma vez realizado o benchmarking e conhecidas as expectativas dos stakeholders,

desenvolve-se o conceito de operações, com a finalidade de entender como o sistema a ser
desenvolvido irá operar e relacionar-se com os sistemas já existentes, além de compreender
como cada entidade envolvida em sua operação irá atuar.
Conforme apresentado na Seção 2.2.4 (estudo conceitual de sistemas) do Capítulo 2
(revisão da literatura) deste trabalho, diferentes autores sugerem conteúdos com algumas
diferenças para o conceito de operações, cabendo à equipe desenvolvedora selecionar quais
tópicos serão constantes de seu documento de conceito de operações, de acordo com o projeto
em que está envolvida. Projetos de maior complexidade, em geral, exigem análise mais
detalhada, com conteúdo mais abrangente. Por outro lado, o desenvolvimento de sistemas mais
simples pode basear-se em um volume de documentação menor, acelerando os processos.
Tendo em vista que o presente trabalho apresenta a análise funcional de uma constelação
de pequenos satélites, as atividades constituintes de seu conceito de operações são mais
simplificadas em comparação ao que se faria para um satélite de grandes dimensões, o que está
alinhado com o modelo de desenvolvimento mais enxuto adotado para pequenos satélites,
conforme foi discutido na revisão da literatura deste trabalho e coerente com o INCOSE (2015),
que afirma que os processos de engenharia de sistemas devem ser aplicados a cada estágio do
ciclo de desenvolvimento adaptados ao escopo e complexidade do projeto. Sendo assim, a
Tabela 10 apresenta a descrição das atividades propostas para a confecção do conceito de
operações, que serão aplicadas no caso de estudo para o pequeno satélite de comunicações.
 76

Tabela 10 – Descrição dos objetivos, informações de entrada, métodos e ferramentas,

envolvidos no processo e resultados relativos a cada uma das atividades da Etapa 4.

Informações de Métodos e Envolvi-

Atividade Objetivos Resultados
entrada ferramentas dos
4.1: Determi- -Determinar os -Escopo do projeto -Reuniões -Equipe -Parâmetros
nação dos parâmetros chave de pro- chave de
parâmetros de desempenho -Objetivos e metas -Métodos jeto desempenho
chave de (KPPs) do projeto intuitivos de (KPPs)
desempenho geração de -Stake-
(KPPs) ideias holders
externos
4.2: -Definir as -Escopo do projeto -Reuniões -Equipe -Fronteiras do
Desenvol- fronteiras do de pro- sistema
vimento do sistema -Objetivos e metas -Métodos jeto
contexto e do projeto intuitivos de -Contextos “As-
arquitetura -Identificar o geração de -Stake- is” e “To-be”
operacionais contexto “As-is” e -Requisitos de ideias holders
definir o contexto missão externos -Sequenciamento
“To-be” -Diagramas de operacional dos
-Requisitos de contexto cenários
-Realizar o sistema
sequenciamento -Diagramas de -Atividades dos
operacional -Parâmetros chave sequência nós operacionais
dos cenários de desempenho
(KPPs) -Diagramas -Relacionamento
-Identificar a
NxN entre os
conexão entre as
-Informações elementos do
entidades
sobre os sistema de
envolvidas no
stakeholders e suas sistemas
projeto
funções
-Determinar as
atividades das
entidades no
projeto
4.3: Identifi- -Identificar -Fronteiras do -Software para -Equipe -Condições
cação das condições sistema modelagem de pro- ambientais a que
condições ambientais a que o jeto o sistema poderá
ambientais sistema poderá -Contextos “As-is” estar exposto
estar exposto e “To-be”

-Sequenciamento
operacional dos
cenários

-Definição da(s)
referência(s) para
o projeto

-Literatura
 77

3.4.1 Atividade 4.1: Determinação dos parâmetros chave de desempenho (KPPs)

Os KPPs (Key Performance Parameters - parâmetros chave de desempenho) são as

capacidades ou características que o sistema deve apresentar, expressando os requisitos de
missão mais relevantes. Sua importância advém do fato de que, caso algum dos KPPs não seja
atingido, todo o projeto pode ser comprometido (LARSON et al., 2009).
Para se determinar os KPPs propõe-se que, a partir das informações referentes ao escopo
e dos objetivos e metas do projeto (definidos na Atividade 3.2), a equipe de projeto se reúna e
negocie com os stakeholders externos qual KPP será associado a cada objetivo. Desta forma,
identifica-se qual capacidade o sistema deve apresentar para atingir as metas referentes àquele
objetivo.
Por exemplo, para uma constelação de pequenos satélites com o objetivo “prover
cobertura de comunicações à região sul do Brasil”, pode-se identificar o KPP “cobertura”.
Em seguida, para cada KPP, devem ser elencados os performance drivers
(direcionadores de desempenho), os elementos capazes de interferir, viabilizando ou não, os
KPPs (LARSON et al., 2009). Durante toda esta atividade, para auxiliar no processo de geração
de ideias, sugere-se a realização de reuniões entre a equipe de projeto e os stakeholders
externos, com emprego de métodos intuitivos, tais como brainstorming.
Retomando o exemplo anterior, para o KPP “cobertura”, possíveis possibilitadores de
desempenho são “altitude, inclinação e número de satélites em órbita”.
Sugere-se que, ao final desta atividade, seja relacionado a cada objetivo do projeto ao
menos um parâmetro chave de desempenho, abordagens alternativas para fins de comparação
(por exemplo, satélite em órbita geossíncrona e satélite de baixa órbita) e possibilitadores de
desempenho, conforme exemplificado na Tabela 11.

Tabela 11 – Exemplo de tabela de parâmetros chave de desempenho, alternativas e

possibilitadores de desempenho, associados a cada objetivo.

Parâmetros chave Alternativas

Possibilitadores
Objetivos de projeto de desempenho Satélite Satélites em de desempenho
(KPP) geossíncrono baixa órbita
Altitude,
Prover cobertura de Cobertura - cobrir a Oferece Depende do
inclinação, número
comunicações à região sul do país cobertura 100% design de
de satélites em
região sul do Brasil 100% do tempo do tempo constelação
órbita
 78

3.4.2 Atividade 4.2: Desenvolvimento do contexto e arquitetura operacionais

O contexto operacional é desenvolvido com o objetivo de definir as fronteiras do

sistema; identificar como é a operação dos sistemas em uso atualmente (“As-is”), e definir como
o sistema desenvolvido irá operar (“To-be”); determinar as sequências de operações para os
cenários; e determinar a conexão existente entre as entidades envolvidas no projeto e definir as
atividades destas entidades.
Partindo do escopo e dos objetivos e metas do projeto, dos requisitos de missão e sistema
e dos KPPs, a equipe de desenvolvimento deve, em conjunto com os stakeholders externos,
definir as fronteiras do sistema. As fronteiras são importantes pois delimitam quais elementos
estão incluídos ou não no desenvolvimento. Para o caso de um sistema espacial de
comunicações, por exemplo, os equipamentos utilizados pelas tropas em solo podem estar
incluídos ou excluídos dos limites. No primeiro caso, serão desenvolvidos no escopo do projeto.
No segundo, o sistema espacial deverá ser compatível com equipamentos de solo pré-existentes.
A seguir, por meio de negociações em reuniões com os stakeholders, propõe-se que,
com uso de diagramas de contexto, seja identificado o contexto “As-is” e desenvolvido o
contexto “To-be”, de modo a se vislumbrarem os processos e métodos envolvidos na operação
do sistema e suas implicações nas interfaces com os sistemas relacionados. Isto porque, em
geral, o início da fase de operação do sistema resulta em novas potencialidades, que podem
implicar mudanças e aprimoramentos do processo, ou mesmo em novos tipos de preocupações.
Neste sentido, Kossiakof e Sweet (2003) defendem que, por vezes, pode-se identificar que o
desenvolvimento de um produto é desnecessário, podendo as necessidades identificadas serem
atendidas por meio de uma mudança de processos, o que pode ser proposto por um trabalho de
engenharia de sistemas.
Uma vez estabelecido o contexto “To-be”, a equipe de projeto deve criar os cenários
operacionais e suas respectivas sequências operacionais, apresentando a sequência de
atividades desempenhadas pelas entidades envolvidas na utilização do sistema. Para criar essas
sequências, a equipe deve identificar que ações as entidades devem executar para se relacionar
com o sistema, e quais respostas do sistema a cada ação. Diagramas ou esboços gráficos simples
ajudam a explicitar aos envolvidos como o sistema pode operar.
As sequências operacionais permitem identificar interações necessárias entre o sistema
de interesse, seus elementos de referência e os stakeholders ativos, identificar lacunas no
conceito de operações previsto, validar os cenários e capacidades e rastrear e sequenciar as
 79

atividades definidas no cenário, para entender como os stakeholders devem interagir com os
elementos do sistema. Durante toda esta atividade sugere-se a utilização de métodos intuitivos
de geração de ideias.
Finalizando esta atividade, considera-se importante que as entidades envolvidas no
projeto identifiquem as atividades a serem desenvolvidas por cada uma, durante o ciclo de vida
do sistema. Propõe-se que sejam determinadas também as relações entre as entidades. Tal
medida visa a deixar claras as atribuições de cada stakeholder e documentar suas
responsabilidades,
Para isto, propõe-se que os stakeholders realizem negociações com o intuito de
consolidar, contratualmente, as atividades dos nós operacionais, que são as entidades
envolvidas na operação do sistema, e o diagrama NxN (conforme exemplo na Tabela 12), por
meio do qual se estabelece como cada elemento do sistema se relaciona com os demais.

Tabela 12 – Diagrama NxN dos elementos do sistema de sistemas.

Sistema A se relaciona Sistema A se relaciona

Sistema A
com Sistema B com Entidade C

Sistema B se relaciona Sistema B se relaciona

Sistema B
com Sistema A com Entidade C

Entidade C se relaciona Entidade C se relaciona

Entidade C
com Sistema A com Sistema B

3.4.3 Atividade 4.3: Identificação das condições ambientais

Com o intuito de permitir o posterior levantamento de requisitos referentes à robustez

do sistema frente às condições ambientais a que estará exposto, é importante identificar as
condições ambientais de operação.
Para isto, propõe-se que a equipe, partindo das fronteiras do sistema, dos diagramas de
contexto “As-is” e “To-be” e das sequências de operações para os cenários e das referências
para o projeto, consulte a literatura (referente a informações a respeito dos diferentes ambientes
pelos quais o sistema passará ao longo de seu ciclo de vida) e realize análise e modelagem por
meio de software voltados para missões espaciais a fim de identificar as condições ambientais
a que o sistema poderá estar exposto não somente durante sua operação, mas ao longo de todo
 80

seu ciclo de vida (incluindo, para o caso de um satélite, atividades como transporte,
armazenamento e lançamento).
Para isto podem ser necessárias, por exemplo, análise térmica, de exposição à radiação
e à vibração. Conhecimento técnico e experiência da equipe são os fatores principais para
definir quais as condições críticas, que podem variar para cada projeto. Por exemplo, o arrasto
aerodinâmico apresenta maior influência sobre satélites em baixa órbita, tendo seus efeitos
reduzidos à medida em que se opera a altitudes mais elevadas.
Ao final desta atividade deve-se consolidar o registro das condições ambientais a que o
sistema estará exposto durante sua operação.

3.5 Etapa 5: Arquiteturas funcional e física

Douglass (2016) sugere a identificação e análise das funções do sistema como forma de
verificar requisitos novos, inconsistentes ou incorretos. Em consonância, neste trabalho propõe-
se também que sejam identificadas as arquiteturas funcional e física do sistema. O método
apresentado para esta etapa constitui-se de uma adaptação do proposto por Douglass (2016).
Na abordagem de Douglass (2016), inicialmente são identificados os subsistemas, para em
seguida determinar requisitos aos mesmos e só então alocar funções. Assim, os subsistemas são
definidos antes das funções que motivam sua existência.
Contudo, este trabalho, concordando com as abordagens de Loures da Costa e Fulindi
(2018), Friedenthal, Moore e Steiner (2015) e Back et al. (2008), propõe que, a partir da análise
do conceito de operações (Etapa 4), sejam inicialmente identificadas as funções que o sistema
deve desempenhar (Atividade 5.1). Os elementos físicos e subsistemas são determinados na
sequência, para atender às funções elencadas (Atividade 5.2).
O objetivo de se estruturar a etapa desta forma é não vincular as funções a um tipo de
solução ou componente específicos. As funções devem ser desempenhadas independentemente
de qual elemento físico selecionado. Assim, o foco está nas funções, e os subsistemas e
componentes são os elementos físicos que possibilitam desempenhar estas funções.
Para finalizar esta etapa, alinhado com os autores citados nesta seção, propõe-se a
alocação de requisitos aos subsistemas (Atividade 5.3). A descrição desta etapa consta da
Tabela 13.
 81

Tabela 13 – Descrição dos objetivos, informações de entrada, métodos e ferramentas,

envolvidos no processo e resultados relativos a cada uma das atividades da Etapa 5.

Atividade Objetivos Informações de Métodos e Envolvidos Resultados

entrada ferramentas
5.1: -Identificar as -Escopo do projeto -Reuniões -Equipe de -Funções do
Identifica funções do projeto sistema
ção das sistema -Objetivos e metas -Software
funções do projeto para criação -Stakehol- -Sequenciamento
do siste- -Realizar o de modelos ders exter- funcional dos
ma sequenciamento -Contexto “To-be” nos sistemas
funcional dos -Diagramas
sistemas -Sequenciamento funcionais
operacional dos
cenários
5.2: -Identificar os -Fronteiras do -Software -Equipe de -Mapeamento
Definição subsistemas sistema para criação projeto funcional
da arqui- de modelos
tetura -Identificar os - Sequenciamento -Identificação dos
física principais operacional dos -Diagramas principais
componentes cenários funcionais componentes dos
dos subsistemas subsistemas
-Funções do
-Realizar o sistema -Sequenciamento
sequenciamento funcional dos
funcional dos -Sequenciamento subsistemas e
subsistemas e funcional dos componentes
componentes sistemas
5.3: -Capturar os -Todas as -Reuniões -Equipe de -Requisitos de
Captura requisitos de informações projeto subsistema
de requi- subsistema referentes ao -Software
sitos de projeto para criação -Stakehol- -Requisitos de
baixo de modelos ders exter- componente
nível -Documentos de nos
controle de
interface de
fornecedores de
componentes

-Requisitos de alto
nível

Para a consecução desta etapa, recomenda-se a utilização de MBSE, apoiando-se em

software de SysML, para a construção de modelos para representar as funções do sistema e o
sequenciamento de funções dos sistemas (Atividade 5.1) e dos subsistemas e componentes
(Atividade 5.2), o que poderá automatizar a geração de documentos e modelos de requisitos
(Atividade 5.3).
 82

A utilização de MBSE nesta etapa é motivada pelo benefício propiciado pelos modelos
quanto ao entendimento das relações das entidades durante a execução das funções do sistema.
Diagramas, como os funcionais, possibilitam uma compreensão mais intuitiva e rápida da
operação do sistema, e evidenciam suas interfaces.
Com relação ao documento que consolida requisitos, a automatização em controlar a
rastreabilidade e gerar as representações para as formas textuais ou gráfica provida pelo
software de SysML permite que cada integrante da equipe de engenharia de sistemas edite o
documento utilizando a interface com que se sente mais familiarizado, enquanto o próprio
software converte o modelo para outros formatos. Isto pode favorecer a prevenção de problemas
causados pela má interpretação dos requisitos por parte de algum integrante da equipe.

3.5.1 Atividade 5.1: Identificação de funções do sistema

Uma vez definido o contexto “To-be” e as sequências operacionais para os cenários,

propõe-se que a equipe de projeto identifique as funções que o sistema deve desempenhar. As
informações referentes ao escopo e objetivos e metas do projeto também direcionam esta
atividade, visto que as funções são meios que o sistema possui para atender ao definido nos
objetivos além de estarem ligadas à operação, gerenciamento e manutenção do sistema,
atividades necessárias durante seu ciclo de vida.
Para realizar esta atividade, sugere-se que sejam identificadas funções associadas a cada
objetivo de projeto e os cenários, que são cada uma das sequências que os eventos podem seguir
devido a interações com elementos externos ou o ambiente (LOUREIRO, 1999), conforme
mostrado na Tabela 14.

Tabela 14 – Exemplo de funções do sistema e cenários.

Objetivos de projeto Funções Cenários

Cenário A
1. Função 1
Cenário B
1. Objetivo de projeto 1 Cenário B
2. Função 2
Cenário C
Entidades relacionadas Entidade 1
3. Função 3 Cenário D
2. Objetivo de projeto 2
Entidades relacionadas Entidade 1, Entidade 2
 83

Para representar as funções do sistema e diagramas de sequenciamento funcional (que

apresentam a sequência temporal da realização das funções) indica-se a construção de modelos
(conforme exemplo na Figura 22, representando os atores e subfunções), de modo a permitir o
melhor entendimento das mesmas por todos os integrantes da equipe.

Figura 22 – Exemplo de modelo para a função 1.

Para construir os diagramas de sequência funcionais, ou diagramas funcionais (um

exemplo de representação é mostrado na Figura 23), deve-se a partir do sequenciamento
operacional, identificar como o sistema deve responder (quais funções deve desempenhar) para
atender à demanda operacional e produzir as saídas necessárias, em seu relacionamento com as
demais entidades. A Figura 23 representa o Ator1 se relacionando com o sistema por meio da
função de uma ação (Ação1) (a). O sistema então desempenha a Função1, interagindo com o
Ator2 por meio da Ação2 (b). Por fim, o Ator2 interage com o Ator1 por meio da Ação3 (c).

Figura 23 – Exemplo de diagrama de sequência funcional para a função 1.

 84

A principal diferença entre os sequenciamentos funcionais e operacionais é que,

enquanto o foco nos sequenciamentos operacionais é entender como o sistema e as entidades
se relacionam durante a operação, no sequenciamento funcional identifica-se como as funções
interagem umas com as outras (LARSON et al., 2009). Desta forma, o sequenciamento
funcional fornece as primeiras informações para a decomposição das funções em subfunções,
a ser realizada na Atividade 5.2.
Por fim, para concluir a análise funcional, sugere-se que esta atividade seja consolidada
por meio de uma reunião envolvendo os stakeholders externos.

3.5.2 Atividade 5.2: Definição da arquitetura física

A definição da arquitetura física do sistema consiste em se identificar os subsistemas e

seus principais componentes, de modo a se ter uma ideia inicial de quais elementos serão
utilizados na construção do sistema espacial. Esta atividade é importante para se começar a
trabalhar em possíveis soluções para atender à necessidade de missão identificada.
Para isto, deve-se partir das informações referentes às sequências de operações, funções
do sistema, suas fronteiras e sequenciamento funcional. Propõe-se que a equipe de projeto
mapeie as funções, decompondo-as em subfunções, alocadas a elementos físicos do sistema,
conforme sugerem Friedenthal, Moore e Steiner (2015). Subfunções são funções de menor
nível, intermediárias para a realização de outra função. Por exemplo, digitar texto pode ser uma
subfunção de comunicar, para um telefone celular. Elementos físicos podem ser os
componentes ou subsistemas, conforme as hierarquias de sistemas apresentadas na Seção 2.2.1
da revisão da literatura deste trabalho. A alocação de funções a sistemas consiste em se
identificar, para cada subfunção, qual o subsistema ou componente (elementos físicos)
responsável por desempenhá-la. A Tabela 15 apresenta um exemplo de mapeamento.

Tabela 15 – Exemplo de mapeamento funcional.

Funções Subfunções Elementos físicos

-Subfunção 1 -Elemento físico 1
Função 1 -Subfunção 2 -Elemento físico 2
-Subfunção 3 -Elemento físico 3
 85

Em seguida, sugere-se identificar, de maneira preliminar e genérica (sem especificar

fabricantes ou modelos), os componentes dos subsistemas (Tabela 16). Para pequenos satélites
esta identificação é possível pois, conforme ressalta Mendes (2018), as arquiteturas básicas são
amplamente conhecidas.

Tabela 16 – Exemplo de identificação dos subsistemas.

Subsistemas Componentes
Componente 1
Subsistema 1
Componente 2

Por fim, utilizando software para criação de modelos, a equipe deve decompor os
diagramas funcionais, desenvolvidos na Atividade 5.1, para os níveis subsistema e componente,
de modo a se entender a atuação dos subsistemas integrados e se identificar as interfaces
internas do sistema. A construção dos diagramas funcionais para subsistemas segue a mesma
lógica que para sistemas, porém, ao invés de se tratar o sistema a partir de uma visão externa,
são identificados seus elementos internos responsáveis pelos principais aspectos de seu
funcionamento, conforme exemplo na Figura 24.

Figura 24 – Exemplo de diagrama de sequência funcional dos subsistemas e componentes

para a função 1.
 86

3.5.3 Atividade 5.3: Captura de requisitos de baixo nível

Para a consecução desta atividade, deve-se utilizar todas as informações disponíveis

acerca do projeto, inclusive os documentos de controle de interface dos fornecedores de
componentes. Alinhado com a abordagem iterativa da engenharia de sistemas, o documento de
requisitos evolui ao longo de todo o desenvolvimento, de modo que a equipe deve estar atenta
à atualização de objetivos, metas, requisitos de alto nível, conceito de operações e documentos
de controle de interface dos fornecedores.
Propõe-se que os requisitos sejam definidos até o nível que a equipe julgar necessário
na realização do estudo conceitual, com o intuito de fornecer subsídios para a definição do
conceito. Desta forma, quando este trabalho se refere a requisitos de componente na realização
do estudo conceitual, não significa que sua definição é obrigatória, mas somente um
direcionamento caso se julgue importante a definição de alguns requisitos e se tenha
conhecimento suficiente acerca do projeto.
Para se escrever os requisitos de mais baixo nível, referentes a subsistema e componente,
deve-se decompor os requisitos de mais alto nível e utilizar o padrão estruturado proposto por
Carson (2015), conforme apresentado na Atividade 3.3. Recomenda-se que os requisitos sejam
relacionados de acordo com sua hierarquia utilizando software de SysML, para automatizar a
rastreabilidade e geração de representações alternativas dos requisitos.
Os requisitos de todos os níveis devem estar disponíveis para consulta por toda a equipe
e passar por atualizações e revisões durante todo o projeto. A equipe de engenharia de sistemas
deve avaliar quais requisitos de baixo nível devem ser apresentados e discutidos em reuniões
com os stakeholders externos. Isto, pois é possível que os stakeholders externos não tenham
conhecimento técnico para discutir requisitos referentes a interfaces internas do sistema ou de
nível componente, por exemplo, e estejam mais interessados no desempenho do sistema,
expresso pelos requisitos de nível mais alto.

3.6 Etapa 6: Exploração de conceitos

Nesta seção serão apresentadas as atividades sugeridas para a realização da exploração

de conceitos, ou seja, a identificação de configurações e soluções para atender aos requisitos
estabelecidos. As atividades desempenhadas nesta etapa são típicas de engenharia aeroespacial
 87

e baseadas na obra de Wertz, Everett e Puschell (2011), sendo integradas ao processo de

engenharia de sistemas que compõe as cinco etapas anteriores.
No contexto de um estudo conceitual, o objetivo desta etapa não é especificar de maneira
detalhada o sistema, mas sim identificar, em alto nível de abstração, as alternativas (conceitos)
que os estudos indiquem que possam satisfazer às necessidades dos stakeholders.
Os resultados produzidos nesta etapa devem fornecer aos stakeholders informações para
selecionar um ou mais conceitos a serem estudados de forma mais pormenorizada. Desse modo,
seguindo o caráter iterativo da engenharia de sistemas e alinhado com o proposto por Hall
(1962), este número reduzido de conceitos selecionados deverá passar por ciclos adicionais e
mais aprofundados de estudo. Durante estes ciclos, o número de conceitos é reduzido,
permitindo que recursos pessoais e materiais sejam sucessivamente concentrados para se obter
um maior nível de detalhamento. Por fim, apenas um conceito será selecionado e passará ao
estágio que Kossiakoff e Sweet (2003) denominam desenvolvimento de engenharia.
Para o desenvolvimento de satélites, propõe-se neste trabalho que esta etapa seja
dividida em duas atividades: a Atividade 6.1 (órbitas e constelações), em que se devem
identificar o tipo, as altitudes e inclinações das órbitas e as configurações das constelações, com
número de planos orbitais e número de satélites por plano; e a Atividade 6.2 (estudo de
desempenho), que objetiva dimensionar, de maneira preliminar, o desempenho exigidos das
funções críticas dos satélites. A descrição das atividades consta da Tabela 17.

Tabela 17 - Descrição dos objetivos, informações de entrada, métodos e ferramentas,

envolvidos no processo e resultados relativos a cada uma das atividades da Etapa 6.

Atividade Objetivos Informações de Métodos e Envol- Resultados

entrada ferramentas vidos
6.1: -Identificar -Escopo do projeto -Software para -Equipe de -Alternativas
Órbitas e alternativas de simulação de projeto de órbitas
constelações inclinações e -Objetivos e metas missões (inclinações e
altitudes do projeto espaciais -Stakehol- altitudes)
ders exter-
-Identificar -Contexto “To-be” -Reuniões nos -Alternativas
alternativas de de configura-
configuração -Requisitos de ção de conste-
de constelação missão lação
-Estudar o -Requisitos de -Tempo em
modo de sistema órbita e modo
descarte dos de descarte
satélites
 88

Atividade Objetivos Informações de Métodos e Envol- Resultados

entrada ferramentas vidos
6.2: -Identificar os -Objetivos e metas -Reuniões -Equipe de -Níveis de
Estudo de níveis de do projeto projeto desempenho
desempenho desempenho associado às
-Funções do sistema
exigidos das principais
principais -Sequenciamento funções
funções funcional dos
sistemas -Componentes
-Verificar se que atinjam ao
-Mapeamento
existem no desempenho
funcional
mercado demandado
componentes -Identificação dos
capazes de principais -Riscos tecno-
atender ao componentes dos lógicos
desempenho subsistemas
demandado
-Sequenciamento
funcional dos
subsistemas e
componentes
-Alternativas de
órbitas (inclinações e
altitudes)
-Alternativas de
configuração de
constelação
-Tempo em órbita e
modo de descarte

3.6.1 Atividade 6.1: Órbitas e constelações

Com a finalidade de se levantar alternativas de órbitas (definidas por inclinação e

altitude) e configurações de constelação (tipo de constelação, quantidade de planos orbitais,
defasagem entre os planos e número de satélites por plano), propõe-se que a equipe de projeto
realize um estudo utilizando um software de simulação de missão espacial como, por exemplo,
o AGI STK. Esta simulação tem por objetivo prever os principais parâmetros relacionados ao
nível de desempenho da constelação e confrontar estes dados com os requisitos de missão e de
sistema. O emprego de software para o estudo de órbitas e constelações é difundida na área
espacial, e visa a reduzir o tempo e esforço envolvidos.
De acordo com a missão a ser desempenhada, os objetivos e metas do projeto, o contexto
operacional “To-be” e os requisitos de missão e sistema relacionados às características das
cargas úteis e da plataforma (por exemplo, potência de transmissores e ângulo de abertura dos
sensores) e a área de interesse, deve-se selecionar a faixa de inclinações e altitudes que serão
 89

simuladas. A fim de reduzir o esforço computacional e o tempo de trabalho para a realização

das simulações, propõe-se que inicialmente sejam simulados satélites isolados para cada uma
das combinações de inclinação e altitude.
Em seguida, para as órbitas que se mostrarem mais adequadas ao atendimento dos
requisitos do projeto, devem ser construídas constelações com diferentes números de planos
orbitais e satélites por plano. Estes dados devem ser analisados pela equipe, a fim de se
determinar quais configurações de constelação, para uma dada órbita, atendem melhor à missão
da forma mais eficiente.
Depois de identificadas possíveis órbitas e configurações de constelações, propõe-se
que a equipe de projeto estude o modo de descarte dos satélites após o fim de sua operação.
Este estudo é importante pois existem duas restrições com relação ao tempo em órbita dos
satélites. A primeira restrição é que o tempo em órbita não pode ser inferior ao tempo mínimo
de operação estabelecido no estudo da missão. A segunda limitação é que, visando à redução
do risco de colisões espaciais, o tempo em uma dada órbita após o fim da operação dos satélites
não pode ser superior ao limite de 25 anos pós-missão estipulado pelo “Manual para Limitação
de Detritos Orbitais”, da NASA (2008), que é uma documentação de referência para o fórum
internacional para questões relacionadas a detritos espaciais, o Comitê Interagências de
Coordenação de Detritos Espaciais (IADC) (SANTOS, 2018).
Para atender às diretrizes do IADC, os satélites podem utilizar um sistema propulsivo
para transferir o sistema para uma órbita de descarte, ou realizar a reentrada na atmosfera
(decaimento). De acordo com a solução adotada, propõe-se a simulação computacional para
calcular os incrementos de velocidade necessários para a transferência de órbita ou o tempo de
decaimento dos satélites.
Ao final desta atividade devem ser identificadas alternativas de órbitas, com as
respectivas inclinações e altitudes, e configurações de constelação (com o tipo, número de
planos, defasagem entre os planos e número de satélites por plano) para a missão, além de se
estimar os tempos em órbita para cada órbita selecionada e definir-se seus respectivos modos
de descarte. Os resultados encontrados devem ser discutidos em reuniões com os stakeholders
externos, a fim de permitir as iterações e discussões necessárias à seleção do conceito.
 90

3.6.2 Atividade 6.2: Estudo de desempenho

Como informações de entrada para esta atividade, devem ser utilizados os objetivos e
metas do projeto e todas as informações referentes às arquiteturas funcional e física dos
satélites. Também devem ser conhecidas as configurações de órbita e constelação, visto que,
por exemplo, de acordo com a altitude pode-se precisar de um sistema para auxiliar no descarte
dos satélites e constelações com maior número de satélites podem exigir controle de atitude e
propulsão mais robustos para manter a posição relativa entre os satélites. A Figura 25 representa
o sequenciamento de ações para a execução da Atividade 6.2.

Figura 25 – Sequência de ações para execução da Atividade 6.2

A fim de formular alternativas para a configuração do satélite, propõe-se o estudo dos

níveis de desempenho que serão demandados para as principais funções e subfunções. Assim,
inicialmente a equipe de projeto deve selecionar, dentre as funções do satélite, aquelas cujo
dimensionamento tem mais impacto no projeto (as funções-chave). Para pequenos satélites,
como em geral é possível relacionar as principais funções e subfunções aos subsistemas e
componentes (por exemplo, a função relativa ao apontamento dos satélites está relacionada ao
ADCS e a função de armazenar energia está relacionada ao EPS), pode-se realizar o estudo
direcionado aos elementos físicos (subsistemas ou componentes) que desempenharão as
funções pretendidas, caso se julgue haver benefícios nesta abordagem.
Em seguida, devem ser identificados os parâmetros relacionados ao desempenho de
cada função selecionada (por exemplo, potência necessária para a função de comunicação).
 91

Estes parâmetros podem variar de acordo com a alternativa de conceito estudada (por exemplo,
satélites de dimensões diferentes podem demandar subsistemas de determinação e controle de
atitude diferentes, caso se opte por realizar o estudo direcionado aos elementos físicos), e
servem de base para a determinação dos requisitos de desempenho relacionados a cada
função, que devem ser calculados de forma analítica ou por meio de programas
computacionais. Os requisitos estabelecem um valor ou nível para os parâmetros. No caso do
apontamento, por exemplo, para o parâmetro “acurácia de determinação e controle de atitude”,
um requisito poderia ser “acurácia de determinação e controle de atitude inferior a 5°”.
Uma vez que a equipe disponha dos requisitos de desempenho, a equipe deve
dimensionar os direcionadores de desempenho (subsistemas e componentes associados às
funções) de acordo com seus níveis de desempenho, que são requisitos para os subsistemas
(para o exemplo do ADCS, o dimensionamento pode incluir o torque gerado pelo subsistema
acima de 1∙10-5 N∙m). Assim, pode-se realizar uma pesquisa de mercado a fim de identificar
elementos físicos que atendam aos valores de dimensionamento exigidos (por exemplo, rodas
de reação, sensores, rádios). Ao se identificar os componentes necessários para cada alternativa
(avaliando também questões relativas à confiabilidade ou nível de prontidão tecnológica (TRL)
dos mesmos), pode-se comparar os custos dos diferentes satélites estudados, o que subsidiará a
posterior seleção de conceito por parte dos stakeholders.
Desta forma, ao final da Atividade 6.2, devem ser reunidos os valores associados ao
desempenho que deverão ser atingidos pelos principais direcionadores de desempenho de cada
um dos conceitos estudados e, se for o caso, identificados os elementos físicos que atendam ao
desempenho exigido. Propõe-se ainda que esta atividade seja consolidada por meio de reuniões
entre os membros da equipe de projeto, para se discutir os resultados obtidos. A Tabela 18
apresenta um exemplo de resultado para esta etapa, com a identificação de dois conceitos
hipotéticos, em que se estudou somente a função de apontamento, com o estudo direcionado ao
elemento físico (subsistema ADCS).
Os resultados produzidos nesta atividade contribuem para a identificação dos riscos
tecnológicos envolvidos no projeto, tais como a não disponibilidade de elemento físico capaz
de atingir algum dos níveis de desempenho demandados pelo sistema, permitindo antecipar
medidas para mitigar os riscos (mudança de abordagem de projeto, desenvolvimento de novas
tecnologias, acordos para retirada de bloqueios de compra, etc.).
 92

Tabela 18 – Exemplo de conceitos para o sistema.

Conceito 1 Conceito 2
Inclinação 5° 15°
Órbita
Altitude 600 km 500 km
Configuração da
constelação
(número de planos orbitais 2x4 3x6
x número de satélites por
plano orbital)
Estrutura dos satélites 6U 3U
Massa mínima 8 kg 3 kg
Dispositivo de
Sim Não
incremento de arrasto
Atitude
(face na direção do vetor 2U 3U
velocidade)
Torque: 0,50 ∙ 10-5 N∙m Torque: 0,10 ∙ 10-5 N∙m
Rodas de reação
Momento armazenado: 0,006 N∙m∙s Momento armazenado: 0,005 N∙m∙s
ADCS
Magneto
Dipolo: 0,21 A∙m² Dipolo: 0,17 A∙m²
torqueador

Como próximo passo, os estudos devem ser apresentados aos stakeholders em reunião,
de modo que os stakeholders possam selecionar um ou mais conceitos para serem estudados de
forma mais detalhada em um novo ciclo. Ao final de um ou mais ciclos adicionais, deve ser
escolhido um conceito definitivo, encerrando o estudo conceitual do sistema. Este conceito
definitivo prosseguirá para o estágio que Kossiakoff e Sweet (2003) denominam
desenvolvimento de engenharia, dando continuidade ao projeto.
Encerra-se, assim, a descrição do método proposto para a análise funcional de uma
constelação de pequenos satélites de comunicações para o Exército Brasileiro. No próximo
capítulo será apresentado um caso de estudo deste método aplicado à realização do estudo
conceitual de uma constelação de pequenos satélites para prover comunicações a tropas a pé do
Exército Brasileiro na região amazônica.
 93

4 Caso de estudo

Neste capítulo será apresentado o caso de estudo do método proposto no Capítulo 3

deste trabalho. Para tal, serão descritos os resultados de aplicação de cada uma das etapas e
atividades deste método, apresentadas na Figura 21.
O objeto desta aplicação é a realização do estudo conceitual de uma constelação de
pequenos satélites para prover comunicações de banda estreita a forças táticas móveis do
Exército Brasileiro na região amazônica. Este projeto é apresentado como sendo uma proposta
à demanda de um conceito de sistema espacial de comunicações de banda estreita que consta
do Apêndice III ao Anexo B do Programa Estratégico de Sistemas Espaciais (PESE).
Conforme foi exposto no Capítulo 1 (introdução) desta dissertação, embora o foco do
presente trabalho tenha sido no Exército Brasileiro, o sistema é concebido para ter a capacidade
de transbordamento e integrar as entidades envolvidas no SISFRON. Isto porque as forças
táticas móveis do EB que realizam deslocamento na região da selva amazônica são o usuário
crítico do sistema (aquele em condições mais difíceis para se prover comunicações), e, ao
desenvolver um sistema capaz de atender a este usuário, é possível realizar o transbordamento
de capacidades para atender aos demais usuários, integrando a cobertura.
A organização desenvolvedora foi o Centro Espacial ITA (CEI), do Instituto
Tecnológico de Aeronáutica. O CEI tem como principal missão a realização de pesquisas e
desenvolvimento de soluções espaciais de até 100 kg para diversas aplicações.
O CEI foi o responsável pelo desenvolvimento do ITASAT, nanossatélite universitário
baseado na plataforma 6U lançado em dezembro de 2018, cujo objetivo era capacitar recursos
humanos em tecnologias espaciais. Atualmente o CEI trabalha no programa SPORT
(Scintillation Prediction Observations Research Task - Tarefa de Pesquisa de Observação de
Previsão de Cintilação), em parceria com a agência estadunidense Administração Nacional de
Aeronáutica e Espaço (NASA), o Instituto Nacional de Pesquisas Espaciais (INPE), a
Universidade Estadual de Utah (USU), a Universidade do Alabama em Huntsville (UAH), a
Universidade do Texas em Dallas (UTD) e a Aerospace Corporation. O programa SPORT
objetiva construir um CubeSat 6U para medir as condições da ionosfera que favorecem a
ocorrência de cintilações e bolhas de plasma (fenômenos eletromagnéticos que interferem nas
comunicações e eletrônicos terrestres) (ABDU, 2016).
 94

Conforme apresentado no Capítulo 1, para viabilizar o trabalho, adequando o volume

de atividades às finalidades acadêmicas, com o intuito de demonstrar a aplicação do método
proposto no Capítulo 3, o caso de estudo foi aplicado envolvendo apenas a participação direta
do stakeholder externo principal: o Exército Brasileiro.
Por questões de confidencialidade, alguns dos resultados obtidos e algumas informações
encontram-se ocultados, sendo apresentado somente extrato das mesmas nos resultados deste
trabalho.
Nas seções a seguir serão mostrados os resultados da aplicação de cada uma das etapas
do método para o caso de estudo em questão. Ainda, ao final deste capítulo, são analisados os
resultados obtidos.

4.1 Etapa 1: Iniciação

Para a consecução desta etapa, foram realizadas as atividades descritas na Tabela 2:

• Atividade 1.1: Alinhamento entre os principais stakeholders
• Atividade 1.2: Definição e mobilização da equipe do projeto

4.1.1 Atividade 1.1: Alinhamento entre os principais stakeholders

Conforme apresentado no Capítulo 3 deste trabalho (método), como informação de

entrada para esta atividade, tinha-se a lista preliminar dos stakeholders e suas funções no projeto
(Tabela 19) e se conheciam informações iniciais sobre a necessidade dos stakeholders externos.

Tabela 19 – Lista preliminar dos stakeholders e suas funções.

Stakeholder Função
Exército Brasileiro (EB) Patrocinador
Centro Espacial ITA (CEI) Organização desenvolvedora
Possível cedente de instalações para montagem,
Instituto Nacional de Pesquisas Espaciais (INPE) integração e testes dos satélites; possível parceria
para operação dos satélites
Comando de Operações Aeroespaciais (COMAE) Parceria para operação dos satélites
Ministério da Defesa (MD) Usuário do sistema
Sociedade brasileira Stakeholder passivo
Fornecedores de equipamentos e componentes Fornecedores
 95

Stakeholder Função
Força Aérea Brasileira (FAB) Usuário do sistema
Marinha do Brasil (MB) Usuário do sistema
Polícias Militares e Civis dos estados Usuário do sistema
Polícias Federal e Rodoviária Federal Usuário do sistema
Receita Federal Usuário do sistema
Agência Brasileira de Inteligência (ABIN) Usuário do sistema
Instituto Brasileiro do Meio Ambiente e dos
Usuário do sistema
Recursos Naturais (IBAMA)
Indústria nacional Usuário do sistema
Organização lançadora Responsável pelo lançamento do satélite
Agência Nacional de Telecomunicações Responsável pelo cadastramento da frequência do
(ANATEL) satélite junto à UIT
Responsável pelo cadastramento da frequência do
União Internacional de Telecomunicações (UIT)
satélite
Responsável pelo cadastramento do satélite junto
Agência Espacial Brasileira (AEB)
à ONU; possível parceira no desenvolvimento
Organização das Nações Unidas (ONU) Responsável pelo cadastramento do satélite
Contrabandistas e traficantes Stakeholder negativo
Nações com interesses contrários aos brasileiros Stakeholder negativo (possíveis futuros
na região amazônica oponentes)

O principal stakeholder externo, o Exército Brasileiro, tinha a necessidade de uma

solução espacial em comunicações para atender às tropas que se deslocam com ou sem apoio
de viaturas ou embarcações pela região amazônica. Desta forma, a solução espacial deveria ser
compatível com equipamentos de comunicação em solo já utilizados pelo EB e que pudessem
ser transportados na mochila dos militares por terreno difícil (selva, pantanal, montanha), o que
restringia tanto as dimensões quanto a massa destes equipamentos (MINISTÉRIO DA
DEFESA, 2018).
Assim, foram realizadas reuniões com representantes do Exército Brasileiro e do CEI
para identificar as necessidades do Exército Brasileiro e transcrevê-las na linguagem de
engenharia de sistemas, bem como definir a solução de projeto e as estimativas de orçamento e
prazo de desenvolvimento. A necessidade de missão identificada foi expressa em linguagem de
engenharia de sistemas como:
“O Exército Brasileiro precisa de uma solução espacial de comunicações de banda
estreita para forças táticas móveis na região amazônica.”
Uma vez identificada a necessidade de missão, passou-se a tratar do tipo de solução de
projeto, em alto nível, a ser empregada.
 96

O PESE estabelece que “o segmento orbital deverá ser composto por uma constelação
de satélites de baixa órbita em operação e satélites de reserva em órbita” (MINISTÉRIO DA
DEFESA, 2018, p. 57), de modo que o tipo de solução já está definido como constelação de
baixa órbita.
Neste momento o CEI, alinhado com as competências que possui e sua especialização
na construção de satélites de até 100 kg, apresentou a opção pelo desenvolvimento de uma
constelação (conjunto de satélites operando coordenadamente) de pequenos satélites não-
geossíncronos, dada sua viabilidade técnica para comunicações de banda estreita como proposto
no PESE (MINISTÉRIO DA DEFESA, 2018), conforme discutido na Seção 2.4 (pequenos
satélites) da revisão da literatura deste trabalho. O baixo custo de construção de cada pequeno
satélite permite que, posteriormente, sejam construídos satélites adicionais para composição de
constelação, com consequente aumento de cobertura.
Desta forma, o CEI explicou ao Exército Brasileiro que é possível obter diferentes níveis
de cobertura em órbitas não-geossíncronas (por exemplo, em baixa órbita), em função do
número de pequenos satélites presentes na constelação. O CEI esclareceu ao Exército Brasileiro
que, em linhas gerais, para uma aplicação em que não seja demandada cobertura 100% do tempo
(por exemplo, um sistema de troca de mensagens de texto que envie e receba informações
durantes as janelas de cobertura a cada órbita), pode-se utilizar um número mais reduzido de
satélites, que deve ser incrementado à medida em que se objetive menor tempo médio de espera
pelas comunicações e/ou maior cobertura.
Neste trabalho, embora a solução possa envolver uma constelação de satélites, o sistema
de interesse frequentemente será referido como “satélite”, no singular, dada a premissa de que
os satélites implementados inicialmente serão similares entre si. Lançamentos posteriores, para
completar ou expandir a constelação, podem envolver satélites diferentes ou com capacidades
ampliadas (ex. com capacidade de fazer imageamento), para atender a evoluções dos requisitos
dos stakeholders ou novos requisitos surgidos ao longo do tempo.
Por fim, como resultado desta atividade, os envolvidos nas reuniões definiram o escopo
do projeto, apresentado na Tabela 20. Os custos e o prazo de desenvolvimento foram calculados
preliminarmente com base no trabalho de Casale e Loures da Costa (2018) e da estimativa de
orçamento do Exército Brasileiro para o projeto.
 97

Tabela 20 – Escopo do projeto.

O Exército Brasileiro precisa de uma solução espacial de

Necessidade de missão comunicações de banda estreita para forças táticas móveis na
região amazônica
Tipo de solução a ser desenvolvido Constelação de pequenos satélites de baixa órbita
Prazo de desenvolvimento 3 anos
Orçamento R$ 55 milhões

Até o momento, não foi assinado contrato entre o CEI e o EB, contudo o CEI decidiu
continuar o desenvolvimento visando a um acordo futuro. Conforme apresentado na Seção 3.1.1
deste trabalho, questões contratuais não serão tratadas no presente trabalho.

4.1.2 Atividade 1.2: Definição e mobilização da equipe de projeto

Uma vez definido o escopo do projeto e decidido seu início por parte do CEI, mobilizou-
se a equipe multidisciplinar de desenvolvimento. Para isso, reuniram-se os responsáveis pelo
CEI, que definiram as funções e especialidades que o projeto iria exigir e, em seguida,
escolheram os integrantes da equipe de trabalho (Tabela 21). Os nomes foram omitidos em
razão de confidencialidade. A equipe foi então reunida, informada sobre o escopo do projeto e
mobilizada para iniciar seu desenvolvimento.

Tabela 21 – Lista de funções e responsáveis da equipe de projeto.

Função Pessoas responsáveis

Gerente de projeto Pessoa A
Coordenação técnica do projeto Pessoa B
Chefe do CEI Pessoa C
Revisor do projeto Pessoa D
Engenheiro de sistemas Pessoa E
Responsáveis pelo cálculo de órbitas e da dimensão da constelação Pessoa F
Engenheiro mecânico Pessoa G
Especialista em logística Pessoa H
Responsável pelo controle e gerenciamento de plataforma Pessoa I
Responsáveis pelas interfaces elétricas Pessoa J
Especialistas em telecomunicações Pessoa L
Especialista em controle de atitude Pessoa M
 98

4.2 Etapa 2: Benchmarking

Uma vez iniciado o projeto, foi realizado o benchmarking, a partir das seguintes
atividades, descritas na Tabela 4:
• Atividade 2.1: Definição dos critérios de benchmarking
• Atividade 2.2: Pesquisa de benchmarking

4.2.1 Atividade 2.1: Definição dos critérios de seleção

Para a definição dos critérios de seleção, partiu-se do escopo do projeto obtido na Etapa
1 e, por meio de discussão em reunião com a equipe, foram elencados os critérios para seleção
de sistemas (Tabela 22) e as características técnicas relevantes (Tabela 23) a serem estudadas
no benchmarking.
Assim, o primeiro critério era que os sistemas fossem pequenos satélites (satélites até
100 kg, conforme a definição apresentada na seção pequenos satélites, da revisão da literatura
deste trabalho). Com o objetivo de pesquisar apenas os sistemas mais recentes, outro critério
foi que os sistemas deveriam ter sido desenvolvidos ou lançados a partir de 2008.
Dado que os sistemas de interesse para estudo podem ter aplicação militar e serem
difíceis de se obter informações, identificou-se, inclusive, que a disponibilidade de
informações era um critério importante para sua seleção. Conhecer os componentes do sistema
é importante para que se possa identificar posteriormente, por exemplo, a utilização de
componentes COTS (comercial-off-the-shelf – componentes disponíveis para venda no
mercado, dispensando desenvolvimento próprio) e ITAR (International Traffic in Arms
Regulations – legislação estadunidense que restringe o fluxo de informações e a venda de certos
equipamentos). Conhecer os serviços oferecidos aos usuários (por exemplo, ligação entre
satélites da constelação) também foi definido como característica relevante para estudo.

Tabela 22 – Critérios para seleção de sistemas a serem estudados no benchmarking.

Critério de seleção Justificativa

O sistema deve ser um pequeno Na Etapa 1 definiu-se que a solução implementada será um
satélite pequeno satélite
O sistema deve ter sido desenvolvido Existe intenção em se filtrar os sistemas mais recentes e
ou lançado a partir de 2008 com tecnologias atuais
 99

Critério de seleção Justificativa

Disponibilidade de informações a
respeito de características técnicas
relevantes e componentes
Serviços de comunicações oferecidos
O acesso às informações de componentes é necessário para
a realização da pesquisa de benchmarking e permite a
posterior identificação de componentes COTS ou ITAR
Conhecer o tipo de serviço oferecido permite identificar as
capacidades dos satélites

Como pode-se observar, não houve exigência de que os objetos de estudo fossem
voltados à aplicação militar, pois julgou-se que nesta etapa tanto soluções civis quanto militares
poderiam contribuir igualmente para a compreensão do nível atual de tecnologia que está sendo
utilizada.
Dentre as características técnicas relevantes, a órbita é uma das principais, relacionada
ao tempo de vida útil (tanto por razões de decaimento quanto em função de perda de
confiabilidade devida à radiação), cobertura e potência necessária para comunicação. As
características identificadas são apresentadas na Tabela 23.

Tabela 23 – Características técnicas relevantes e justificativas.

Característica técnica Justificativa

Configuração A configuração determina o espaço disponível para plataforma e carga
útil
Massa A massa influencia nos custos de lançamento
Órbita A órbita determina a região de cobertura e influencia na vida útil, além
da cobertura e potência necessária para comunicação
Tempo de vida útil O tempo de vida útil de cada satélite determina a frequência de
de cada satélite reposição de satélites para manter a cobertura
Dispenser O dispenser, dispositivo de proteção e interface do satélite para
(se for o caso) lançamento, está relacionado ao tipo de lançamento
Custo Conhecer o custo visa a estimar o valor financeiro a ser alocado para o
projeto
Estrutura Conhecer a estrutura visa a determinar a resistência estrutural,
condutividade elétrica e resiliência ao ambiente espacial da estrutura
Mecanismos de Os mecanismos de abertura estão relacionados à confiabilidade e
abertura capacidade energética do satélite (no caso dos painéis solares de
abertura)
Controle térmico A existência e tipo de controle térmico estão relacionados à
confiabilidade do satélite e componentes sensíveis à temperatura
Fonte de energia A operação do satélite depende de energia
Controle e processa- O controle e processamento de dados é o subsistema responsável pelo
mento de dados gerenciamento do satélite
Sensores de atitude Algumas cargas úteis e subsistemas da plataforma demandam atitude
do satélite específica para comunicação
Atuadores Os atuadores realizam o controle e a estabilização de atitude do satélite
Precisão do con- A precisão deve ser conhecida para se projetar o subsistema de
trole de atitude determinação e controle de atitude do satélite
 100

Característica técnica Justificativa

Conhecimento O conhecimento de órbita é importante para realização do controle de
de órbita atitude e da constelação
Sistema O sistema propulsivo permite manutenção de órbita do satélite
propulsivo
Rádio para O rádio para status permite comunicação da plataforma com o
status segmento solo, para gerenciamento do sistema em voo
Rádio embarcado O rádio embarcado da carga útil permite comunicação da carga útil
da carga útil com rádios em solo, para atender aos usuários
Frequência (ou banda) A frequência (ou banda) de operação dos rádios pode limitar a taxa de
de operação dos rádios transmissão e eficiência da conversão em dados
Serviço Serviços oferecidos aos usuários
Operabilidade A operabilidade determina as potencialidades e versatilidade do
sistema
Tipo de rádio O tipo de rádio é importante para conhecer o tipo de solução utilizada
pelos satélites desenvolvidos
Encriptação Como o sistema a ser projetado tem aplicação militar, existe interesse
de dados em criptografia
Componentes A utilização de COTS pode reduzir tempo e/ou custos de
COTS desenvolvimento
Componentes A utilização de componentes ITAR, que podem ter a comercialização
ITAR restringida, aumenta o nível de dependência estrangeira do projeto

4.2.2 Atividade 2.2: Pesquisa de benchmarking

Dando continuidade à execução da atividade de benchmarking, selecionaram-se

sistemas a serem estudados, com base nos critérios da Tabela 22. As informações sobre os
pequenos satélites foram pesquisadas por meio de fontes recomendadas por Poghosyan e Golkar
(2017), isto é, pesquisa em páginas de Internet referentes a missões espaciais e nos bancos de
dados de satélites FP7 NANOSAT database (NANOSAT, 2018) e Gunter’s Space (GUNTER’S
SPACE, 2018d). Destes, o FP7 NANOSAT database é o maior banco de dados do mundo no
que se refere a nanossatélites (subcategoria de pequeno satélite mais utilizada para
comunicações), com informações de nanossatélites lançados desde 1998, sendo atualizado ao
menos a cada 2 meses, enquanto a página da Gunter’s Space apresenta informações sobre
diversas missões espaciais, classificadas por país e tipo de satélite e apresentando também
informações sobre o tipo de missão. A utilização destas fontes permitiu uma pesquisa
abrangendo os principais satélites de até 100 kg voltados à comunicação. Os sistemas
selecionados são apresentados na Tabela 24.
 101

Tabela 24 – Sistemas selecionados para o benchmarking.

Nome País Desenvolvedor

SMDC-ONE EUA SMDC
SNaP-3 EUA SMDC
3-Diamonds Reino Unido SAS
KIPP Canadá Kepler

Desta forma, quatro nanossatélites de comunicações foram selecionados. Partindo-se

destes, conforme definido na Seção 3.2.2 do capítulo referente ao método, dividiu-se a pesquisa
segundo a especialidade dos membros da equipe. O especialista em controle foi responsável
pelo estudo do subsistema de determinação e controle de atitude (ADCS), por exemplo. As
características técnicas relevantes de cada sistema estudado são apresentadas na Tabela 25.

Tabela 25 – Tabela comparativa de características técnicas (os valores marcados com (*)
foram deduzidos pela equipe com base nas imagens ou demais informações técnicas).

Dados relacionados à configuração mecânica

Característica/
SMDC-ONE SNaP-3 3-Diamonds KIPP
Sistema
Configuração CubeSat 3U CubeSat 3U CubeSat 3U CubeSat 3U
Tipo TAB* Tipo TAB* --- Tipo RAIL(ISIS)*
Massa (kg) 4,5 5,3 6 5*
Órbita 462 x 889 km 495 x 801 km 496 x 511 km 528 x 545 km
120,5° 64,78° 97,45° 97,54°
Tempo de vida útil > 1 ano > 2 anos > 2 anos* 3 anos
Dispenser NanoRack* NanoRack * LauncherOne ISISpod*
(VirginOrbit)
Custo (USD) 350 mil 500 mil 500 mil ---
Dados relacionados aos subsistemas da plataforma
Característica/
SMDC-ONE SNaP-3 3-Diamonds KIPP
Sistema
Estrutura Alumínio 7075* Alumínio 7075* Alumínio Alumínio 7075*
7075*
Mecanismo de 8 antenas/ ativo 4 antenas/ativo 4 4 antenas/ativo
abertura/tipo de 4 painéis antenas/passivo 2 painéis
abertura solares/ativo solares/ativo
Controle térmico --- --- Passivo Passivo
Energia Painel solar fixo Painel solar de Painel solar fixo Painel solar de
abertura abertura
Conjunto de Conjunto de
baterias íon- Conjunto de baterias baterias íon- Conjunto de
Lítio* íon-Lítio* Lítio* baterias íon-Lítio*
Controle e proces- Aviônica Aviônica dedicada COTS COTS
samento de dados dedicada (GOMspace)* (Clyde Space)*
Sensores de atitude --- --- --- ---
 102

Atuadores 3 eixos (controle 3 eixos (rodas de 3 eixos COTS 3 eixos COTS

magnético reação MAI-400) (GOMspace) (Clyde Space)*
passivo)
Precisão do --- < 1°* --- ---
controle de atitude
Conhecimento de GPS GPS --- ---
órbita
Sistema propulsivo Não possui Sistema de gás frio Não possui Não possui
Rádio para status UHF/VHF --- UHF/VHF UHF/VHF (ISIS
TRXUV)*
Dados relacionados às cargas úteis de comunicação
Característica/
SMDC-ONE SNaP-3 3-Diamonds KIPP
Sistema
Rádio embarcado Compatível com Compatível com os Compatível Compatível com a
da carga útil rádios usados rádios PRC 117, PRC com a aviação aviação comercial e
por tropas 152 e Harris 5800M comercial e militar
militares militar
Frequência (ou HF Banda Ka Banda S Banda Ku
banda) de operação
Banda L
dos rádios
Serviço Voz/texto Voz/texto/ dados Voz/texto/dados Voz/texto/dados
Operabilidade CSL (Customer CSL CSL CSL
to Satellite Link –
ligação do usuário ISL (Inter Satellite Link ISL
com o satélite) – ligação entre satélites)
Tipo de rádio --- SDR (Software Defined SDR SDR (Novel)
Radio - rádio definido
por software)
Encriptação de Sim Sim Sim Sim
dados

O mais antigo sistema selecionado, o SMDC-ONE (Space Missile Defense Command -

Operational Nanosatellite Effect), foi desenvolvido pelo Comando Espacial e de Mísseis do
Exército do EUA (SMDC), e 5 nanossatélites deste tipo foram lançados entre 2010 e 2013. O
objetivo era demonstrar pela primeira vez a capacidade de comunicação por voz e envio de
dados por meio de satélites de baixa órbita utilizando rádios militares padrão. Os satélites
desenvolvidos neste projeto eram CubeSats 3U com massa de cerca de 4 kg, alimentados por
células solares (sem painéis de abertura) e utilizando baterias, sem sistema propulsivo, sem
controle de atitude e com tempo de vida de 1 ano. Por meio deste programa foi possível
estabelecer comunicações sem linha de visada e além do horizonte, a mais de 1600 km de
distância (GUNTER’S SPACE, 2018b; DUCOMMUN INCORPORATED, [s.d.]).
Sendo uma continuação do SMDC-ONE, em 12 de junho de 2013 foi lançado o satélite
SNaP-3 (SMDC Nanosatellite Program – Programa de Nanossatélite do SMDC). Foi um
projeto de demonstração de tecnologia, e teve por objetivo a construção de CubeSats (satélites
 103

baseados na plataforma modular de “U”) experimentais de 3U com a missão de desenvolver

rádios definidos por software para comunicação além da linha de visada para usuários de nível
tático em desvantagem (remotos, móveis ou embarcados) em locais remotos. Os nanossatélites
SNaP-3 são os primeiros do SMDC a incorporar sistema propulsivo, controle de atitude e
painéis solares de abertura (GUNTER’S SPACE, 2018c). Cada satélite possui entre 4,5 e 5,5
kg, tendo 4 painéis solares voltados para o zênite e 4 antenas na face 1U voltada para o nadir,
operando na banda Ka (entre 27 e 40 GHz).
O terceiro sistema selecionado foi construído pela companhia Sky and Space Global
(SAS), que opera um conjunto de 3 nanossatélites 3U para aplicação civil, os 3-Diamonds (Red,
Green e Blue), visando no estágio atual a atuar como demonstradores de tecnologia, com
capacidade de comunicar-se uns com os outros e também com a terra. O plano da empresa é
estabelecer uma constelação com 200 nanossatélites operando em banda S, provendo cobertura
equatorial (SKY AND SPACE GLOBAL, [s.d.]).
O quarto sistema selecionado, o KIPP, é um CubeSat 3U voltado para o mercado de
comunicações máquina-a-máquina (M2M) e Internet das Coisas. Seu desenvolvedor, a
companhia Kepler, visa à colocação de 140 satélites em órbita entre 500 e 650 km. A vida útil
esperada para os nanossatélites é de 10 anos, mas seu baixo custo permite substituição mais
frequente, em cerca de 3 anos (BOUGHER, 2016).
Após o levantamento das informações, a equipe se reuniu para analisar e discutir os
resultados. Da análise do benchmarking, verificou-se que todas as soluções estudadas são
CubeSats 3U, apresentando massas entre 4,5 e 6 kg, cujas órbitas são superiores a 450 km. Com
exceção do SMDC-ONE, por limitação operacional e não de órbita, todos os outros possuem
vida útil de pelo menos dois anos. Os nanossatélites estudados também apresentam controle de
atitude em 3 eixos, e o SNaP-3 é o único a possuir propulsão.
Observou-se ainda que todos demandam ao menos quatro antenas com mecanismo de
abertura, e o subsistema de energia utiliza painéis solares. O valor unitário é de cerca de USD
500.000,00, e as soluções civis estudadas (3-Diamonds e KIPP) possuem a vantagem de utilizar
componentes COTS para os subsistemas de controle e gerenciamento de bordo, enquanto as
militares (SMDC-ONE e SNaP-3) utilizam aviônica dedicada. Os COTS apresentam, em geral,
menor custo.
Com relação aos nanossatélites militares, os mesmos possuem receptor GPS e são
compatíveis com rádios de comunicação atualmente usados pelas tropas no terreno, o que é
uma grande vantagem para comunicação com unidades isoladas. Dos sistemas estudados, o
 104

SNaP-3 e os 3-Diamonds têm possibilidade de transmissão de voz, texto e dados, com

operabilidade CSL (Customer to Satellite Link – ligação do usuário com o satélite) e ISL (Inter
Satellite Link – ligação entre satélites).
Assim, dadas as características estudadas no benchmarking e a finalidade de construção
de sistemas voltados à aplicação militar para usuários de nível tático em desvantagem em
terrenos remotos, e a partir de reunião com a equipe, conforme apresentado no Capítulo 3 deste
trabalho (método), decidiu-se pelo SNaP-3, pelos 3-Diamonds e pelo KIPP como sendo os
satélites mais compatíveis como referências para o projeto. O SMDC-ONE foi descartado por
já ter sido sucedido pelo SNaP-3 para o mesmo propósito.
Ainda, o benchmarking permitiu constatar que pequenos satélites não geossíncronos são
alternativas viáveis para comunicação com tropas militares, de modo que têm sido objeto de
pesquisa por outras nações.

4.3 Etapa 3: Objetivos e metas

Para a realização desta etapa, foram realizadas as atividades descritas na Tabela 9:

• Atividade 3.1: Síntese das expectativas dos stakeholders
• Atividade 3.2: Definição dos objetivos e metas do projeto
• Atividade 3.3: Captura de requisitos de alto nível

4.3.1 Atividade 3.1: Síntese das expectativas dos stakeholders

Para identificar as expectativas dos stakeholders, inicialmente a equipe de projeto

reuniu-se e selecionou, dentre os envolvidos no projeto, aqueles que participariam das
entrevistas (Tabela 26).
Dentre os stakeholders selecionados, julgou-se que o envolvimento do INPE desde as
etapas nas entrevistas favoreceria o estabelecimento de parcerias, tanto para a cessão de
instalações (laboratórios) e equipamentos para as atividades de montagem, integração e testes,
quanto para a operação dos satélites. O Comando de Operações Aeroespaciais (COMAE) foi
incluído nesta lista devido à sua importância na operação da constelação de satélites, por meio
do Centro de Operações Espaciais (COPE), que constituem as estações de controle dos satélites,
conforme definido no documento da “Necessidade Operacional de Comunicações Militares por
 105

Satélite” do Estado-Maior Conjunto das Forças Armadas (COMISSÃO DE COORDENAÇÃO

E IMPLANTAÇÃO DE SISTEMAS ESPACIAIS, 2017). Embora tanto o COMAE quanto o
CEI pertençam à FAB, estas entidades constam na lista como stakeholders separados dadas as
diferentes funções que exercem.

Tabela 26 – Lista dos stakeholders selecionados para as entrevistas.

Stakeholder
Exército Brasileiro (EB)
Centro Espacial ITA (CEI)
Instituto Nacional de Pesquisas
Espaciais (INPE)
Comando de Operações
Aeroespaciais (COMAE)
Ministério da Defesa (MD)
Força Aérea Brasileira (FAB)
Marinha do Brasil (MB)
Agência Espacial Brasileira
(AEB)
Função
Patrocinador
Organização desenvolvedora
Possível cedente de instalações para montagem, integração e testes
dos satélites; possível parceria para operação dos satélites
Parceria para operação dos satélites
Usuário do sistema
Usuário do sistema
Usuário do sistema
Responsável pelo cadastramento do satélite junto à ONU; possível
parceira no desenvolvimento

Seguindo uma lógica similar, o EB, a FAB, a MB e o MD foram incluídos como

entidades separadas. Isto porque é possível que tanto o MD quanto as Forças Singulares
isoladamente são usuários do sistema quando de sua implantação e transbordamento,
integrando as comunicações do SISFRON.
O contato com a indústria nacional e os fornecedores foi considerado desnecessário
neste momento inicial, pois, pelo fato de a equipe de desenvolvimento estar participando de
outros projetos espaciais em fases mais adiantadas, a equipe estava a par do mercado, sabendo,
por exemplo, quais os principais componentes que foram descontinuados e os que continuavam
disponíveis para aquisição. Deste modo, decidiu-se que este contato seria realizado após a
seleção do conceito, quando for se avaliar quais modelos e fabricantes de componentes seriam
utilizados.
Contudo, conforme apresentado no início deste capítulo, o caso de estudo não foi
aplicado a todos os stakeholders selecionados, mas somente ao Exército Brasileiro, de modo
que a entrevista teve como participantes apenas os responsáveis pelo projeto por parte do CEI
e do EB. Foram utilizados também como fonte de informações o PESE e a o documento da
“Necessidade Operacional de Comunicações Militares por Satélite”.
 106

Desta forma, realizou-se a entrevista com os representantes do EB, seguindo os

princípios expostos no método e utilizando ferramentas como brainstorming, de modo que se
pôde sintetizar as expectativas para os diferentes stakeholders, a partir da visão do CEI e do
EB. Um extrato do resultado desta atividade é apresentado na Tabela 27.

Tabela 27 – Extrato das expectativas dos stakeholders.

Stakeholder Expectativa
Obter um meio confiável e seguro de comunicação com tropas a pé
isoladas na região amazônica e a leitura dos sensores de guerra eletrônica
Exército Brasileiro (EB) instalados na região amazônica; interesse em poder ampliar a cobertura
para todo o território nacional e cobertura para dados de sensores do
Sistema Integrado de Monitoramento de Fronteiras (SISFRON)
Desenvolver uma plataforma viável para atender a diferentes necessidades
CEI no setor espacial, projetando-se como referência no setor para futuros
clientes; inserir seus alunos em projetos reais de engenharia
Obter maior cobertura de comunicações e integração na região amazônica;
Ministério da Defesa
obter autonomia na área espacial voltada à defesa; estimular agentes
(MD)
nacionais a desenvolver tecnologias para a área de defesa
Melhoria nas ações das Forças Armadas nas fronteiras, reduzindo o tráfico
que abastece de armas ilegais e drogas as cidades de todo o país; aumento
Sociedade brasileira da capacidade de defesa externa; integração do território nacional;
desenvolvimento tecnológico e científico do país; geração de demanda por
profissionais qualificados na área tecnológica
Fornecedores de Prover instrumentos, componentes, equipamentos e GSE (Ground Support
equipamentos e Equipments - Equipamentos de Suporte em Solo) para os satélites e apoio
componentes em solo
Aumentar a efetividade na detecção de aeronaves ilegais na região
Força Aérea Brasileira amazônica, bem como melhores comunicações em operações em regiões
(FAB); Marinha do isoladas ou para navegação a baixa altura; interesse em poder ampliar a
Brasil (MB) cobertura para todo o território nacional e cobertura para dados de sensores
do SISFRON
Polícias Militares, Civis, Aumento de capacidade de coordenação das ações de fiscalização
Rodoviária e Federal; ambiental e das regiões de fronteira no contexto do SISFRON, por meio da
Receita Federal; ABIN; integração e cooperação entre as instituições, corporações e órgãos
IBAMA usuários do sistema satelital de comunicações
Prover instrumentos, componentes, equipamentos e GSE para os satélites e
Indústria nacional
apoio em solo
Espera que o sistema cumpra as normas de lançamento (expectativa não
Organização lançadora
ligada à operação do sistema)
ANATEL Espera que o sistema cumpra as frequências estabelecidas
UIT Espera que o sistema cumpra as frequências estabelecidas
AEB Espera que ocorra fomento da atividade espacial no Brasil
ONU Espera que o sistema cumpra as normas para utilização do espaço

Dentre estas expectativas, observou-se que em um primeiro momento o Exército

Brasileiro tem interesse de cobertura para as comunicações satelitais na região amazônica. A
 107

expansão da cobertura para todo o território nacional é de interesse do stakeholder, mas em

fases posteriores do SISFRON. Desta forma, o sistema a ser implementado deve ser
desenvolvido para viabilizar esta expansão de cobertura sem demandar alterações dispendiosas
no projeto. A implementação de constelação de nanossatélites é compatível com esta demanda,
podendo-se aumentar a cobertura por meio da adição de novos satélites em diferentes
inclinações.
O CEI, como desenvolvedor de plataformas, visa a ampliar sua visibilidade no setor
espacial, além de permitir aos seus colaboradores e aos alunos do ITA o contato com projetos
reais de engenharia. O resultado emergente desta participação é a formação para o mercado e
para as Forças Armadas de engenheiros com experiência em projetos.
A FAB, a MB e o MD poderão ser beneficiados em suas atividades integradas ao EB na
fiscalização das fronteiras, favorecendo tanto a defesa externa quanto a segurança pública, por
meio da fiscalização contra o tráfico de drogas e armas.
A sociedade brasileira é um stakeholder passivo dado que é afetada pela intensificação
da fiscalização nas fronteiras. O contrabando está ligado a diversas outras atividades
criminosas, sendo origem de recursos para o crime organizado que afeta a segurança pública no
Brasil. Um sistema que melhore as comunicações das Forças Armadas permite ainda maior
capacidade operacional para ações de defesa externa e maior integração do território nacional,
que vão ao encontro dos interesses nacionais.
Ainda, um reflexo indireto do desenvolvimento nacional deste sistema, é a geração de
demanda por profissionais especializados em tecnologia no país, oferecendo postos de trabalho
para um público mais especializado e estimulando a qualificação dos recursos humanos, além
de estimular a economia. Estes resultados beneficiam ainda fornecedores e a indústria nacional,
que terá a oportunidade de se desenvolver para atender à demanda de componentes de alta
tecnologia, e a AEB, que tem interesse no fomento da atividade espacial no Brasil.
A função desempenhada pela organização lançadora é necessária para que o sistema
alcance seu ambiente operacional e inicie suas atividades. As normas emitidas por ela são fontes
de requisitos e devem ser estudadas e atendidas.
A ONU espera que sejam seguidas as normas para utilização do espaço, entre elas a
norma referente ao controle de detritos espaciais, que podem causar degradação ou perda de
missões de terceiros. Além disso, a ONU, a ANATEL, a UIT e a AEB são stakeholders
importantes, uma vez que o cadastramento do satélite e suas frequências de comunicação
 108

implicam responsabilidade civil, inclusive para evitar que haja interferência em serviços
primários de outros sistemas, por utilizar frequência eventualmente já alocada.
Desta forma, as expectativas dos stakeholders foram identificadas e pode-se prosseguir
para a definição dos objetivos e metas do projeto.

4.3.2 Atividade 3.2: Definição dos objetivos e metas do projeto

Uma vez determinadas as expectativas dos stakeholders, a equipe de projeto e os

representantes do EB identificaram os objetivos e metas que caracterizam a satisfação de suas
necessidades. As informações referentes ao escopo do projeto, expectativas dos stakeholders e
as referências para o projeto obtidas no benchmarking foram utilizadas nesta atividade. Com
relação aos aspectos técnicos da demanda de comunicações (ex. taxa de transmissão, cobertura),
consultaram-se especialistas em comunicações do Comando de Comunicações e Guerra
Eletrônica do Exército (CComGEx). Assim, para a necessidade de missão do Exército
Brasileiro, os objetivos e metas são apresentados na Tabela 28.

Tabela 28 – Necessidade de missão do stakeholder Exército Brasileiro, objetivos e metas para

o projeto.

Necessidade de missão: O Exército Brasileiro precisa de uma solução espacial de comunicações de

banda estreita para forças táticas móveis na região amazônica
Objetivos Metas
1.1. Transmitir texto e dados a uma taxa de 56 Kbps
1. Prover serviço de comunicação 1.2. Permitir a comunicação em 40% do tempo (limite), 80% do
para tropas militares nos níveis tempo (objetivo) (TBC) às tropas na região amazônica
grupo de combate, pelotão, 1.3. Permitir a comunicação a cada 10 minutos (limite), 5
companhia e batalhão localizadas na minutos (objetivo) (TBC) às tropas na região amazônica
região amazônica 1.4. Fornecer a posição dos usuários com precisão de 100 m
(limite), 20 m (objetivo)
2. Ser compatível com equipamentos 2.1. Ser compatível com rádios já utilizados pelas tropas em
de comunicação operados por tropas região de selva
do Exército Brasileiro
3.1. Garantir a confidencialidade da informação, a integridade
dos dados e a autenticidade do autor da mensagem ao Exército
Brasileiro (limite) ou garantir a confidencialidade da
3. Manter a segurança das
informação, a integridade dos dados, a autenticidade do autor
comunicações
da mensagem, a irretratabilidade do autor da mensagem e a
disponibilidade da informação ao Exército Brasileiro
(objetivo)
 109

Necessidade de missão: O Exército Brasileiro precisa de uma solução espacial de comunicações de

banda estreita para forças táticas móveis na região amazônica
Objetivos Metas
4.1. Ser 100% controlado nacionalmente por meio das estações
4. Viabilizar a autonomia para a de solo do Centro de Operações Espaciais (COPE)
implementação de soluções de
comunicações pelas Forças Armadas 4.2. Apresentar índice de nacionalização de ao menos 70% nos
satélites construídos a partir de 2025
5*. Prover serviço de comunicação 5.1*. Transmitir dados oriundos dos sensores em solo a uma
com os sensores em solo taxa de 56 Kbps
6. Integrar a região amazônica ao 6.1. Transmitir comunicações a uma taxa de 56 Kbps para
território nacional por meio da socorro em caso de emergências médicas e/ou sociais às
presença das Forças Armadas nas comunidades da região amazônica, com satisfação superior a
comunidades indígenas e/ou isoladas 80% (limite), 100% (objetivo)
Nota: O asterisco (*) destaca o objetivo a ser atendido apenas em condições emergenciais, conforme será explicado
no texto adiante.

O objetivo número 1 está relacionado à necessidade do Exército de atender às tropas

de menor nível. Estas tropas dispõem de menor estrutura de apoio e podem estar, inclusive,
mobilizadas ao longo do teatro de operações, tendo de levar consigo seus meios de
comunicações. Isto se observa especialmente para as patrulhas de nível pelotão ou grupo de
combate, como as que realizam missões de reconhecimento de marcos fronteiriços. As metas
relacionadas às taxas de transmissão (56 kbps) constam do PESE (MINISTÉRIO DA DEFESA,
2018) para o sistema satelital de comunicações de banda estreita.
Durante as reuniões com representantes do EB verificou-se também que, para este
projeto, a comunicação por meio de texto e transmissão de dados seria o suficiente para atender
à necessidade de missão. Posteriormente podem ser adicionadas novas capacidades ao sistema,
o que é permitido pela constante renovação da constelação, com possibilidade de lançamento
de satélites que incorporem outras cargas úteis. Por exemplo, é possível no futuro incluir cargas
úteis de imageamento da superfície terrestre nos satélites construídos para repor os antigos, ou
aumentar a cobertura para possibilitar comunicações por voz. Como o ciclo de reposição
previsto no PESE é de 6 anos, a constelação pode responder rapidamente a mudanças nos
requisitos dos stakeholders.
O objetivo número 2, é relacionado à compatibilidade com equipamentos de
comunicação já utilizados pelas forças táticas móveis do EB na região amazônica.
O objetivo número 3 é relacionado à segurança das comunicações. Nesta fase do
projeto não foram definidas as soluções a serem utilizadas pela constelação, mas o EB informou
quais as principais métricas associadas à segurança (confidencialidade, integridade,
autenticidade, irretratabilidade e disponibilidade), constantes também do documento da
 110

“Necessidade Operacional de Comunicações Militares por Satélite” (NOP) (COMISSÃO DE

COORDENAÇÃO E IMPLANTAÇÃO DE SISTEMAS ESPACIAIS, 2017).
O objetivo número 4, relativo à autonomia para a implementação de soluções de
comunicações prevista na NOP (COMISSÃO DE COORDENAÇÃO E IMPLANTAÇÃO DE
SISTEMAS ESPACIAIS, 2017), contribui para o desenvolvimento de tecnologia nacional,
além de excluir as opções de contratação de serviço de comunicações de empresas estrangeiras,
que poderiam interromper o serviço ou fornecer informações sigilosas para terceiros.
O objetivo número 5, que trata dos dados oriundos dos sensores em solo, embora
compreendido nas demandas do Exército Brasileiro no contexto do SISFRON, não
necessariamente deve ser atendido pelo sistema baseado na constelação de pequenos satélites
objeto de estudo deste trabalho, sendo por isso destacado com um asterisco (*). Sua inclusão
neste estudo visou capturar de maneira mais ampla os objetivos compreendidos no atendimento
da necessidade de missão do stakeholder. Contudo uma análise preliminar de taxa de
transmissão e cobertura demandadas pelos sensores indicou que esta capacidade pode ser
atingida pelos pequenos satélites apenas em ocasiões pontuais e/ou emergenciais, não sendo a
destinação principal da constelação, voltada para a comunicação de tropas. Assim, decidiu-se
pela adoção de interface de comunicação compatível entre sensores e pequenos satélites, mas a
cobertura 100% do tempo deve ser provida por outro tipo de solução.
Note-se que as metas relacionadas ao objetivo número 6 estabelecem que se deve
atingir um determinado nível de satisfação do stakeholder, conforme propõe Fulindi (2017),
em vez de se mensurar, por exemplo, pelo número de comunicações realizadas. Esta medição
pode ser realizada através de questionário fechado aplicado nas comunidades afetadas após o
atendimento das emergências descritas na meta, sendo que o conteúdo deste questionário não
está no escopo do trabalho.
Conforme será discutido posteriormente, a equipe de engenharia de sistemas não
dispunha software de SysML que garantisse a segurança dos dados, de modo que o controle de
consistência e rastreabilidade relativos aos objetivos e metas e requisitos do sistema foi
implementado sem auxílio computacional.

4.3.3 Atividade 3.3: Captura de requisitos de alto nível

Para a consecução desta atividade, a equipe utilizou como informações de entrada os

objetivos e metas do projeto. A equipe de engenharia de sistemas não dispunha software de
 111

SysML que garantisse a segurança dos dados, de modo que os documentos textuais e os
modelos foram gerados manualmente, por meio de outros programas.
A hierarquização de requisitos usada neste trabalho foi a adaptada da sugerida pela
NASA (2018a) (Figura 26), pois esta estrutura foi considerada adequada à complexidade de
projetos de pequenos satélites, tendo sido utilizada com sucesso em desenvolvimentos
anteriores do CEI.

Figura 26 – Hierarquia de requisitos adaptado de NASA (2018a).

Acima do nível sistema, estão os requisitos de missão. Um extrato dos requisitos de

missão obtidos durante o desenvolvimento deste trabalho é apresentado a seguir (Tabela 29):

Tabela 29 – Extrato dos requisitos de missão.

Requisitos de missão
MisReq_01- A missão deve prover comunicações para tropas na região amazônica
MisReq_02- A missão deve prover segurança às comunicações
MisReq_03- A missão deve cobrir cada região a cada 10 minutos (limite) 5 minutos (objetivo)
MisReq_04- A missão deve utilizar satélites capazes de operar por ao menos 6 anos sem demandar
substituição de satélites
MisReq_05- A missão deve usar estações de solo existentes no COPE
MisReq_06- A missão deve ter uma estratégia de final de vida, com descarte de cada satélite em até 25
anos após o fim de sua vida útil

Os três primeiros requisitos de missão (MisReq_01, MisReq_02 e MisReq_03) estão

associados a características de desempenho que a missão deve atender. Os requisitos de missão
MisReq_04 e MisReq_05 refletem características não funcionais previstas no PESE
(MINISTÉRIO DA DEFESA, 2018) e no documento da “Necessidade Operacional de
 112

Comunicações Militares por Satélite” (COMISSÃO DE COORDENAÇÃO E

IMPLANTAÇÃO DE SISTEMAS ESPACIAIS, 2017), sendo o MisReq_05 ligado à
autonomia para implantação dos sistemas de comunicações, por serem realizadas no COPE e,
portanto, sob controle da Forças Armadas, ao mesmo tempo em que racionaliza o emprego de
recursos, determinando que a missão deve ser definida de modo a permitir a utilização das
estações de solo previamente existentes. O requisito MisReq_06 visa a atender a política de
controle de detritos espaciais. Um exemplo da decomposição dos requisitos de missão para o
nível sistema é apresentado na Tabela 30.

Tabela 30 – Extrato dos requisitos do(s) satélite(s), no nível sistema.

Requisito de sistema
SysReq_01- O sistema deve estabelecer o enlace entre usuários

A Figura 27 mostra o modelo que representa estes mesmos requisitos e sua

rastreabilidade. Observa-se que o quadro destacado em cinza representa a solicitação feita pelos
stakeholders utilizando sua própria linguagem profissional. Esta solicitação é, então, traduzida
para linguagem de engenharia, dando origem aos requisitos de nível mais alto que
sucessivamente são decompostos nos níveis missão e sistema.

Figura 27 – Extrato do modelo de rastreabilidade dos requisitos de alto nível.

Por fim, os requisitos foram discutidos em reuniões, a fim de consolidar uma versão
basilar do documento de requisitos de mais alto nível.
 113

4.4 Etapa 4: Conceito de operações

Uma vez identificadas as necessidades de missão, objetivos e metas do projeto, bem

como as expectativas dos stakeholders, desenvolveu-se o conceito de operações, a partir das
seguintes atividades (Tabela 10):
• Atividade 4.1: Determinação dos parâmetros chave de desempenho (KPPs)
• Atividade 4.2: Desenvolvimento do contexto e arquitetura operacionais
• Atividade 4.3: Identificação das condições ambientais

4.4.1 Atividade 4.1: Determinação dos parâmetros chave de desempenho (KPPs)

Com o objetivo de determinar os KPPs, utilizaram-se as informações constantes do

escopo e os objetivos e metas do projeto. A equipe desenvolvedora reuniu-se com os
representantes do Exército Brasileiro e, por meio de alinhamentos e brainstorming, foram
determinados os KPPs (Tabela 31). Como abordagens alternativas para comparação,
escolheram-se as órbitas baixa e geossíncrona. A órbita baixa foi escolhida para comparação
por ser a mais usual para este tipo de sistema, e a órbita geossíncrona foi selecionada para
comparação, pois os sistemas satelitais atuais que o EB utiliza são geossíncronos.

Tabela 31 – Parâmetros chaves de desempenho e possibilitadores de desempenho para as

alternativas apresentadas, associados a cada objetivo.

Parâmetros chave Alternativas

Objetivos de Possibilitadores de
de desempenho Satélite Satélites em
projeto desempenho
(KPP) geossíncrono baixa órbita
1. Prover serviço de Cobertura – Prover Oferece Depende do Altitude, inclinação, número
comunicação para serviço de comuni- Design da de satélites em órbita, potên-
tropas militares nos cação na região constelação cia dos rádios, nível de robus-
níveis grupo de amazônica ao menos tez do satélite, sensibilidade
combate, pelotão, 40% do tempo com dos receptores, nível de inter-
companhia e intervalo entre perío- ferência de tempestades
batalhão localizadas dos de cobertura má- solares e cintilações, altitude,
na região amazônica ximo de 10 minutos faseamento da constelação
2. Ser compatível Compatibilidade – Maior altitude Menor altitude Dimensões, peso
com equipamentos satélites devem ser exige maior de operação
de comunicação compatíveis com potência, que demanda menor
operados por tropas rádios já em uso exige potência de
do Exército pelas forças táticas equipamentos e transmissão,
Brasileiro móveis baterias compatível com
maiores equipamentos
menores
 114

Parâmetros chave Alternativas

Objetivos de Possibilitadores de
de desempenho Satélite Satélites em
projeto desempenho
(KPP) geossíncrono baixa órbita
3. Manter a Segurança - Proteção Oferece Oferece Tempo de resposta, resposta,
segurança das contra interferência e tipo de medidas de Guerra
comunicações escuta Eletrônica, tipo de
criptografia
4. Viabilizar a Autonomia – Oferece Oferece Porcentagem de componentes
autonomia para a Capacidade de as de venda controlada (ex.
implementação de Forças Armadas ITAR) não produzidos no
comunicações pelas proverem suas Brasil, exclusividade no
Forças Armadas comunicações sem controle e conhecimento de
dependência de protocolos para
empresas ou nações status/telecomando
estrangeiras
5.* Prover serviço de Capacidade de Atende Atende Taxa de transmissão
comunicação com os transmissão -
sensores em solo Permitir leitura e
armazenamento dos
dados dos sensores
em solo e
retransmitir os dados
para as organizações
militares
6. Integrar a região Integração - Não aplicável Não aplicável Nível de demonstração de
amazônica ao Aumentar a presença capacidade operacional e
território nacional do Estado brasileiro domínio de tecnologia para
por meio da pre- em regiões remotas controle da região
sença das Forças
Armadas nas co-
munidades indíge-
nas e/ou isoladas

A cobertura relaciona-se com os objetivos relativos ao tempo de cobertura oferecido.

Para satélites em baixa órbita, ela depende principalmente da altitude, inclinação, faseamento e
número de satélites operando. Já os satélites geossíncronos permanecem sobre a área de
interesse 100% do tempo, podendo prover cobertura contínua. A potência dos rádios e as
condições climáticas (terrestres e espaciais) também interferem na possibilidade de contato.
Com o intuito de aproveitar a estrutura logística e os contratos já firmados para
manutenção dos equipamentos de comunicação em solo em uso atualmente pelo Exército
Brasileiro, a constelação de satélites deve possuir compatibilidade de operação com rádios já
em uso pelas tropas.
A segurança das comunicações advém das medidas de Guerra Eletrônica e criptografia
utilizadas. Satélites de maior porte, em geral, comportam maior volume disponível para cargas
úteis, o que pode facilitar a instalação de equipamentos dedicados a manter a segurança das
comunicações.
 115

Outro parâmetro importante é a autonomia, que é ligada à exclusividade do controle

nacional dos satélites e também ao nível de dependência de componentes de venda restrita ou
controlada por outras nações. Uma mudança de política que resulte em suspensão da venda
destes componentes ao Brasil pode impactar negativamente os custos e cronograma do projeto.
A capacidade de transmissão dos dados dos sensores em solo, embora compreendido
nas demandas do EB no contexto do Sistema Integrado de Monitoramento de Fronteiras
(SISFRON), não necessariamente deve ser atendido pelo sistema em estudo. Sua inclusão visou
capturar de maneira mais ampla os objetivos para atender à necessidade de missão do
stakeholder. Porém uma análise preliminar da taxa de transmissão demandada pelos sensores
indicou que esta capacidade pode ser atingida pelos pequenos satélites apenas em ocasiões
pontuais e/ou emergenciais, não sendo a destinação principal da constelação, voltada para a
comunicação de tropas. Com relação aos satélites geossíncronos, em geral de maior volume, a
capacidade de terem embarcadas cargas úteis e painéis solares com maiores capacidades de
transmissão de dados e geração de energia, respectivamente, permite melhores condições para
atender às demandas dos sensores em solo.
O poder das comunicações como fator integrador advém da demonstração de força e
capacidade operacional para as comunidades isoladas ou fronteiriças, apresentada por uma
tropa que é capaz de se comunicar com seu comando dadas as dimensões continentais do Brasil.
Desta forma, as comunidades locais podem sentir a presença e disposição das Forças Armadas
em manter a unidade nacional, como um forte poder de integração.
Dentre as alternativas apresentadas, observa-se que tanto satélites geossíncronos quanto
constelações em baixa órbita são capazes de atender aos objetivos do projeto, satisfazendo aos
KPP.

4.4.2 Atividade 4.2: Identificação do contexto e arquitetura operacionais

Nesta atividade, inicialmente a equipe de projeto e os stakeholders externos

(representantes do EB), a partir do escopo, objetivos e metas do projeto, dos requisitos de
missão e sistema e dos KPPs, estabeleceram, em reunião, as fronteiras do sistema (Figura 28).
Identificou-se que constitui o sistema de interesse a constelação de pequenos satélites.
Compreendidos na elipse pontilhada do sistema de sistemas e externos à elipse do sistema de
interesse, encontram-se o lançador, a operação dos sistemas espaciais, os satélites
geossíncronos, os rádios (equipamentos de comunicação em solo) e as estações de solo (Figura
 116

28). Para os satélites geossíncronos que se encontram em órbita atualmente, não foi considerado
o relacionamento com o lançador, que garantirá a reposição da constelação de pequenos
satélites. A operação dos satélites é realizada a partir das estações de solo. Os usuários (tropas
militares dos diferentes níveis) e os sensores de defesa encontram-se fora das fronteiras do
sistema de sistemas (elipse externa), sendo entidades externas ao sistema.

Figura 28 – Fronteiras do sistema.

Em seguida, utilizando também as informações sobre os stakeholders e suas funções,

utilizaram-se diagramas para estabelecer, em reunião, os contextos “As-is” e “To-be”.
No estado atual “As-is” (Figura 29), nota-se que existe uma infraestrutura baseada em
satélites geossíncronos (GEO) que realiza o envio de dados de sensores de defesa, além de
fornecer serviço de comunicação de dados, voz e texto entre as unidades do Exército de nível
maior ou igual a batalhão e COp (Centro de Operações, que pode estar no nível batalhão ou
brigada). Porém não existe recurso satelital militar para comunicação de forças táticas móveis
tais como grupos de combate, pelotões e companhias se deslocando em região de selva, e as
comunicações neste nível, em geral, são realizadas com redes de rádio transmissores e estações
de rádio repetidoras. O ambiente (radiação, cintilações, tempestades solares, chuvas, variações
de temperatura) atuam degradando o sistema e interferindo nas transmissões. Os oponentes e
elementos adversos involuntariamente emitem sinais, a partir de suas aeronaves, embarcações
ou rádios, por exemplo, que possibilitam sua detecção por sensores. Considera-se que os
 117

oponentes (nações) podem ter capacidade de interferir nos sistemas satelitais, enquanto os
elementos adversos (ex. contrabandistas e traficantes) não apresentam esta potencialidade. O
Comando de Comunicações e Guerra Eletrônica do Exército (CComGEx) é o responsável por
assessorar o Comando de Operações Terrestres (COTER) ou o Comando do EB na utilização
dos recursos satelitais, coordenando com as estações de solo sua operação. Cabe ressaltar que,
de acordo com as dimensões da operação, outros níveis de comando podem estar presentes,
como forças-tarefa, divisões, e exércitos de campanha, contudo os diagramas desta seção visam
a apresentar o contexto operacional enfatizando os elementos de nível batalhão e inferior, que
são o foco do projeto.

Figura 29 – Diagrama de contexto “As-is”.

A solução proposta pela equipe para o presente projeto é esboçada no modelo “To-be”
(Figura 30), relativo à constelação de pequenos satélites de comunicação.
 118

Figura 30 – Diagrama de contexto “To be” para a constelação de pequenos satélites.

O modelo “To-be” inclui capacidades de comunicação por texto e dados a tropas de

nível companhia, pelotão e grupos de combate (marcadas na cor cinza, pois neste contexto se
relacionam diretamente com o recurso satelital). A constelação de pequenos satélites tem
capacidade ainda de estabelecer contato com batalhões, mas atende aos níveis brigada e superior
(exemplificados pelo COTER e Comando do EB) apenas excepcionalmente, dado que não
possuem taxa de transmissão compatível com o provimento de serviço contínuo de
comunicação para estes níveis. As comunicações de banda estreita, conforme definido no
PESE, tem como usuário alvo as forças táticas móveis, e não os grandes comandos. Conforme
definido nos objetivos e metas do projeto, Seção 3.3.2, as informações oriundas de sensores de
defesa (como radares, por exemplo) podem ser transmitidas por meio dos pequenos satélites,
em casos emergenciais, de maneira degradada. Os equipamentos a serem usados pelas tropas
devem possibilitar a comunicação, ao menos, por texto e dados, e respeitar os limites de
dimensões e massa estabelecidos, a fim de não interferir na agilidade do deslocamento das
tropas, ainda que em terreno difícil.
 119

Para permitir o entendimento da operação da constelação de pequenos satélites em

conjunto com satélites em órbita geossíncrona, como o SGDC, construiu-se o diagrama “To-
be” incluindo as soluções satelitais geossíncronas e os pequenos satélites não-geossíncronos
(Figura 31). Neste diagrama, observa-se a participação do CComGEx, coordenando a operação
dos sistemas espaciais que provêm os seguintes serviços:
1. Comunicação entre sensores de defesa e usuários;
2. Comunicação entre usuários de diferentes níveis (ex. batalhões, companhias,
pelotões, tropas militares em geral).

Figura 31 – Diagrama de contexto “To-be” incluindo as soluções satelitais geossíncronas e os

pequenos satélites não-geossíncronos.

A comunicação entre sensores de defesa e usuários permite recebimento de

informações de radares e sensores de Guerra Eletrônica a respeito de embarcações, aeronaves
e tropas não identificadas no território nacional.
Este canal demanda cobertura 100% do tempo (também chamada 24/7, ou seja, 24 horas
por dia, 7 dias por semana), visto que qualquer lacuna pode ser aproveitada por elementos
adversos, que passam a operar justamente nestas falhas. Assim, um serviço que apresente
 120

intervalos conhecidos de indisponibilidade pode ser aproveitado por elementos que se planejem
para executar suas ações nas áreas e horários de não cobertura.
Desta forma, os sistemas espaciais para atender a esta ligação podem ser satélites
geossíncronos, que atendem ao requisito de cobertura 100% do tempo, ou constelações de
pequenos satélites, de acordo com o número de pequenos satélites e órbitas. Com relação à taxa
de transmissão disponível, satélites GEO, dadas as suas dimensões, em geral, oferecem espaço
para instalação de cargas úteis com uma capacidade maior, enquanto pequenos satélites
demandam um estudo mais aprofundado para dimensionar suas cargas úteis.
A comunicação entre usuários de diferentes níveis refere-se àquela realizada entre as
tropas e seus respectivos comandos. Os níveis podem ser esquadras, grupos de combate,
pelotões, companhias, batalhões, brigadas e divisões, além de forças-tarefa e exércitos de
campanha. As tropas dos diferentes níveis precisam ter suas necessidades de comunicação
atendidas para permitir um exercício eficaz de Comando e Controle, mas, dadas as diferentes
demandas de banda, cobertura e tempo de resposta, as soluções empregadas para cada nível
podem ser diferentes.
Usuários de nível menor, por demandarem menor taxa de transmissão, podem ser
atendidos por pequenos satélites, podendo inclusive não demandar cobertura 100% do tempo
ou em tempo real (os protocolos operacionais atuais, inclusive, recomendam o estabelecimento
de horários predeterminados para estabelecer contato). Já usuários de nível mais elevado, como
batalhões e brigadas, podem exigir fluxo de dados maior e maior cobertura, para estarem
disponíveis durante as janelas de cobertura das diferentes frações subordinadas. Neste contexto,
a cobertura para comunicações por voz pode também ser atendida pelos satélites GEO.
A seguir, a equipe desenvolvedora e o EB identificaram dois cenários operacionais para
uma comunicação de dois usuários de níveis diferentes. O primeiro cenário identificado foi de
tentativa de comunicação em condições ambientais (incluindo as condições climáticas terrestres
e espaciais) favoráveis (ex. terreno com pouca cobertura vegetal, sem nuvens, sem tempestade
solar, sem cintilações e bolhas de plasma ionosféricas). O segundo cenário foi para tentativa de
comunicação em condições ambientais desfavoráveis (ex. terreno com densa cobertura vegetal,
com nuvens, com tempestades solares). Para estes cenários, foram construídas sequências
operacionais para cada um dos serviços (comunicação entre sensores de defesa e usuários e
comunicação entre usuários de diferentes níveis). Nesta seção, somente serão apresentadas duas
sequências operacionais para os cenários de condições ambientais favoráveis, de modo que
todas as atividades acontecem conforme previsto. Para o cenário de condições ambientais
 121

desfavoráveis, a interferência ambiental pode comprometer o sequenciamento de operações,

interrompendo o fluxo de mensagens.
A sequência operacional para comunicação entre usuários de diferentes níveis em
condições ambientais favoráveis é apresentada na Figura 32. Nesta sequência, observa-se que
uma confirmação de recebimento de mensagem é enviada automaticamente pelo equipamento
de comunicação do destinatário, que o satélite transmite ao chamador. Desta forma, o chamador
pode saber se sua mensagem foi recebida ou não, o que pode contribuir para seu conhecimento
a respeito do destinatário (caso o destinatário tenha recebido a mensagem, é um sinal de que o
destinatário tem carga nas baterias e está em área com cobertura satelital naquele momento).
Nesta sequência operacional, os usuários foram divididos em dois níveis genéricos: tropa, para
o elemento subordinado, e comando, para os elementos de maior nível entre os dois. Este ciclo
de comunicação pode se repetir, alternando as posições de chamador e destinatário, de modo a
se estabelecer o contato entre as forças militares.

Figura 32 – Sequência de operações para comunicação entre usuários de diferentes níveis em

condições ambientais favoráveis.

A Figura 33 apresenta a sequência operacional para comunicação entre sensores de

defesa e usuários em condições ambientais favoráveis. Nesta sequência, uma possível ameaça
(ex. navio, aeronave, tropa cuja comunicação seja detectada) invade o território nacional e é
detectada por um sensor de defesa. Este sensor transmite a informação para uma unidade militar
pré-definida (“comando”) por meio de satélites, e esta unidade militar processa as informações,
 122

identifica a ameaça e, se for o caso, inicia contato para solicitar ou providenciar uma
interceptação.

Figura 33 – Sequência de operações para comunicação entre sensores de defesa e usuários em

condições ambientais favoráveis.

Em reunião envolvendo a equipe de projeto e o EB foi elaborada a Tabela 32, que mostra
as atividades das principais entidades envolvidas na operação do sistema (nós operacionais).

Tabela 32 – Nós operacionais.

Nó operacional Atividades
Satélites de comunicações * Detectam dados de comunicação dos usuários (voz/texto)
* Detectam dados de missão dos usuários
* Detectam dados de sensores de Guerra Eletrônica
* Enviam dados de comunicação aos usuários (dados/texto)
* Geram e enviam dados de telemetria do satélite
* Recebem e executam comandos operacionais
Estação de solo (COMAE) * Recebe status dos satélites
* Envia telecomando para os satélites
CComGEx (EB) * Recebe os dados de missão para os satélites do controle de missão
* Analisa os dados de status/telecomando dos satélites
* Gera os comandos operacionais dos satélites
* Registra o conjunto de dados de status/telecomando dos satélites
* Envia dados de missão dos satélites para o controle de missão
Usuários (tropas) * Recebem dados de comunicação dos satélites
* Recebem dados de missão dos satélites
* Recebem dados de sensores de Guerra Eletrônica dos satélites
* Enviam dados de comunicação para os satélites
 123

Nó operacional Atividades
Controle de missão * Analisa os dados de comunicação dos satélites
* Analisa os dados de missão dos satélites
* Analisa os dados dos sensores de Guerra Eletrônica
* Gera os dados de comunicação dos satélites
* Gera os dados de missão dos satélites
* Gera relatórios de missão
Usuário (Comando) * Recebe e solicita relatórios de missão
* Gera plano de missão

Como se pode observar, as partes elencaram apenas atividades e relações para a fase de
operações do sistema, e não para todo o ciclo de vida do mesmo (que inclui, por exemplo,
montagem, integração e teste, transporte, lançamento). Além disso, tais atividades não foram
registradas contratualmente. Isto porque ainda não havia, naquele momento, a contratação do
desenvolvimento, de modo que as reuniões entre a equipe de projeto do CEI e os representantes
do EB visavam a amadurecer o conceito do sistema, com a expectativa de contratação futura.
Assim, a identificação das sequências operacionais foi realizada de forma simplificada.
Encerrando esta atividade, a equipe desenvolvedora e o EB estudaram a lista com as
funções dos principais stakeholders e as sequência de operações para cada cenário. As partes
identificaram, então, as relações entre as entidades envolvidas no projeto e os sistemas no
diagrama NxN dos elementos do sistema de sistemas (Tabela 33). Neste diagrama, cada volta
no sentido horário apresenta, respectivamente, o elemento que uma entidade provê para outra,
e o que ela recebe da mesma.

Tabela 33 – Diagrama NxN dos elementos do sistema de sistemas.

Dados de
SATÉLITE DE
Status do comunicação
COMUNI-
satélite (usuários) e/ou
CAÇÕES
dados sensores
ESTAÇÃO DE Telemetria
Comando do
SOLO operacional do
satélite
(COMAE) satélite
Comandos Conjunto de
CCOMGEX Relatório de
operacionais do dados de
(EB) desempenho
satélite operação
Dados de Dados de
USUÁRIOS
comunicação comunicação e
(TROPAS)
para os usuários sensores
Dados de
Dados de Solicita dados CONTROLE Relatório de
comunicação para
missão operacionais DE MISSÃO missão
os usuários
Análise de Análise e escopo USUÁRIO
desempenho da missão (COMANDO)
 124

4.4.3 Atividade 4.3: Identificação das condições ambientais

Para a identificação das condições ambientais, uma vez definidas as fronteiras do

sistema, a equipe de projeto estudou novamente os diagramas de contexto e as sequências de
operações para os cenários. Verificou-se que os produtos compreendidos no escopo do
desenvolvimento eram os satélites da constelação.
Para os satélites, além do estudo do ambiente espacial, procedeu-se também à
modelagem computacional no software AGI STK, que permite a simulação de missões
espaciais e forneceu informações relativas à faixa de temperatura esperada para órbitas
semelhantes às dos satélites elencados na Etapa 2 (Benchmarking) como sendo referências para
o projeto. As condições críticas, bem como as justificativas que explicam a adoção de cada uma
delas, são apresentadas na Tabela 34.

Tabela 34 – Condições ambientais.

Sistema Condição ambiental Justificativa

Satélite Temperatura: Faixa de temperatura esperada para operação em
-45° a +65°C ambiente espacial
Resistência às condições Vácuo espacial pode provocar volatilização de
de vácuo espacial partículas contaminantes, que degradam o
desempenho do sistema
Resistência à Radiação é uma condição que degrada desempenho e
degradação por radiação vida útil dos sistemas espaciais

4.5 Etapa 5: Arquiteturas funcional e física

Uma vez definido o conceito de operações, realizaram-se as seguintes atividades

(descritas na Tabela 13):
• Atividade 5.1: Identificação das funções do sistema
• Atividade 5.2: Definição da arquitetura física
• Atividade 5.3: Captura de requisitos de baixo nível
 125

4.5.1 Atividade 5.1: Identificação das funções do sistema

Uma vez definidos o contexto “To-be” e as sequências de operações para os cenários, a

equipe e os stakeholders externos reuniram-se para identificar as funções a serem
desempenhadas pelo sistema, a partir de cada um dos objetivos de projeto.
Desta forma, cinco funções foram apontadas: comunicar com tropas, comunicar com
outros satélites, proteger as comunicações, gerenciar o sistema durante a operação e, por fim,
comunicar com os sensores em solo. Conforme explicado anteriormente, a terceira função, da
comunicação com os sensores em solo, embora compreendida nas demandas do Exército
Brasileiro no contexto do SISFRON, não necessariamente deve ser atendida pelo sistema
baseado na constelação de nanossatélites. Sua inclusão neste estudo visou capturar de maneira
mais ampla o contexto em que está inserida a necessidade de missão do Exército Brasileiro.
Associados a cada função, foram identificados cenários, sendo um extrato dos resultados
apresentado na Tabela 35.

Tabela 35 – Extrato das funções do sistema e cenários.

Objetivos de projeto Funções Cenários

1. Prover serviço de
comunicação para tropas
militares nos níveis grupo de
combate, pelotão, companhia
e batalhão localizadas na
região amazônica
2. Ser compatível com
equipamentos de comunicação
operados por tropas do
Exército Brasileiro
3. Manter a segurança das
comunicações
4. Viabilizar a autonomia para
a implementação de soluções
de comunicações pelas Forças
Armadas
5*. Prover serviço de
comunicação com os sensores sensores em solo
em solo
Nota: O asterisco (*) destaca o objetivo a ser atendido apenas em condições emergenciais.
1. Comunicar com Condições ambientais favoráveis
tropas Condições ambientais desfavoráveis
2. Comunicar com Condições ambientais favoráveis
outros satélites Condições ambientais desfavoráveis
Entidades relacionadas Usuários (tropas do EB), satélites
Requisito não funcional Não se aplica
Entidades relacionadas Equipamentos de comunicação em solo
Interceptação da comunicação pelo
3. Proteger as oponente
comunicações Perda da comunicação devido a ruídos
causados pelo oponente
Entidades relacionadas Stakeholders negativos
Interface com o centro de operações
4. Gerenciar o sistema Corrigir falhas do sistema em operação
durante a operação Corrigir defasagem entre os satélites nos
planos orbitais
Entidades relacionadas COPE
5*. Comunicar com os Condições ambientais desfavoráveis
Corrigir falhas do sistema em operação
Entidades relacionadas Radares/ sensores, comando
 126

O cenário “Corrigir defasagem entre os satélites nos planos orbitais” pode se

apresentar em três momentos diferentes durante a permanência dos satélites em órbita:
1. Antes do início da operação, caso se precise ajustar a posição relativa entre os
satélites após o lançamento;
2. Durante a operação, caso algum objeto externo (detrito, por exemplo) ou fator
ambiental comprometa a órbita de algum dos satélites, sem causar sua
perda;
3. Durante a operação, caso algum dos satélites seja perdido (por falha, devido a
detritos espaciais ou outro motivo), demandando o reposicionamento dos demais
satélites enquanto não houver substituição do satélite perdido, para otimizar o
desempenho da constelação.
Dada a missão operacional do sistema, os principais cenários para as comunicações são
influenciados por condições de clima (terrestre ou espacial) que podem dificultar a recepção
dos sinais. Com relação à segurança das comunicações, entra em atuação o stakeholder
negativo, um eventual oponente que tenha interesse em interceptar ou interferir nas
comunicações. A função de gerenciamento durante a operação visa a manter o funcionamento
e o estado de operacionalidade do sistema.
Foram criados modelos para representar as funções. A Figura 34 apresenta o modelo
para as funções “comunicar” (numeradas na Tabela 35 como 1 e 2, para tropas e outros
satélites, e 5, para sensores), mostrando os atores envolvidos (grupos de combate, pelotões,
companhias e batalhões) e a ação das estações de solo do COPE, gerenciando a operação dos
sistemas espaciais. Identificam-se ainda funções e subfunções ligadas à função “comunicar”,
como “proteger informações”, “proteger operação”, “confirmar comunicação” e “transmitir
localização”.
Este modelo é apresentado de modo a incluir a atuação dos satélites geossíncronos e dos
sensores, com o intuído de mostrar o relacionamento do sistema de interesse (a constelação de
pequenos satélites) com outros sistemas.
 127

Figura 34 – Modelo para as funções “comunicar”.

Em seguida, foram criados diagramas de sequência para as funções. Estes diagramas

apresentam o encadeamento das ações e o fluxo de informações entre os atores, para uma dada
função em diferentes cenários (DOUGLASS, 2016).
Para a função “comunicar com tropas”, no cenário de condições ambientais favoráveis,
no caso em que o comando envia uma mensagem para a tropa (Figura 35), tem-se que
inicialmente o sistema deve estar pronto para receber mensagens (a). O comando então envia
uma mensagem (b), e o sistema inicia o contador (c), enquanto processa o recebimento da
mensagem (d) e verifica a integridade da mensagem (e). Em seguida, o sistema envia para o
comando uma confirmação do recebimento da mensagem por parte do satélite (f). Então, o
sistema transmite a mensagem para a tropa (g). O equipamento de comunicação da tropa envia
um sinal de confirmação de recebimento da mensagem por parte da tropa (h). O sistema
encaminha ao comando o sinal de recebimento da mensagem por parte da tropa (i) e zera o
contador (j). Ao final deste processo, o sistema deve estar pronto para receber novas mensagens
(l).
 128

Figura 35 – Diagrama de sequência funcional para a função “comunicar com tropas”, em que
o comando envia uma mensagem para tropa, no cenário de condições ambientais favoráveis.

Para a função “comunicar com tropas”, no cenário de condições ambientais

desfavoráveis, no caso em que o comando envia uma mensagem para a tropa, considerando que
a mensagem é recebida pelo satélite e o comando recebe a confirmação de recebimento pelo
satélite, a sequência é a mesma da anterior até a fase (f), como pode ser observado na Figura
36. O ambiente, então, oferece resistência para o recebimento da mensagem por parte da tropa
(g), de modo que a transmissão da mensagem não chega até a tropa (h). O contador informa ao
sistema que foi excedido o tempo para a comunicação (i). O sistema então zera o contador (j) e
retorna ao estado de pronto para receber novas mensagens (l). Desta forma, o sistema pode
responder a novas tentativas de comunicação (m).
 129

Figura 36 – Diagrama de sequência para a função “comunicar com tropas”, em que o

comando envia uma mensagem para tropa, no cenário de condições ambientais desfavoráveis.

4.5.2 Atividade 5.2: Definição da arquitetura física

Com o objetivo de se identificar os subsistemas e seus principais componentes, de posse

das informações referentes às sequências de operações, fronteiras do sistema, funções e
sequenciamento funcional do sistema, a equipe de projeto mapeou as funções, decompondo-as
em subfunções. Para estas subfunções identificaram-se os elementos físicos que devem
desempenhá-las. Embora o sistema de interesse (SoI) inclua em suas fronteiras apenas a
constelação de pequenos satélites, a arquitetura física foi também identificada para os
equipamentos de comunicação em solo, para identificar uma proposta de constituição mínima
dos mesmos (Tabela 36 e Tabela 37).
 130

Tabela 36 - Mapeamento funcional do(s) satélite(s).

Função Subfunções Elementos físicos

Comunicar com -Receber mensagem -Rádios

tropas -Iniciar contador -Antenas
-Transmitir mensagem -Computador de bordo
-Confirmar recebimento -Cablagem
-Receber localização
-Zerar contador
-Transmitir localização
Proteger a operação -Proteger as comunicações -Computador de encriptação
-Evitar interceptação
-Evitar perda das comunicações

Comunicar com os -Receber mensagem -Rádios

sensores de solo -Transmitir mensagem -Antenas

Gerenciar o sistema -Receber telecomando -Rádios

durante a operação -Checar status -Antenas
-Enviar status -Computador de bordo
-Corrigir falhas durante operação -ADCS (Attitude Determination and
-Configurar modo de operação Control Systems - subsistema de
-Manter atitude controle e determinação de atitude)
-Gerar energia -Painéis solares
-Armazenar energia -Baterias
-Distribuir energia -EPS (Electrical Power Systems –
-Manter temperatura de operação subsistema de potência e energia)
-Corrigir defasagem -Estrutura
-Proteção térmica
-Subsistema propulsivo
-Cablagem

Tabela 37 - Mapeamento funcional dos equipamentos de comunicação em solo.

Função Subfunções Elementos físicos

Comunicar com -Receber mensagem -Rádio
sistemas espaciais -Confirmar recebimento -Antena
-Transmitir mensagem
-Receber localização
Comunicar com -Receber mensagem -Rádio
equipamentos em solo -Transmitir mensagem -Antena
Informar localização -Identificar localização -Receptor de localização
dos usuários -Alternar modo de identificação de -Botões para digitação (ou teclado virtual)
localização (automática/manual)
-Digitar localização
-Transmitir localização
Proteger as -Evitar interceptação -Computador de encriptação
comunicações -Evitar perda das comunicações
 131

Função Subfunções Elementos físicos

Apresentar -Exibir mensagem -Tela
mensagem ao usuário -Executar mensagem de voz -Alto falante
-Controles de volume
-Controles de frequência
-Cablagem
Receber mensagem -Digitar mensagem -Tela
do usuário -Receber mensagem de voz -Botões para digitação (ou teclado virtual)
-Controles de frequência
-Microfone
-Cablagem
Gerenciar o sistema -Receber energia -Carregador elétrico
durante a operação -Armazenar energia -Porta para carregamento elétrico
-Baterias
-Cablagem

Conforme foi possível identificar no modelo para as funções “comunicar” (Figura 34),
a demanda do EB pelo envio da localização do usuário que transmite a mensagem, visando a
facilitar o apoio às tropas em caso de necessidade de evacuação aeromédica, por exemplo,
implica a função “informar localização dos usuários”, para os equipamentos de comunicação
em solo. Esta localização pode ser identificada automaticamente pelo equipamento, ou ser
inserida pelo próprio usuário, o que implica as subfunções “identificar localização”, “digitar
localização” e ainda “alternar modo de identificação de localização (automática/manual)”. Por
fim, o equipamento precisa “transmitir localização” para os satélites.
Para os satélites, receber e transmitir esta localização são subfunções da função
“comunicar”. Desta forma, da perspectiva dos satélites, a localização é apenas mais um dado a
ser recebido e enviado juntamente com a mensagem, enquanto para os equipamentos em solo
existe a necessidade de uma nova função, pois além de “comunicar” os equipamentos precisam,
de alguma forma, identificar sua localização ou aceitar uma localização como entrada. Esta
função demanda um receptor de posicionamento e/ou uma interface por meio da qual o usuário
possa inserir manualmente no sistema sua localização, o que, em geral, é realizado por meio de
um teclado (com botões ou virtual).
Com relação ao sistema propulsivo, que está relacionado à função “gerenciar o sistema
durante a operação”, seu emprego deve ocorrer majoritariamente durante início de operação ou
em caso de perda de um dos satélites, para corrigir a defasagem entre os mesmos na constelação.
As demais funções foram decompostas seguindo o mesmo processo mental, podendo
estar relacionadas de forma diferente para os satélites e os equipamentos de comunicação em
solo. Observa-se que o mesmo elemento físico pode estar associado à execução de mais de uma
 132

função, como os “botões para digitação (ou teclado virtual)”, relacionados a “receber mensagem
do usuário” e “informar localização dos usuários”.
Em seguida, a equipe identificou, preliminarmente e sem especificar fabricantes ou
modelos, os componentes dos subsistemas de cada satélite (Tabela 38).

Tabela 38 - Identificação dos principais componentes dos subsistemas para o(s) satélite(s).

Subsistemas Componentes
-Painéis solares
Subsistema de potência e energia (EPS) -Baterias
-Unidade de condicionamento e distribuição de energia
-Sensores
Subsistema de determinação e controle de
-Atuadores
atitude (ADCS)
-Computador de controle
Subsistema de status/ telecomando e -Rádios
controle (TT&C) -Antenas
Subsistema de gerenciamento de bordo
-Computador de bordo
(OBDH)
-Estrutura externa
Subsistema estrutural
-Estrutura Interna
-Computador de encriptação
Subsistema de comunicação (carga útil) -Rádios
-Antenas
Subsistema propulsivo -Propulsores

O EPS é o subsistema responsável pela geração, armazenamento e distribuição de

energia ao satélite. Seus painéis solares são componentes críticos para a missão, pois precisam
gerar energia suficiente para garantir o funcionamento de todos os subsistemas sem alteração
de desempenho, mesmo no pior cenário operacional. Desta forma, pode-se considerar a
utilização de painéis de abertura para maximizar a geração de energia.
O ADCS é responsável pelo controle de atitude e/ou estabilização do(s) satélite(s).
Ainda que nesta fase de projeto não esteja determinado o tipo de controle necessário ou a
quantidade de eixos a se controlar (1, 2 ou 3 eixos), verificou-se no benchmarking que os
sistemas estudados apresentavam algum controle de atitude para melhorar o desempenho de
transmissão de dados, ainda que somente para estabilização de rotação dos satélites.
O subsistema de comunicação, como carga útil embarcada no satélite, pode utilizar um
computador dedicado para realizar a encriptação dos dados, visando a desonerar o computador
de bordo do processamento da encriptação, ou ainda utilizar o próprio computador de bordo
para tal função. O rádio utilizado pela carga útil também pode ser o mesmo que o utilizado pelo
 133

TT&C. Estas decisões demandam estudos posteriores, e irão depender do nível de desempenho
exigido pelos stakeholders.
O sistema propulsivo é o responsável por corrigir a defasagem dos satélites, caso seja
necessário, no início ou durante a operação, conforme tratado na Seção 4.5.1.
Com relação aos equipamentos de comunicação em solo, a interface com o usuário pode
ser feita através de botões convencionais ou por meio de telas de toque e teclado virtual (Tabela
39). Independente da solução de projeto definida posteriormente, o sistema deve fornecer a
possibilidade de leitura e digitação de mensagens de textos, conforme estabelecido do conceito
de operações.

Tabela 39 - Identificação dos principais componentes dos subsistemas para os equipamentos

de comunicações em solo.

Subsistemas Componentes
-Baterias
Subsistema de potência e energia -Unidade de condicionamento e distribuição de energia
(EPS) -Porta para carregamento elétrico
-Carregador elétrico
-Tela
-Botões para digitação (ou teclado virtual)
Subsistema de interface com o
-Controles de volume
usuário
-Controles de frequência
-Microfone
-Estrutura Externa
Subsistema estrutural
-Estrutura Interna
-Computador de encriptação
Subsistema de comunicação
-Antenas
(carga útil)
-Memória
Subsistema de localização
-Receptor de localização
(carga útil)

Construíram-se, então os diagramas funcionais dos subsistemas e componentes para as

funções. A Figura 37 apresenta um destes diagramas, para a função “comunicar com tropas”.
Neste diagrama pode-se observar o relacionamento dos componentes “antena”, “rádio” e
“computador de bordo” durante a transmissão de uma mensagem oriunda do comando. Para
este caso, em que não há um computador dedicado a criptografia, é o computador de bordo que
desempenha as funções de desencriptar as mensagens, verificar sua integridade e encriptar
mensagens. Esta forma de execução da função comunicar é preliminar, e o modo de operação
interna dos subsistemas e seu relacionamento continuará sendo atualizado durante o processo
 134

de desenvolvimento, sendo dependente inclusive do conceito a ser selecionado pelo Exército

Brasileiro ao final da fase de estudo conceitual.

Figura 37 - Diagrama de sequência funcional dos subsistemas e componentes para a função

“comunicar com tropas”.

4.5.3 Atividade 5.3: Captura de requisitos de baixo nível

Para a consecução desta atividade, a equipe utilizou-se de todas as informações

disponíveis acerca do projeto, incluindo os documentos de controle de interface dos
fornecedores. A equipe avaliou que não era necessário decompor os requisitos até o nível
componente nesta fase para o projeto em questão. Desta forma, os requisitos de sistema foram
decompostos para o nível subsistema. Um exemplo da decomposição dos requisitos de sistema
para o nível subsistema é apresentado na Tabela 40.
 135

Tabela 40 – Extrato dos requisitos do(s) satélite(s), nos níveis sistema e subsistema.

SysReq_01- O sistema deve estabelecer o enlace entre usuários

Subsistema Requisitos

Comunicação SubSysReq_01.1- O subsistema de comunicação deve transmitir dados a uma taxa

de 56 Kbps
SubSysReq_01.5- O subsistema de comunicação deve permitir apontamento em até
30 segundos (limite), 10 segundos (objetivo) sem uso de equipamentos para
apontamento

O requisito de sistema SatReq_01 foi decomposto em requisitos de subsistema. Destes,

são apresentados os SubSysReq_01.1 e SubSysReq_01.5, que alocam no subsistema de
comunicação requisitos que quantificam a taxa de transmissão de dados e tempo de
apontamento para estabelecimento do enlace entre usuários do sistema e satélites. A Figura 38
mostra o modelo que representa estes mesmos requisitos e sua rastreabilidade, decompostos até
o nível subsistema.

Figura 38 – Extrato do modelo de rastreabilidade dos requisitos.

Os requisitos foram discutidos em reuniões com os stakeholders, resultando em uma

nova versão basilar do documento de requisitos.
 136

4.6 Etapa 6: Exploração de conceitos

Uma vez definidas as arquiteturas funcional e física, para a exploração de conceitos

realizaram-se as seguintes atividades (descritas na Tabela 17):
• Atividade 6.1: Órbitas e constelações
• Atividade 6.2: Estudo de desempenho

4.6.1 Atividade 6.1: Órbitas e constelações

A partir das informações do escopo do projeto e seus objetivos e metas, a área de

interesse selecionada foi a da região amazônica conforme apresentado na Figura 39. A fim de
se obter um parâmetro de comparação entre as diferentes combinações de inclinação e altitude,
limitou-se a cobertura do sensor instalado em cada satélite a uma geometria cônica com
semiabertura de 60°.
Para se definir configurações de constelações que pudessem atender à necessidade de
missão do EB, utilizou-se como valores iniciais de referência os identificados no trabalho de
Loures Da Costa, Shibuya e Albuquerque (2017), que apontaram para inclinações entre 0 e 15°.
As altitudes simuladas corresponderam aos valores usuais para satélites de comunicações em
baixa órbita, entre 450 km e 800 km, com passo de 50 km. Esta faixa de altitude se encontra
entre uma altitude mínima (450 km) que permite atingir tempo em órbita e cobertura
compatíveis com os objetivos e metas do projeto e uma altitude máxima (800 km) interior ao
cinturão de Van Allen, reduzindo a exposição dos satélites a efeitos da radiação (WERTZ;
EVERETT; PUSCHELL, 2011).
Em virtude das dificuldades impostas pelo clima e vegetação amazônicos ao
estabelecimento de comunicações, foi priorizada neste estudo de órbitas a altitude de 450 km,
por ser, dentre as selecionadas, a que fornece a maior probabilidade de sucesso no enlace em
momentos de clima desfavorável, com os demais valores de altitude (até 800 km) servindo
como referência. Estudos adicionais acerca da capacidade de comunicação dos equipamentos
de comunicação utilizados em solo por forças táticas móveis com satélites através da densa
selva amazônica sob diferentes condições climáticas terrestres e espaciais podem contribuir
para demonstrar a viabilidade de altitudes até 800 km.
 137

Figura 39 – Área de interesse selecionada no software AGI STK.

O software de simulação de missões espaciais utilizado foi o AGI STK, e para otimizar
o emprego de esforço computacional, simulou-se inicialmente, para cada combinação de
inclinação e altitude, um único satélite. Foram registrados os parâmetros relativos a tempo
máximo e médio de revisita, quantidade mínima de acessos por dia, duração média dos acessos,
porcentagem média do tempo de cobertura, tempo de cobertura diária mínima. O tempo de
simulação estabelecido foi de um ano.
A partir dos resultados encontrados para um único satélite, selecionaram-se as
configurações mais apropriadas para a missão. Dentre os satélites que as simulações mostraram
cobrir 100% da área de interesse, foram priorizados os que apresentaram os menores tempos
médio e máximo de revisita, e os maiores percentuais de cobertura. Os demais critérios foram
considerados na comparação para tentar identificar possíveis comportamentos inadequados de
determinadas órbitas. Por exemplo, para se garantir que, além da realização do acesso, o acesso
seja mantido por tempo adequado à transmissão de mensagens, foram excluídas as
configurações que apresentaram menos de 200 segundos de tempo médio de acesso.
Desta forma, as configurações de inclinação e altitude selecionadas são apresentadas na
Tabela 41, com as altitudes de 550, 600 e 800 km como referência.
 138

Tabela 41 – Combinações de inclinação e altitude selecionadas.

Inclinação (graus) Altitude (km)

5 450
8 450
10 450
10 550
5 600
0 800

Uma vez selecionadas as combinações de inclinação e altitude que indicavam melhor

nível de desempenho em cobertura, foram estudadas diversas configurações de constelações
associadas a cada combinação. Foram utilizadas constelações do tipo Walker, pois elas
fornecem a melhor cobertura para a área de interesse utilizando o menor número de satélites
(WERTZ; EVERETT; PUSCHELL, 2011). De modo geral, se buscam soluções empregando o
menor número de satélites e/ou menor altitude possíveis, para minimizar o custo do projeto.
Em seguida, procedeu-se à comparação do nível de desempenho das constelações utilizando os
mesmos parâmetros que os utilizados anteriormente para o caso de um satélite.
Os critérios a que se atribuiu maior importância foram os tempos médio e máximo de
revisita. Isto porque para a transmissão de dados, imagem e texto com cobertura inferior a 100%
do tempo (conforme definido no conceito de operações para este projeto), o parâmetro mais
importante a se determinar é aquele que informa, uma vez que um dos satélites tenha deixado
de prestar cobertura a um ponto, em quanto tempo outro satélite estará posicionado prestando
cobertura àquele mesmo ponto (LOURES DA COSTA; SHIBUYA; ALBUQUERQUE, 2017).
Desta forma, é possível estimar qual o maior tempo que em média um usuário do sistema terá
de esperar para que sua mensagem seja recepcionada pela constelação.
As constelações selecionadas por meio deste processo e alguns de seus parâmetros de
desempenho são apresentados na Tabela 42, e uma visualização do resultado de uma
constelação e seu campo de visão é mostrada na Figura 40, em que os parâmetros com
resultados considerados satisfatórios são preenchidos em verde e os insatisfatórios em vermelho
claro. Consideraram-se satisfatórios os tempos de revisita inferiores a 10 minutos (conforme
requisito de missão MisReq_03) e porcentagens médias de cobertura superiores a 7% no ponto
de mínimo e 12% na média geral.
 139

Tabela 42 - Tempo de revisita e tempo porcentual de cobertura em função da órbita e

configuração da constelação, com as altitudes de 550 e 600 km como referência.

Órbita Configuração da Tempo % média de cobertura

constelação Total de médio de
Inclinação Altitude Ponto de Média
(planos x satélites satélites revisita
(graus) (km) por plano)
mínimo geral
(minutos)
5 600 2x6 12 6,5 4,9 53,5
5 450 2x6 12 13,2 1,1 30,2
5 450 2x8 16 9,1 1,4 40,4
5 450 3x6 18 7,7 1,6 45,4
8 450 3x3 9 15,9 7,8 20,0
8 450 3x4 12 11,0 10,4 26,6
8 450 2x4 8 18,3 6,9 17,8
8 450 3x5 15 8,9 12,9 32,3
8 450 3x6 18 6,7 14,8 37,7
8 450 4x3 12 12,7 9,6 12,7
10 450 3x6 18 6,6 21,5 36,0
10 450 3x5 15 9,2 17,6 31,1
10 450 3x4 12 11,7 14,3 24,0
10 450 2x5 10 19,0 10,1 16,7
10 550 3x3 9 15,0 12,3 25,0

Figura 40 - Exemplo de constelação simulada, com 10º de inclinação a 450 km de altitude.

Os resultados expressos na Tabela 42 indicam que das configurações estudadas apenas

aquelas com 8° e 10° de inclinação, altitude de 450 km e configurações 3 x 5 e 3 x 6 atendem
aos parâmetros comparados. Contudo isto não descarta a possibilidade de, ao longo do projeto,
os requisitos dos stakeholders sofrerem alterações que motivem a revisão de alguns dos
parâmetros utilizados. Por exemplo, na ocorrência de uma restrição orçamentária que limite o
projeto ao lançamento inicial de apenas 12 satélites, os stakeholders podem aceitar um tempo
de revisita superior a 11 minutos, de modo que a solução com 8° de inclinação, 450 km de
 140

altitude e configuração 3 x 4 passaria a atender aos novos requisitos. Caso estudos posteriores
mostrem a viabilidade da constelação a altitudes maiores que 450 km, espera-se também o
aumento de cobertura para o mesmo número de satélites, de modo que as opções com menos
satélites poderiam ser consideradas.
A variedade de soluções estudadas permite ainda estimar o nível mínimo de serviço em
caso de perda ou falha de algum dos satélites da constelação, destacando-se que as soluções
com número maior de satélites por plano apresentam maior resiliência nestes casos. Por
exemplo, no caso de uma constelação 3 x 4 perder um satélite, ainda assim é possível ajustar
sua configuração de modo que ela continue oferecendo serviços com tempo de revisita e
coberturas melhores que uma constelação 3 x 3. Para isto destaca-se novamente a importância
de os satélites disporem de sistema propulsivo, para poderem se redistribuir no plano orbital em
caso de necessidade. Os valores iniciais estudados para constelações e altitudes permitem
oferecer uma referência de nível de desempenho entregue aos stakeholders. Deste modo, após
apresentados estes resultados às partes interessada no projeto, é de se esperar que os
stakeholders, com incremento de conhecimento acerca do serviço que se pode obter das
diferentes configurações e suas limitações, redefinam seu desempenho pretendido. Assim, a
realização de ciclos iterativos com os envolvidos discutindo as questões relativas a órbitas pode
contribuir para um projeto que melhor atenda aos usuários da constelação.
Ainda, o relativamente baixo custo de construção de cada pequeno satélite permite que
posteriormente, com aditivo no orçamento, sejam construídos satélites adicionais para
composição de constelação, o que apresenta como vantagem, além do aumento da cobertura,
incremento em confiabilidade devido a efeitos de redundância e menor perda de eficácia, em
caso de falha de um dos sistemas (FORTESCUE; SWINERD; STARK, 2011).
Uma vez definidas as alternativas iniciais de constelações e altitudes, procedeu-se ao
estudo do modo de descarte dos satélites e seu tempo em órbita. Devido a questões relativas aos
elevados volume, massa e custo do sistema propulsivo necessário para transferir um pequeno
satélite para uma órbita de descarte, a solução adotada para este projeto foi a de reentrada na
atmosfera, que é a solução mais usual para missões abaixo de 1400 km de altitude (WERTZ;
EVERETT; PUSCHELL, 2011). O tipo de reentrada escolhido foi o decaimento descontrolado
dos satélites pelo arrasto atmosférico, dispensando assim propulsão para controle da reentrada
ou sistemas de recuperação.
Para realizar o estudo do tempo de reentrada dos satélites utilizou-se o Debris
Assessment Software (DAS), da NASA. Esta escolha é motivada pelo estudo de Santos (2018),
 141

que concluiu que embora outros software, como o AGI STK, o Basic Propagator of the Semi-
major axis Decay rate (BPSD) e o Satellite Aeroassisted Maneuver Simulator (SAMS) também
permitam cálculos de decaimento, o DAS apresenta resultados com menor erro.
Três parâmetros foram variados para se realizar um estudo inicial e se identificar quais
conceitos atendem ao tempo mínimo de missão por satélite de 6 anos estabelecido para o ciclo
de reposição no PESE (MINISTÉRIO DA DEFESA, 2018) e ao requisito de reentrada em 25
anos pós-missão, bem como quais conceitos demandam mecanismos para acelerar a reentrada
após o fim de sua operação. Os parâmetros variados foram altitude, massa e a área do satélite
perpendicular ao vetor velocidade (área de arrasto).
Para a altitude, utilizaram-se os valores de 450, 550, 600, 650, 700, 750 e 800 km, por
estarem compreendidos no intervalo em que costumam operar sistemas similares. Isto porque,
conforme exposto anteriormente, no limite inferior desta faixa (450 km) a cobertura oferecida
pelos transmissores embarcados é menor, dada a maior proximidade do solo, e o tempo de
reentrada dos sistemas é reduzido, o que pode limitar a vida útil (especialmente no caso de
satélites de menor massa), embora o custo de lançamento e a potência necessária para
comunicação a altitudes mais baixas também
A massa e área de arrasto estão relacionadas ao tipo de satélite. Identificaram-se quatro
configurações de satélites para servir de referência aos estudos:
• CubeSat 3U;
• CubeSat 6U (2x3U);
• CubeSat 12U;
• CubeSat 27U.
A configuração 3U foi selecionada para estudo com base nos resultados do
benchmarking, enquanto as demais foram escolhidas com o intuito de explorar conceitos que
possam oferecer diferentes níveis de desempenho para o EB. Isto porque nos satélites maiores
(6U, 12U e 27U) pode-se embarcar uma maior variedade de cargas úteis, além de controles de
atitude mais robustos e sistemas propulsivos para manutenção de órbita (necessários para se
manter o posicionamento dos satélites em constelações mais numerosas). Como as
configurações são apenas referências para massa e dimensões, e a estrutura interna dos satélites
não é levada em consideração no estudo de decaimento, os valores encontrados são válidos para
pequenos satélites de dimensões similares, ainda que não baseados na plataforma CubeSat.
Satélites com massas maiores tendem a demandar maior tempo para reentrar na
atmosfera. Para o CubeSat 3U foram simuladas massas de 5 e 6 kg, correspondentes aos valores
 142

encontrados no benchmarking. Para o CubeSat 6U as massas utilizadas foram 9 e 12 kg. O

CubeSat 12U foi simulado com massas de 16, 20 e 24 kg, e o CubeSat 27U simulado com
massas de 36, 45, 54 kg. Estes valores de massa estão são baseados nos limites apresentados
por Hevner et al. (2011) para pequenos satélites.
O terceiro parâmetro, a área de arrasto, está relacionado às dimensões, à atitude do
satélite e a seus dispositivos de abertura. Foram selecionadas as seguintes áreas de arrasto:
• 0,02 m2, correspondente às faces 2U de um CubeSat 6U;
• 0,03 m2, correspondente às faces 3U do CubeSat 6U ou às faces 3U do CubeSat
3U;
• 0,04 m2, correspondente às faces 4U do CubeSat 12U;
• 0,06 m2, correspondente às faces 6U dos CubeSats 6U e 12U;
• 0,09 m2, correspondente às faces 9U do CubeSat 27U;
Para cada configuração foram calculadas as relações de área de arrasto dividida pela
massa, utilizadas como dado de entrada no software DAS. Para estas simulações foi utilizado o
modelo se fluxo solar versão f10.7, de 26 de setembro de 2018, atualizado a partir do próprio
desenvolvedor do DAS. A órbita utilizada foi circular, com inclinações de 0°, 5° e 10°, ascensão
reta do nodo ascendente e argumento do perigeu de 0º, para fins de referência. O início da
simulação foi definido como sendo o segundo semestre de 2024, compatível com a estimativa
de entrada em operação do sistema de comunicações de banda estreita previsto no PESE.
Os resultados de tempo de vida em órbita em função da altitude obtidos nas simulações
para inclinação 0º são apresentados na Tabela 43 (a alteração do valor da inclinação para 5º e
10º produziu mudanças inferiores a 0,5% nos resultados, que foram consideradas desprezíveis
para este estudo, de modo que seus resultados não são apresentados neste trabalho). Os casos
que atenderam aos requisitos de tempo de vida (mínimo de 6 anos) e reentrada (estabelecido
como 6 anos de operação mais 25 anos de pós-missão, totalizando um máximo de 31 anos) são
destacados em verde, e os que não atenderam são destacados em vermelho. Como observou-se
que a partir de 650 km todos os satélites excediam ao limite de 31 anos, para apresentar os
resultados de forma mais enxuta são omitidas as colunas para 700, 750 e 800 km na Tabela 43.
 143

Tabela 43 – Tempos de decaimento para diferentes altitudes órbita para inclinação de 0º.

Área de Área de
Tipo de Massa Tempo de vida em função da altitude (anos)
arrasto arrasto/massa
satélite (kg)
(m²) (m²/kg) 450 km 500 km 550 km 600 km 650 km
0,03 5,00 0,00600 1,96 7,95 11,43 24,84 51,66
3U
0,03 6,00 0,00500 2,65 8,55 14,66 30,80 61,87
0,02 9,00 0,00222 8,30 15,08 31,73 65,37 >100
0,02 12,00 0,00167 9,45 20,13 42,14 86,87 >100
0,03 9,00 0,00333 6,57 10,20 21,24 43,66 90,23
6U
0,03 12,00 0,00250 7,86 12,30 29,81 60,85 >100
0,06 9,00 0,00667 1,68 7,60 10,71 21,91 44,31
0,06 12,00 0,00500 2,65 8,55 14,66 30,80 61,87
0,04 16,00 0,00250 7,86 12,30 29,81 60,85 >100
0,04 20,00 0,00200 8,70 18,17 34,26 73,94 >100
0,04 24,00 0,00167 9,45 20,13 42,14 86,87 >100
12U
0,06 16,00 0,00375 5,35 9,65 20,03 40,93 81,82
0,06 20,00 0,00300 7,14 10,77 22,79 50,99 99,81
0,06 24,00 0,00250 7,86 12,30 29,81 60,85 >100
0,09 36,00 0,00250 7,86 12,30 29,81 60,85 >100
27U 0,09 45,00 0,00200 8,70 18,17 34,26 73,94 >100
0,09 54,00 0,00167 9,45 20,13 42,14 86,87 >100

Verificou-se que à altitude de 450 km as configurações 3U simuladas não atendiam aos

requisitos de tempo mínimo em órbita, as configurações 6U atendiam aos requisitos somente
nos casos em que as faces 2U ou 3U são expostas ao arrasto, a configuração 12U não atendia
ao tempo mínimo para o caso de maior área de arrasto e menor massa simulado, mas atendia
para os demais casos, e a configuração 27U atendia aos requisitos para qualquer das áreas de
arrasto simuladas. A 500 km de altitude todas as configurações atendiam aos requisitos. A
maioria das configurações atendiam aos requisitos para 550 km. Para a altitude de 600 km
apenas os CubeSats 3U com área de arrasto de 0,03 m2 e 6U na condição em que apresenta área
de arrasto de 0,06 m2 cumpriam os requisitos. Para as altitudes a partir de 650 todas as
configurações excederam o tempo limite de reentrada.
Para viabilizar a utilização de constelações das altitudes maiores simuladas, que
oferecem maior cobertura em relação às altitudes menores, buscou-se opções para acelerar a
reentrada dos satélites. Dentre estas opções, a considerada mais viável para o projeto foi a
utilização de dispositivos passivos de incremento de arrasto, como os apresentados por Yost
(2018).
A utilização de dispositivos passivos, por um lado, apresenta as desvantagens de
redução do volume disponível para cargas úteis, aumento de custo dos satélites e aumento de
 144

risco de falha durante a operação (devido à possibilidade de acionamento indesejado, que

degradaria a órbita do satélite). Como vantagem, contudo, estes dispositivos uma vez abertos
tornam desnecessário o controle ativo de atitude do satélite para o decaimento. O satélite
tenderá naturalmente a manter-se na atitude de maior arrasto e mais rápida reentrada. A não
necessidade de controle favorece ao cumprimento de outros requisitos ligados ao controle de
detritos espaciais previstos no Handbook for limiting orbital debris (NASA, 2008), como a
passivação (descarregamento de toda energia armazenada e interrupção da geração de energia).
Assim, foram simuladas as áreas totais de arrasto que permitissem a reentrada em até
25 anos (pós-missão, portanto iniciando os cálculos no segundo semestre de 2030, para os
satélites que iniciem a operação no segundo semestre de 2024) aos satélites de diferentes massas
a partir de 600 km. Estas áreas totais de arrasto são a soma das áreas de arrasto dos satélites e
dos dispositivos passivos de incremento de arrasto, uma vez abertos. Desconsiderou-se o
decaimento ocorrido durante os 6 anos de operação, de modo que foram obtidos valores mais
conservativos. A Tabela 44 apresenta os resultados para esta simulação.
A partir da Tabela 44 e tendo-se definidas a altitude a atitude de voo dos satélites
(orientação dos satélites em relação a seu vetor velocidade), pode-se dimensionar o dispositivo
de incremento de arrasto necessário para se cumprir os requisitos de tempo em órbita.

Tabela 44 – Áreas de arrasto para obter tempos de decaimento em 25 anos.

Tempo de decaimento a uma dada altitude

23,56 anos a 600 km 23,90 anos a 650 km 24,81 anos a 700 km 24,99 anos a 750 km 24,89 anos a 800 km
Massa Área de Área de Área de Área de Área de
(kg) Área de Área de Área de Área de Área de
arrasto/ arrasto/ arrasto/ arrasto/ arrasto/
arrasto arrasto arrasto arrasto arrasto
massa massa massa massa massa
(m²) (m²) (m²) (m²) (m²)
(m²/kg) (m²/kg) (m²/kg) (m²/kg) (m²/kg)
5,00 0,03 0,06 0,11 0,21 0,38
6,00 0,04 0,07 0,13 0,25 0,45
9,00 0,05 0,11 0,20 0,37 0,68
12,00 0,07 0,14 0,26 0,49 0,90
16,00 0,10 0,19 0,35 0,66 1,20
0,006 0,012 0,022 0,041 0,075
20,00 0,12 0,24 0,44 0,82 1,50
24,00 0,14 0,29 0,53 0,98 1,80
36,00 0,22 0,43 0,79 1,48 2,70
45,00 0,27 0,54 0,99 1,85 3,38
54,00 0,32 0,65 1,19 2,21 4,05

Os estudos de órbitas e constelações foram apresentados aos stakeholders, que iniciaram

suas próprias análises internas dos resultados para se decidir por algum dos conceitos
apresentados (e, portanto, realizar a seleção de conceito, no que se refere a órbitas e
 145

constelações) ou solicitar estudos adicionais. A solicitação de estudos adicionais, por meio de

um processo iterativo típico de engenharia de sistemas, pode ocorrer, conforme tratado
anteriormente, devido ao aumento de conhecimento dos stakeholders da potencialidade e
limitações dos sistemas. Ressalta-se que, por vezes, pode ser a primeira vez que um demandante
se envolve no desenvolvimento de um tipo de sistema (no caso, o EB envolvido no
desenvolvimento de pequenos satélites de baixa órbita), de modo que durante o projeto a
organização amadurece seus conceitos e expectativas acerca do sistema, o que pode resultar em
algumas alterações nos requisitos de desempenho do mesmo.

4.6.2 Atividade 6.2: Estudo de desempenho

Inicialmente, a partir das informações acerca das funções, arquitetura física e dos
conceitos de órbitas e configurações de constelação, a equipe identificou as funções e
subfunções-chave que deveriam ter seus parâmetros dimensionados. Estas funções e
subfunções selecionadas foram: manter atitude, comunicar, gerar energia e armazenar
energia.
Como para o projeto de pequenos satélites é possível realizar o relacionamento direto
entre algumas funções e elementos físicos (subsistemas e componentes) (MENDES, 2018),
optou-se por trabalhar diretamente com os elementos físicos associados às funções. Desta
forma, identificou-se que os subsistemas que deveriam ser dimensionados (subsistemas mais
impactantes para o projeto) eram o subsistema de determinação e controle de atitude (ADCS,
relacionado à subfunção “manter atitude”), o subsistema de comunicação (carga útil,
relacionado à função “comunicar”) e o subsistema de potência e energia (EPS, relacionado às
funções “gerar energia” e “armazenar energia”).
A equipe, então, identificou e calculou os parâmetros relacionados ao desempenho de
cada um dos três subsistemas selecionados. Uma vez calculados, estes parâmetros serviram de
base para a determinação dos requisitos de desempenho dos diferentes subsistemas. Embora no
estudo de órbitas e constelações tenha se priorizado a altitude de 450 km, o estudo de
subsistemas foi realizado para altitudes de 450 até 800 km, com o intuito de permitir uma
comparação do impacto da altitude no dimensionamento dos subsistemas.
Com relação ao ADCS, para verificar a viabilidade técnica em se cumprir os requisitos
de missão, foi adotado o processo de cálculo apresentado por Wertz, Everett e Puschell (2011)
e Santos e Albuquerque (2018), baseado nos agentes perturbadores, propriedades geométricas
 146

e de massa dos satélites e modos de controle de atitude, que permite identificar os requisitos de
desempenho para o ADCS, isto é, o tipo de apontamento, a acurácia de determinação e controle
de atitude e o tempo para executar manobra de reorientação. Como os atuadores em geral são
mais críticos que os sensores para o ADCS, este estudo não tratou dos sensores. Os requisitos
de desempenho a se atingir constam da Tabela 45.

Tabela 45 - Requisitos de desempenho do satélite (sistema).

Requisitos de desempenho do satélite

Tipo de apontamento: Terrestre
Acurácia de determinação e controle: ≤ 1° (em modo nominal)
Manobra de slew (reorientação): 30° em 30 minutos

Para se atingir estes requisitos, a equipe escolheu a estabilização em 3 eixos como a

solução mais adequada. Foram calculados então o torque e o momento a ser armazenado pelas
rodas de reação e o dipolo do magneto torqueador para as diversas configurações de satélites
estudadas nas diferentes (3U, 6U, 12U e 27U). As margens aplicadas foram de 20% para os
torques relativos a reorientação, gradiente gravitacional, radiação solar, arrasto atmosférico e
amortecimento do momento inicial e de 50% para a rejeição a perturbações. Foram variadas as
contribuições do magneto torqueador e das rodas de reação para compensar a velocidade
angular inicial de 2° por segundo, de modo que foi realizado um processo iterativo simulando
diversos cenários. Como resultado deste processo, a equipe identificou os valores críticos de
torque e momento (Tabela 46), que representam as condições de maior exigência de
desempenho para o ADCS.

Tabela 46 – Requisitos de torque e momento a serem atingidos pelo ADCS (subsistema).

Requisitos de desempenho do ADCS

Torque das rodas de reação: 0,90 ∙ 10-5 N∙m
Momento armazenado pelas rodas de reação: 0,008 N∙m∙s
Dipolo do magneto torqueador: 0,28 A∙m2

Por meio de uma pesquisa de mercado a equipe verificou que existem componentes
COTS com dimensões e massa compatíveis com nanossatélites (inclusive 3U) e capazes de
atender aos requisitos apresentados na Tabela 46, como rodas de reação COTS capazes de gerar
torque superior a 100∙10-5 N∙m e momento de 0,01 N∙m∙s e magneto torqueadores que geram
 147

um dipolo maior que 0,31 A∙m2. Se optou por não tratar das questões relativas à dessaturação
das rodas de reação relativas às órbitas de baixa inclinação neste ciclo do estudo, pois este
problema não foi considerado crítico neste momento visto existirem soluções adequadas em
uso por satélites similares. Desta forma, para esta fase de projeto, o estudo do ADCS mostrou
a viabilidade dos satélites em relação ao controle de atitude.
Para dimensionar a potência demandada pelo subsistema de comunicação para
transmissão a diferentes altitudes, a equipe de projeto empregou a planilha
SMAD_Design_Worksheet_Ver_6_1_-_Participant_1_, que é um complemento do livro Space
Mission Engineering: The New SMAD (WERTZ; EVERETT; PUSCHELL, 2011), e contém as
principais fórmulas do livro implementadas, sendo comumente utilizada na fase de estudo
conceitual de sistemas. Para todas as simulações foi considerado o erro de apontamento de 1º
para os satélites e probabilidade de erro de bit (BER) de 10-6.
Foram calculadas as potências necessárias para transmissão entre os satélites e o solo.
Os valores utilizados foram 10º para o ângulo de elevação, atenuação de 3 dB devido a
condições climáticas, ganho das antenas de 15 dB para os equipamentos de comunicações em
solo e diâmetro equivalente das antenas dos satélites de 30 cm. As faixas de frequência
estabelecidas no PESE para a constelação de satélites de comunicações de banda estreita são de
291 a 318 MHz para uplink em UHF, e de 243 a 270 MHz para downlink em VHF
(MINISTÉRIO DA DEFESA, 2018, p. 57). Foram utilizados nos cálculos os limites superiores
das frequências de uplink e downlink estabelecidas no PESE com taxa de transmissão de 56
kbps. Para fins de comparação, foram calculadas também as potências necessárias para
transmissão a uma taxa de 100 Kbps utilizando banda S, com frequência de 2,2 GHz. Os
resultados são apresentados na Tabela 47, e correspondem a valores de potência suficientes para
atingir uma margem de energia do bit dividida pela densidade espectral do ruído de ao menos
3,00 dB.
 148

Tabela 47 – Potência demandada para transmissão a diferentes atitudes.

Sentido de Frequência/ Taxa de Altitude Potência Margem

transmissão banda transmissão (km) (W) (dB)
450 2,25 3,06
500 2,60 3,02
550 3,00 3,04
Uplink
318 MHz 600 3,40 3,05
Origem: Solo 56 Kbps
(UHF) 650 3,80 3,03
Destino: Satélite
700 4,25 3,07
750 4,65 3,03
800 5,10 3,04
450 1,06 3,03
500 1,25 3,08
550 1,42 3,03
Downlink
270 MHz 600 1,60 3,01
Origem: Satélite 56 Kbps
(VHF) 650 1,80 3,03
Destino: Solo
700 2,00 3,03
750 2,20 3,02
800 2,40 3,01
450 4,00 3,02
500 4,70 3,06
550 5,40 3,07
Uplink
2,2 GHz 600 6,10 3,05
Origem: Solo 100 Kbps
(Banda S) 650 6,80 3,03
Destino: Satélite
700 7,50 3,00
750 8,25 3,00
800 9,10 3,03
450 1,90 3,03
500 2,20 3,00
550 2,55 3,05
Downlink
2,2 GHz 600 2,90 3,06
Origem: Satélite 100 Kbps
(Banda S) 650 3,20 3,00
Destino: Solo
700 3,60 3,05
750 3,95 3,04
800 4,30 3,01

A equipe então avaliou os equipamentos de comunicação utilizados pelas tropas em solo

para o uplink, e encontrou modelos com potência de transmissão que varia de 1 W a 20W, de
acordo com a faixa de frequência. Verificou-se que utilizando a banda UHF com taxa de
transmissão de 56 Kbps, conforme previsto no PESE, a maioria dos rádios já em uso pelo
Exército Brasileiro pode ser compatível com sistemas de comunicação satelitais a até 750 km.
Já para a banda S e taxa de transmissão de 100 Kbps, a maioria dos rádios é compatível com
satélites a até 500 km. Cabe ressaltar que, conforme já tratado anteriormente, demandam-se
estudos adicionais a respeito da influência das características de vegetação e climáticas
particulares da região amazônica nas comunicações com os satélites, que pode reduzir as
 149

altitudes limites encontradas, o que justificou a opção conservativa pela órbita a 450 km para a
constelação.
Para o downlink, verificou-se que existe viabilidade técnica de para se construir os
sistemas de comunicação dos satélites tanto para a banda VHF à taxa de transmissão de 56 Kbps
quanto para a banda S à taxa de transmissão de 100 Kbps.
Ainda, uma vez identificadas as demandas energéticas necessárias para atender à
missão, a equipe de projeto concluiu que, dentre as configurações de satélite estudadas, as
configurações 3U e 6U eram suficientes para atingir aos níveis de desempenho exigidos, com
as configurações 12U e 27U sendo consideradas ineficientes economicamente, devido a seu
superdimensionamento para o projeto. A equipe considerou ainda que a configuração 6U tem
vantagem sobre a 3U pois, embora de maior custo, é mais flexível a alterações nas necessidades
dos usuários, como a possível inclusão de uma carga útil de imagem nos satélites ou aumento
nas taxas de transmissão. Desta forma, mudanças ocorridas antes do lançamento dos primeiros
satélites ou mesmo aquelas que requeiram alterações nos satélites lançados para repor a
constelação podem ser mais facilmente incorporadas ao projeto, reduzindo seu custo total.
Para os cálculos relativos ao subsistema de potência e energia (EPS), a equipe de
projeto empregou o processo proposto por Larson e Wertz (1999), utilizando inicialmente as
informações de mais alto nível obtidas nas etapas anteriores do trabalho para dimensionar as
necessidades de geração de energia. As dimensões dos satélites impactam nas cargas úteis e
demais subsistemas que os mesmos podem levar embarcados, de modo que, em geral, satélites
de maior massa apresentam maiores demandas energéticas. Para este trabalho, o cálculo para o
EPS restringiu-se à configuração 6U, por ser esta a configuração julgada pela equipe a mais
adequada ao projeto. Utilizando dados de missões similares e realizando a conversão de
potência segundo a equação (1):

𝑃𝑟𝑒𝑓 ⋅ 𝑚𝑡𝑜𝑡𝑎𝑙
𝑃𝑡𝑜𝑡𝑎𝑙 = (1)
𝑚𝑟𝑒𝑓

Em que 𝑃𝑡𝑜𝑡𝑎𝑙 é a potência total a ser demandada do EPS, 𝑃𝑟𝑒𝑓 é a potência demandada
pelo satélite de referência, 𝑚𝑡𝑜𝑡𝑎𝑙 é a massa do satélite sendo projetado e 𝑚𝑟𝑒𝑓 é a massa do
satélite referência. O valor encontrado para 𝑃𝑡𝑜𝑡𝑎𝑙 foi de 11 W.
Empregou-se novamente a planilha do Space Mission Engineering: The New SMAD
(WERTZ; EVERETT; PUSCHELL, 2011). Como dados de entrada, utilizou-se tempo de vida
 150

de 6 anos para os satélites, com degradação dos painéis solares de 0,5% ao ano e degradação
inerente (dependente da construção dos painéis) de 77%, considerando painéis multijunção com
eficiência teórica de 28% (η). O fluxo solar (Φ) utilizado nos cálculos foi de 1367 W/m2, de
modo que a potência por área de painel solar (𝑃0 ) é:

𝑃0 = η ⋅ Φ = 0,28 ⋅ 1367 = 382,76W/m2 (2)

A equação de energia do satélite indica que:

𝐸𝑃𝑆 = 𝐸𝑛 + 𝐸𝑑 (3)

Em que 𝐸𝑃𝑆 é a energia gerada pelos painéis solares, 𝐸𝑛 é a energia consumida durante
a noite e 𝐸𝑑 é a energia consumida durante o dia. Assim, como a energia é o produto de potência
pelo tempo, e a energia é gerada pelos painéis solares exclusivamente durante o período de
iluminação solar, tem-se que:

𝑃𝑛 𝑇𝑛 𝑃𝑑
𝑃𝑃𝑆 = + (4)
𝑋𝑃𝑆2𝐵 𝑋𝐵2𝐿 𝑇𝑑 𝑋𝑃𝑆2𝐿

Sendo 𝑃𝑃𝑆 é a potência gerada pelos painéis solares, 𝑇𝑑 o tempo de incidência solar
(dia), 𝑃𝑛 a potência consumida durante o eclipse (noite), 𝑇𝑛 o tempo de eclipse e 𝑃𝑑 a potência
demandada durante o dia, 𝑋𝑃𝑆2𝐵 a eficiência de transferência dos painéis solares para as
baterias, 𝑋𝐵2𝐿 a eficiência de transferência das baterias para cargas noturnas e 𝑋𝑃𝑆2𝐿 a eficiência
de transferência dos painéis solares para cargas diurnas.
As potências no início (𝑃𝐵𝑂𝐿 ) e fim da operação (𝑃𝐸𝑂𝐿 ) são dadas por:

𝑃𝐵𝑂𝐿 = 𝑃0 𝐼𝑑 𝑐𝑜𝑠(θ) (5)

𝑃𝐸𝑂𝐿 = 𝑃𝐵𝑂𝐿 (1 − 𝐷 )𝐿 (6)

Em que 𝐼𝑑 é a degradação inerente (com valor de 0,77), 𝐿 é o tempo de vida em anos e

𝐷 a degradação anual (0,5% ao ano). Assim, a área dos painéis solares (𝐴𝑃𝑆 ) necessária para a
missão é dada por:

𝑃𝑃𝑆
𝐴𝑃𝑆 = (7)
𝑃𝐸𝑂𝐿
 151

Os resultados são apresentados na Tabela 48.

Tabela 48 – Dimensionamento do EPS (estabelece requisitos para o EPS).

Período Tempo máximo Potência solar Área de painéis

Altitude
orbital de eclipse necessária solares
(km)
(min) (min) (W) (m2)
450 93,59 35,92 25,2 0,10
500 94,62 35,75 24,9 0,09
550 95,65 35,61 24,6 0,09
600 96,69 35,49 24,4 0,09
650 97,73 35,38 24,2 0,09
700 98,77 35,29 23,9 0,09
750 99,82 35,20 23,7 0,09
800 100,87 35,13 23,5 0,09

Com relação às baterias recarregáveis, que fornecem energia aos satélites durante picos
de energia e eclipses, para um período de operação de 6 anos, identificou-se que o número de
ciclos seria superior a 31000 (trinta e um mil). A partir deste resultado, e consultando curvas de
ciclo de vida em função da profundidade de descarga de bateria (PD) presentes na literatura
(WERTZ; EVERETT; PUSCHELL, 2011), verificou-se que, para se poder dispor de uma
margem de PD de 41,5%, seria necessário utilizar baterias de Níquel-Hidrogênio (Ni-H2).
Contudo não se encontrou no mercado bateria COTS de Ni-H2 para CubeSats. Deste modo,
confrontando-se os dados presentes nas curvas de ciclo de vida em função de PD com as
informações referentes a baterias, decidiu-se por empregar baterias de Lítio Íon Polímero (Li-
Po) por elas serem, dentre as baterias COTS com alta variedade e disponibilidade para
CubeSats, aquelas com maior vida útil. Para se atingir a durabilidade pelo número de ciclos
necessários, a estratégia adotada foi aumentar a capacidade das baterias, de modo a reduzir sua
PD.
Assim, utilizando baterias de Lítio Íon Polímero (Li-Po), com densidade energética de
100 Wh/kg (valor conservativo, baseado na densidade energética das baterias existentes no
mercado para CubeSats (YOST, 2019; PAVLOVSKIS; BRYSON; KANE, 2017)) e limitando
a profundidade de descarga (PD) a 10%, foram encontrados os valores apresentados na Tabela
49 para os valores de altitude estudados, considerando uma tensão de barramento de 14 V.
 152

Tabela 49 – Quantidade de ciclos, profundidade de descarga e massa das baterias, para 6 anos
de operação de um satélite.

Taxa de Massa das

Altitude
Ciclos descarga baterias
(km)
(Ah) (kg)
450 33721 5,2 0,732
500 33354 5,2 0,728
550 32994 5,2 0,725
600 32640 5,2 0,723
650 32292 5,1 0,721
700 31950 5,1 0,719
750 31615 5,1 0,717
800 31285 5,1 0,716

Com base nos cálculos realizados, a equipe concluiu que as necessidades energéticas
podem ser atendidas por satélites 6U com painéis solares de abertura, e a massa das baterias é
compatível com esta configuração de satélite, de modo que a missão é também tecnicamente
viável do ponto de vista energético para qualquer das altitudes estudadas (entre 450 e 800 km).
Ao final desta atividade, os resultados foram discutidos em uma reunião com a equipe de
desenvolvimento, de modo que se tratou do dimensionamento dos principais subsistemas,
permitindo a determinação de quais modelos de componentes e fabricantes eram capazes de
atender ao projeto da constelação. Os fabricantes, modelos e custos de componentes não são
apresentados neste trabalho, dado seu caráter acadêmico.
Desta forma, a equipe definiu os níveis de desempenho associados aos principais
subsistemas para as diferentes altitudes estudadas para a missão, encerrando a etapa de
exploração de conceitos com a conclusão de que existem componentes COTS no mercado que
permitem cumprir os requisitos de desempenho. Os resultados obtidos neste estudo foram
reunidos na Tabela 50, em que constam os conceitos identificados por meio do presente
trabalho. Optou-se por não apresentar a descrição de fabricantes ou modelos de componentes.
Uma observação importante a ser feita é que, dado o elevado tempo de vida útil dos
satélites (6 anos), pode ser necessário empregar componentes de elevada resistência à radiação,
cuja venda sofre restrições. A nacionalização deste tipo de componente representa também um
desafio técnico adicional, dificultando a obtenção de autonomia para construção dos satélites.
Deste modo, o requisito de tempo de vida útil de 6 anos pode representar um risco tecnológico
identificado neste ciclo do estudo conceitual para o projeto.
 153

Tabela 50 – Conceitos identificados para o sistema.

Inclinação 8° a 10°
Órbita
Altitude 450 km*
Configuração da constelação
(número de planos orbitais x número 3 x 5 ou 3 x 6
de satélites por plano orbital)
Estrutura dos satélites 6U
Dispositivo de incremento de arrasto Não**
Atitude 2U ou 3U
(face na direção do vetor velocidade)
6 kg (para face 2U na direção do vetor
Massa mínima*** velocidade) ou 9 kg (para face 3U na
direção do vetor velocidade)
Torque: 0,90 ∙ 10-5 N∙m
Rodas de reação
ADCS Momento armazenado: 0,008 N∙m∙s
Magneto torqueador Dipolo: 0,28 A∙m²
Uplink (UHF): 291 a 318 MHz
Frequência
Subsistema de Downlink (VHF): 243 a 270 MHz
comunicação Taxa de transmissão 56 kbps
Potência para transmissão 2,5 W****
Potência total 11 W
Área de painéis solares 0,10 m²
EPS Massa de baterias 0,732 kg
Taxa de descarga das baterias 5,2 Ah
Tipo de baterias Lítio Íon Polímero (Li-Po)
* Altitudes limitadas pela capacidade de comunicação através da vegetação amazônica. Estudos
adicionais sobre a interferência ambiental nas comunicações podem provar a viabilidade de extensão da
altitude.
** Entre 450 e 550 km a maioria das atitudes de satélites 6U não demanda dispositivos passivos para
aumento de arrasto.
*** A massa mínima visa a garantir que os satélites permaneçam mais de 6 anos em órbita para a
altitude de 450 km. Ocorrendo aumento de altitude, pode-se reduzir a massa mínima.
**** Optou-se por utilizar um valor conservativo para os equipamentos em solo, dado que se verificou
que existe margem no EPS para fornecer tal potência de transmissão e com maior potência existe
flexibilidade para os satélites operarem a altitudes maiores.

Os stakeholders podem, assim, selecionar alguma das combinações da Tabela 50 como

conceito a passar para o estágio de desenvolvimento de engenharia, ou solicitar ciclos de estudo
adicionais. Observa-se que os resultados obtidos possuem interdependência. Por exemplo, a
atitude com a face 6U voltada na direção do vetor velocidade foi descartada por não atender ao
requisito de tempo mínimo em órbita a 450 km de altitude. Já no caso de operação da
constelação a altitudes maiores, a face 6U pode estar voltada na direção do vetor velocidade.
Com o intuito de discutir os aspectos mais importantes percebidos durante a aplicação
do método proposto neste trabalho, na próxima seção será apresentada a análise dos resultados
obtidos.
 154

4.7 Análise dos resultados

Durante a aplicação do método proposto neste trabalho, foram notados pontos fortes,
bem como limitações do mesmo. A seguir, serão analisadas estas questões para cada uma das
etapas propostas, sem, contudo, pretender realizar o processo de validação do método.
Foi importante desenvolver um método próprio para este trabalho, considerando as
especificidades do sistema de interesse (constelação de pequenos satélites, com prazos e
orçamentos reduzidos), da organização desenvolvedora (possui uma estrutura ágil e reduzida,
de modo a trabalhar melhor com processos enxutos) e da situação de contratação (o projeto
ainda não foi contratado, portanto não estavam disponíveis recursos específicos para o seu
desenvolvimento).
Neste trabalho, os princípios do Manifesto Ágil não foram empregados em sua
totalidade. Tendo em vista questões relacionadas à garantia para os envolvidos, foram adotadas
medidas burocráticas em alguns momentos (ex. registro das alterações na documentação de
requisitos dos stakeholders para evitar contestações futuras).
A utilização dos diagramas de MBSE contribuiu para melhorar a visualização dos dados
de engenharia (tanto para a equipe, quanto para os demais stakeholders) e ressaltar a
importância da rastreabilidade dos requisitos e da consistência da documentação (isto é, ao se
alterar determinado requisito ou função, todos os requisitos ou funções derivados devem ser
revistos).
Observou-se que a característica não sequencial do método permite uma maior interação
entre os stakeholders e melhor utilização do tempo. No Capítulo 4 (Caso de estudo), foram
apresentados apenas os resultados finais das iterações realizadas, porém, para se atingir estes
resultados, foram realizados diversos ciclos.
Buscou-se também estruturar o método de forma clara e didática, para que pudesse ser
usado e adaptado para projeto conceitual de outros tipos de sistemas complexos. As Etapas de
1 a 5 são gerais e podem ser aplicada para diversos sistemas, enquanto a Etapa 6 é específica
para satélites, agregando elementos de engenharia aeroespacial. Desta forma, este método visa
a fornecer subsídios para a seleção ou definição do conceito de sistema a ser desenvolvido, de
modo que apresenta algumas atividades além do que se costuma realizar em estudos conceituais
(como a identificação de alguns componentes e seus requisitos, caso a equipe julgue necessário
para antever riscos tecnológicos, por exemplo) ao mesmo tempo em que deixa de contemplar
 155

outras atividades que alguns autores realizam na fase conceitual (como a identificação dos
riscos).
Neste trabalho, a aplicação do método não considerou uma importante limitação técnica:
a dificuldade de transmissão através da selva amazônica, haja vista suas características de
vegetação e climáticas que podem interferir nas comunicações com os satélites. Tais
particularidades podem influenciar, inclusive, em parte dos resultados obtidos neste estudo.
Por questões de proteção à informação, neste trabalho foram apresentados apenas
extratos dos resultados obtidos, de modo a exemplificar a aplicação do método e permitir a
compreensão da arquitetura operacional da constelação de satélites.

4.7.1 Etapa 1: Iniciação

A primeira etapa, que compreendeu o início do projeto, cumpriu seus objetivos de

definir o escopo do projeto, em comum acordo com representantes do EB, e de selecionar e
mobilizar a equipe de desenvolvimento.
Contudo, até o presente momento, não houve assinatura de contrato entre a organização
desenvolvedora e o patrocinador, o que impediu a alocação de recursos financeiros para o
projeto. Este problema pôde ser mitigado, pois, conforme discutido na Seção 2.1 da revisão da
literatura deste trabalho, as fases iniciais do desenvolvimento demandam um menor orçamento.
Assim, o CEI decidiu direcionar parte do tempo de seus recursos humanos e sua estrutura física
para continuar o projeto, na expectativa de acordo futuro entre as partes, após serem
apresentados os conceitos e potencialidades do projeto.
Desta forma, o estudo conceitual e as reuniões com representantes do EB continuaram
ocorrendo.

4.7.2 Etapa 2: Benchmarking

Por meio do Benchmarking foi possível comparar sistemas semelhantes e selecionar

referências para o projeto, tendo sido atingidos os objetivos desta etapa.
Com relação ao método, um ponto positivo a se destacar foi a estruturação didática das
atividades propostas nesta etapa, com a definição de critérios de seleção e levantamento das
características técnicas a serem pesquisadas inicialmente e, em um segundo momento, a
pesquisa de benchmarking propriamente dita. Embora diversos autores que tratam de
 156

desenvolvimento de sistemas complexos enfatizarem a importância de se realizar o

benchmarking, suas obras em geral não apresentam um processo descrevendo como executar
esta tarefa.
No entanto, a escassez de dados técnicos acerca dos sistemas buscados dificultou as
pesquisas. Embora as bases de dados acerca de satélites ofereçam diversas informações, como
local e data de lançamento, finalidade do sistema, país desenvolvedor, custo, dimensões, entre
outros, informações acerca dos componentes são mais raras, tendo que ser, muitas vezes,
presumidas, com base na experiência e conhecimento da equipe a respeito de sistemas similares.
Ainda, informações referentes à implementação de software, em geral, não são divulgadas. Esta
carência de informações é proposital por parte de seus desenvolvedores, e visa a manter a
vantagem competitiva, no caso dos sistemas civis, e a segurança, para os sistemas militares.

4.7.3 Etapa 3: Objetivos e metas

A terceira etapa cumpriu o que se propunha, identificar as expectativas dos stakeholders

com relação ao projeto, os objetivos e metas e os requisitos a serem alcançados pelo sistema.
Devido ao fato de o projeto ainda não ter sido contratado, o Exército Brasileiro foi o
único dentre os stakeholders selecionados a participar das entrevistas, além da equipe
desenvolvedora do CEI. O fato de os demais stakeholders externos não terem participado fez
com que os resultados tenham sido centrados na visão do EB e do CEI, o que pode ter
ocasionado que aspectos importantes para o projeto tenham sido desconsiderados.
Com relação às ferramentas, a equipe de engenharia de sistemas não dispunha software
de SysML que garantisse a segurança dos dados, de modo que o controle de consistência e
rastreabilidade relativos aos objetivos e metas e requisitos do sistema foi implementado sem
auxílio computacional, exigindo maior esforço e tempo por parte da equipe. Assim, embora
tenha sido proposto no método utilizar a abordagem de MBSE e se reconheçam suas vantagens
para o controle de versões, o software de MBSE não foi aplicado.
Tais limitações, no entanto, não comprometeram a qualidade dos resultados obtidos,
uma vez que o conceito de MBSE foi empregado por meio da criação dos modelos, servindo
para direcionar o restante do estudo realizado, ainda que sem os benefícios da automatização
de atividades que os programas SysML fornecem.
 157

4.7.4 Etapa 4: Conceito de operações

Na quarta etapa, foram definidos os parâmetros chave de desempenho, as fronteiras do

sistema, os diagramas de contexto “As-is” e “To-be”, bem como as sequências de operações
para os cenários, além de terem sido determinadas as funções dos nós operacionais e o diagrama
NxN dos elementos do sistema de sistemas, de modo que o objetivo proposto para esta etapa
foi atingido.
A utilização do software AGI STK permitiu também a identificação das condições
ambientais a que os satélites estarão expostos durante sua operação, contribuindo para a captura
de requisitos do sistema.
Dado que não havia a contratação do projeto e diversos stakeholders selecionados não
haviam sido entrevistados, decidiu-se que não seria produtivo para o projeto, naquele momento,
estabelecer a sequência de operações para os cenários ao longo de todo o ciclo de vida do projeto
(incluindo a montagem, integração e testes, o armazenamento, o transporte para o lançamento
e o lançamento). Assim, a equipe desenvolvedora focou no sequenciamento da fase de
operações, com o intuito de entender o relacionamento do sistema com as demais entidades
durante a fase de principal interesse para o Exército Brasileiro.
Desta forma, os resultados produzidos nesta etapa foram considerados satisfatórios,
permitindo compreender como a constelação de pequenos satélites de comunicações a ser
desenvolvida irá operar no contexto dos demais sistemas, atualmente existentes ou em
implantação.
A abordagem adotada, que embora mantivesse claras as limitações de objetivo da
constelação (especialmente com relação à exclusão da responsabilidade contínua sobre a
transmissão de dados oriundos de radares e demais sensores), ainda assim previa a possibilidade
de transmissão de seus dados, em regime degradado, em casos emergenciais, por contribuir para
a resiliência do sistema de sistemas (SoS) de comunicações na região, que inclui os satélites
geossíncronos. Esta resiliência é desejável em sistemas militares, dada a possibilidade de ações
adversas por parte de possíveis oponentes.
Ainda, o estudo de um conceito de operações visou a contribuir para sanar parte da
lacuna identificada nos programas de Defesa que estão sendo elaborados, oferecendo uma
proposta de “Descrição de Operação do Sistema de Comunicações de Banda Estreita” previsto
no Apêndice III ao Anexo B do PESE (MINISTÉRIO DA DEFESA, 2018).
 158

4.7.5 Etapa 5: Arquiteturas funcional e física

A quinta etapa do método propôs a identificação da arquitetura funcional do sistema de

interesse e o sequenciamento destas funções.
Os elementos de MBSE, na forma de diagramas de sequência, contribuíram para a
melhor compreensão da forma como os satélites irão operar e para a melhor visualização dos
dados de engenharia. No entanto, não houve melhora na automatização da manutenção de
consistência dos dados de engenharia por meio de rastreabilidade, tendo em vista que o software
de SysML não estava disponível.
O mapeamento funcional permitiu identificar os elementos físicos relacionados às
funções e subfunções do sistema. A experiência da equipe do CEI no desenvolvimento de
pequenos satélites facilitou a definição da arquitetura física e o sequenciamento operacional dos
subsistemas.
Como a equipe de engenharia de sistemas não dispunha software de SysML que
garantisse a segurança dos dados, os requisitos foram gerados por meio de outros programas,
exigindo o controle manual da rastreabilidade. Embora tenha demandado maior esforço e tempo
da equipe, com revisões mais pormenorizadas, como o desenvolvimento de pequenos satélites
envolve processos mais simplificados e uma quantidade menor de requisitos em relação ao
necessário para satélites maiores, foi possível realizar esta tarefa com sucesso, mantendo a
consistência dos documentos.
O requisito de vida útil de 6 (seis) anos para os satélites, presente no PESE, mostrou-se
bastante restritivo, exigindo a opção por componentes com elevada resistência à radiação, que
sofrem controle de venda (podendo prejudicar a construção dos satélites). A dificuldade em se
produzir componentes com este elevado tempo de vida útil pode também comprometer o
objetivo de autonomia para implementação das soluções satelitais, dificultando atingir-se a
meta de obter um índice de nacionalização de 70% até 2025. Deste modo, recomenda-se um
estudo a respeito da revisão deste requisito, levando-o para valores como os encontrados para
sistemas similares na Etapa 2 (benchmarking), isto é, de 2 (dois) a 3 (três) anos de vida útil por
satélite.
 159

4.7.6 Etapa 6: Exploração de conceitos

Durante a etapa de exploração de conceitos, a equipe de projeto identificou

configurações iniciais de órbitas e constelações, associando-as a parâmetros de desempenho
que permitiram apresentar as características do serviço de comunicações oferecido para cada
configuração. Estas órbitas deverão ser refinadas por meio de um processo iterativo em que os
stakeholders passarão gradativamente a conhecer melhor os níveis de desempenho possíveis e
as limitações para cada configuração, de modo a poder decidir de modo mais consciente e
assertivo. Pode ocorrer, por exemplo, a expansão da solicitação da área de cobertura.
Foram calculados ainda os valores associados ao desempenho que deverão ser atingidos
pelos principais subsistemas dos satélites para cada uma das altitudes estudadas, de modo que
se realizou a exploração de conceitos pretendida. Embora no capítulo referente ao método deste
trabalho recomende-se a identificação dos componentes físicos e seus custos, optou-se por não
mostrar estes resultados no trabalho, tendo em vista o caráter comercial destas informações.
Com relação às baterias, para se obter o número de ciclos de carga e descarga necessário
à missão com as baterias disponíveis para CubeSats de Li-Po, foi necessário reduzir a
profundidade de descarga para 10%, demandando emprego de baterias de maior capacidade.
Possíveis reduções no tempo de vida exigido de cada satélite permitiriam maiores
profundidades de descarga, viabilizando a redução das baterias.
O próximo capítulo apresenta as conclusões e propostas de trabalhos futuros, a partir do
desenvolvimento do presente trabalho.
 160

5 Conclusões

Este capítulo apresenta as conclusões do presente trabalho, em que se estruturou um

método para o estudo conceitual de pequenos satélites e o mesmo foi aplicado ao
desenvolvimento de conceitos para uma constelação de pequenos satélites não-geossíncronos
que visa prover comunicações de banda estreita a forças táticas móveis do Exército Brasileiro
na região amazônica.
O método apresenta, além das etapas tradicionais de desenvolvimento de sistemas,
conceitos e orientações para o estudo de órbitas, constelações e subsistemas de pequenos
satélites, sendo ao mesmo tempo enxuto, iterativo e didático, explicitando as atividades,
recursos, entradas e saídas de cada etapa, de modo a facilitar que seja utilizado ou adaptado
para projeto de outros tipos de sistemas complexos.
Verificou-se que este trabalho foi efetivo ao:
• Estruturar um método híbrido, combinando as abordagens de engenharia de
sistemas baseada em modelos (Atividades 3.2, 3.3, 5.1, 5.2 e 5.3 do método) e
em documentação (demais atividades apresentadas no método);
• Identificar as necessidades e expectativas dos stakeholders em relação à
constelação de pequenos satélites, por meio de reuniões entre as partes
interessadas e membros da equipe de projeto;
• Realizar a análise operacional para os satélites de comunicações, com a
definição do sistema de interesse e seu relacionamento com os demais sistemas,
usuários e elementos adversos;
• Realizar a análise funcional dos satélites e seus subsistemas, empregando
diagramas para auxiliar na visualização dos dados de engenharia;
• Explorar conceitos, com estudo de constelações, órbitas, e dos principais
subsistemas dos satélites, utilizando software para simulação de missões
espaciais.
O estabelecimento do conceito de operações deve ser destacado pela sua importância na
definição das premissas de utilização do sistema, que repercutem nas funções dos satélites e na
configuração da constelação. Outro fator a ser destacado foi a utilização de elementos de MBSE
em algumas atividades do método, o que contribuiu para deixar mais intuitiva a visualização
das funções interagindo com o ambiente, usuários e elementos adversos, e do relacionamento
 161

entre os requisitos de diferentes níveis. Isso permitiu um melhor entendimento do projeto por
parte dos membros da equipe de desenvolvimento, favorecendo a execução de suas atividades.
Com relação à aplicação, um ponto forte observado em todas as etapas foi o alinhamento
dos estudos realizados com o documento da “Necessidade Operacional de Comunicações
Militares por Satélite” (COMISSÃO DE COORDENAÇÃO E IMPLANTAÇÃO DE
SISTEMAS ESPACIAIS, 2017) e o PESE (MINISTÉRIO DA DEFESA, 2018), de modo a
buscar o atendimento às necessidade e requisitos já identificados pelas Forças Armadas, por
meio de estudos anteriores.
Quanto às dificuldades encontradas, verificou-se que a não disponibilidade de um
software de MBSE fez com que os modelos fossem criados manualmente, impossibilitando a
automatização da rastreabilidade do documento de requisitos e dificultando a manutenção de
sua consistência. Dado o volume de requisitos de um pequeno satélite ser reduzido em relação
a satélites de maior porte, a falta do software, embora tenha exigido trabalho adicional, não
comprometeu as atividades. Contudo, em projetos de maior complexidade, a não
disponibilidade de recursos computacionais pode implicar em atrasos no cronograma e
dificuldade em gerenciar os requisitos.
As contribuições deste trabalho ficam restritas às delimitações expressas na Seção 1.2,
de modo que o planejamento, gerenciamento, revisões de projeto, aquisições, contrato,
propriedade intelectual e análise de riscos, não foram contempladas no escopo deste trabalho,
que também não pretendeu realizar a validação do método. Observou-se que estas delimitações
foram adequadas para se atingir os objetivos propostos no presente trabalho. Contudo os
aspectos citados acima como externos ao escopo do trabalho deveriam ser considerados na
situação de um projeto real.
Dadas as limitações apresentadas e o fato de o presente trabalho não ter a pretensão de
realizar o desenvolvimento completo da constelação, propõem-se novos trabalhos para
contribuir com o projeto do sistema:
• Estudo contemplando o gerenciamento da missão (análise de risco, gestão de
pessoal, etc.);
• Realização do estudo conceitual apresentado neste trabalho utilizando
exclusivamente engenharia de sistemas baseada em documentação, com o
intuito de permitir a comparação com o modelo híbrido proposto;
• Realização de estudos adicionais buscando conceitos alternativos ao proposto,
considerando a mudança de requisitos e premissas frente aos cenários de risco,
 162

para posterior análise de suas vantagens e desvantagens, de modo a se fornecer

maiores subsídios para a seleção de conceito;
• Estruturação de um método orientado a pequenos satélites e adaptado à
organização desenvolvedora para a realização do estágio que Kossiakoff e Sweet
(2003) nomeiam desenvolvimento de engenharia e aplicação do mesmo para dar
continuidade a este trabalho;
• Realização de estudo focado nos equipamentos de comunicação em solo visando
a propor conceitos com potencial de se comunicar com a constelação de satélites
na selva amazônica, tornando inclusive as órbitas mais próximas de 800 km mais
atrativas, dada a maior área de cobertura que possibilitam em relação às altitudes
menores;
• Realização de estudo acerca de outras possíveis frequências para operação do
sistema, como as de banda Ka;
• Realização de estudo adicional relativo ao tempo de vida útil de cada satélite,
analisando as vantagens e desvantagens de uma possível redução do tempo de 6
(seis) anos previsto no PESE;
• Expandir o estudo para toda a Área de Interesse da Defesa, o que implica em
novos cálculos de órbita e novas configurações para a constelação.
Há também possibilidades de estudos para a utilização de pequenos satélites não-
geossíncronos em outras aplicações, como:
• Monitorar o posicionamento de localizadores transportados por pessoas que
realizem expedições em regiões remotas, de modo a facilitar a localização e
resgate de aventureiros em caso de necessidade;
• Monitorar a localização de animais, de modo a facilitar a realização de estudos
ambientais e de populações da fauna.
 163

Referências

ABDU, M. A. The Scintillation Prediction Observations Research Task (SPORT). São José
dos Campos: Fundação de Amparo à Pesquisa do Estado de São Paulo, 2016.

AGILE. Manifesto para desenvolvimento Ágil de software. Disponível em:

<http://agilemanifesto.org/iso/ptbr/manifesto.html>. Acesso em: 21 jul. 2018.

ALECRIM, E. Robotic Falconry, um drone que “caça” drones disparando uma rede.
Disponível em: <https://tecnoblog.net/190467/robotic-falconry-antidrone/>. Acesso em: 29 jul.
2018.

AMARO, L. P. Proposta de um modelo para a pré-aquisição de produtos de defesa em

organizações das Forças Armadas nos primeiros níveis de maturidade. 175f. Dissertação
(Mestrado em Engenharia Aeronáutica e Mecânica) - Instituto Tecnológico de Aeronáutica,
São José dos Campos, 2012.

ARAUJO, L. C. G. Organização, sistemas e métodos e as tecnologias de gestão

organizacional. São Paulo: Atlas, 2001.

ASUNDI, S. A.; FITZ-COY, N. G. Cubesat mission design based on a systems engineering

approach. IEEE, 2013.

ASUNDI, S. B. A. CubeSat system design based on methodologies adopted for developing

wireless robotic platform. [s.l.] University of Florida, 2011.

BACK, N. et al. Projeto integrado de produtos: planejamento, concepção e modelagem.

Barueri: Manole, 2008.

BELL, T. E.; THAYER, T. A. Software requirements: are they really a problem? TRW Defense
and Space Systems Group, 1976.

BLANCHARD, B. S. Logistics engineering and management. 6. ed. New Jersey: Pearson,

2003.

BONINO, E. Novo satélite de comunicações. Disponível em:

<http://revistapesquisa.fapesp.br/2017/06/20/novo-satelite-de-comunicacoes/>. Acesso em: 29
jul. 2018.

BOUGHER, M. Details emerge on Kepler Communications and Telesat Small Satellite

Constellations. Disponível em:
<http://spaceq.ca/details_emerge_on_kepler_communications_and_telesat_small_satellite_co
nstellations/>. Acesso em: 3 mar. 2018.
 164

BRASIL. Decreto no. 6.703, de 18 de dezembro de 2008. Aprova a Estratégia Nacional de

Defesa, e dá outras providências. 2008.

CABRAL, R. A. DA V. Programa Estratégico De Sistemas Espaciais: avanço tecnológico

beneficia as Forças Armadas e a sociedade civil. Revista da Associação dos Diplomados da
Escola Superior de Guerra, p. 2, jan. 2015.

CARSON, R. S. Implementing structured requirements to improve requirements quality.

INCOSE International Symposium. Anais...Seattle: INCOSE, 2015.

CASALE, D. E.; LOURES DA COSTA, L. E. V. SATCOMTAT - Satélite de Comunicações

Táticas. São José dos Campos, 2018.

CHANG, Y.-K.; HWANG, K.-L.; KANG, S.-J. SEDT (Systems Engineering Design Tool)
development and its application to Small Satellite conceptual design. Acta Astronautica, v.
61, p. 676–690, 2007.

COMISSÃO DE COORDENAÇÃO E IMPLANTAÇÃO DE SISTEMAS ESPACIAIS.

Necessidade Operacional de Comunicações Militares por Satélite. Brasília, 2017.

CRISP, N. H.; SMITH, K.; HOLLINGSWORTH, P. Launch and deployment of distributed

small satellite systems. Acta Astronautica, v. 114, p. 65–78, 2015.

DEFESANET. O promissor mercado de soluções anti-drones. Disponível em:

<http://www.defesanet.com.br/vant/noticia/28450/O-promissor-mercado-de-solucoes-anti-
drones/>. Acesso em: 29 jul. 2018.

DELLIGATTI, L. SysML distilled: a brief guide to the Systems Modeling Language. Nova
Jersey: Pearson Education, 2014.

DEPARTMENT OF DEFENSE SYSTEMS MANAGEMENT COLLEGE. Systems

engineering fundamentals. Fort Belvoir: Defense Acquisition University, 2001.

DOUGLASS, B. P. Agile systems engineering. Waltham: Morgan Kaufmann, 2016.

DUCOMMUN INCORPORATED. US Army Space and Missile Defense Command

Operational Nanosatellite Effect (SMDC-ONE). Disponível em:
<https://www.ducommun.com/pdf/SMDC-ONEMediaDeck.pdf>. Acesso em: 3 mar. 2018.

ECSS. Space project management - project planning and implementation: Rev 1.

Noordwijk, 2009a.

ECSS. ECSS-E-ST-10C - Space engineering: system engineering general requirements.

Noordwijk, 2009b.

EICKHOFF, J.; FLEMMING, J.; FOURNIE, J.-M. Model-based development and

verification. DASIA 2002. Anais...Dublin: ESA, 2002.
 165

EKPO, S. C.; GEORGE, D. A system engineering analysis of highly adaptive Small Satellites.
IEEE SYSTEMS JOURNAL, v. 7, n. 4, p. 642–648, 2013.

ESTEFAN, J. A. Survey of Model-Based Systems Engineering (MBSE) metodologies.

Pasadena. INCOSE MBSE Initiative, 2008.

FOLHA DE SÃO PAULO. China faz teste com míssil que destrói satélites e desagrada
EUA. Disponível em: <https://www1.folha.uol.com.br/folha/mundo/ult94u103904.shtml>.
Acesso em: 29 jul. 2018.

FORTESCUE, P.; SWINERD, G.; STARK, J. Spacecraft systems engineering. 4a ed.

Chennai: Wiley, 2011.

FRIEDENTHAL, S.; MOORE, A.; STEINER, R. A practical guide to SysML - the Systems
Modeling Language. Waltham: Morgan Kaufmann, 2015.

FRIEDMAN, A. L.; MILES, S. Stakeholders: theory and practice. Nova York: Oxford
University, 2006.

FULINDI, J. Auxílio computacional a um processo de engenharia simultânea de sistemas

espaciais. Instituto Nacional de Pesquisas Espaciais, São José dos Campos, 2011.

FULINDI, J. Integration of a systemic hazard analysis into a systems engineering

approach. Instituto Tecnológico de Aeronáutica, São José dos Campos, 2017.

G1 GLOBO. Trump diz que EUA terão uma “força espacial” como novo braço do
Pentágono. Disponível em: <https://g1.globo.com/mundo/noticia/trump-diz-que-eua-terao-
uma-forca-espacial-como-novo-braco-do-pentagono.ghtml>. Acesso em: 29 jul. 2018.

GNIPPER, P. Índia destrói satélite em órbita e se autointitula "uma potência espacial".

Disponível em " <https://canaltech.com.br/espaco/india-destroi-satelite-em-orbita-e-se-
autointitula-uma-potencia-espacial-135895/>. Acesso em: 14 mai. 2019.

GOODWIN, K. Design for the digital age - how to create human-centered products and
services. Indianapolis: Wiley, 2009.

GRIFFIN, M. D. The art and science of systems engineering, 2009.

GUNTER’S SPACE. Star One C1, C2. Disponível em:

<http://space.skyrocket.de/doc_sdat/starone-c.htm>. Acesso em: 29 jul. 2018a.

GUNTER’S SPACE. SMDC-ONE. Disponível em:

<http://space.skyrocket.de/doc_sdat/smdc-one.htm>. Acesso em: 3 mar. 2018b.

GUNTER’S SPACE. SNaP. Disponível em: <http://space.skyrocket.de/doc_sdat/snap.htm>.

Acesso em: 3 mar. 2018c.

GUNTER’S SPACE. CubeSat. Disponível em:

<http://space.skyrocket.de/doc_sat/cubesat.htm>. Acesso em: 3 mar. 2018d.
 166

HALL, A. D. A methodology for systems engineering. Nova York: D. Van Nostrand, 1962.

HEVNER, R. et al. An advanced standard for Cubesats. Disponível em:

<https://digitalcommons.usu.edu/cgi/viewcontent.cgi?article=1111&context=smallsat>.
Acesso em: 4 out. 2018.

HIRATA, G. Polícia francesa está treinando quatro águias-douradas para interceptar

objetos voadores em pleno voo. Disponível em: <https://exame.abril.com.br/mundo/franca-
esta-usando-aguias-para-destruir-drones-terroristas/>. Acesso em: 29 set. 2018.

INCOSE. Systems engineering handbook: a “what to” guide for all SE practitioners.
Seatle: International Council on Systems Engineering (INCOSE), 2004.

INCOSE. Systems engineering vision 2025. Disponível em:

<https://www.incose.org/docs/default-source/aboutse/se-vision-
2025.pdf?sfvrsn=4&sfvrsn=4>. Acesso em: 21 fev. 2018.

INCOSE. Systems engineering handbook: a guide for systems life cycle processes and
Activitiea. 4. ed. Hoboken: John Wiley & Sons, 2015.

INCOSE. About systems engineering. Disponível em: < https://www.incose.org/about-

systems-engineering/about-systems-engineering>. Acesso em 30 Dez. 2018.

INPE. LSIS - Laboratório de Engenharia Simultânea de Sistemas. Disponível em:

<http://www.lit.inpe.br/pt-br/lsis_laboratorio_de_engenharia_simultanea_de_sistemas>.
Acesso em: 17 fev. 2019.

KAFRUNI, S. Com custo de R$ 2,8 bilhões, satélite de defesa não atrai interessados.
Disponível em:
<https://www.correiobraziliense.com.br/app/noticia/economia/2017/11/12/internas_economia,
640439/com-custo-de-r-2-8-bilhoes-satelite-de-defesa-nao-atrai-interessados.shtml>. Acesso
em: 29 jul. 2018.

KOSSIAKOFF, A.; SWEET, W. N. Systems engineering principles and practice. Hoboken:

Wiley, 2003.

KOSSIAKOFF, A; SWEET, W. N.; SEYMOUR, S. J.; BIEMER, S. M. Systems engineering

principles and practice. 2. ed. Hoboken: Wiley, 2011. 559 p.

LARSON, W. et al. Applied space systems engineering. Hoboken: McGraw-Hill, 2009.

LARSON, W. J.; WERTZ, J. R. Space Mission Analysis and Design (SMAD). 3. ed.
Dordrecht: Kluwer Academic, 1999.

LEMOS JUNIOR, A. DA S. Implantação do Programa Estratégico dos Sistemas Espaciais

Brasileiro: uma proposta de investimento contínuo. Escola Superior De Guerra (ESG), Rio
de Janeiro, 2014.
 167

LOUREIRO, G. A systems engineering and concurrent engineering framework for the

integrated development of complex products. Loughborough University, 1999.

LOUREIRO, G.; PANADÉS, W. F.; SILVA, A. Lessons learned in 20 years of application of

Systems Concurrent Engineering to space products. Acta Astronautica, v. 151, p. 44–52, 2018.

LOURES DA COSTA, L. E. V.; FULINDI, J. B. Notas de aula de TE-265. Instituto

Tecnológico de Aeronáutica, São José dos Campos, 2018.

LOURES DA COSTA, L. E. V.; SHIBUYA, L. H.; ALBUQUERQUE, P. K. DE. Estudo

preliminar de um satélite de pequeno porte para comunicação na região de fronteira norte
e noroeste do Brasil. Instituto Tecnológico de Aeronáutica, São José dos Campos, 2017.

MENDES, W. S. Um método de modelagem descritiva de sistemas de engenharia para

possibilitar a geração automática de requisitos textuais aplicado a um satélite. Instituto
Nacional de Pesquisas Espaciais (INPE), São José dos Campos, 2018.

MINISTÉRIO DA DEFESA. Programa Estratégico de Sistemas Espaciais (PESE), 2018.

MOURA, I. V. P. An approach to evaluate robotic radio base station technology for

exploration and coverage in wireless communication networks. Instituto Tecnológico de
Aeronáutica, São José dos Campos, 2018.

NANOSAT. Nanosatellites Database. Disponível em: <http://www.nanosats.eu/>. Acesso

em: 3 mar. 2018.

NASA. NASA systems engineering handbook. Washington, DC, 2016.

NASA. Handbook for limiting orbital debris. Washington, DC, 2008.

NASA. NASA systems engineering handbook: Rev. 2. Washington, DC, 2007.

NASA. The Systems Engineering (SE) process. Disponível em:

<https://www.nasa.gov/pdf/598887main_Auburn_PowerPoints_SE.pdf>. Acesso em: 21 fev.
2018a.

NASA. Orbital testing begins for advanced small spacecraft communications. Disponível
em: <https://phys.org/news/2018-03-orbital-advanced-small-spacecraft.html>. Acesso em: 2
jul. 2018b.

OLIVEIRA, G. C. T. G. DE. EUA participam como observadores de exercício militar na

Amazônia. Disponível em: <http://agenciabrasil.ebc.com.br/geral/noticia/2017-11/eua-
participam-como-observadores-de-exercicio-militar-na-amazonia>. Acesso em: 29 jul. 2018.

PAVLOVSKIS, E.; BRYSON, D.; KANE, A. User manual: 3rd generation CubeSat battery
family, Clyde Space, Glasgow, 2017.

PEREIRA, A. H. R. General diz que Brasil pode perder parte de Roraima, segundo jornal.
Disponível em: <http://g1.globo.com/Noticias/Politica/0,,MUL395429-5601,00-
 168

GENERAL+DIZ+QUE+BRASIL+PODE+PERDER+PARTE+DE+RORAIMA+SEGUNDO
+JORNAL.html>. Acesso em: 29 jul. 2018.

PINTO, G. A. A organização do trabalho no século XX: Taylorismo, Fordismo e

Toyotismo. 1. ed. São Paulo: Expressão Popular, 2007.

PINTO, T. R. Proposta de um método para avaliação de custos e valores do produto para

stakeholders ao longo do seu ciclo de vida - aplicado nas etapas iniciais do
desenvolvimento do produto. Instituto Tecnológico de Aeronáutica, São José dos Campos
2014.
PMI. A guide to the Project Management Body of Knowledge (PMBoK_. In: A Guide to the
Project Management Body of Knowledge (PMBOK Guide). 2013.

POGHOSYAN, A.; GOLKAR, A. CubeSat evolution: analyzing CubeSat capabilities for

conducting science missions. Progress in Aerospace Sciences, v. 88, p. 59–83, 2017.

RAMOS, A. L.; FERREIRA, J. V.; BARCELÓ, J. Model-Based Systems Engineering: an

emerging approach for modern systems. IEEE TRANSACTIONS ON SYSTEMS, MAN,
AND CYBERNETICS, v. 42, p. 101–111, 2012.

RAUPP, M. A. “Temos de melhorar a comunicação na Amazônia”. Disponível em:

<https://www.estadao.com.br/noticias/geral,temos-de-melhorar-a-comunicacao-na-amazonia-
imp-,828242>. Acesso em: 29 jul. 2018.

ROZENFELD, H. et al. Gestão de desenvolvimento de produtos: uma referência para a

melhoria de processos. 1. ed. São Paulo: Saraiva, 2006.

SÁ, C. M. DE. O Brasil conquistando o Espaço. Revista da Associação de Diplomados da

Escola Superior de Guerra, p. 6–9, jan. 2015.

SAGE, A. P.; CUPPAN, C. D. On the systems engineering and management of systems of

systems and federations of systems. Information Knowledge Systems Management, v. 2, n.
4, p. 325–345, 2001.

SAGE, A. P.; ROUSE, W. B. Handbook of systems engineering and management. 2. ed.

Hoboken: John Wiley & Sons, 2009.

SANDAU, R.; BRIESS, K.; D’ERRICO, M. Small satellites for global coverage: Potential and
limits. ISPRS Journal of Photogrammetry and Remote Sensing, v. 65, p. 492–504, 2010.

SANTOS, W. G. DOS. De-orbiting analysis of satellites in Low Earth Orbits. São José dos
Campos, 2018.

SANTOS, W. G. DOS; ALBUQUERQUE, P. K. Notas de Aula de PRJ-73. São José dos

Campos, 2018.

SCHEEREN, I. Comparação entre método centrado em documentos e de engenharia de

sistemas baseada em modelos. Universidade Federal do Rio Grande do Sul, 2013.
 169

SCHMIDT, M. Ground station networks for efficient operation of distributed Small

Satellite systems. [s.l.] Julius-Maximilians-Universität Würzburg, 2011.

SEBOK CONTRIBUTORS. Transitioning systems engineering to a model-based

discipline. Disponível em:
<http://www.sebokwiki.org/w/index.php?title=Transitioning_Systems_Engineering_to_a_Mo
del-based_Discipline&oldid=52541>. Acesso em: 21 fev. 2018.

SELLERS, J. J. Understanding space. Nova York: McGraw-Hill, 2004.

SELVA, D.; KREJCI, D. A survey and assessment of the capabilities of Cubesats for Earth
observation. Acta Astronautica, v. 74, p. 50–68, 2012.

SILLITTO, H.; MARTIN, J.; GRIEGO, R.; MCKINNEY, D.; ARNOLD, E.; GODFREY, P.;
DORI, D.; KROB, D.; JACKSON, S. Envisioning systems engineering as a
transdisciplinary venture. 28th annaul INCOSE international simposyum, Washington. 2018.

SKY AND SPACE GLOBAL. 3-Diamonds. Disponível em:

<https://www.skyandspace.global/operations-overview/>. Acesso em: 3 mar. 2018.

SPENDOLINI, M. J. Benchmarking. Bogotá: Norma, 1994.

TERRA. China e Rússia criticam EUA após derrubada de satélite. Disponível em:
<http://noticias.terra.com.br/mundo/noticias/0,,OI2498233-EI294,00-
China+e+Russia+criticam+EUA+apos+derrubada+de+satelite.html>. Acesso em: 29 jul. 2018.

TRISTANCHO, J. Implementation of a Femto-Satellite and a Mini-Launcher. Universitat

Politecnica de Catalunya, 2010.

VASCONCELOS FILHO, S. L. DE. Sistema Integrado de Monitoramento de Fronteiras

(SISFRON): Uma Contribuição para a Segurança Nacional. Escola Superior de Guerra,
2014.

VITAL, J. V.; KENJI, P. Análise de viabilidade de empreendimento de grande porte do

Programa Estratégico de Sistemas EspaciaisComissão de Coordenação do Programa
Estratégico do Satélite Espacial, 2012.

WALTRICK, R. Empresa lança “bazuca anti-drones” que captura aeronaves; veja vídeo.
Disponível em: <https://www.gazetadopovo.com.br/economia/inteligencia-artificial/empresa-
lanca-bazuca-anti-drones-que-captura-aeronaves-veja-video-d1wy1nh0qhzyukocfeumiq6n7>.
Acesso em: 29 jul. 2018.

WERTZ, J. R.; EVERETT, D. F.; PUSCHELL, J. J. Space mission engineering: the new
SMAD. Hawthorne: Space Technology, 2011.
WHEELWRIGHT, S. C.; CLARK, K. B. Revolutioning new product development:
quantum leaps in speed, efficiency, and quality. New York: The Free Press, 1992.

WOELLERT, K. et al. Cubesats: cost-effective science and technology platforms for emerging
and developing nations. Advances in Space Research, v. 47, p. 663–684, 2011.
 170

YOST, B. 12. Passive deorbit systems. Disponível em: <https://sst-soa.arc.nasa.gov/12-

passive-deorbit-systems>. Acesso em: 2 out. 2018.

YOST, B. 03. Power. Disponível em: <https://sst-soa.arc.nasa.gov/03-power>. Acesso em: 24

mar. 2019.
 171

FOLHA DE REGISTRO DO DOCUMENTO

1. 2. 3. 4.
CLASSIFICAÇÃO/TIPO DATA REGISTRO N° N° DE PÁGINAS

DM 21 de maio de 2019 DCTA/ITA/DM-030/2019 170

5.
TÍTULO E SUBTÍTULO:

Estudo conceitual de uma constelação de pequenos satélites de comunicações de banda estreita para o Exército
Brasileiro
6.
AUTOR(ES):

Douglas Estevam Casale

7. INSTITUIÇÃO(ÕES)/ÓRGÃO(S) INTERNO(S)/DIVISÃO(ÕES):

Instituto Tecnológico de Aeronáutica – ITA

8.
PALAVRAS-CHAVE SUGERIDAS PELO AUTOR:

1. Microssatélites. 2. Estudo conceitual. 3. Partes interessadas. 4. Telecomunicações. 5. Engenharia de sistemas.

9.PALAVRAS-CHAVE RESULTANTES DE INDEXAÇÃO:

Microssatélites; Sistemas complexos; Partes interessadas; Telecomunicações; Engenharia de sistemas.

10.
APRESENTAÇÃO: X Nacional Internacional

ITA, São José dos Campos. Curso de Mestrado. Programa de Pós-Graduação em Ciências e Tecnologias
Espaciais. Área de Gestão Tecnológica. Orientador: Prof. Dr. Luís Eduardo Vergueiro Loures da Costa;
coorientador: D. Sc. Jonas Bianchini Fulindi. Defesa em 17/05/2019. Publicada em 2019.
11.
RESUMO:

A região amazônica apresenta desafios ao estabelecimento de comunicações militares confiáveis. Meios

convencionais para comunicações a longa distância na selva amazônica dependem da instalação de antenas
repetidoras, o que pode atrasar missões ou comprometer o sigilo das operações. Novas possibilidades de solução
para esta necessidade de comunicação surgiram com a evolução da tecnologia espacial, que levou ao
desenvolvimento de pequenos satélites apresentando ciclo de desenvolvimento mais rápido, menores custos e
capacidade de desempenhar missões antes restritas aos satélites de maior porte. Paralelamente, a engenharia de
sistemas tem evoluído de uma abordagem baseada em documentação para abordagens utilizando também
modelos (MBSE), adaptadas à estrutura de cada organização desenvolvedora e às características do sistema. Neste
contexto, este trabalho objetiva propor um método híbrido para realizar o estudo conceitual de sistemas
complexos e aplicá-lo ao desenvolvimento de uma constelação de pequenos satélites de comunicações de banda
estreita para atender a forças táticas móveis do Exército Brasileiro na região amazônica. Este método é composto
por seis etapas. Na primeira etapa são definidas a necessidade de missão do projeto, seu prazo e orçamento
preliminares. A segunda etapa compreende a pesquisa de benchmarking. Na terceira etapa são levantadas as
expectativas dos stakeholders com relação ao sistema e os objetivos e metas do projeto. A quarta etapa
compreende a definição do conceito de operações. Na quinta etapa são identificadas as arquiteturas funcional e
física do sistema de interesse, e na sexta etapa é realizada a exploração de conceitos. A partir dos resultados
obtidos, pôde-se concluir que o método se mostrou adequado à realização de estudo conceitual de constelações
de pequenos satélites, sendo enxuto, claro, didático e flexível, tendo seus elementos de MBSE contribuído para
deixar a visualização das funções, dos requisitos e suas interações mais intuitiva.

12.
GRAU DE SIGILO:

(X ) OSTENSIVO( ) RESERVADO ( ) SECRETO