INSTITUTO TECNOLÓGICO DE AERONÁUTICA

Douglas Estevam Casale

ANÁLISE FUNCIONAL DE UMA CONSTELAÇÃO

DE PEQUENOS SATÉLITES DE
COMUNICAÇÕES PARA O EXÉRCITO
BRASILEIRO

Trabalho de Graduação
2018

Curso de Engenharia Aeronáutica

 CDU:629.78:62ES

Douglas Estevam Casale

ANÁLISE FUNCIONAL DE UMA

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

Orientador
Prof. Dr-Ing. Luís Eduardo Vergueiro Loures da Costa (ITA)

Coorientador
D. Sc. Jonas Bianchini Fulindi (ITA)

ENGENHARIA AERONÁUTICA

SÃO JOSÉ DOS CAMPOS

INSTITUTO TECNOLÓGICO DE AERONÁUTICA

2018
Dados Internacionais de Catalogação-na-Publicação (CIP)
Divisão de Informação e Documentação
Casale, Douglas
Análise funcional de uma constelação de pequenos satélites de comunicações para o
Exército Brasileiro / Douglas Estevam Casale.
São José dos Campos, 2018.
Número de folhas no formato 108f.

Trabalho de Graduação – Engenharia Aeronáutica – Instituto Tecnológico de Aeronáutica,

2018. Orientador: Prof. Dr-Ing. Luís Eduardo Vergueiro Loures da Costa. Coorientador: Prof. D.
Sc. Jonas Bianchini Fulindi.

1. Microssatélites. 2. Análise funcional. 3. Partes interessadas. 4. Telecomunicações. 5.

Engenharia de sistemas.

REFERÊNCIA BIBLIOGRÁFICA

CASALE, Douglas Estevam. Análise funcional de uma constelação de pequenos

satélites de comunicações para o Exército Brasileiro. 2018. 108f. Trabalho de
Conclusão de Curso. (Graduação em Engenharia Aeronáutica) – Instituto Tecnológico
de Aeronáutica, São José dos Campos.

CESSÃO DE DIREITOS (NEGRITO, TAMANHO 12)

NOME DO AUTOR: Douglas Estevam Casale

TÍTULO DO TRABALHO: Análise funcional de uma constelação de pequenos satélites de
comunicações para o Exército Brasileiro
TIPO DO TRABALHO/ANO: Graduação / 2018

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

deste trabalho de graduaçã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
deste trabalho de graduação pode ser reproduzida sem a autorização do autor.

__________________________________
Douglas Estevam Casale
Praça Marechal Eduardo Gomes, 50, Vila das Acácias
12228-900, São José dos Campos-SP
 v

Dedico este trabalho a meu avô, Antônio Estevam.

 vi

Agradecimentos

Agradeço aos Prof. Loures e Jonas pela orientação, amizade, confiança, conhecimento
transmitido e oportunidades apresentadas ao longo desta jornada.
Aos meus pais, Mário e Virgínia, e meu tio Antônio Roberto, que me propiciaram os
estudos que me possibilitaram ingressar no ITA. A meu avô, Antônio, que despertou em mim
o interesse pelas ciências exatas e pela carreira das Armas. A meus irmãos, Daphnnie,
Dreyphus, Dânae e Dan, pelo companheirismo.
À minha esposa Rafaela, pelo apoio, orientação e suporte. Seu amor faz minha vida
muito mais feliz. Você me mostrou um novo modo de ver o mundo, um mundo muito mais feliz
com seu amor.
Aos amigos Breno, Hélio e Jéssica, integrantes da equipe do projeto apresentado neste
trabalho, pelas relevantes contribuições prestadas e ensinamentos transmitidos.
À Lídia, pelas orientações profissionais, acadêmicas, pessoais e pela lição de liderança
transmitida.
Ao Prof. Christopher, meu companheiro nas atividades de engenharia de requisitos
para o projeto SPORT, pela amizade, orientação e conhecimento transmitido.
Aos demais integrantes do Centro Espacial ITA, Linélcio, Emerson, Vinícius, Prof.
Willer, 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 Maj Paulo César, pelo suporte, orientação e confiança durante o processo seletivo,
que me forneceram as condições para realizar a preparação para esta caminhada.
Ao Ten Cel Diogo e Majores Macedo, Assumpção, Lúcio e Damy, pelas orientações
e apoio.
Ao Exército Brasileiro, que me confiou esta missão, e à Força Aérea Brasileira, pela
acolhida e conhecimentos transmitidos.
 vii

"Nós somos da pátria a guarda”.

(trecho da canção do Exército)
 viii

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, como os pequenos satélites. Paralelamente, a
engenharia de sistemas tem evoluído de uma abordagem baseada em documentação para
abordagens utilizando também modelos, 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 a análise funcional de mísseis e pequenos satélites para missões
diversas, combinando elementos de engenharia de sistemas baseada em documentação e em
modelos, sendo composto por cinco etapas. Na primeira etapa são definidas as necessidades 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 é identificada a arquitetura funcional nível do sistema
de interesse. Este método foi aplicado ao estudo 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. A partir dos
resultados obtidos, pôde-se concluir que o método permite a realização da análise funcional,
tendo sido estabelecidas as funções que os pequenos satélites da constelação devem
desempenhar para atender às demandas dos stakeholders.
 ix

Abstract

The Amazon region presents challenges to establishing 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, such as small satellites. At the same time, systems engineering has evolved
from a documentation-based approach to approaches using also models, tailored 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 perform the functional analysis of missiles and small
satellites for different missions, combining elements of systems engineering based on
documentation and models, being composed of five stages. In the first stage the mission's needs
for the project, its preliminary deadline and budget are defined. The second stage comprises
benchmarking research. In the third stage, the expectations of the stakeholders regarding the
system and the objectives and goals of the project are raised. The fourth stage comprises the
definition of the concept of operations. In the fifth stage is identified the functional level
architecture of the system of interest. This method was applied to the study of a constellation
of small satellites to provide communications to troops on foot of the Brazilian Army in the
Amazon region. From the results obtained, it was possible to conclude that the method allows
the accomplishment of the functional analysis, having been established the functions that the
small satellites of the constellation must carry out to meet the demands of the stakeholders.
 x

Sumário

1 INTRODUÇÃO .............................................................................................................. 12
1.1 Objetivos .................................................................................................................. 16
1.2 Delimitações do trabalho ....................................................................................... 16
1.3 Estrutura do texto ................................................................................................... 17

2 REVISÃO DA LITERATURA ..................................................................................... 18

2.1 Engenharia de sistemas .......................................................................................... 18
2.1.1 Sistema ..................................................................................................................... 18
2.1.2 Definições para engenharia de sistemas ................................................................... 20
2.1.3 Abordagens de engenharia de sistemas .................................................................... 23
2.1.4 Estudo conceitual de sistemas .................................................................................. 30
2.2 Pequenos satélites ................................................................................................... 35
2.3 Posicionamento do trabalho .................................................................................. 36

3 MÉTODO ........................................................................................................................ 39
3.1 Etapa 1: Iniciação ................................................................................................... 42
3.1.1 Atividade 1.1: Alinhamento entre os principais stakeholders .................................. 43
3.1.2 Atividade 1.2: Definição e mobilização da equipe de projeto .................................. 44
3.2 Etapa 2: Benchmarking .......................................................................................... 45
3.2.1 Atividade 2.1: Definição dos critérios de benchmarking ......................................... 46
3.2.2 Atividade 2.2: Pesquisa de benchmarking ................................................................ 47
3.3 Etapa 3: Objetivos e metas .................................................................................... 48
3.3.1 Atividade 3.1: Síntese das expectativas dos stakeholders ........................................ 49
3.3.2 Atividade 3.2: Definição dos objetivos e metas do projeto ...................................... 51
3.4 Etapa 4: Conceito de operações ............................................................................. 51
3.4.1 Atividade 4.1: Determinação dos parâmetros chave de desempenho (KPPs) .......... 53
3.4.2 Atividade 4.2: Desenvolvimento do contexto e arquitetura operacionais ................ 54
3.4.3 Atividade 4.3: Identificação das condições ambientais ............................................ 56
3.5 Etapa 5: Arquitetura funcional ............................................................................. 56
3.5.1 Atividade 5.1: Identificação de funções do sistema ................................................. 57

4 CASO DE ESTUDO ....................................................................................................... 59

4.1 Etapa 1: Iniciação ................................................................................................... 61
 xi

4.1.1 Atividade 1.1: Alinhamento entre os principais stakeholders .................................. 61

4.1.2 Atividade 1.2: Definição e mobilização da equipe de projeto .................................. 64
4.2 Etapa 2: Benchmarking .......................................................................................... 64
4.2.1 Atividade 2.1: Definição dos critérios de seleção .................................................... 65
4.2.2 Atividade 2.2: Pesquisa de benchmarking ................................................................ 68
4.3 Etapa 3: Objetivos e metas .................................................................................... 72
4.3.1 Atividade 3.1: Síntese das expectativas dos stakeholders ........................................ 73
4.3.2 Atividade 3.2: Definição dos objetivos e metas do projeto ...................................... 76
4.4 Etapa 4: Conceito de operações ............................................................................. 80
4.4.1 Atividade 4.1: Determinação dos parâmetros chave de desempenho (KPPs) .......... 81
4.4.2 Atividade 4.2: Identificação do contexto e arquitetura operacionais ....................... 84
4.4.3 Atividade 4.3: Identificação das condições ambientais ............................................ 92
4.5 Etapa 5: Arquitetura funcional ............................................................................. 93
4.5.1 Atividade 5.1: Identificação das funções do sistema ................................................ 94
4.6 Análise dos resultados ............................................................................................ 98
4.6.1 Etapa 1: Iniciação ..................................................................................................... 98
4.6.2 Etapa 2: Benchmarking ............................................................................................. 98
4.6.3 Etapa 3: Objetivos e metas ....................................................................................... 99
4.6.4 Etapa 4: Conceito de operações ................................................................................ 99
4.6.5 Etapa 5: Arquitetura funcional ............................................................................... 100

5 CONCLUSÕES............................................................................................................. 101

REFERÊNCIAS ................................................................................................................... 103

 12

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.
 13

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élite
(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. Como observação, nota-se um possível lapso técnico da autoridade
no texto da norma, ao referir-se a “geoestacionários”, visto que a órbita geoestacionária é um
caso particular de órbita geossíncrona, quando a inclinação é nula. Neste trabalho considera-se
que a intenção da autoridade foi referir-se a “geossíncronos”, que é o conceito mais geral para
este tipo de órbita.
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). Nenhum destes satélites atende às tropas que
 14

realizem deslocamento a pé pela selva amazônica. O equipamento em banda X necessário para

comunicação militar com o SGDC, por exemplo, 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 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.
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 comprometimento de sigilo, 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 satélites geossíncronos, como o SGDC, apresentam ainda elevada vulnerabilidade
estratégica, com países como EUA (TERRA, 2008) e China (FOLHA DE SÃO PAULO, 2007)
já tendo demonstrado capacidade de destruí-los. Adicionalmente, os EUA criaram em 2018
uma Força Espacial em seu Departamento de Defesa (DoD), visando ao controle militar do
espaço (G1 GLOBO, 2018).
Os altos custos de fabricação e lançamento e o longo tempo de desenvolvimento são
ainda outras desvantagens dos satélites geossíncronos. Porém a evolução da tecnologia espacial
tem tornado possível a miniaturização dos outrora grandes e pesados satélites para diversas
aplicações, 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$ 1,5
milhão (GUNTER’S SPACE, 2018c; SKY AND SPACE GLOBAL, [s.d.]).
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. O PESE foi criado em maio de 2012, visando a atender às necessidades
estratégicas das Forças Armadas e mantendo o caráter tanto civil quanto militar dos sistemas
implantados. 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.
 15

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. Isto porque o ciclo de desenvolvimento destes satélites é 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, nota-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.
O sistema pode contribuir ainda para a integração pretendida no SISFRON, fornecendo uma
solução de comunicações que conecte as 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.
Porém, para este trabalho, a questão será tratada com foco no Exército Brasileiro (EB).
Esta escolha se deve ao fato de as tropas a pé 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.
Outros possíveis transbordamentos são a expansão de cobertura para todo o território
nacional e a utilização de uma constelação de pequenos satélites para monitorar o
posicionamento de localizadores transportados por pessoas que realizem expedições em regiões
remotas (facilitando a localização e resgate de aventureiros, por exemplo) ou mesmo
implantados em animais que se deseje monitorar, para fins de estudos de comportamento e
preservação de espécies.
 16

Assim, dadas as dimensões da Amazônia e as dificuldades intrínsecas ao exercício de

Comando e Controle por toda sua extensão, a questão central deste trabalho consiste em
identificar quais são as funções que cada pequeno satélite não-geossíncrono de uma constelação
deve desempenhar para prover comunicações a tropas a pé do Exército Brasileiro atuando na
região amazônica.

1.1 Objetivos

Tendo em vista a contextualização apresentada anteriormente, o objetivo geral deste

trabalho é realizar a análise funcional de uma constelação de pequenos satélites não-
geossíncronos para prover comunicações a tropas a pé do Exército Brasileiro na região
amazônica, a partir da aplicação de um método de engenharia de sistemas híbrido, pautado nas
abordagens baseada em documentação e baseada em modelos.
Para a consecução do objetivo geral, foram identificados os seguintes objetivos
específicos:
 Estruturação de um método baseado em engenharia de sistemas, combinando
elementos das abordagens baseada em documentação e baseada em modelos;
 Identificação das necessidades e expectativas dos stakeholders;
 Análise operacional para os satélites de comunicações, com a finalidade de
identificar o conceito de operações em que a constelação de satélites será
empregada;
 Análise funcional, com o objetivo de definir as funções que devem ser
desempenhadas pelo sistema e seus subsistemas.

1.2 Delimitações do trabalho

O processo de engenharia de sistemas para 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; SWINERD; STARK,
2011; WERTZ, EVERETT E PUSCHELL, 2011). Contudo este trabalho tem foco na fase
inicial do estudo conceitual, abrangendo somente sua análise de necessidades, análise
operacional e análise funcional.
 17

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. 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.
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 sua introdução, problema, objetivos, justificativa e delimitações do
trabalho neste primeiro capítulo, é apresentada uma revisão da literatura, com foco nos
principais temas abordados nos capítulos subsequentes: engenharia de sistemas, tratando de
seus principais conceitos, suas definições, abordagens e foco no estudo conceitual, em que está
inserido este trabalho; pequenos satélites e posicionamento do trabalho.
No capítulo 3 é apresentado 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 cinco etapas:
• Etapa 1: Iniciação;
• Etapa 2: Benchmarking;
• Etapa 3: Objetivos e metas;
• Etapa 4: Conceito de operações;
• Etapa 5: Arquitetura funcional.
O método descrito acima foi aplicado para a realização da análise funcional 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. Seus resultados e discussões são apresentados no capítulo 4.
Por fim, no capítulo 5 constam as conclusões deste trabalho e as propostas para trabalhos
futuros.
 18

2 Revisão da literatura

Este capítulo apresenta a fundamentação teórica para os principais temas deste trabalho:
engenharia de sistemas e pequenos satélites.
A primeira seção apresenta as principais abordagens e conceitos utilizados em
engenharia de sistemas. A segunda seção trata de pequenos satélites. Ao final do capítulo, é
discutido o posicionamento do presente trabalho em relação a outros correlatos.

2.1 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.1.1 Sistema

O INCOSE (2015) usa a terminologia sistema para um conjunto de elementos inter-

relacionados que desempenham uma função útil. 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 1.
 19

Figura 1 – 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, na Figura 2, 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).

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

2015, p. 8)).
 20

Na Figura 2 nota-se também que há vários sistemas representados. 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
sistemas 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 2, 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. Os termos desenvolvimento de
produtos e desenvolvimento de sistemas também são sinônimos.

2.1.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.
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, p. 3), 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
 21

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, 2009) contextualiza a
engenharia de sistemas, apresentando suas interfaces com o gerenciamento, a produção,
operações e logística e garantia de produto (Figura 3). 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;
 Design e configuração, que define as características funcionais e a arquitetura
física do sistema;
 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 3 – Fronteiras da engenharia de sistemas (adaptado de ECSS (2009, p. 18)).

 22

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;
 Grade de Poder/Influência, baseada nos níveis de autoridade e envolvimento;
 Grade de Influência/Impacto, 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 do método 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; ESTEFAN, 2007). Estas entidades realizam revisões períódicas em seus
processos de aquisições (DEPARTMENT OF DEFENSE, 2001; ESTEFAN, 2007). 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 mesmas 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).
 23

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 4, em que a curva representa a razão entre o custo real pelo custo
planejado (HONOUR, 2013, apud INCOSE, 2015).

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

(HONOUR, 2013, apud INCOSE, 2015, p.16).

2.1.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 5.
A primeira fase é chamada de estudos do sistema (ou planejamento do programa),
compreende os contatos iniciais com stakeholders, alocação e priorização de recursos,
 24

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 melhor sistema, que compreende restringir 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.
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
 25

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 5 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).

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

produção (adaptado de Hall (1962, p. 87)).

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).
 26

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 6. 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
anteriormente, além de realizar as atividades de engenharia que deixem o sistema
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 6 – Comparação de modelos de ciclo de vida de sistemas (KOSSIAKOFF; SWEET,

2003, p. 52).
 27

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., 2015, 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,
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
 28

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, Programação Extrema (XP), Desenvolvimento de Software Adaptativo (ASD)
(AGILE, 2001; PINTO, 2014).
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;
 29

 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 de acordo periodicamente.
Embora a MBSE esteja se popularizando, o INCOSE (2014), em sua “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.
Assim, o que se verifica atualmente é 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, 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,
 30

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.

2.1.4 Estudo conceitual de sistemas

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

conceitual de um sistema, que é foco deste trabalho. O estudo conceitual tem por objetivo
definir o conceito do sistema que 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 em que 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 7, 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.
 31

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

Neste trabalho, será dada ênfase à abordagem de Kossiakoff e Sweet (2003), que
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.
 32

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
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, p. 38) afirma que o
conceito de operações deve conter as seguintes informações: definição da necessidade de
 33

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 sitemas 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
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. As funções (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.
 34

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.
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 7. 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).
 35

2.2 Pequenos satélites

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).
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 e comunicações
às cargas úteis (FORTESCUE; SWINERD; STARK, 2011; WERTZ, EVERETT; PUSCHELL,
2011).
Subsistemas de comunicações podem ser tanto integrantes exclusivamente da
plataforma, quanto da plataforma e das cargas úteis, a depender da missão do satélite. Os
subsistemas de comunicações 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
 36

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.
Desta forma, Woellert et al. (2011) apresentam em seu trabalho que seu
desenvolvimento é 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.

2.3 Posicionamento do trabalho

Conforme apresentado no capítulo de introdução deste trabalho, existe uma demanda

por comunicações militares confiáveis que atendam às tropas a pé, que estejam se deslocando
pela região amazônica. As alternativas 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 atuais também são inadequadas para atender às tropas realizando missões de
patrulhamento de selva e/ou fronteira.
 37

Soluções baseadas em pequenos satélites não-geossíncronos têm demonstrado potencial

para solucionar este problema. Porém não foram encontrados na literatura ou no mercado
trabalhos ou desenvolvimentos acerca de pequenos satélites de comunicações para atender a
tropas móveis na selva amazônica. Embora existam pesquisas acerca de comunicações militares
por parte do exército estadunidense, como os programas SMDC-ONE e SNaP apresentados na
seção 2.2, 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 da análise funcional 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. Para isso, propõe-se a estruturação de um método baseado em
atividades de engenharia de sistemas pautado nas abordagens baseada em documentação e
baseada em modelos. Desta forma, a contribuição científica deste trabalho é a criação de um
método que também pode ser empregado para a análise funcional de pequenos satélites para
outras aplicações (como imageamento terrestre e localização), a partir de abordagens
estabelecidas por diferentes autores e adaptado às características do desenvolvimento de
constelações de pequenos satélites. O método proposto visa a facilitar a gestão de
desenvolvimento e acompanhamento de projetos espaciais, por meio da consolidação de um
modelo integrado de engenharia de sistemas e engenharia de missão espacial.
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,
NASA, 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.1.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. Desta forma, em geral, a MBSE não tem sido aplicada de maneira exclusiva, mas
 38

sim em conjunto com processos de engenharia de sistemas tradicional (ESTEFAN, 2008, apud
SEBOK CONTRIBUTORS, 2016; INCOSE, 2014).
Alinhado com este contexto, no capítulo 3 será apresentado um método híbrido para a
fase de análise de necessidades do estudo conceitual, combinando engenharia de sistemas
baseada em documentação e MBSE, a partir da integração das proposições de Hall (1962);
Kossiakoff e Sweet (2003); Rozenfeld et al. (2006); Larson et al. (2009); Fortescue, Swinerd e
Stark (2011); Wertz, Everett e Puschell (2011); PMI (2013); INCOSE (2015); Douglass (2016)
e Loures da Costa e Fulindi (2018). Este método será aplicado à análise funcional de uma
constelação de pequenos satélites de comunicações para o Exército Brasileiro, de forma a
apresentar uma solução ao problema proposto neste trabalho.
 39

3 Método

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

realizar a análise funcional 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. Esta abordagem integra elementos
de engenharia de sistemas baseada em documentação e MBSE (engenharia de sistemas baseada
em modelos), e é fundamentada pelas proposições de Hall (1962); Kossiakoff e Sweet (2003);
Rozenfeld et al. (2006); Larson et al. (2009); 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 aplicada para desenvolver mísseis e pequenos satélites para outras aplicações.
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.
O método proposto é dividido em 5 etapas:
 Etapa 1: Iniciação;
 Etapa 2: Benchmarking;
 Etapa 3: Objetivos e metas;
 Etapa 4: Conceito de operações;
 Etapa 5: Arquitetura funcional.
As principais atividades relativas a cada uma das etapas do método deste trabalho são
apresentadas na Figura 8.
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.
Esta 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 e os objetivos e metas 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
 40

dos nós operacionais. Na quinta etapa (Arquitetura funcional), partindo dos cenários de
operações, é identificada a arquitetura funcional do sistema de interesse.

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

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), 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.1.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
podem 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 de 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 contratos textuais. Este formato textual favorece também
a revisão por parte dos departamentos jurídicos das entidades envolvidas, que provavelmente
 41

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.
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 consistência e a rastreabilidade nos documentos. Assim, sugere-se a utilização de
elementos de MBSE para contribuir com a segunda atividade desempenhada 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.
A maneira proposta neste trabalho para estruturar a quinta etapa, arquitetura funcional,
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 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.
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, 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 levam
à 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.
 42

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, como datas das revisões de projeto, entre outros (e não apenas prazo para
término), elaboração do plano de gestão de riscos, plano de segurança, plano de suprimentos e
gerenciamento das comunicações.
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 1 apresenta os
objetivos, informações de entrada, métodos e ferramentas, envolvidos e resultados obtidos após
a finalização desta etapa.

Tabela 1 – 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
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
 43

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), a estimativa de prazo e o orçamento preliminar do projeto; bem
como decidir pelo início 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á
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
 44

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.
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 2).

Tabela 2 – 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.
 45

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 bem realizado 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.
Indica-se neste trabalho que esta etapa seja dividida em duas atividades (Tabela 3),
sendo a primeira o estabelecimento dos critérios do benchmarking e a segunda a pesquisa e
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 3 – 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ções Métodos e Envolvidos Resultados

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

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
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 4 e a Tabela 5 são modelos
de saídas desta atividade.

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

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 5 – 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
 47

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 6.

Tabela 6 – 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 6, propõe-se a divisão
da responsabilidade de pesquisa das características técnicas consolidadas na Tabela 5 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 7, além de outras informações que os
membros da equipe de desenvolvimento julgarem importantes.
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
 48

por Larson et al. (2009), antevendo requisitos de interface e restrições impostas pelos demais
subsistemas.

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

Característica/Sistema Sistema A Sistema B Sistema C

Característica técnica 1 Utiliza 2 sensores Utiliza 3 sensores Não utiliza

de velocidade de velocidade sensores
Característica técnica 2 Possui tratamento Não possui Não demanda
antichamas tratamento tratamento
antichamas antichamas devido
aW
Característica técnica 3 Suporta Suporta Suporta
temperaturas entre temperaturas entre temperaturas entre
1000°C e 1100°C 500°C e 530°C por 1500°C e 1800°C
por T segundos 2T segundos por 3T segundos

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 e metas 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 8.
 49

Tabela 8 – 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 Envolvidos Resultados

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

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õe 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.
 50

Ainda, conforme apresentado por PMI (2013), é importante que cada alteração na
documentação proposta pelos envolvidos seja documentada e assinada pelo demandante, para
evitar contestações futuras.
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
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.
 51

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
sobre as versões do documento. Larson et al. (2009) propõem que este responsável seja o
engenheiro de sistemas.
Para a realizar a quantificação 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 simulação computacional.
Ao final desta etapa 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. Propõe-se que os resultados desta etapa sejam,
posteriormente, incorporados aos modelos em SysML, para fins de consistência e controle de
rastreabilidade nos documentos de requisitos.

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.1.4 (Estudo conceitual) 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á
 52

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 9 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.

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 4.

Informações Métodos e
Atividade Objetivos Envolvidos Resultados
de entrada ferramentas
4.1: -Determinar os -Escopo do -Reuniões -Equipe de -Parâmetros
Determi- parâmetros chave de projeto projeto chave de
nação dos desempenho (KPPs) -Métodos desempenho
parâme- -Objetivos e intuitivos de -Stakehol- (KPPs)
tros chave metas do geração de ders
de desem- projeto ideias externos
penho
(KPPs)
4.2: -Definir as fronteiras do -Escopo do -Reuniões -Equipe de -Fronteiras do
Desenvol- sistema projeto projeto sistema
vimento -Métodos
do -Identificar o contexto -Objetivos e intuitivos de -Stakehol- -Contextos “As-
contexto e “As-is” e definir o metas do geração de ders is” e “To-be”
arquitetu- contexto “To-be” projeto ideias externos
-Sequencia-
ra opera-
-Realizar o sequen- -Parâmetros -Diagramas mento opera-
cionais
ciamento operacional chave de de contexto cional dos
dos cenários desempenho cenários
(KPPs) -Diagramas
-Identificar a conexão de sequência -Atividades dos
entre as entidades -Informações nós operacionais
envolvidas no projeto sobre os -Diagramas
stakeholders e NxN -Relacionamen-
-Determinar as suas funções to entre os
atividades das entidades elementos do
no projeto sistema de
sistemas
 53

Informações Métodos e
Atividade Objetivos Envolvidos Resultados
de entrada ferramentas
4.3: -Identificar condições -Fronteiras do -Software -Equipe de -Condições
Identifi- ambientais a que o sistema para projeto ambientais a que
cação das sistema poderá estar modelagem o sistema poderá
con-dições exposto -Contextos estar exposto
ambien- “As-is” e “To-
tais be”
-Sequencia-
mento
operacional
dos cenários
-Definição
da(s)
referência(s)
para o projeto

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”.
 54

Sugere-se que, ao final desta atividade, sejam relacionados a cada objetivo do projeto
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 10.

Tabela 10 – 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
Design de inclinação, número
comunicações à região região sul do país Oferece
constelação de satélites em
sul do Brasil 100% do tempo
órbita

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 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
 55

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
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 11), por
meio do qual se estabelece como cada elemento do sistema se relaciona com os demais.

Tabela 11 – 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
 56

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, 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 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: Arquitetura funcional

Douglass (2016) sugere a identificação e análise das funções do sistema como forma de
identificar requisitos novos, inconsistentes ou incorretos. Assim, neste trabalho propõe-se que
seja identificada a arquitetura funcional 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).
 57

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. A descrição
desta etapa consta da Tabela 12.

Tabela 12 – 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 do -Software
funções projeto para criação -Stakehol- -Sequenciamen-
do -Realizar o de modelos ders to funcional dos
sistema sequenciamento -Contexto “To-be” externos sistemas
funcional dos -Diagramas
sistemas -Sequenciamento funcionais
operacional dos
cenários

Para a consecução desta etapa, propõe-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).
A utilização de MBSE nesta etapa é motivada pelo benefício propiciado pelos modelos
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.

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 disso, as funções também estão ligadas à operação, gerenciamento e
manutenção do sistema, atividades necessárias durante seu ciclo de vida.
 58

Propõe-se a construção de modelos para representar as funções do sistema e diagramas

de sequenciamento funcional (que apresentam a sequência temporal da realização das funções),
de modo a permitir o melhor entendimento das mesmas por todos os integrantes da equipe. Para
construir os diagramas de sequência funcionais, ou diagramas funcionais, 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 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.
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.
Desta forma, encerra-se o 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 da análise funcional 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.
 59

4 Caso de estudo

Neste capítulo será apresentada a aplicação 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 9.

Figura 9 – Etapas e atividades do método proposto neste trabalho.

O objeto desta aplicação é a realização da análise funcional 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. 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.
Conforme foi exposto no capítulo 1 (introdução) deste trabalho, este caso de estudo foi
realizado com foco no Exército Brasileiro, embora o sistema seja concebido para ter a
capacidade de transbordamento e integrar as entidades envolvidas no SISFRON. Isto porque as
tropas a pé 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
 60

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.
O CEI foi o responsável pelo desenvolvimento do ITASat-1, nanossatélite universitário
baseado na plataforma 6U, 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, que 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).
Conforme apresentado no capítulo de introdução deste trabalho, 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 ocultadas, sendo apresentado somente extrato das mesmas nos resultados neste
trabalho.
A seguir são apresentados os resultados da iniciação (Etapa 1), do benchmarking (Etapa
2), das expectativas dos stakeholders (Etapa 3), do conceito de operações (Etapa 4) e da
arquitetura funcional (Etapa 5). Ainda, ao final deste capítulo, são analisados os resultados
obtidos.
 61

4.1 Etapa 1: Iniciação

Para a consecução desta etapa, foram realizadas as atividades descritas na Tabela 13:
 Atividade 1.1: Alinhamento entre os principais stakeholders
 Atividade 1.2: Definição e mobilização da equipe do projeto

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 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
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

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 14) e se conheciam informações iniciais sobre a necessidade dos stakeholders externos.
 62

Tabela 14 – 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
Instituto Nacional de Pesquisas Espaciais
montagem, integração e testes dos satélites;
(INPE)
possível parceria para operação dos satélites
Comando de Operações Aeroespaciais
Parceria para operação dos satélites
(COMAE)
Ministério da Defesa (MD) Usuário do sistema
Sociedade brasileira Stakeholder passivo
Fornecedores de equipamentos e
Fornecedores
componentes
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
(ANATEL) do satélite junto à UIT
União Internacional de Telecomunicações Responsável pelo cadastramento da frequência
(UIT) do satélite
Responsável pelo cadastramento do satélite
Agência Espacial Brasileira (AEB) junto à 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 Stakeholder negativo (possíveis futuros
brasileiros na região amazônica oponentes)

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 para
tropas a pé na região amazônica.”
 63

Uma vez identificada a necessidade de missão, discutiu-se o tipo de solução de projeto,

em alto nível, a ser empregada. 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, custo compatível com o orçamento
proposto, conforme discutido na seção 2.2 (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. Este dimensionamento da constelação depende de
análise posterior, a ser realizada durante o estudo conceitual.
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 15.

Tabela 15 – Escopo do projeto.

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

missão comunicações para tropas a pé na região amazônica
Tipo de solução a ser Constelação de pequenos satélites em órbita não-
desenvolvido geossíncrona
Prazo de desenvolvimento 3 anos
Orçamento R$ 50 milhões
 64

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 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 16). Os nomes foram omitidos em razão de confidencialidade.

Tabela 16 – 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 Pessoa F
dimensão da constelação
Engenheiro mecânico Pessoa G
Especialista em logística Pessoa H
Responsável pelo controle e gerenciamento de Pessoa I
plataforma
Responsáveis pelas interfaces elétricas Pessoa J
Especialistas em telecomunicações Pessoa L
Especialista em controle de atitude Pessoa M

A equipe foi então reunida, informada sobre o escopo do projeto e mobilizada para
iniciar seu desenvolvimento.

4.2 Etapa 2: Benchmarking

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

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 2.

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

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

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 18) e as características técnicas relevantes (Tabela 19) 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
 66

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 18 – Critérios para seleção de sistemas a serem estudados no benchmarking.

Critério de seleção Justificativa

O sistema deve ser um pequeno satélite
O sistema deve ter sido desenvolvido
ou lançado a partir de 2008
Disponibilidade de informações a
respeito de características técnicas
relevantes e componentes
Serviços de comunicações oferecidos
Na Etapa 1 definiu-se que a solução
implementada será um pequeno satélite
Existe intenção em se filtrar os sistemas mais
recentes e com tecnologias atuais
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 19.

Tabela 19 – 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 vida útil, além da
cobertura e potência necessária para comunicação
Tempo de vida útil de O tempo de vida útil de cada satélite determina a frequência de
cada satélite reposição de satélites para manter a cobertura
 67

Característica técnica Justificativa

Dispenser O dispenser, dispositivo de proteção e interface do satélite para
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 abertura Os mecanismos de abertura estão relacionados à confiabilidade e
capacidade energética do satélite
Controle térmico A existência e tipo de controle térmico está relacionado à
confiabilidade do satélite e componentes sensíveis
Fonte de energia A operação do satélite depende de energia
Controle e processamento O controle e processamento de dados é o subsistema responsável
de dados pelo gerenciamento do satélite
Sensores de atitude Algumas cargas úteis e subsistemas da plataforma demandam
atitude específica para comunicação
Atuadores Os atuadores realizam o controle de atitude do satélite
Precisão do A precisão deve ser conhecida para se projetar o controle de
controle de atitude do satélite
atitude
Conhecimento O conhecimento de órbita é importante para realização do
de órbita controle
Sistema O sistema propulsivo realiza manutenção de órbita do satélite
propulsivo
Rádio para status O rádio para status permite comunicação da plataforma com o
segmento solo, para gerenciamento do sistema em voo
Rádio embarcado da O rádio embarcado da carga útil permite comunicação da carga
carga útil útil com rádios em solo, para atender aos usuários
Frequência (ou banda) de A frequência (ou banda) de operação dos rádios pode limitar a
operação dos rádios taxa de 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 de dados Como o sistema a ser projetado tem aplicação militar, existe
interesse em criptografia
Componentes COTS A utilização de COTS pode reduzir tempo e/ou custos de
desenvolvimento
Componentes ITAR A utilização de componentes ITAR, que podem ter a
comercialização restringida, aumenta o nível de dependência
estrangeira do projeto
 68

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 18. 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 20.

Tabela 20 – 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 21.
 69

Tabela 21 – 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 500 km
120,5° 64,78° 97,45° (órbita
heliossíncrona)
Tempo de vida > 1 ano > 2 anos > 2 anos* 3 anos
útil
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 7075* Alumínio 7075*
Mecanismo de 8 antenas/ ativo 4 antenas/ativo 4 4 antenas/ativo
abertura/tipo de antenas/passivo
abertura 4 painéis 2 painéis
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-Lítio* Conjunto de baterias íon- Conjunto de
baterias íon- Lítio* baterias íon-Lítio*
Lítio*
Controle e Aviônica dedicada Aviônica COTS COTS (Clyde
processamento dedicada (GOMspace)* Space)*
de dados
Sensores de --- --- --- ---
atitude
Atuadores 3 eixos (controle 3 eixos (rodas 3 eixos COTS 3 eixos COTS
magnético passivo) de reação MAI- (GOMspace) (Clyde Space)*
400)
Precisão do --- < 1°* --- ---
controle de
atitude
Conhecimento GPS GPS --- ---
de órbita
Sistema Não possui Sistema de gás Não possui Não possui
propulsivo frio
Rádio para UHF/VHF --- UHF/VHF UHF/VHF (ISIS
status TRXUV)*
 70

Dados relacionados às cargas úteis de comunicação

Característica/
SMDC-ONE SNaP-3 3-Diamonds KIPP
Sistema
Rádio Compatível com Compatível com Compatível Compatível com a
embarcado da rádios usados por os rádios PRC com a aviação aviação comercial
carga útil tropas militares 117, PRC 152 e comercial e e militar
Harris 5800M militar

Frequência (ou HF Banda Ka Banda S Banda Ku

banda) de
operação dos Banda L
rádios
Serviço Voz/texto Voz/texto/ Voz/texto/dados Voz/texto/dados
dados
Operabilidade CSL (Customer to CSL CSL CSL
Satellite Link –
ligação do usuário ISL (Inter ISL
com o satélite) Satellite Link –
ligação entre
satélites)
Tipo de rádio --- SDR (Software SDR SDR (Novel)
Defined 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
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
 71

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
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).
 72

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 22:
 Atividade 3.1: Síntese das expectativas dos stakeholders
 Atividade 3.2: Definição dos objetivos e metas do projeto

Tabela 22 – 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 Envolvidos Resultados

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

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 23).

Tabela 23 – 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

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). 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.
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
 74

disponíveis para aquisição. Deste modo, decidiu-se que este contato seria realizado após a
análise funcional, durante o estudo de conceitos alternativos e a seleção do conceito, quando
for se avaliar a arquitetura física do sistema.
Contudo, conforme apresentado no início deste capítulo, o caso de estudo foi aplicado
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.
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
pode 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 24.

Tabela 24 – 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 instalados na
Exército Brasileiro
região amazônica; interesse em poder ampliar a cobertura para todo o território
(EB)
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 no
CEI 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; obter
Ministério da
autonomia na área espacial voltada à defesa; estimular agentes nacionais a
Defesa (MD)
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 da
Sociedade
capacidade de defesa externa; integração do território nacional;
brasileira
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 em
componentes solo
Força Aérea Aumentar a efetividade na detecção de aeronaves ilegais na região amazônica,
Brasileira (FAB); bem como melhores comunicações em operações em regiões isoladas ou para
Marinha do Brasil navegação a baixa altura; interesse em poder ampliar a cobertura para todo o
(MB) território nacional e cobertura para dados de sensores do SISFRON
Polícias Militares,
Aumento de capacidade de coordenação das ações de fiscalização ambiental e
Civis, Rodoviária e
das regiões de fronteira no contexto do SISFRON, por meio da integração e
Federal; Receita
cooperação entre as instituições, corporações e órgãos usuários do sistema
Federal; ABIN;
satelital de comunicações
IBAMA
 75

Beneficiar-se do desenvolvimento tecnológico dentro do país, inclusive com

Indústria nacional aumento de disponibilidade de mão de obra especializada, capaz de suprir
soluções COTS anteriormente vindas do exterior
Organização Espera que o sistema cumpra as normas de lançamento (expectativa não ligada
lançadora à 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
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,
 76

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
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 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 25.

Tabela 25 – Necessidade de missão do 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
para tropas a pé na região amazônica
Objetivos
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
viáveis para ser transportados e
operados por tropa a pé em
terreno difícil (selva, pantanal,
montanha)
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
em solo
6. Integrar a região amazônica
ao território nacional por meio
da presença das Forças
Armadas nas comunidades
indígenas e/ou isoladas
77
Metas
1.1. Transmitir texto e dados a uma taxa de 5 Mbps (limite), 50
Mbps (objetivo) (TBC) entre as tropas
1.2. Permitir a comunicação em 40% do tempo (limite), 80% do
tempo (objetivo) (TBC) às tropas na região amazônica
1.3. Permitir a comunicação a cada 10 minutos (limite), 5 minutos
(objetivo) (TBC) às tropas na região amazônica
1.4. Permitir transmissão a uma taxa mínima de 9,6 kbps (limite),
64 kbps (objetivo) em condições severas de operação (fortes
chuvas, mata densa)
1.5. Fornecer a posição dos usuários com precisão de 100 m
(limite), 20 m (objetivo)
2.1. Ser interfaceável com equipamentos de comunicação em solo
de dimensões inferiores a 30x35x15 cm (limite), 20x25x10 cm
(objetivo) (excluindo as antenas) (TBC)
2.2. Ser interfaceável com equipamentos de comunicação em solo
de massa inferior a 10 kg (limite), 5 kg (objetivo) (TBC)
2.3. Permitir apontamento em até 30 segundos (limite), 10
segundos (objetivo) sem uso de equipamentos para tal
2.4. Demandar até 4 horas (limite), 2 horas (objetivo) de instrução
para pleno treinamento de operador
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 informação,
a integridade dos dados, a autenticidade do autor da mensagem,
a irretratabilidade do autor da mensagem e a disponibilidade da
informação ao Exército Brasileiro (objetivo)
4.1. Ser 100% controlado nacionalmente por meio das estações de
solo do Centro de Operações Espaciais (COPE)
5.1*. Transmitir dados oriundos dos sensores em solo a uma taxa
de 5 Mbps (limite), 50 Mbps (objetivo)
6.1. Transmitir comunicações a uma taxa de 9,6 kbps (limite),
38,4 kbps (objetivo) (TBD) para socorro em caso de emergências
médicas e/ou sociais às comunidades da região amazônica com
satisfação superior a 80% (limite), 100% (objetivo)
 78

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 foram estudadas pela equipe em conjunto com o Exército
Brasileiro e são compatíveis com o fluxo esperado para os níveis até batalhão.
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 deste
tipo de sistemas costuma variar de 1 a 3 anos, a constelação pode responder rapidamente a
mudanças nos requisitos dos stakeholders.
O objetivo número 2, relacionado à viabilidade para utilização por tropa a pé em
terreno difícil, apresenta metas relacionadas ao apontamento em até 30 segundos, sem
necessidade de equipamentos especiais. Isto porque as tropas a que se visa atender já
transportam, via de regra, uma carga elevada de materiais relacionados ao cumprimento de suas
missões, entre provisões, munições e outros. Além disso, o sistema deve ser de utilização
simples, para poder ser operado com pouco tempo de treinamento por qualquer militar, mesmo
em situação de desvantagem (em terreno remoto, durante deslocamentos ou embarcado). As
dimensões e peso dos equipamentos de comunicação utilizados pelas tropas a pé foram
definidas com o valor “objetivo” visando a permitir seu transporte na mochila de média
capacidade utilizada pelo EB. Para o caso de estas dimensões não serem atingidas, definiu-se
como limite dimensões compatíveis com a mochila de grande capacidade do EB. Para ambos
os casos, foram definidas dimensões tais que seja possível transportar nas mochilas os
equipamentos de comunicação em solo e mais a dotação de equipamentos e munições padrão
do militar de infantaria de selva.
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
 79

quais as principais métricas associadas à segurança (confidencialidade, integridade,

autenticidade, irretratabilidade e disponibilidade).
O objetivo número 4, relativo à autonomia para a implementação de soluções de
comunicações, 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.
 80

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 26):
 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

Tabela 26 – 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 chave
nação dos parâmetros chave de de desempenho
parâmetros de desempenho -Objetivos e metas -Métodos projeto (KPPs)
chave de (KPPs) do projeto intuitivos de
geração de -Stake-
desempenho
ideias holders
externos

4.2: -Definir as -Escopo do projeto -Reuniões -Equipe -Fronteiras do

Desenvol- fronteiras do de sistema
vimento do sistema -Objetivos e metas -Métodos projeto
contexto e do projeto intuitivos de -Contextos “As-is”
arquitetura -Identificar o con- geração de -Stake- e “To-be”
operacionais texto “As-is” e -Parâmetros chave ideias holders
definir o contexto de desempenho externos -Sequenciamento
“To-be” (KPPs) -Diagramas operacional dos
de contexto cenários
-Realizar o -Informações
sequenciamento sobre os -Diagramas -Atividades dos
operacional dos stakeholders e suas de sequência nós operacionais
cenários funções
-Diagramas -Relacionamento
-Identificar a cone- NxN entre os elementos
xão entre as do sistema de
entidades sistemas
envolvidas no
projeto
-Determinar as
atividades das
entidades no
projeto
 81

Informações de Métodos e Envolvi-

Atividade Objetivos Resultados
entrada ferramentas dos
4.3: Identifi- -Identificar -Fronteiras do -Software -Equipe -Condições
cação das condições sistema para de ambientais a que o
condições ambientais a que o modelagem projeto sistema poderá
-Contextos “As-is”
ambientais sistema poderá estar exposto
e “To-be”
estar exposto
-Sequenciamento
operacional dos
cenários
-Definição da(s)
referência(s) para
o projeto

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 27). 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 27 – 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 baixa
projeto desempenho
(KPP) geossíncrono órbita
1. Prover serviço Cobertura – Prover Oferece Depende do Altitude, inclinação,
de comunicação serviço de Design da número de satélites
para tropas mili- comunicação na constelação em órbita, potência
tares nos níveis região amazônica ao dos rádios, nível de
grupo de comba- menos 40% do robustez do satélite,
te, pelotão, com- tempo com intervalo sensibilidade dos
panhia e batalhão entre períodos de receptores, nível de
localizadas na cobertura máximo interferência de
região amazônica de 10 minutos tempestades solares e
cintilações, altitude
 82

Parâmetros chave Alternativas

Objetivos de Possibilitadores de
de desempenho Satélite Satélites em baixa
projeto desempenho
(KPP) geossíncrono órbita
2. Ser compatível Portabilidade - Os Maior Menor altitude Dimensões, peso
com equipamentos de altitude de operação
equipamentos de comunicação devem exige maior demanda menor
comunicação ser passíveis de potência, po-tência de
viáveis para serem transportados que exige transmissão,
serem por tropa a pé em equipa- permitindo
transportados e terreno acidentado mentos e reduzir as
operados por baterias dimensões e peso
tropa a pé em maiores dos
terreno difícil equipamentos
(selva, pantanal,
montanha)
3. Manter a Segurança - Oferece Oferece Tempo de resposta,
segurança das Proteção contra resposta, tipo de
comunicações interferência e medidas de Guerra
escuta Eletrônica, tipo de
criptografia

4. Viabilizar a Autonomia - Oferece Oferece Porcentagem de

autonomia para a Capacidade de as componentes de
implementação Forças Armadas venda controlada (ex.
de comunicações proverem suas ITAR) não
pelas Forças comunicações sem produzidos no Brasil,
Armadas dependência de exclusividade no
empresas ou nações controle e
estrangeiras conhecimento de
protocolos para
status/telecomando
5.* Prover Capacidade de Atende Atende Taxa de transmissão
serviço de transmissão -
comunicação Permitir leitura e ar-
com os sensores mazenamento dos
em solo dados dos sensores
em solo e retransmi-
tir os dados para as
organizações
militares
6. Integrar a Integração - Não Não aplicável Nível de
região amazônica Aumentar a aplicável demonstração de
ao território na- presença do Estado capacidade
cional por meio brasileiro em regiões operacional e domínio
da presença das remotas de tecnologia para
Forças Armadas controle da região
nas comunidades
indígenas e/ou
isoladas
 83

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

Para satélites em baixa órbita, ela depende da altitude, inclinação 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.
Uma vez que o sistema de comunicações visa a atender tropa a pé em regiões isoladas
e/ou terreno difícil (acidentado, alagado), a portabilidade é propiciada pelas dimensões e peso
dos equipamentos. Ainda, os equipamentos de comunicação em solo necessitam de maior
potência para contato com satélites geossíncronos (GEO) do que com satélites em baixa órbita
(LEO), de modo que componentes como baterias tendem a ser maiores e mais pesados para
contato com satélites GEO.
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.
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.
Para um sistema militar, a robustez é um aspecto relevante. Dadas as condições
climáticas dos diferentes biomas nacionais, que incluem a região amazônica onde tempestades
são constantes e a cobertura vegetal dificulta a transmissão das ondas de rádio. Assim, o
 84

objetivo de se prover comunicação tática para tropas em áreas remotas envolve a resiliência do
sistema, bem como criptografia e medidas de Guerra Eletrônica, que estão associadas ao
objetivo de comunicações seguras.
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 e dos KPPs,
estabeleceram, em reunião, as fronteiras do sistema (Figura 10).
Identificou-se que estariam incluídos nas fronteiras do sistema de interesse a constelação
de pequenos satélites e os equipamentos de comunicação utilizados pelas tropas no terreno. Os
equipamentos de comunicação foram incluídos nas fronteiras do sistema de interesse
(representada pela elipse destacada em cinza) pois, conforme apresentado anteriormente (seção
4.3.2), o Exército Brasileiro havia concordado em restringir as metas deste projeto à transmissão
de texto e dados. Desta forma, optou-se por dar liberdade à equipe para desenvolver um
equipamento de comunicação para as tropas a pé mais alinhado aos parâmetros chave de
desempenho, especialmente no que se refere à portabilidade.
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 e as estações de solo (Figura 10). 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 sistemas espaciais é
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.
 85

Figura 10 – 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” (Figura 11) e “To-
be” (Figura 12).

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

 86

No estado atual “As-is”, 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 grupos de combate, pelotões e
companhias, 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 emitem involuntariamente sinais, a partir de
suas aeronaves, embarcações ou rádios, por exemplo, que possibilitam sua detecção por
sensores. Considera-se que os 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 12 – Diagrama de contexto “To be” para a constelação de pequenos satélites.

 87

A solução proposta pela equipe para o presente projeto é esboçada no modelo “To-be,
relativo à constelação de pequenos satélites de comunicação.
O modelo proposto “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 em situações
isoladas, dado que não possuem banda para prover serviço contínuo de comunicação para estes
níveis. 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.
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 13).

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

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

No diagrama da Figura 13, 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)
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
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 à
banda 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 banda, 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.
 89

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 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.
A sequência operacional para comunicação entre usuários de diferentes níveis em
condições ambientais favoráveis é apresentada na Figura 14. 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
toma ciência de 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, ele
tem bateria 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 14 – Sequência de operações para comunicação entre usuários de diferentes níveis em

condições ambientais favoráveis.
 90

A Figura 15 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 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, identifica a
ameaça e, se for o caso, inicia contato para solicitar ou providenciar uma interceptação.

Figura 15 – 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 confeccionada ainda a Tabela

28, que apresenta as atividades das principais entidades envolvidas na operação do sistema (nós
operacionais).

Tabela 28 – Nós operacionais.

Nó operacional Atividades
Satélite de comunicações * Detecta dados de comunicação dos usuários (voz/texto)
* Detecta dados de missão dos usuários
* Detecta dados de sensores de Guerra Eletrônica (radar ou COMINT)
* Envia dados de comunicação aos usuários (dados/texto)
* Envia dados de missão aos usuários
* Gera e envia dados de telemetria do satélite
* Recebe e executa comandos operacionais
 91

Nó operacional Atividades
Estação de solo * Recebe status do satélite
(COMAE) * Envia comandos para o satélite
CComGEx (EB) * Analisa os dados de telemetria
* Gera os comandos operacionais do satélite
* Registra o conjunto de dados de status/telecomando do satélite
Usuários (tropas) * Recebe dados de comunicação do satélite
* Recebe dados de missão do satélite
* Recebe dados de sensores de Guerra Eletrônica do satélite
* Envia dados de comunicação para o satélite
* Envia dados de missão para o satélite
Controle de missão * Analisa os dados de comunicação do satélite
* Analisa os dados de missão do satélite
* Analisa os dados dos sensores de Guerra Eletrônica
* Gera os dados de comunicação do satélite
* Gera os dados de missão do satélite
* 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 29). 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.
 92

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

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

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 dois elementos principais e diversos estavam
compreendidos no escopo do desenvolvimento: os equipamentos de comunicação utilizados em
solo pelas tropas e os satélites, sujeitos a condições ambientais diversas.
Realizou-se análise dos ambientes operacionais e condições de transporte e
armazenamento para os equipamentos de comunicação usados em solo, com atenção às
condições de terreno e climáticas enfrentadas pelas tropas, como regiões alagadiças, períodos
chuvosos e armazenamento em ambientes sem ventilação adequada e expostos ao sol, tornando-
se excessivamente quentes. 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 30.
 93

Tabela 30 – Condições ambientais.

Sistema Condição ambiental Justificativa

Equipamento de Temperatura: -10° a +70°
comunicação
utilizado pelas
tropas em solo
Umidade: Imersão até 2
metros de água por 5
minutos
Resistência a choque
mecânico e quedas
acidentais de até 2 metros
Satélite Temperatura: -40° a
+65°C
Resistência às condições
de vácuo espacial
Resistência à degradação
por radiação
Faixa de temperatura esperada para
operação e armazenamento em diferentes
condições ambientais no território
nacional
Resistência adequada à operação em
ambiente de selva e contato acidental com
água durante transposição de cursos
d’água
Resistência necessária para prevenir danos
em casos de quedas acidentais,
especialmente quando transportado por
trilhas escorregadias
Faixa de temperatura esperada para
operação em ambiente espacial
Vácuo espacial pode provocar
volatilização de partículas contaminantes,
que degradam o desempenho do sistema
Radiação é uma condição que degrada
desempenho e vida útil dos sistemas
espaciais

4.5 Etapa 5: Arquitetura funcional

Uma vez definido o conceito de operações, realizou-se a seguinte atividade (descrita na

Tabela 31):
 Atividade 5.1: Identificação das funções do sistema

Tabela 31 - 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 do -Software
funções projeto para criação -Stakehol- -Sequenciamen-
do -Realizar o de modelos ders to funcional dos
sistema sequenciamento -Contexto “To-be” externos sistemas
funcional dos -Diagramas
sistemas -Sequenciamento funcionais
operacional dos
cenários
 94

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,

reuniram-se a equipe e os stakeholders externos para identificar as funções a serem
desempenhadas pelo sistema.
Desta forma, quatro funções foram apontadas: comunicar-se com tropas, proteger as
comunicações, comunicar com os sensores em solo, e gerenciar o sistema durante sua operação.
Conforme explicado anteriormente, a terceira função, da comunicação com os sensores em solo,
embora compreendido 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 apresentados na Tabela 32.

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

Objetivos de projeto Funções Cenários

1. Prover serviço de 1. Comunicar com tropas 1.1. Condições ambientais

comunicação para tropas
militares nos níveis grupo
de combate, pelotão,
companhia e batalhão
localizadas na região
amazônica
favoráveis
2. Comunicar com outros
satélites 1.2. Condições ambientais
desfavoráveis
Entidades relacionadas:
Usuários (tropas do EB), satélites

3. Manter a segurança das 3. Proteger as comunicações 3.1. Interceptação da comunicação

comunicações pelo oponente
Entidades relacionadas:
Stakeholders negativos 3.2. Perda da comunicação devido
a ruídos causados pelo oponente

4. Viabilizar a autonomia 4. Gerenciar o sistema durante a 4.1. Interface com o centro de

para a implementação de operação operações
soluções de comunicações
pelas Forças Armadas Entidades relacionadas: 4.2. Corrigir falhas do sistema em
COPE operação

5*. Prover serviço de
comunicação com os
sensores em solo
5*. Comunicar com os sensores 5.2. Condições ambientais
em solo desfavoráveis
Entidades relacionadas: 4.2. Corrigir falhas do sistema em
Radares/ sensores, comando operação
 95

Dada a missão operacional do sistema, os principais cenários para as comunicações são

influenciados de 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 16 apresenta o modelo
para as funções “comunicar” (numeradas na Tabela 32 como 1, 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”.

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

 96

Este modelo é apresentado de modo a incluir a atuação dos satélites geossíncronos e dos
sensores, de modo a mostrar o relacionamento do sistema de interesse (a constelação de
pequenos satélites) com outros sistemas.
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 17), 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). Em seguida, o sistema envia para o comando uma confirmação do recebimento
da mensagem por parte do satélite (e). Então, o sistema transmite a mensagem para a tropa (f).
O equipamento de comunicação da tropa envia um sinal de confirmação de recebimento da
mensagem (g). O sistema encaminha ao comando o sinal de recebimento de mensagem por
parte da tropa (h) e zera o contador (i). Ao final deste processo, o sistema deve estar pronto para
receber novas mensagens (j).

Figura 17 – 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 favoráveis.
 97

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 (e). O ambiente, então, oferece resistência
para o recebimento da mensagem por parte da tropa (f), de modo que a transmissão da
mensagem não chega até a tropa (g). O contador informa ao sistema que foi excedido o tempo
para a comunicação (h). O sistema então zera o contador (i) e retorna ao estado de pronto para
receber novas mensagens (j). Desta forma, o sistema pode responder a novas tentativas de
comunicação (l). Este cenário é apresentado na Figura 18.

Figura 18 – 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.

A seguir será apresentada a análise dos resultados obtidos.

 98

4.6 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.
A abordagem é positiva pois um método estruturado permite a melhor aderência dos
resultados, e sua característica não sequencial permite uma maior interação entre os
stakeholders e melhor utilização do tempo.

4.6.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 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.6.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. O benchmarking,
contudo, foi restrito aos sistemas espaciais, não abrangendo os equipamentos de comunicação
em solo.
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,
 99

presumidas. 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.6.3 Etapa 3: Objetivos e metas

A terceira etapa cumpriu seus objetivos de identificar as expectativas dos stakeholders

com relação ao projeto e os objetivos e metas 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, que
foram aprovados por representantes do EB em reunião, servindo para direcionar o restante do
estudo realizado.

4.6.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.
 100

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), e 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, o EB considerou os resultados produzidos nesta etapa como 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, agradou ao EB,
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.

4.6.5 Etapa 5: Arquitetura funcional

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 melhor visualização dos dados
de engenharia.
O próximo capítulo apresenta as conclusões e propostas de trabalhos futuros, a partir do
desenvolvimento do presente trabalho.
 101

5 Conclusões

Meios de comunicações satelitais baseados em constelações de pequenos satélites não-

geossíncronos apresentam-se como soluções viáveis para prover serviço de comunicações
militares com tropas militares, de modo que têm sido objeto de pesquisa por outras nações. Isto
motiva o estudo destas constelações para atender às demandas do Exército Brasileiro na região
amazônica, face às dificuldades de se estabelecer comunicações nesta região.
As tropas a pé do EB foram consideradas o usuário mais difícil de se atender, por dispor
de menor estrutura de apoio e realizarem suas missões com adversidades potencialmente
maiores, como longos deslocamentos em terreno de difícil mobilidade e ações de forças
oponentes. Assim, uma vez atendida a sua necessidade, é possível realizar o transbordamento
para prestar o serviço de comunicações integrando as demais entidades compreendidas no
contexto do SISFRON e também ampliar a cobertura para o restante do território nacional.
A contribuição científica deste trabalho foi a criação de um método que também pode
ser empregado para a análise funcional de sistemas como mísseis e pequenos satélites para
diversas aplicações, a partir de abordagens estabelecidas por diferentes autores e adaptado às
características do desenvolvimento de constelações de pequenos satélites. Verificou-se que o
método proposto foi efetivo a:
 Identificar as necessidades e expectativas dos stakeholders;
 Realizar a análise operacional para os satélites de comunicações, com a
finalidade de identificar o conceito de operações em que o sistema será
empregado;
 Realizar a análise funcional de uma constelação de pequenos satélites não-
geossíncronos para prover comunicações a tropas a pé do Exército Brasileiro na
região amazônica e de seus subsistemas.
Com relação às contribuições técnicas, 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.
Conforme discutido, o presente trabalho não teve a pretensão de realizar o
desenvolvimento completo da constelação. Neste sentido, propõem-se novos trabalhos para
contribuir com o desenvolvimento do sistema:
 102

 Realização do estudo conceitual de uma constelação de satélites para atender às

demandas de comunicação de usuários a pé no contexto do SISFRON;
 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,
mesmo em regiões com densa cobertura vegetal, como na selva amazônica.
Ainda, vislumbra-se a utilização de pequenos satélites não-geossíncronos para outras
aplicações, propondo-se o estudo conceitual de constelações com as finalidades de:
 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.
 103

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. 2012. 175f.
Dissertação (Mestrado em Engenharia Aeronáutica e Mecânica) - Instituto Tecnológico de
Aeronáutica, São José dos Campos.

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

organizacional. São Paulo: Atlas, 2001.

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

Barueri: Manole, 2008.

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.

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.

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

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

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. ECSS-E-ST-10C - Space engineering: system engineering general requirements.

Noordwijk: [s.n.].

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

Pasadena. INCOSE MBSE Focus Group, 2007.

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. Integration of a systemic hazard analysis into a systems engineering

approach. 2017. 157f. Tese (Doutorado em Ciências e Tecnologias Espaciais) - Instituto
Tecnológico de Aeronáutica, São José dos Campos.

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.

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

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.

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

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.

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.

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

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

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

LOURES DA COSTA, L. E. V.; FULINDI, J. B. Notas de aula de TE-265. São José dos
Campos: Instituo Tecnológico de Aeronáutica, 2018.

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

exploration and coverage in wireless communication networks. 2018. Dissertação
(Mestrado em Engenharia Eletrônica e Computação) - Instituto Tecnológico de Aeronáutica,
São José dos Campos.

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

em: 3 mar. 2018.

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.

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-
GENERAL+DIZ+QUE+BRASIL+PODE+PERDER+PARTE+DE+RORAIMA+SEGUNDO
+JORNAL.html>. Acesso em: 29 jul. 2018.

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. 2014. 237f. Tese (Doutorado em Engenharia Aeronáutica e
Mecânica) - Instituto Tecnológico de Aeronáutica, São José dos Campos.

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.
 107

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.; 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.

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

sistemas baseada em modelos.2013. 99f. Dissertação (Mestrado em Engenharia Elétrica) -
Universidade Federal do Rio Grande do Sul, Porto Alegre.

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

Satellite systems. 2011. 192f. Tese (Doutorado) - Julius-Maximilians-Universität Würzburg,
Würzburg.

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.

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

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. 2010. 72f.

Dissertação (Mestrado em Ciência e Tecnologia Aeroespaciail) - Universitat Politecnica de
Catalunya, Barcelona.
 108

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

(SISFRON): Uma Contribuição para a Segurança Nacional. 2014. 63f. Monografia - Escola
Superior de Guerra (ESG), Rio de Janeiro.

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

Programa Estratégico de Sistemas Espaciais. Comissã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.

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.
 FOLHA DE REGISTRO DO DOCUMENTO
1. 2. 3. 4.
CLASSIFICAÇÃO/TIPO DATA REGISTRO N° N° DE PÁGINAS

TC 19 de novembro de 2018 DCTA/ITA/TC-049/2018 108

5.
TÍTULO E SUBTÍTULO:

Análise funcional de uma constelação de pequenos satélites de comunicações 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:

Pequenos satélites, Engenharia de sistemas, Estudo conceitual.

9.PALAVRAS-CHAVE RESULTANTES DE INDEXAÇÃO:
Microssatélites; Análise funcional; Partes interessadas; Telecomunicações; Engenharia de sistemas.
10.
APRESENTAÇÃO: X Nacional Internacional
ITA, São José dos Campos. Curso de Graduação em Engenharia Aeronáutica. Orientador: Prof. Luís
Eduardo Vergueiro Loures da Costa; coorientador: Prof. Jonas Bianchini Fulindi. Publicado em 2018.
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, como os
pequenos satélites. Paralelamente, a engenharia de sistemas tem evoluído de uma abordagem baseada em
documentação para abordagens utilizando também modelos, 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 a análise funcional de mísseis e pequenos satélites para missões diversas, combinando
elementos de engenharia de sistemas baseada em documentação e em modelos, sendo composto por cinco
etapas. Na primeira etapa são definidas as necessidades 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 é identificada a arquitetura funcional
nível do sistema de interesse. Este método foi aplicado ao estudo 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. A partir dos resultados
obtidos, pôde-se concluir que o método permite a realização da análise funcional, tendo sido estabelecidas
as funções que os pequenos satélites da constelação devem desempenhar para atender às demandas dos
stakeholders.

12.
GRAU DE SIGILO:

(X ) OSTENSIVO ( ) RESERVADO ( ) SECRETO