Dados Internacionais de Catalogação-na-Publicação (CIP)
Divisão de Informação e Documentação
Vinci, Edson
Análise de Confiabilidade da CPU do Satélite Universitário ITASAT e Proposta de Melhoria / Edson Vinci.
São José dos Campos, 2010.
149f.
Tese de mestrado – Curso de Pós-Graduação em Engenharia Aeronáutica e Mecânica, Área de Sistemas
Aeroespaciais e Mecatrônica – Instituto Tecnológico de Aeronáutica, 2010. Orientador: Prof. Dr. Osamu
Saotome.
1. Satélite. 2. Computador de Bordo. 3. Predição de Confiabilidade. I. Comando-Geral de Tecnologia
Aeroespacial. Instituto Tecnológico de Aeronáutica. Divisão de Engenharia Aeronáutica e Mecânica. II. Análise
de Confiabilidade da CPU do Satélite Universitário ITASAT e Proposta de Melhoria
REFERÊNCIA BIBLIOGRÁFICA
VINCI, Edson. Análise de Confiabilidade da CPU do Satélite Universitário ITASAT e
Proposta de Melhoria. 2010. 149 folhas. Tese de mestrado – Instituto Tecnológico de Aeronáutica,
São José dos Campos.
CESSÃO DE DIREITOS
NOME DO AUTOR: Edson Vinci
TÍTULO DO TRABALHO: Análise de Confiabilidade da CPU do Satélite Universitário ITASAT e
Proposta de Melhoria
TIPO DO TRABALHO/ANO: Tese de Mestrado/2010
É concedida ao Instituto Tecnológico de Aeronáutica permissão para reproduzir cópias desta tese e
para emprestar ou vender cópias somente para propósitos acadêmicos e científicos. O autor reserva
outros direitos de publicação e nenhuma parte desta tese pode ser reproduzida sem a sua autorização
(do autor).
___________________________
Edson Vinci
Pça. Mal. do Ar Eduardo Gomes, 50 – Vl. Acácias
CEP: 12228-900 – São José dos Campos – SP – Brasil
iii
ANÁLISE DE CONFIABILIDADE DA CPU DO SATÉLITE
UNIVERSITÁRIO ITASAT E PROPOSTA DE MELHORIA
Edson Vinci
Composição da Banca Examinadora:
Profa. Dra.
Prof. Dr.
Prof. Dr.
Prof. Dr.
Emilia Villani
Osamu Saotome
Geilson Loureiro
Samuel Euzédice de Lucena
Presidente - ITA
Orientador - ITA
Membro interno - ITA
Membro externo - FEG / UNESP
ITA
iv
DEDICATÓRIA
“Dedico este trabalho aos meus pais e a
minha namorada.”
v
AGRADECIMENTOS
Ao meu orientador, Prof. Dr. Osamu Saotome, pelo suporte científico deste trabalho. À
Agência Espacial Brasileira – AEB, ao Instituto Nacional de Pesquisas Espaciais – INPE, ao
Instituto Tecnológico de Aeronáutica – ITA e ao Projeto ITASAT, pela oportunidade e apoio
financeiro para execução do projeto. Ao Prof. Dr. Irany de Andrade Azevedo, pelo apoio em
conhecimentos sobre confiabilidade. Ao Prof. Dr. Wilson José Vieira, pelo apoio em conhecimentos
específicos. Ao Eng. Marcelo de Lima Bastos Moreira, da empresa Equatorial Sistemas S.A., pelo
apoio na utilização da ferramenta computacional Relex Reliability Studio 2008. Ao
Prof. Ms. Giovanni Fernandes Amaral, pelo apoio técnico e motivação. A todas as pessoas que
indiretamente ajudaram na realização deste trabalho.
vi
RESUMO
Esta tese apresenta uma análise do computador de bordo para o satélite universitário
ITASAT, propondo redundância interna de hardware nos itens críticos e comparando índices de
confiabilidade entre a utilização de componentes de aplicação espacial e componentes COTS –
Commercial off-the-shelf. O ITASAT consiste num projeto de desenvolvimento de um satélite
tecnológico de pequeno porte pela parceria entre o Instituto Tecnológico de Aeronáutica – ITA, o
Instituto Nacional de Pesquisas Espaciais – INPE e a Agência Espacial Brasileira – AEB.
Após uma breve explanação sobre os subsistemas que compõem um satélite genérico, as
principais características funcionais e requisitos preliminares para o projeto do hardware do
computador de bordo do satélite universitário ITASAT são apresentadas. Em seguida, definido o
sistema computacional do segmento espacial do ITASAT como ACDH – Attitude, Control and
Data Handling, é organizado o computador de bordo em módulos. O módulo denominado de CPU
é analisado com componentes de aplicação espacial e sua confiabilidade de hardware calculada
para uma vida útil de dois anos de missão, seguindo a norma militar MIL-HDBK-217F com suporte
da ferramenta computacional Relex Reliability Studio 2008. Não atingindo o nível especificado de
confiabilidade, aplicou-se redundância cold standby ao módulo da CPU, o que o tornou um módulo
tolerante a falhas. Esta técnica de redundância exigiu duas unidades adicionais, de gerenciamento
de redundância e de chaveamento. Baseando-se nesta configuração redundante, é abordado um
conjunto de mecanismos de verificação e projetos, conjuntamente denominados de FDIR – Failure
Detection, Isolation and Recovery, que têm como objetivo proteger a integridade do módulo da
CPU, evitando a perda de suas partes ou totalidade, na presença de uma falha simples, de forma a
assegurar o desempenho da missão durante sua vida útil. Novamente, foi calculada a confiabilidade
do módulo da CPU com redundância cold standby e os resultados obtidos mostraram um acréscimo
do nível de confiabilidade suficiente para atender a esse requisito. Por fim, foram substituídos os
componentes de aplicação espacial por componentes COTS e recalculada a confiabilidade para o
módulo da CPU.
Os resultados obtidos com as configurações estudadas para o módulo da CPU mostraram
que a aplicação de tolerância a falhas eleva o índice de confiabilidade e a combinação da utilização
de componentes de aplicação espacial e componentes COTS garante, em algumas configurações, a
superação do índice de confiabilidade de hardware especificado.
vii
ABSTRACT
This thesis presents an analysis of on-board computer for ITASAT university satellite,
proposing internal hardware redundancy in critical items and comparing reliability level between
the use of space application components and COTS – Commercial off-the-shelf components.
ITASAT is a project for developing a small technological satellite by a consortium composed of
Instituto Tecnológico de Aeronáutica – ITA, Instituto Nacional de Pesquisas Espaciais – INPE and
Agência Espacial Brasileira – AEB.
After a brief explanation of the subsystems that compose a generic satellite, the main
characteristics and preliminary requirements, the design of ITASAT’s on-board computer hardware
is presented. Then, ITASAT’s ACDH – Attitude, Control and Data Handling is defined and the onboard computer is organized in modules. It is analyzed the module named CPU with space
application components and hardware reliability is calculated assuming a mission life cycle of two
years, following the military standard MIL-HDBK-217F and using computational support tool
Relex Reliability Studio 2008. Not reaching the reliability level specified, it was applied cold
standby redundancy to the CPU module, making it a fault-tolerant module. This technique of
redundancy required two additional units, redundancy manager and switching. Based on the
configuration with redundancy, it was applied a design and verification tool set called FDIR –
Failure Detection, Isolation and Recovery. FDIR aims to protect the CPU module integrity,
avoiding part or total failure in the presence of a single failure. This ensures CPU designed
performance during operational lifetime. Again, the reliability of the CPU module with cold
standby redundancy and the results showed an increase in the reliability level sufficient to satisfy
this requirement. Finally, the space application components have been replaced by COTS
components and the reliability for the CPU module was calculated.
The results obtained with the configurations studied for the CPU module shown that the
application of fault tolerance increases the reliability level and the combination of the use of space
application components and COTS components assures, in some configurations, the surpassing of
the specified hardware reliability level.
viii
LISTA DE FIGURAS
Figura 1 – Discriminação de falhas nos subsistemas do satélite [11]................................................18
Figura 2 – Ocorrência do tipo de falha nos subsistemas OBDH e TT&C [11]. ................................19
Figura 3 – Impacto de falhas nos componentes dos subsistemas OBDH e TT&C [11]. ...................19
Figura 4 – Sistema completo de um satélite genérico [12]. ...............................................................22
Figura 5 – Diagrama em blocos dos subsistemas de um satélite genérico. .......................................23
Figura 6 – Arquitetura centralizada para o sistema computacional de um satélite [14]. ...................28
Figura 7 – Arquitetura em anel distribuído para o sistema computacional de um satélite [14].........29
Figura 8 – Arquitetura em barramento para o sistema computacional de um satélite [14]. ..............30
Figura 9 – Arquitetura em barramento distribuído para o sistema computacional de um satélite [14].
............................................................................................................................................................30
Figura 10 – Diagrama em blocos do computador de bordo do SCD-1 [22]. .....................................32
Figura 11 – Diagrama em blocos do sistema computacional do CBERS [22]. .................................33
Figura 12 – Diagrama em blocos do sistema computacional do SACI-1 [22]. .................................34
Figura 13 – Modos de operação do satélite universitário ITASAT [18]. ..........................................41
Figura 14 – Diagrama funcional do segmento espacial do satélite universitário ITASAT. ..............46
Figura 15 – Diagrama em blocos do ACDH para o satélite ITASAT [27]........................................47
Figura 16 – Diagrama em blocos do computador de bordo para o ACDH........................................48
Figura 17 – Diagrama em blocos do módulo de comunicação para o computador de bordo............49
Figura 18 – Diagrama em blocos do módulo condicionador de energia para o computador de bordo.
............................................................................................................................................................50
Figura 19 – Diagrama em blocos do módulo de I/O para o computador de bordo............................51
Figura 20 – Diagrama em blocos do módulo da CPU para o computador de bordo. ........................53
Figura 21 – Árvore de falhas da perda do computador de bordo do satélite universitário ITASAT. 55
Figura 22 – Árvore de falhas para o módulo de comunicação do computador de bordo. .................55
Figura 23 – Árvore de falhas para o módulo condicionador de energia do computador de bordo....56
Figura 24 – Árvore de falhas para o módulo de I/O do computador de bordo. .................................57
Figura 25 – Árvore de falhas para o módulo da CPU do computador de bordo................................58
Figura 26 – Resultado do cálculo de confiabilidade do módulo da CPU obtido no software Relex. 64
Figura 27 – Redundância cold standby para o módulo da CPU do computador de bordo. ...............67
Figura 28 – Diagrama em blocos da unidade de gerenciamento de redundância. .............................69
Figura 29 – Canal serial da unidade de gerenciamento de redundância. ...........................................71
ix
Figura 30 – Memória compartilhada centralizada, unidade de gerenciamento de redundância. .......75
Figura 31 – Diagrama de tempo de pulsos de status da unidade nominal e redundante do módulo da
CPU destinados à unidade de gerenciamento de redundância...........................................................77
Figura 32 – Diagrama de estados das unidades redundantes do módulo da CPU. ............................79
Figura 33 – Diagrama em blocos da unidade de chaveamento..........................................................80
Figura 34 – Chaves e sinais de controle da unidade de chaveamento. ..............................................81
Figura 35 – Circuito de controle de chave, unidade de chaveamento................................................82
Figura 36 – Circuito de proteção, unidade de chaveamento. .............................................................84
Figura 37 – Circuito de watchdog timer para a unidade de gerenciamento de redundância. ............85
Figura 38 – Resultado do cálculo de confiabilidade para a unidade de gerenciamento de
redundância, obtido no software Relex..............................................................................................89
Figura 39 – Resultado do cálculo de confiabilidade da unidade de chaveamento, obtido no software
Relex. .................................................................................................................................................90
Figura 40 – RBD da redundância cold standby para o Módulo da CPU do computador de bordo. ..91
Figura 41 – Resultado do cálculo de confiabilidade da redundância cold standby para o módulo da
CPU do computador de bordo, obtido no software Relex. ................................................................92
Figura 42 – Predição de confiabilidade da redundância cold standby para o módulo da CPU do
computador de bordo com componentes de aplicação espacial.........................................................93
Figura 43 – Árvore de eventos da redundância cold standby para o módulo da CPU do computador
de bordo no primeiro ciclo de operação.............................................................................................94
Figura 44 – Árvore de eventos da redundância cold standby para o módulo da CPU do computador
de bordo depois do primeiro ciclo de operação. ................................................................................95
Figura 45 – Resultado do cálculo de confiabilidade do módulo da CPU com componentes COTS,
obtido no software Relex. ................................................................................................................101
Figura 46 – Resultado do cálculo de confiabilidade para a unidade de gerenciamento de redundância
com componentes COTS, obtido no software Relex. ......................................................................102
Figura 47 – Resultado do cálculo de confiabilidade da unidade de chaveamento com componentes
COTS, obtido no software Relex......................................................................................................103
Figura 48 – Resultado do cálculo de confiabilidade da redundância cold standby para o módulo da
CPU do computador de bordo com componentes COTS, obtido no software Relex.......................104
Figura 49 – Predição de confiabilidade da redundância cold standby para o módulo da CPU do
computador de bordo com componentes COTS...............................................................................105
x
Figura 50 – Resultado do cálculo de confiabilidade da redundância cold standby com a unidade
nominal do módulo da CPU com componentes COTS e as demais unidades com componentes de
aplicação espacial, obtido no software Relex. .................................................................................107
Figura 51 – Resultado do cálculo de confiabilidade da redundância cold standby com a unidade
nominal e redundante do módulo da CPU com componentes COTS e as demais unidades com
componentes de aplicação espacial, obtido no software Relex. ......................................................108
Figura 52 – Resultado do cálculo de confiabilidade da redundância cold standby com a unidade
redundante do módulo da CPU com componentes de aplicação espacial e as demais unidades com
componentes COTS, obtido no software Relex. ..............................................................................110
Figura 53 – Predição de confiabilidade da redundância cold standby para o módulo da CPU do
computador de bordo com componentes de aplicação espacial e COTS. ........................................111
Figura 54 – Curva da banheira [56]. ................................................................................................125
Figura 55 – Função R(t) e F(t) para λ = 1 falha / hora. ....................................................................126
Figura 56 – Sistema com associação em série [50]. ........................................................................131
Figura 57 – Sistema com associação em paralelo [50]. ...................................................................132
Figura 58 – Função RS(t) para n componentes associados em paralelo [58]. ..................................133
Figura 59 – Sistema com associação em standby: a) interface de entrada e saída e alimentação
chaveada, b) interface de entrada e saída comum e alimentação chaveada [58]. ............................135
Figura 60 – Função RS(t) para n componentes associados em standby [58]....................................136
Figura 61 – Sistema com associação em standby com chaveamento imperfeito [50].....................137
Figura 62 – Exemplo de formato de uma planilha de FMEA [60]...................................................143
Figura 63 – Diagrama em blocos da arquitetura interna do processador ERC32 [49]. ...................144
Figura 64 – Diagrama em blocos da arquitetura interna do microcontrolador 80C32 [61].............146
xi
LISTA DE TABELAS
Tabela 1 – Confiabilidade dos equipamentos do subsistema ACDH do satélite universitário
ITASAT [27]......................................................................................................................................44
Tabela 2 – FMEA dos principais modos de falhas do módulo da CPU do computador de bordo.....59
Tabela 3 – Predição da taxa de falha do módulo da CPU do computador de bordo..........................62
Tabela 4 – Estados das chaves da unidade de chaveamento..............................................................82
Tabela 5 – Predição da taxa de falha da unidade de gerenciamento de redundância. .......................86
Tabela 6 – Predição da taxa de falha da unidade de chaveamento. ...................................................87
Tabela 7 – Predição de confiabilidade do Módulo da CPU do computador de bordo.......................93
Tabela 8 – Predição da taxa de falha do módulo da CPU do computador de bordo com componentes
COTS..................................................................................................................................................97
Tabela 9 – Predição da taxa de falha da unidade de gerenciamento de redundância com
componentes COTS............................................................................................................................98
Tabela 10 – Predição da taxa de falha da unidade de chaveamento com componentes COTS. ........99
Tabela 11 – Predição de confiabilidade do Módulo da CPU do computador de bordo com
componentes COTS..........................................................................................................................106
Tabela 12 – Síntese das predições de confiabilidade para o módulo da CPU do computador de bordo
do satélite universitário ITASAT.....................................................................................................112
Tabela 13 – Síntese dos tempos para as predições de confiabilidade do módulo da CPU do
computador de bordo que não atingiram o valor especificado de confiabilidade............................113
Tabela 14 – Síntese dos resultados obtidos pela aplicação da redundância cold standby. ..............114
Tabela 15 – Simbologia, nome e descrição para árvore de falhas [56] [46]....................................142
xii
LISTA DE ABREVIATURAS E SIGLAS
ACDH
Attitude Control and Data Handling
AOCS
Attitude and Orbit Control System
COTS
Commercial off-the-shelf
CPU
Central Processing Unit
DCS
Data Collection System
FDIR
Failure Detection, Isolation and Recovery
FMEA
Failure Modes and Effects Analysis
FMECA
Failure Modes, Effects and Criticality Analysis
FPGA
Field Programmable Gate Array
FTU
Fault Tolerant Unit
GPS
Global Positioning System
I/O
Input / Output
MEMS
Microelectromechanical Systems
MTTF
Mean Time to Failure
N
Nominal
OBC
On Board Computer
OBDH
On Board Data Handling
PCDU
Power Control and Distribution Unit
PDU
Power Distribution Unit
PSS
Power Supply Subsystem
R
Redundante
RBD
Reliability Block Diagram
RX
Receive Data
TC
Telecommand
TM
Telemetry
TX
Transmit Data
TT&C
Telemetry, Tracking and Command
λ
Taxa de Falha
xiii
SUMÁRIO
1. Introdução ..................................................................................................................................16
1.1 Motivação ...............................................................................................................................18
1.2 Objetivo ..................................................................................................................................20
1.3 Organização do trabalho.........................................................................................................20
2. Satélites .......................................................................................................................................22
2.1 Subsistemas ............................................................................................................................23
2.1.1 Estrutura ...........................................................................................................................23
2.1.2 Suprimento de energia .....................................................................................................24
2.1.3 Controle de órbita e atitude..............................................................................................24
2.1.4 Propulsão..........................................................................................................................25
2.1.5 Serviço de comunicação...................................................................................................25
2.1.6 Gestão de bordo ...............................................................................................................25
2.1.7 Controle térmico ..............................................................................................................26
2.1.8 Carga útil..........................................................................................................................27
2.2 Arquitetura do sistema computacional de um satélite ............................................................27
2.3 Principais satélites brasileiros.................................................................................................31
2.3.1 Arquitetura de hardware do sistema computacional .......................................................31
2.3.1.1 SCD...........................................................................................................................31
2.3.1.2 CBERS ......................................................................................................................32
2.3.1.3 SACI..........................................................................................................................33
2.4 ITASAT ..................................................................................................................................34
3. Requisitos do ITASAT e de seu computador de bordo ..........................................................36
3.1 Computador de bordo .............................................................................................................36
3.1.1 Requisitos funcionais .......................................................................................................37
3.1.1.1 Equipamento OBC ....................................................................................................38
3.1.2 Requisitos de desempenho ...............................................................................................38
3.1.3 Requisito de potência .......................................................................................................39
3.1.4 Requisitos de massa e volume .........................................................................................39
3.1.5 Modos operacionais .........................................................................................................40
3.1.6 Compatibilidade eletromagnética ....................................................................................41
3.2 Ambiente espacial...................................................................................................................42
xiv
3.2.1 Radiação...........................................................................................................................42
3.2.2 Térmico ............................................................................................................................43
3.2.3 Órbita ...............................................................................................................................43
3.3 Confiabilidade para o satélite ITASAT ..................................................................................44
4. Análise de confiabilidade de uma arquitetura de hardware para o computador de bordo 45
4.1 Análise funcional do satélite universitário ITASAT ..............................................................45
4.2 Arquitetura de hardware para o computador de bordo ..........................................................47
4.2.1 Análise de árvore de falhas do computador de bordo......................................................54
4.2.2 FMEA para o módulo da CPU .........................................................................................59
4.2.3 Predição da taxa de falha do módulo da CPU..................................................................61
4.2.4 Predição de confiabilidade do módulo da CPU ...............................................................63
5. Proposta de melhoria de confiabilidade do módulo da CPU do computador de bordo......65
5.1 Redundância de hardware aplicada ao módulo da CPU ........................................................65
5.1.1 Unidade de gerenciamento de redundância .....................................................................69
5.1.1.1 Detecção de falhas pelo canal serial .........................................................................71
5.1.1.2 Detecção de falhas por sensores redundantes ...........................................................72
5.1.1.3 Detecção de falhas por monitoramento do processador............................................73
5.1.1.4 Memória compartilhada para variáveis de redundância ...........................................74
5.1.1.5 Isolação de falha pelo gerenciador de redundância ..................................................76
5.1.1.6 Reconfiguração a partir de falhas..............................................................................78
5.1.2 Unidade de chaveamento .................................................................................................80
5.1.2.1 Detecção de falhas na unidade de gerenciamento de redundância ...........................83
5.2 Predição da taxa de falha ........................................................................................................85
5.3 Predição de confiabilidade......................................................................................................88
5.4 Análise por árvore de eventos ................................................................................................94
5.5 Redundância com componentes COTS...................................................................................96
5.5.1 Predição da taxa de falha .................................................................................................96
5.5.2 Predição de confiabilidade .............................................................................................100
5.6 Combinação com componente de aplicação espacial e COTS .............................................106
5.7 Discussão dos resultados ......................................................................................................112
6. Conclusão..................................................................................................................................114
Referências bibliográficas .............................................................................................................117
Apêndice A – Confiabilidade ........................................................................................................123
A.1 Fundamentos de confiabilidade ...........................................................................................123
xv
A.1.1 Definição...........................................................................................................................123
A.1.2 Parâmetro de confiabilidade..............................................................................................124
A.1.2.1 Função confiabilidade .................................................................................................125
A.1.3 Métodos para aumentar a confiabilidade ..........................................................................127
A.1.3.1 Redundância................................................................................................................127
A.1.3.1.1 Classificação da redundância .............................................................................128
A.1.3.2 Tolerância a falhas ......................................................................................................129
A.1.4 Confiabilidade de sistemas ...............................................................................................130
A.1.4.1 Diagrama de bloco de confiabilidade..........................................................................130
A.1.4.1.1 Sistema série ......................................................................................................130
A.1.4.1.2 Sistema paralelo .................................................................................................132
A.1.4.1.3 Sistema standby .................................................................................................134
A.1.5 Análise de modos de falhas e efeitos ................................................................................138
A.1.6 Análise de árvore de falhas ...............................................................................................138
A.1.7 Predição de confiabilidade para componentes eletrônicos ...............................................139
A.1.7.1 Método de cálculo.......................................................................................................141
Anexos .............................................................................................................................................142
A.1 Nomenclatura para árvore de falhas .....................................................................................142
A.2 Planilha para FMEA..............................................................................................................143
A.3 Descrição do processador ERC32 ........................................................................................144
A.4 Descrição do microcontrolador 80C32.................................................................................146
Glossário .........................................................................................................................................148
16
1. Introdução
Os satélites artificiais em órbita da Terra foram desenvolvidos pelo homem para
realizar missões. As principais finalidades das missões dos satélites estão relacionadas com o
segmento de telecomunicação, navegação, observação da Terra, científico ou militar.
Contudo, dividir os satélites de acordo com sua massa é uma forma de classificá-lo. Desta
forma, as classificações mais usuais são [1]:
•
satélite grande: maior que 1.000 kg;
•
satélite médio: entre 500 kg e 1.000 kg; e
•
satélite pequeno: menor que 500 kg.
Todavia, os satélites de pequeno porte podem ser subclassificados, também com
relação à sua massa, em:
•
mini-satélite: entre 100 kg e 500 kg;
•
micro-satélite: entre 10 kg e 100 kg;
•
nano-satélite: entre 1 kg e 10 kg;
•
pico-satélite: entre 0,1 kg e 1 kg; e
•
femto-satélite: menor que 100 g.
Dentre as subclasses de satélites de pequeno porte, a configuração de micro-satélite
vem se disseminando pelos projetos espaciais de interesse de universidades, corporações e
institutos governamentais. Esta configuração é encontrada, por exemplo, no MYRIADE [2] da
agência espacial francesa (CNES), no ILSE [3] da Universidade de Stuttgart, no HummerSat-1
[4] da Academia chinesa de Tecnologia Espacial (CAST), entre outros.
No desenvolvimento de um sistema computacional para o segmento espacial de um
satélite, é significativa a utilização de componentes especificados para o espaço, os quais
apresentam resistência à radiação e são conhecidos como Rad-Hard. No entanto, aliado a
17
fatores limitantes para redução de custos num projeto espacial, a utilização de componentes
militares qualificados, ou mesmo de componentes do tipo COTS – Commercial off-the-shelf,
são adotadas [5]. Em contrapartida, não há disponível dados de radiação de componentes do
tipo COTS, o que requer testes específicos de resistência para estes componentes antes de
serem colocados em órbita.
Por outro lado, projetos de baixo custo não descartam investimentos na confiabilidade
dos seus satélites, para se obter sucesso na missão, já que a confiabilidade é reconhecida como
um atributo crítico para sistemas espaciais [6]. Com efeito, o satélite universitário ITASAT se
enquadra na categoria de micro-satélite, aliado a níveis de confiabilidade para o bom
desempenho da missão determinada para dois anos.
Dentre os diversos equipamentos que compõem os subsistemas de um satélite, o
computador de bordo desempenha atividades vitais para o bom funcionamento da missão. No
ITASAT, o computador de bordo é caracterizado por reunir o controle de órbita e atitude e a
gestão de bordo do satélite num único computador. Por esta razão, o computador de bordo
deve ser altamente confiável a ponto de continuar a missão, mesmo que de forma degradada,
quando da ocorrência de uma falha.
A prática de aplicação de redundância no computador de bordo, para torná-lo tolerante
a falhas, é relativamente comum nos projetos espaciais, e ao mesmo tempo contribui
positivamente no aumento da confiabilidade (para mais detalhes, veja o Apêndice A.1). Isto
faz com que o item em desenvolvimento se torne uma unidade tolerante a falhas, FTU – Fault
Tolerant Unit. Diversos modos de tornar um item tolerante a falhas podem ser adotados nos
satélites, em especial no computador de bordo. Exemplo de aplicação de tolerância a falhas
pode ser evidenciado no satélite Hiten [7], do Instituto de Espaço e Ciência Astronáutica do
Japão, o qual aplica redundância tripla no subsistema e, a partir de um votador, realiza a
função de mascarar a falha ocorrida no módulo [8]. O Departamento de Pesquisa de Alta
18
Tecnologia e Programa de Desenvolvimento da China [9] propõe redundância dupla de
processadores interligados por um barramento, com uma unidade de controle central que
monitora a redundância; esta proposta utiliza-se de componentes do tipo COTS no projeto do
computador de bordo. E ainda, o Instituto de Tecnologia de Harbin [10] propõe redundância
de FPGA – Field Programmable Gate Array para o computador de bordo, podendo ser
utilizado na configuração ativa ou em standby, estando também os módulos interligados entre
si por uma interface serial para troca de dados de backup.
1.1 Motivação
Segundo estudos realizados em satélites civis e militares em órbita, de 1980 a 2005
foram identificadas falhas que discriminadas entre os subsistemas do satélite apresentam-se
conforme a Figura 1.
Figura 1 – Discriminação de falhas nos subsistemas do satélite [11].
A categoria “outros” reúne os subsistemas de estrutura, de carga útil e outros
subsistemas. O estudo também aponta os tipos de falhas ocorridas nos subsistemas OBDH –
On Board Data Handling e TT&C – Telemetry, Tracking and Command juntos, e mostra que
a maioria das falhas é de natureza elétrica, conforme ilustrado pela Figura 2.
19
Figura 2 – Ocorrência do tipo de falha nos subsistemas OBDH e TT&C [11].
Dentre os componentes envolvidos nos subsistemas OBDH e TT&C, as magnitudes
dos danos provocados pelas falhas nos componentes estão ilustradas na Figura 3.
Figura 3 – Impacto de falhas nos componentes dos subsistemas OBDH e TT&C [11].
Pelo gráfico da Figura 3, observa-se que o maior impacto de falhas reflete no
processador de controle, ou seja, no computador de bordo. Entretanto, um menor índice de
falhas registradas no subsistema OBDH é um indicativo de alta confiabilidade agregada.
Portanto, apresenta-se neste trabalho uma proposta de implementação de redundância
para o computador de bordo do satélite universitário ITASAT, visando os altos valores de
confiabilidade e ao mesmo tempo oferecer um comparativo de valores de confiabilidade entre
a utilização de componentes de aplicação espacial e componentes do tipo COTS.
20
1.2 Objetivo
Esta tese tem por objetivo apresentar uma proposta de arquitetura que visa o aumento
da confiabilidade do computador de bordo do satélite universitário ITASAT, implementando
redundância de hardware de forma a caracterizá-lo como uma unidade tolerante a falhas. Visa
também comparar valores de confiabilidade entre a utilização de componentes de aplicação
espacial e componentes COTS.
A partir de uma divisão modular e por análise de falhas do computador de bordo, uma
arquitetura de hardware restrita ao módulo da CPU é especificada e sua predição de
confiabilidade é estimada pelo uso de ferramenta computacional. Com efeito, na aplicação de
redundância ao módulo da CPU, unidades adicionais de chaveamento e de gerenciamento são
propostas e analisadas.
1.3 Organização do trabalho
Este trabalho está organizado em seis capítulos. O capítulo 2 apresenta uma breve
explicação sobre o satélite e seus subsistemas. Mostra as principais arquiteturas do sistema
computacional aplicado aos satélites, bem como as utilizadas nos satélites brasileiros,
concluindo com a definição do satélite universitário ITASAT. O capítulo 3 apresenta as
principais características funcionais e requisitos preliminares para o projeto do hardware do
computador de bordo do satélite universitário ITASAT. O capítulo 4 apresenta uma análise de
uma arquitetura de hardware para o computador de bordo e avalia as principais falhas
identificáveis neste equipamento, especificando e estimando a predição de confiabilidade de
um circuito elétrico para o módulo da CPU. O capítulo 5 apresenta uma proposta para
melhoria da confiabilidade do computador de bordo, aplicando redundância cold standby ao
21
módulo da CPU, tornando-o tolerante a falhas. Analisa o funcionamento das unidades
adicionais requeridas pela redundância e compara valores de confiabilidade caracterizados
pela utilização de componentes de aplicação espacial e componentes do tipo COTS. O
capítulo 6 apresenta as conclusões e sugere trabalhos futuros.
22
2. Satélites
Um satélite na visão de sistema completo pode ser composto basicamente por um
segmento solo e um segmento espacial. No segmento solo, estão presentes a estação de
recepção e transmissão, que tem como função a comunicação com o satélite, e o centro de
controle e comando, para análise de dados e a geração de telecomandos. No segmento
espacial, estão presentes a carga útil e a plataforma do satélite [12] [13]. A Figura 4 ilustra o
sistema completo de um satélite genérico com os principais segmentos.
Figura 4 – Sistema completo de um satélite genérico [12].
A operação do envio de uma telemetria pelo satélite (segmento espacial) para a estação
de controle (segmento solo) é denominada de downlink. A ordem, ou telecomando, que é
enviada da estação de controle (segmento solo) em direção ao satélite (segmento espacial) é
chamada de uplink [12]. A plataforma do satélite, juntamente com a carga útil, pode ser divida
em subsistemas para assegurar a sistematização dos requisitos de projeto, de montagem e de
testes [13]. Portanto, este capítulo primeiramente aborda os subsistemas que compõem o
segmento espacial e suas principais características. Na seqüência, são analisadas as principais
arquiteturas de hardware utilizadas no sistema computacional de um satélite. Posteriormente,
são relatados os principais satélites brasileiros com suas arquiteturas de hardware do sistema
23
computacional. Por fim, é definido o objetivo do satélite universitário ITASAT com suas
principais características.
2.1 Subsistemas
Os subsistemas reúnem os diversos equipamentos que compõem o segmento espacial e
podem ser classificados como: estrutura, suprimento de energia, controle de órbita e atitude,
propulsão, serviço de comunicação, gestão de bordo, controle térmico e cargas úteis [12]. A
Figura 5 ilustra os subsistemas que compõem o segmento espacial de um satélite genérico.
Figura 5 – Diagrama em blocos dos subsistemas de um satélite genérico.
2.1.1 Estrutura
O subsistema estrutura tem por finalidade prover suporte mecânico entre os diversos
equipamentos presentes nos subsistemas, e entre o satélite e o veículo lançador [14]. De modo
geral, as principais funções são mecânicas e geométricas. A mecânica suporta os esforços
durante o lançamento, o desacoplamento do veículo lançador e as operações de configuração
24
em órbita. A geométrica, além de fornecer uma interface de acoplamento com o veículo
lançador, disponibiliza a superfície de montagem para os equipamentos, que garanta a posição
precisa e a proteção contra radiação [12].
2.1.2 Suprimento de energia
O subsistema de suprimento de energia tem por finalidade gerar, armazenar,
condicionar e distribuir a energia elétrica para todos os equipamentos presentes nos
subsistemas do satélite [14]. Via de regra, a energia solar é convertida em energia elétrica por
painéis solares, para suprir as necessidades do satélite [12]. O suprimento de energia também
deve apresentar proteção do sistema contra um curto-circuito ou consumo excessivo por um
equipamento [15].
2.1.3 Controle de órbita e atitude
O controle de órbita e atitude tem como objetivo corrigir a posição do satélite no
espaço, estabilizando e orientando em uma direção desejada, mesmo na presença de
perturbações de torques externos agindo sobre o satélite [14]. Para orientar o satélite numa
direção, é necessário que existam a bordo meios de aplicar uma rotação no seu eixo, através
da ação de um torque. Um sistema básico de controle de órbita e atitude é composto por:
sensores, com a função de medir erros de atitude; computador, com a função de calcular ações
corretivas; e atuadores, com a função de aplicar as correções calculadas [12].
25
2.1.4 Propulsão
O subsistema de propulsão tem a função de manter a posição do satélite no espaço,
após seu lançamento, e de atuar na mudança de órbita [14]. Os subsistemas de controle de
órbita e atitude, de controle térmico e de estrutura, compõem as principais interfaces com o
subsistema de propulsão [12].
2.1.5 Serviço de comunicação
O subsistema de serviço de comunicação, também conhecido como TT&C –
Telemetry, Tracking and Command, é responsável pela telemetria, rastreio e comando do
satélite. Essas funções permitem a comunicação do satélite (segmento espacial) com o centro
de controle em solo [14]. O satélite envia para o centro de controle informações sobre seu
funcionamento, o que caracteriza uma telemetria. Além disso, o centro de controle envia
freqüentemente comandos para configuração das funções do satélite, o que caracteriza um
telecomando, ou simplesmente comando. Por fim, também é função do subsistema de serviço
de comunicação executar o rastreio do satélite, localizando-o no espaço. O rastreio consiste no
envio de um sinal ao satélite, que o retransmite ao centro de controle em solo, possibilitando
assim a determinação de sua localização [12].
2.1.6 Gestão de bordo
O subsistema de gestão de bordo tem como atividade supervisionar os equipamentos
presentes nos subsistemas do satélite, a partir de grupos de funções principais [12]:
26
•
controle do satélite: administra os modos de operação do satélite, comunicando ao
segmento solo quando da presença de falha num equipamento;
•
comunicação interna: provê interface entre os equipamentos e subsistemas do
satélite;
•
processamento de dados: recepção, decodificação e distribuição de comandos para
o subsistema e carga útil. Realiza a aquisição, formatação, armazenamento e
transmissão de dados de operações do satélite, denominados Housekeeping Data,
de missão ou de uso pelo computador de bordo, denominados Science Data [14].
Atua também no subsistema de controle de atitude quando um mesmo computador
de bordo é compartilhado com o subsistema de gestão de bordo.
O subsistema gestão de bordo realiza todas as funções apresentadas anteriormente por
intermédio de um computador de bordo. O volume e massa do subsistema gestão de bordo
estão diretamente proporcionais à complexidade do satélite. Preocupações com a
confiabilidade podem exigir redundância no subsistema, até mesmo dobrando o tamanho do
hardware [14].
2.1.7 Controle térmico
O subsistema controle térmico tem como objetivo manter todos os equipamentos do
satélite e a carga útil na faixa de temperatura para a qual foram projetados, durante a missão.
Dois limites são freqüentemente definidos: limite operacional, no qual o componente deve
permanecer enquanto estiver em operação; e o limite de sobrevivência, no qual o componente
deve permanecer durante todo o tempo, mesmo quando não alimentado [14].
27
O controle térmico aplicado ao satélite pode ser geralmente classificado como ativo e
passivo. O controle ativo requer o consumo de energia elétrica, ao contrário do controle
passivo, que não o requer para ser aplicado [16].
2.1.8 Carga útil
A carga útil, ou payload, é a combinação de hardware e software que interage com o
mundo exterior do satélite, para cumprimento dos objetivos da missão [14]. Dentre as diversas
missões, as cargas úteis mais freqüentes são de telecomunicação e de sensoriamento remoto,
entre outras [12]. Em suma, a carga útil é a razão fundamental para o lançamento do satélite.
2.2 Arquitetura do sistema computacional de um satélite
A arquitetura do sistema computacional de um satélite é definida de acordo com os
requisitos da missão e as necessidades operacionais [17]. A bordo do satélite, os
computadores se tornam uma parte integrante do sistema global, bem como fazendo parte da
maioria dos subsistemas [14]. As principais arquiteturas do sistema computacional de um
satélite são: centralizada, em anel, em barramento ou em barramento com processamento
distribuído.
A arquitetura centralizada, também denominada de estrela, apresenta interfaces pontoa-ponto entre as unidades de processamento e um único computador central. As principais
vantagens são: o bom funcionamento com poucas unidades, devido a todas as interfaces
estarem ligadas diretamente ao computador central; e ser altamente confiável pelo fato de que
uma falha numa interface não afeta a outra. As principais desvantagens são: necessidade de
mudança no hardware e no software do computador central para o acréscimo de uma nova
28
unidade; e uma grande quantidade de conexões entre o computador central e as unidades [14].
Geralmente, a arquitetura centralizada é utilizada em situações em que as unidades ou
subsistemas conectados ao computador central não possuem processadores [18].
A Figura 6 apresenta em diagrama em blocos a arquitetura centralizada para o sistema
computacional de um satélite, com os principais equipamentos.
Figura 6 – Arquitetura centralizada para o sistema computacional de um satélite [14].
A arquitetura em anel estabelece um caminho arbitrário para o controle de fluxo de
informação à medida que os dados são passados num padrão circular. Nesta configuração, os
pacotes de dados com a mesma informação passam uma única vez pelo ponto servidor e são
recebidos por vários clientes quase que simultaneamente [19]. As principais vantagens são:
menor número de conexões que podem ser distribuídas ao longo de toda a estrutura do
satélite; e mudanças limitadas para o processador central quando adicionadas novas unidades.
A principal desvantagem é por ser menos confiável pelo fato de cada unidade estar em linha e
assim requerer a transmissão para a próxima unidade [14]. Geralmente, a arquitetura em anel
é utilizada em situações em que as unidades ou subsistemas conectados ao anel possuem
processadores.
29
A Figura 7 apresenta em diagrama em blocos a arquitetura em anel distribuído para o
sistema computacional de um satélite, com os principais equipamentos.
Figura 7 – Arquitetura em anel distribuído para o sistema computacional de um satélite [14].
Num sistema computacional de um satélite, os diversos subsistemas devem comunicar
entre si, de forma que, uma possível implementação desta comunicação se faz pela utilização
de um barramento. Portanto, uma arquitetura em barramento é caracterizada por utilizar um
barramento de dados compartilhado entre os subsistemas [19] [14].
A arquitetura em barramento apresenta como vantagem a versatilidade, no qual,
definido um esquema de interconexão, novos dispositivos podem ser adicionados com
facilidade; e também pela simplicidade na distribuição do barramento, pois um único conjunto
de fios é compartilhado entre as várias unidades. A principal desvantagem de um barramento
é a limitação de comunicação, possivelmente restringindo o máximo de entrada/saída [19].
Como exemplo de interface de comunicação, o padrão MIL-STD-1553B é utilizado na
arquitetura em barramento de um sistema computacional de um satélite [14].
A Figura 8 apresenta em diagrama em blocos a arquitetura em barramento para o
sistema computacional de um satélite, com os principais equipamentos.
30
Figura 8 – Arquitetura em barramento para o sistema computacional de um satélite [14].
Uma variação da arquitetura em barramento é a utilização de múltiplos processadores
para execução dos softwares embarcados [14]. A Figura 9 apresenta em diagrama em blocos a
arquitetura em barramento com processamento distribuído para o sistema computacional de
um satélite, com os principais equipamentos.
Figura 9 – Arquitetura em barramento distribuído para o sistema computacional de um
satélite [14].
31
A arquitetura em barramento com processamento distribuído provê um alto nível de
redundância no sistema. Contudo, a concepção de um sistema computacional para aplicação
espacial procura otimizar a disponibilidade, a capacidade, a flexibilidade e a confiabilidade do
sistema, minimizando os custos e riscos da missão [14].
2.3 Principais satélites brasileiros
Os primeiros satélites desenvolvidos no Brasil foram os Satélites de Coleta de Dados
SCD-1 e 2, lançados, respectivamente, em 1993 e 1998 [20]. Na seqüência, o Satélite SinoBrasileiro de Recursos Terrestres, CBERS – China-Brazil Earth Resources Satellite, fruto de
um acordo de cooperação entre Brasil e China para desenvolvimento de satélites de
imageamento da Terra, resultaram no CBERS-1 lançado em 14 de outubro de 1999, e o
CBERS-2 lançado em 21 de outubro de 2003. Ainda em 19 de setembro de 2007 foi lançado o
CBERS-2B com algumas melhorias, comparado com os anteriores [21]. De carona com
CBERS-1, ocorreu o lançamento do Micro-satélite de Aplicações Científicas SACI-1, no
entanto, este satélite foi colocado em órbita, mas não funcionou [13].
2.3.1 Arquitetura de hardware do sistema computacional
2.3.1.1 SCD
A arquitetura do computador de bordo do SCD-1 foi baseada no PISB – Padrão INPE
de Supervisão de Bordo, o qual define um sistema computacional distribuído tolerante a
falhas onde as unidades de processamento são organizadas em níveis hierárquicos [22]. A
32
Figura 10 mostra a arquitetura do computador de bordo do satélite SCD-1, juntamente com as
unidades de decodificador de telecomando (TC) e codificador de telemetria (TM).
Figura 10 – Diagrama em blocos do computador de bordo do SCD-1 [22].
A Figura 10 ilustra a unidade UPC (Unidade de Processamento Central), a qual
supervisiona todo o sistema computacional e ainda se comunica com o segmento solo,
recebendo telecomandos e enviando telemetrias; e a unidade UPD/C (Unidade de
Processamento Distribuído/Central), que se apresenta como uma redundância para a unidade
UPC, além dos atributos de um processamento distribuído para os subsistemas do satélite
SCD-1 [22].
2.3.1.2 CBERS
A arquitetura de hardware do sistema computacional do CBERS, baseada no padrão
INPE de supervisão de bordo (PISB), foi organizada em OBDH – On Board Data Handling, e
AOCS – Attitude and Orbit Control System, interligadas por um barramento redundante
padrão MIL-STD-1553. O OBDH e AOCS são responsáveis respectivamente pela supervisão
do subsistema de bordo e pelo posicionamento do satélite [22]. A Figura 11 mostra a
arquitetura do sistema computacional adotada no satélite CBERS.
33
Figura 11 – Diagrama em blocos do sistema computacional do CBERS [22].
A Figura 11 ilustra a unidade CTU – Central Terminal Unit, correspondente à unidade
de processamento central (UPC); e as RTU – Remote Terminal Unit, correspondente à
unidade de processamento distribuído (UPD). As LTU – Local Terminal Unit, são ramos de
uma comunicação serial na topologia estrela com a AOCC – Attitude and Orbit Control
Computer [22].
2.3.1.3 SACI
A arquitetura do satélite SACI-1, na topologia em malha, é caracterizada por três
módulos de processamento e interfaces denominadas: SRI, usada na comunicação serial com
os experimentos; UAC, usada na geração de comandos e aquisição de telemetrias dos
subsistemas do satélite; e TC/TM, para comunicação com o segmento solo no recebimento de
telecomando e no envio de telemetria. A presença de uma chave em cada módulo, controlada
por um circuito cão-de-guarda do próprio módulo, possibilita uma degradação progressiva do
sistema na presença de falhas. Na medida em que a falha vai surgindo, a chave é acionada de
34
modo a anular o processamento do módulo [22]. A Figura 12 mostra a arquitetura do sistema
computacional adotada pelo satélite SACI-1.
Figura 12 – Diagrama em blocos do sistema computacional do SACI-1 [22].
2.4 ITASAT
O ITASAT é um projeto de desenvolvimento de um satélite tecnológico de pequeno
porte executado pelo Instituto Tecnológico de Aeronáutica – ITA (incluindo participação de
outras universidades públicas nacionais), sob consultoria técnica, de infra-estrutura
laboratorial e gestão financeira do Instituto Nacional de Pesquisas Espaciais – INPE, e
coordenação geral e patrocínio da Agência Espacial Brasileira – AEB [23].
O satélite universitário ITASAT carrega a bordo, como carga útil principal, um
transponder para transmissão de dados coletados pelas Plataformas de Coleta de Dados
(PCDs) distribuídas ao longo de todo o território nacional. Esta carga útil é uma atualização
da correspondente utilizada no Sistema de Coleta de Dados operado desde o SCD-1 e 2 [24].
Experimentos tecnológico-científicos compõem a missão.
35
A ser lançado como carga útil secundária (carona), com a finalidade de ser colocado
em baixa órbita, o satélite universitário ITASAT tem como características principais
apresentar-se com massa menor que 85 kg, dimensões de 70 x 60 x 40 cm e potência entre 80
e 100 W [23].
Outra característica do satélite universitário ITASAT é apresentar-se com o subsistema
de controle de órbita e atitude e o subsistema de gestão de bordo unificados em um único
computador, denominando-o assim de ACDH – Attitude, Control and Data Handling [25]. O
sistema computacional do ITASAT será arranjado numa arquitetura de hardware centralizada,
comunicando-se com os demais subsistemas e equipamentos a partir de uma interface serial
no padrão RS-422. Embarcado no computador de bordo, um sistema operacional de tempo
real fará o gerenciamento das rotinas atribuídas à missão [18].
36
3. Requisitos do ITASAT e de seu computador de bordo
Este capítulo reúne as características essenciais para o projeto do hardware do
computador de bordo do satélite universitário ITASAT, descrevendo as principais funções e
os requisitos preliminares para a missão. Entretanto, para um projeto espacial é necessário
conhecer as características ambientais às quais o satélite estará sujeito durante sua operação.
Por isto, os principais fatores ambientais como radiação, térmico e orbital serão sucintamente
apresentados. Tendo em vista que o satélite após ser lançado não possibilita condições de
manutenção, o sistema satélite deve ser confiável a ponto de satisfazer o período de vida útil
da missão. Com efeito, um índice de confiabilidade é atribuído ao segmento espacial e
distribuído entre os subsistemas do satélite. Índices de confiabilidade são então atribuídos
para os equipamentos pertencentes aos subsistemas do satélite universitário ITASAT.
3.1 Computador de bordo
O computador de bordo do satélite universitário ITASAT será denominado ACDH –
Attitude, Control and Data Handling, por reunir os subsistemas de controle de órbita e
atitude, conhecido como AOCS – Attitude and Orbit Control System, e o subsistema de gestão
de bordo, conhecido como OBDH – On Board Data Handling [26]. Portanto, o subsistema
ACDH do satélite universitário ITASAT deve apresentar como função básica a supervisão
dos equipamentos e subsistemas, bem como posicionar, estabilizar e orientar o satélite para
uma direção desejada. Um único computador de bordo modular deve ser adotado para o
subsistema ACDH e deve dispor interfaces para o equipamento de controle de atitude, para os
outros subsistemas e carga útil [27].
37
3.1.1 Requisitos funcionais
Os principais requisitos funcionais atribuídos ao subsistema ACDH do satélite
universitário ITASAT, relacionados à gestão de bordo, são [27]:
•
telecomando: deve prover a função de recepção de telecomandos recebidos pelo
subsistema TT&C e a função de distribuição desses comandos para os subsistemas
e carga útil do satélite;
•
telemetria: deve prover a função de aquisição de telemetrias dos subsistemas e
carga útil do satélite e a função de transmissão dessas telemetrias para o
subsistema TT&C;
•
on-board time: deve prover a função de geração e distribuição de base de tempo
para os subsistemas e carga útil do satélite, sincronizados com o segmento solo e
conforme o tempo universal;
•
gestão do satélite: deve prover função de gestão da memória de massa, controle
térmico, on/off da alimentação dos equipamentos e monitoramento da tensão de
barramento dos equipamentos;
•
interfaces de teste: deve prover interface para teste dos subsistemas durante as
fases de integração e lançamento.
Os principais requisitos funcionais atribuídos ao subsistema ACDH do satélite
universitário ITASAT, relacionados ao controle de atitude, são [27]:
•
controle de atitude com spin estabilizado [28]; e
•
aquisição e manutenção de uma atitude segura após a fase de lançamento ou após a
presença de uma falha em órbita.
38
3.1.1.1 Equipamento OBC
O subsistema ACDH contém um equipamento computador de bordo, chamado OBC –
On Board Computer. Os principais requisitos funcionais atribuídos ao OBC são [27]:
•
recursos para reconfiguração interna, após a instalação de uma falha, através do
mecanismo denominado de FDIR – Failure Detection, Isolation and Recovery;
•
capacidade de ser alimentado por linhas de potência independentes e nãoreguladas;
•
função de gerência de memória de massa;
•
recursos para teste dos equipamentos durante as fases de projeto;
•
capacidade de processamento para o controle de atitude;
•
interfaces com os atuadores e sensores do subsistema ACDH;
•
um programa de start-up que inicializa o computador de bordo para carregar e
executar um sistema operacional; e
•
um sistema operacional de tempo real onde serão implementados drivers de
software para todas as interfaces do computador de bordo.
3.1.2 Requisitos de desempenho
Os principais requisitos de desempenho atribuídos à unidade de processamento do
OBC são [27]:
•
capacidade de processamento: > 10 MIPs;
•
memória de start-up (PROM): > 64 kbytes;
•
memória de execução (RAM): > 4 Mbytes;
•
memória de escrita não-volátil (EEPROM): > 1 Mbytes;
39
•
taxa de dados de recepção de telecomandos: 20 kbits/s;
•
taxa de transmissão de telemetria: 200 kbits/s no modo nominal de operação e
25 kbits/s no modo seguro de operação;
•
precisão para on-board time: melhor que 1 ms; e
•
capacidade de memória de massa: 2 Gbits.
Os principais requisitos de interface de aquisição atribuídos ao computador de bordo
do satélite universitário ITASAT são [27]:
•
número de canais analógicos: > 88 (sendo a quantidade de 24 para termistores);
•
número de canais bilevel: > 64;
•
precisão de aquisição de canais analógicos: melhor ou igual a 8 bits;
•
precisão de aquisição de canais termistores: melhor ou igual a 8 bits;
•
taxa de aquisição de canais analógicos: maior que 4 Hz;
•
taxa de aquisição de canais bilevel: maior que 4 Hz; e
•
taxa de aquisição de canais termistores: maior que 2 Hz.
3.1.3 Requisito de potência
O OBC será alimentado por linhas de tensão não-regulada de valor igual a
28,5 ± 6,5 Vdc, e o consumo de potência máxima no modo de operação nominal deve ser de
18 W [27].
3.1.4 Requisitos de massa e volume
O OBC deve ser projetado para apresentar os seguintes parâmetros [27]:
40
•
massa igual a 7,5 kg; e
•
dimensões
de
300 x 200 x 200 mm
de
comprimento,
largura
e
altura
respectivamente.
3.1.5 Modos operacionais
O equipamento computador de bordo, assim como todo o satélite universitário
ITASAT, apresentará os seguintes modos de operação durante sua vida útil [29]:
•
modo desligado: o satélite estará completamente desenergizado;
•
modo de lançamento: usado na fase de lançamento, quando a alimentação é
permitida durante o lançamento e em testes intermediários para a integração do
satélite em solo. Este modo é atingido pela remoção de um alça de power on;
•
modo de integração e teste: usado em solo para testar e integrar os equipamentos
do satélite;
•
modo seguro: usado para colocar o satélite numa condição estável, com o mínimo
consumo de energia e capaz de receber comandos. Este modo é utilizado para a
aquisição de atitude inicial e em situações eventuais, após a detecção automática
de anomalias;
•
modo de aquisição de atitude: usado para adquirir a atitude do satélite antes do
modo nominal de operação. Este modo é alcançado a partir do modo seguro por
um comando do segmento solo;
•
modo nominal: todos os equipamentos do satélite, incluindo a carga útil, estão na
configuração de operação para a qual foram projetados.
A transição entre os modos de operação do ITASAT deve estar de acordo com o
diagrama da Figura 13:
41
Figura 13 – Modos de operação do satélite universitário ITASAT [18].
Pela Figura 13 observa-se que, após o modo de lançamento, a transição para o modo
seguro de operação se dá por intermédio de um telecomando (TC) ou pela detecção de falha,
resultado do mecanismo FDIR.
3.1.6 Compatibilidade eletromagnética
Embora assegurando a recepção e transmissão de sinais no satélite, correntes elétricas
podem induzir campo elétrico e magnético, que pode causar interferência no desempenho do
satélite. As antenas são os elementos mais simples do satélite sensíveis a interferências,
porque operam diretamente transformando campos eletromagnéticos em correntes elétricas e
vice-versa. O satélite universitário ITASAT requer compatibilidade eletromagnética
(Electromagnetic Compatibility – EMC) entre os vários equipamentos e subsistemas, para
garantir a menor interferência [30].
42
3.2 Ambiente espacial
3.2.1 Radiação
No ambiente espacial os componentes eletrônicos são afetados quanto ao seu
desempenho e tempo de vida, o que influencia a fase de projeto com aplicação de proteção
nos sistemas que resultam em alterações no seu tamanho, peso, complexidade e custo [14].
Em órbita, o satélite estará exposto a níveis de radiação que podem afetar diretamente
o funcionamento dos componentes eletrônicos. Dentre as radiações, o raio gama representa
um grave perigo, porque uma única partícula pode causar um defeito nos componentes
eletrônicos, tais como memória RAM, microprocessadores e transistores de potência. Quando
uma única partícula passa por um sistema causando mau funcionamento, é denominado efeito
de radiação single-event phenomena – SEP [14].
O single-event phenomena inclui três diferentes efeitos nos componentes eletrônicos
[14]:
•
single-event upset – SEU: também chamado de bitflip, não prejudica o
componente eletrônico, podendo até mesmo não interferir nas suas operações
subseqüentes;
•
single-event latch-up – SEL: prejudica a operação do componente, que deixa de
funcionar até que a alimentação seja desligada, e depois religada. Um tempo
excessivo neste estado pode danificar o componente eletrônico;
•
single-event burnout – SEB:
eletrônicos.
causa
falhas
permanentes
nos
componentes
43
Todos os componentes eletrônicos aplicados ao satélite universitário ITASAT devem
ser selecionados para sobreviver à radiação do ambiente espacial especificado para a vida útil
da missão [31].
3.2.2 Térmico
Em órbita, o satélite estará exposto a cargas térmicas internas e externas. As cargas
térmicas internas estão relacionadas à dissipação dos equipamentos. As cargas térmicas
externas apresentam-se como principais: a radiação solar direta, que é a maior fonte de
aquecimento do satélite; o albedo, que é o aquecimento causado pela radiação solar refletida
pela Terra; e a radiação infravermelha emitida pela Terra [16].
Todos os equipamentos dos subsistemas do satélite universitário ITASAT devem ser
projetados para operar na faixa de temperatura especificada. Para o computador de bordo é
especificada uma faixa de temperatura entre –10°C e +45°C [27].
3.2.3 Órbita
A órbita de um satélite está relacionada diretamente com sua atitude e apresenta
parâmetros como plano polar ou equatorial, inclinação e altitude. Pode ser classificada em
órbita baixa (Low-Earth Orbit – LEO), restrita entre os primeiros 200 km e 15.000 km, e
geossíncrona (Geosynchronous Earth Orbit – GEO), localizanda numa altitude próxima dos
36.000 km [32] [33].
O satélite universitário ITASAT enquadra-se na classificação de baixa órbita, LowEarth Orbit – LEO, com 750 km de altitude e inclinação de 25° em relação ao plano do
equador [28] [34].
44
3.3 Confiabilidade para o satélite ITASAT
Os subsistemas e equipamentos do satélite universitário ITASAT serão projetados para
atender os requisitos especificados de operação em órbita para um período de vida útil da
missão de dois anos, correspondente a 17.520 horas. Para todo o segmento espacial do
ITASAT será atribuído um valor de confiabilidade de 0,7, que não pode ser inferior durante o
período de vida útil da missão [35]. Contudo, na presença de todos os fatores de degradação
identificáveis, o subsistema ACDH deve ter uma probabilidade de sucesso de 0,9474 para a
vida útil especificada [27]. Os valores de confiabilidade dos equipamentos que compõem o
subsistema ACDH são mostrados na Tabela 1.
Tabela 1 – Confiabilidade dos equipamentos do subsistema ACDH do satélite universitário
ITASAT [27].
Equipamento
Confiabilidade
OBC
Magnetômetro
Sensor solar
Magneto-torque
Roda de Momento
0,9600
0,9950
0,9995
0,9995
0,9750 [26]
45
4. Análise de confiabilidade de uma arquitetura de hardware para o
computador de bordo
Este capítulo apresenta inicialmente uma análise funcional do satélite universitário
ITASAT, descrevendo seus principais subsistemas e funcionalidades. Na seqüência, são
identificados os módulos que sintetizam o equipamento computador de bordo do satélite
universitário ITASAT e uma análise de árvore de falhas, a FTA – Failure Tree Analysis, é
apresentada para cada módulo. Em particular, a partir das principais falhas identificáveis que
levariam à perda do computador de bordo, são estudados os modos de falhas dos componentes
eletrônicos do módulo da CPU com relação a suas causas e efeitos, aplicando uma FMEA –
Failure Modes and Effects Analysis. Por fim, é estimada a predição da taxa de falha e a
confiabilidade para o módulo da CPU do computador de bordo e os resultados obtidos são
comparados com os valores de confiabilidade especificados.
4.1 Análise funcional do satélite universitário ITASAT
Uma das principais características do segmento espacial do satélite universitário
ITASAT é ser ACDH – Attitude, Control and Data Handling, como descrito na seção 3.1 da
página 36. Portanto, a partir desta característica e tendo como base os subsistemas que
compõem o segmento espacial de um satélite genérico, como descrito na seção 2.1 da página
23, é possível organizar o segmento espacial do satélite universitário ITASAT em um
diagrama funcional. A Figura 14 ilustra o diagrama funcional dos subsistemas que compõem
o segmento espacial do satélite universitário ITASAT.
46
Figura 14 – Diagrama funcional do segmento espacial do satélite universitário ITASAT.
O diagrama funcional da Figura 14 mostra que o segmento espacial do satélite
universitário ITASAT é composto por cinco subsistemas, sendo eles:
•
TT&C (ou serviço de comunicação): responsável pela recepção de telecomando e
transmissão de telemetrias entre o segmento espacial e o segmento solo do
ITASAT;
•
ACDH: responsável pelo controle de atitude e por toda a gestão de bordo do
ITASAT, como também pelo processamento de controle térmico;
•
Payload (ou carga útil): corresponde aos experimentos tecnológico-científicos
embarcados no ITASAT, para serem executados durante missão;
•
Suprimento de energia: responsável por toda a energia elétrica disponível aos
equipamentos que compõem os subsistemas do ITASAT;
•
Coleta de dados: principal função da missão do satélite universitário ITASAT. É
composto por um transponder de coleta de dados para transmissão de dados
coletados pelas Plataformas de Coleta de Dados (PCD’s) [15].
Como descrito na seção 2.4 da página 34, o sistema computacional do satélite
universitário ITASAT apresentará arquitetura de hardware centralizada e a comunicação
entre os subsistemas e equipamentos será realizada a partir de uma interface serial no padrão
RS-422.
47
4.2 Arquitetura de hardware para o computador de bordo
O segmento espacial do satélite universitário ITASAT, denominado de ACDH, reúne
essencialmente o subsistema controle de órbita e atitude e o subsistema de gestão de bordo.
Para isto, o ACDH é composto por sensores, com a função de medir erros de atitude;
computador, com a função de calcular ações corretivas; e atuadores, com a função de aplicar
as correções calculadas, como descrito na seção 2.1.3 da página 24. O computador presente
no ACDH, também denominado de OBC – On Board Computer, além das funções de
controle de atitude e órbita, é o responsável pela gestão de bordo e controle térmico do
ITASAT. A Figura 15 ilustra o diagrama em blocos dos principais componentes que formam
o ACDH do satélite universitário ITASAT.
Figura 15 – Diagrama em blocos do ACDH para o satélite ITASAT [27].
Pelo diagrama em blocos da Figura 15, observa-se que basicamente o subsistema
ACDH é alimentado pelo subsistema de suprimento de energia, contém uma interface com o
subsistema TT&C e carga útil para troca de dados e apresenta um cordão umbilical, que é
uma conexão física para depuração do computador de bordo na fase de projeto. Contudo, suas
partes internas são constituídas pelos equipamentos [28]:
•
1 computador de bordo;
48
•
•
Sensores:
ƒ
1 magnetômetro;
ƒ
3 sensores solares;
Atuadores:
ƒ
1 magneto-torque; e
ƒ
1 roda de momento.
O computador de bordo, como parte integrante do subsistema ACDH e com suas
inúmeras funções dentro do segmento espacial do ITASAT, foi dividido em módulos com o
objetivo de facilitar e detalhar o projeto de hardware [37]. A Figura 16 ilustra o diagrama em
blocos do computador de bordo do satélite universitário ITASAT com os módulos que o
compõem.
Figura 16 – Diagrama em blocos do computador de bordo para o ACDH.
Pelo diagrama em blocos da Figura 16, observa-se que o equipamento computador de
bordo do ITASAT é baseado numa arquitetura centralizada, composto por quatro módulos
que se apresentam como:
•
módulo de comunicação: com as funções de decodificação de telecomando e
codificação de telemetria, entre computador de bordo e o subsistema TT&C;
49
•
módulo condicionador de energia: com a função de conversão da tensão
proveniente do subsistema de suprimento de energia para o uso interno do
computador de bordo;
•
módulo de I/O: com as funções de condicionar sinais de sensores e atuadores,
aquisição de telemetrias e distribuição de telecomandos por todo o satélite; e
•
módulo da CPU: com as funções de processamento do controle de órbita e atitude,
gestão de bordo e controle térmico, além de armazenamento de dados, entre outras
funções pertinentes.
O módulo de comunicação do computador de bordo proporciona interface entre o
computador e o subsistema de TT&C, responsável pela recepção de telecomando e a
transmissão de telemetria entre o segmento solo e o segmento espacial. O diagrama em blocos
da Figura 17 ilustra os principais componentes eletrônicos que compõem o módulo de
comunicação.
Figura 17 – Diagrama em blocos do módulo de comunicação para o computador de bordo.
50
O subsistema TT&C apresentará dois equipamentos transceivers de comunicação
redundante, operados na configuração standby, para se comunicar com o segmento solo [18].
A interface de dados do transceiver é no padrão serial RS-422, e isto requer no módulo de
comunicação a mesma interface para se comunicar com este equipamento. Os pacotes de
dados de telecomando e telemetria que trafegam entre o subsistema TT&C e módulo de
comunicação são respectivamente decodificados e codificados por um FPGA, localizado no
próprio módulo de comunicação. Por fim, os pacotes que trafegam entre o módulo de
comunicação e o módulo da CPU, dentro do computador de bordo, também utilizarão do
padrão serial RS-422, como mostrado na Figura 17.
O subsistema de suprimento de energia deve fornecer tensão de 28,5 ± 6,5 Vdc para
todos os subsistemas e equipamentos do satélite universitário ITASAT. Cada subsistema
deverá condicionar esta tensão para os níveis requeridos por seus equipamentos. O módulo
condicionador de energia para o computador de bordo, com os principais componentes
eletrônicos, é ilustrado pelo diagrama em blocos da Figura 18.
Figura 18 – Diagrama em blocos do módulo condicionador de energia para o computador de
bordo.
Pela Figura 18, observa-se que o módulo condicionador de energia recebe a tensão de
28,5 ± 6,5 Vdc do subsistema de suprimento de energia, converte este valor através de
51
reguladores de tensão e distribui aos demais módulos do computador de bordo níveis de
tensão nos valores de 12 V, 5 V, 3,3 V e 1,2 V. Para cada nível de tensão disponível haverá
um circuito de proteção contra sobrecorrente com a finalidade de assegurar a integridade dos
módulos contra o SEL.
O computador de bordo deve proporcionar interface com os sensores do controle de
atitude, sensor solar e magnetômetro; com os atuadores, magneto-torque e roda de momento;
com os diversos termistores do controle térmico; com as diversas telemetrias provenientes dos
subsistemas e equipamentos do ITASAT, seja de natureza analógica ou digital; e com os
telecomandos destinados aos subsistemas e equipamentos do ITASAT. Todas essas interfaces
estarão reunidas no computador de bordo pelo módulo de I/O, que apresentará também a
função de condicionar os sinais de entrada e saída pertinentes. A Figura 19 ilustra o diagrama
em blocos dos principais componentes que compõem o módulo de I/O do computador de
bordo do satélite universitário ITASAT.
Figura 19 – Diagrama em blocos do módulo de I/O para o computador de bordo.
52
A Figura 19 mostra os diversos sensores, atuadores, sinais de telemetria e telecomando
localizados no módulo de I/O, que serão monitorados pelo módulo da CPU do computador de
bordo. Arranjos de conversores analógico/digital e digital/analógico, multiplexadores
analógicos e drivers compõem os componentes essenciais do módulo de I/O.
O módulo da CPU é a parte do equipamento computador de bordo que contém o
processador, memória de programa, memória de dados, circuito de clock, circuito de reset e
decodificador de endereços. Além dos componentes essenciais que compõem um sistema
computacional, o módulo da CPU também apresenta um circuito de watchdog timer (cão-deguarda) externo, um canal serial de interfaces com módulo de comunicação do computador de
bordo e os subsistemas do ITASAT, buffer e latch de interface com o módulo de I/O. A
Figura 20 ilustra o diagrama em blocos do módulo da CPU para o computador de bordo do
satélite universitário ITASAT.
Pela Figura 20, observam-se as conexões externas do módulo da CPU, definidas por:
alimentação proveniente do módulo condicionador de energia; buffer e latch interfaceando o
barramento de dados e endereços do processador com os itens pertencentes ao módulo de I/O;
e comunicação serial com o módulo de comunicação, com as cargas úteis e com o cordão
umbilical, conexão que proporciona a depuração do computador de bordo nas fases de
projeto. A presença do bloco nomeado de canal serial tem por objetivo multiplexar os pinos
TX e RX do processador para os drivers e receivers de linha padrão serial RS-422, destinados
a cada ponto de comunicação.
53
Figura 20 – Diagrama em blocos do módulo da CPU para o computador de bordo.
Também pela Figura 20, observa-se o circuito de watchdog timer, também
denominado de circuito cão-de-guarda, que tem a função de analisar o comportamento do
processador e o reconduzir a um estado de normalidade caso uma anomalia seja detectada.
Este procedimento é realizado por pulsos provenientes do próprio processador que reiniciam a
contagem de um contador presente no circuito de watchdog timer; caso contrário, o contador
não sendo reiniciado, o circuito de reset é solicitado, reiniciando o processador [38]. Por fim,
um ponto relevante para o computador de bordo, pré-definido pelos idealizadores do projeto
do satélite universitário ITASAT, é a utilização do processador ERC32 da Atmel® (para mais
54
detalhes, veja o Anexo A.3). Entre as funcionalidades do processador ERC32, inclui-se a
EDAC – Error Detection And Correction, que detecta qualquer erro de bit simples ou duplo
no barramento de dados de 32 bits e os corrige automaticamente [49]. A finalidade da EDAC
é assegurar a integridade dos dados armazenados nas memórias contra o SEU [9].
4.2.1 Análise de árvore de falhas do computador de bordo
Uma falha em um dos módulos do equipamento computador de bordo pode se
propagar de tal forma que o satélite deixe de operar corretamente [39]. Por isso, tendo como
base os diagramas em blocos do computador de bordo mostrados na seção 4.2 da página 47 e
os principais componentes que compõem cada módulo, é possível levantar as principais falhas
identificáveis que levariam à perda do computador de bordo do satélite universitário ITASAT,
aplicando aos subsistemas a análise de árvore de falhas ou FTA – Failure Tree Analysis [36].
(para mais detalhes, veja o Apêndice A.1.6). As principais falhas e os eventos causadores da
perda do computador de bordo do ITASAT são mostrados na árvore da falhas da Figura 21.
Em análise à árvore de falhas da Figura 21, conclui-se que a perda do equipamento
computador de bordo poderá ocorrer caso se estabeleça a presença de um dos eventos: falha
no módulo de I/O, falha no módulo de comunicação, falha no módulo da CPU ou falha no
módulo condicionador de energia.
55
Figura 21 – Árvore de falhas da perda do computador de bordo do satélite universitário
ITASAT.
Os eventos mostrados na Figura 21 são agora apresentados a partir de eventos de
menor nível. Com efeito, o módulo de comunicação apresenta falha caso ocorra uma falha no
hardware ou no firmware embarcado na FPGA, responsável pela decodificação de
telecomando e codificação de telemetria. A Figura 22 ilustra a árvore de falhas dos principais
eventos que causariam falha no módulo de comunicação.
Figura 22 – Árvore de falhas para o módulo de comunicação do computador de bordo.
56
O módulo condicionador de energia responsável pela conversão dos 28,5 ± 6,5 Vdc,
fornecidos pelo subsistema de suprimento de energia, para níveis de tensão de uso interno do
equipamento computador de bordo, em essência, é composto por conversores de tensão e
circuitos de proteção contra sobrecorrente. A Figura 23 ilustra a árvore de falhas dos
principais eventos que causariam falha no módulo condicionador de energia.
Figura 23 – Árvore de falhas para o módulo condicionador de energia do computador de
bordo.
O módulo de I/O com a função de aquisição de telemetria, distribuição de
telecomando e condicionador de sinal dos inúmeros sensores e atuadores presentes no satélite,
apresentará falha caso uma destas funções venha a falhar. A Figura 24 ilustra a árvore de
falhas dos principais eventos que causariam falha no módulo de I/O.
57
Figura 24 – Árvore de falhas para o módulo de I/O do computador de bordo.
O módulo da CPU com as principais funções de processamento de controle de órbita e
atitude, gestão de bordo, controle térmico e armazenamento de dados, apresentará falha caso
seja detectada uma falha no hardware ou no seu firmware embarcado. A Figura 25 ilustra a
árvore de falhas dos principais eventos que causariam falha no módulo da CPU.
Pela Figura 25, conclui-se que uma falha no hardware do módulo da CPU está
diretamente relacionada à falha no processador ou em seus periféricos. Com efeito, uma falha
no módulo da CPU poderá se propagar nas funções de processamento do controle de órbita e
atitude, nas funções de gestão de bordo do satélite, no processamento do controle térmico ou
até mesmo no armazenamento de dados do satélite, impactando diretamente nas atividades
fundamentais para execução da missão atribuída ao satélite universitário ITASAT.
58
Figura 25 – Árvore de falhas para o módulo da CPU do computador de bordo.
As análises de árvores de falha abordadas nesta seção sugerem a implementação no
computador de bordo do satélite universitário ITASAT de um conjunto de mecanismos para
detectar, isolar e se reconfigurar na presença de uma falha. Este conjunto de mecanismos é
denominado de FDIR – Failure Detection, Isolation and Recovery, que tem como principal
objetivo proteger a integridade de um sistema, evitando a perda de suas partes ou totalidade,
de forma a assegurar o desempenho da missão durante sua vida útil [36].
Como parte do escopo deste trabalho, o módulo da CPU do computador de bordo do
satélite universitário ITASAT será abordado nas próximas seções, analisado os modos de
falhas atrelados às suas causas e efeitos e concluindo com a predição de taxa de falha e
confiabilidade. Os módulos de comunicação, condicionador de energia e de I/O, que fazem
parte do computador de bordo do satélite universitário ITASAT, não serão considerados neste
estudo de confiabilidade. Futuros trabalhos poderão abordar esta questão.
59
4.2.2 FMEA para o módulo da CPU
Caracterizadas as principais falhas identificáveis que levariam à perda do computador
de bordo do satélite universitário ITASAT na seção 4.2.1, os modos de falhas dos
componentes eletrônicos do módulo da CPU foram estudados com relação às suas causas e
efeitos, aplicando-se a análise de modos de falhas e efeitos denominada de FMEA – Failure
Modes and Effects Analysis [36] (para mais detalhes, veja o Apêndice A.1.5).
Em análise ao diagrama em blocos do módulo da CPU do computador de bordo da
Figura 20 da página 53, conclui-se que os principais componentes eletrônicos envolvidos são
oriundos de circuitos lógicos digitais, e em média aproximada, os principais modos de falhas
destes componentes são: 80 % fixam as saídas em nível lógico alto ou baixo e 20 % não
realizam nenhuma função [40]. A partir disto, as causas e efeitos de cada modo de falha dos
principais componentes do módulo da CPU do computador de bordo do satélite universitário
ITASAT são mostradas na FMEA da Tabela 2 [40] [41] [42].
Tabela 2 – FMEA dos principais modos de falhas do módulo da CPU do computador de
bordo.
Item
Modo de Falha
1
Driver ou receiver
do canal serial com
saída fixa ou
inoperante
2
Seleção inoperante
dos canais de
comunicação
seriais
Causa da Falha
Radiação
Interferência eletromagnética
Vibração
Temperatura
Defeito no componente eletrônico
Radiação
Interferência eletromagnética
Vibração
Temperatura
Defeito no componente eletrônico
Efeitos da Falha
Sem comunicação entre
processador e o módulo
de comunicação, o
payload e o cordão
umbilical
Processador não troca
comunicação entre o
módulo de comunicação,
o payload e o cordão
umbilical
60
3
4
5
6
7
8
9
10
11
Radiação
Interferência eletromagnética
Gerador de onda
quadrada com saída Vibração
fixa ou inoperante Temperatura
Defeito no componente eletrônico
Radiação
Contador do
Interferência eletromagnética
circuito de
watchdog timer
Vibração
com saída fixa ou Temperatura
inoperante
Defeito no componente eletrônico
Radiação
Interferência eletromagnética
Oscilador não
fornece a base de Vibração
tempo corretamente Temperatura
Defeito no componente eletrônico
Radiação
Interferência eletromagnética
Processador não
Vibração
executa tarefas
Temperatura
Defeito no componente eletrônico
Radiação
Memória de boot
Interferência eletromagnética
fornece dados
Vibração
corrompidos, ou
Temperatura
não permite leitura
Defeito no componente eletrônico
Radiação
Memória de
programa fornece Interferência eletromagnética
dados corrompidos, Vibração
ou não permite
Temperatura
leitura
Defeito no componente eletrônico
Memória de dados Radiação
Interferência eletromagnética
fornece dados
corrompidos, ou
Vibração
não permite leitura, Temperatura
ou gravação
Defeito no componente eletrônico
Memória de massa Radiação
Interferência eletromagnética
fornece dados
corrompidos, ou
Vibração
não permite leitura, Temperatura
ou gravação
Defeito no componente eletrônico
Radiação
Decodificador de
Interferência eletromagnética
endereços não
Vibração
habilita os
Temperatura
periféricos
Defeito no componente eletrônico
Contador do circuito de
watchdog timer (cão-deguarda) não executa a
contagem
Não retirada do
processador de um
possível estado de
anomalia
Processador não realiza
suas tarefas de maneira
sincronizada e com
velocidade
predeterminada
Todas as funções de
processamento pelo
computador de bordo
são afetadas
Processador não carrega
as instruções de
inicialização que deve
executar
Processador não carrega
as instruções que deve
executar
Processador não
armazena
temporariamente
informações
Processador não
armazena
temporariamente
informações de missão
Processador não
seleciona os periféricos
para realização de suas
tarefas
61
12
Radiação
Buffer ou latch com Interferência eletromagnética
saída fixa ou
Vibração
inoperante
Temperatura
Defeito no componente eletrônico
Processador não acessa
os sensores e os
atuadores para realização
de suas tarefas
Na Tabela 2, foram consideradas as principais causas de falhas potenciais no módulo
da CPU do computador de bordo, que são: radiação, interferência eletromagnética, vibração,
temperatura ou defeito no componente eletrônico, causas comuns a qualquer circuito que
utiliza semicondutores [43]. A análise de modos de falhas e efeitos abordados nesta seção
contribui para identificar os pontos críticos do módulo da CPU do computador de bordo do
satélite universitário ITASAT, com o objetivo de eliminar falhas, de mitigar ou controlar os
riscos inerentes [42].
4.2.3 Predição da taxa de falha do módulo da CPU
A predição da taxa de falha do módulo da CPU foi determinada a partir da norma
MIL-HDBK-217F – Reliability Prediction of Electronic Equipment, pelo método da análise
de esforços [44] (para mais detalhes, veja o Apêndice A.1.7).
A determinação da taxa de falha foi realizada com a utilização da ferramenta
computacional Relex Reliability Studio [45], com os seguintes parâmetros de configuração:
•
Modelo de cálculo: MIL-HDBK-217 FN2;
•
Temperatura: 45,0°C; e
•
Ambiente: “Space Flight”.
Para a predição da taxa de falha total do módulo da CPU, foi considerado que os
componentes pertencentes ao mesmo sistema estão na configuração série do ponto de vista da
confiabilidade, resultando na falha de todo o sistema quando falhar um componente [46]. Os
componentes eletrônicos abordados nesta seção são de aplicação espacial, e foram
62
especificados a partir das listas EPPL – European Preferred Parts List [47] e da NPSL –
NASA Parts Selection List [48]. A Tabela 3 lista os códigos dos componentes, com suas
respectivas taxas de falha em função das quantidades adotadas no circuito elétrico.
Tabela 3 – Predição da taxa de falha do módulo da CPU do computador de bordo.
Item
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
Componente
Código
Quantidade
Predição da
taxa de falha Nota
[Falhas / hora]
1,42365E-07
1
1,62037E-08
2
4,71993E-10
1
2,39010E-09
1
1,19505E-09
1
1,16004E-08
1
1,47944E-08
1
1,84109E-09
1
8,87663E-09
1
1,28893E-09
1
2,08333E-06
3
1,57740E-08
2
6,35214E-09
2
5,99395E-09
2
1,00702E-06
2
2,74627E-08
2
8,81880E-09
2
2,57645E-09
1
1,29464E-08
2
2,36654E-09
2
2,36654E-09
2
3,23488E-09
1
2,74684E-08
2
3,50470E-09
2
1,12710E-10
2
3,38691E-10
2
2,53597E-10
2
1,36000E-08
1
Diodo
1N5416
49
Conector de interface
MHD 300 44 30 121
1
Transistor NPN
2N2222AHR
1
Porta lógica Não E
M54HC00
2
Porta lógica OU
M54HC32
1
Decoder
M54HC138
9
Buffer 3-State
M54HC244
10
Multiplexer 3-State
M54HC251
2
Latch tipo D
M54HC373
6
Contador binário
M54HC4040
1
Processador
TSC695FL
1
Memória PROM
HS-6664RH
10
Memória EEPROM
MMEE085108045SXC
3
Capacitor cerâmico
M123A01BPB102%C
1
Capacitor cerâmico
M123A02BXC104KC
111
Capacitor cerâmico
M123A02BXB106KC
2
Capacitor cerâmico
M123A01BPC330%C
2
Latch endereçável
HCF4099B
2
Cristal de Quartzo
T1507
1
Driver RS-422
HS-26CT31RH
4
Receiver RS-422
HS-26CT32RH
4
Amplificador operacional
LM124AJRQMLV
1
Memória SRAM
MMSR16001604S-C
3
Memória SDRAM
MMSD08512808S-E
1
Resistor
RBR52%10001#&
4
Resistor
RBR52%100R0#&
7
Resistor
RBR52%10002#&
9
Placa de circuito impresso
4 camadas
1
Predição da taxa de falha
3,42454E-06
do módulo da CPU
Notas: 1. item cujo código do componente consta no banco de dados do software Relex [45].
2. item cujo código do componente não consta no banco de dados do software Relex.
Taxa de falha obtida por um componente, pertencente ao banco de dados do software
Relex [45], com característica análoga ao item.
3. Item cujo código do componente não consta no banco de dados do software Relex.
Taxa de falha obtida pela documentação do componente [49].
63
A taxa de falha determinada para o módulo da CPU foi de 3,42454E-06 falhas / hora
como mostrado na Tabela 3.
4.2.4 Predição de confiabilidade do módulo da CPU
A predição de confiabilidade para o satélite universitário ITASAT deve ser
determinada para o intervalo de tempo de 2 anos, correspondente a 17.520 horas, período
estimado para a vida útil da missão. Portanto, a predição de confiabilidade do módulo da CPU
foi calculada para este intervalo de tempo. Considerando a taxa de falha de 3,42454E-06
falhas / hora e um intervalo de tempo de 17.520 horas, para o módulo da CPU, aplica-se a
definição de sistema em série para o cálculo de confiabilidade (para mais detalhes, veja o
Apêndice A.1.4.1.1). A Figura 26 mostra o resultado do cálculo de confiabilidade para o
módulo da CPU, obtido no software Relex.
A Figura 26 mostra que o valor de confiabilidade do módulo da CPU num intervalo de
tempo de 17.520 horas é de 0,941766, sendo o MTTF de 292.009,8 horas. O valor de
confiabilidade obtido para o módulo da CPU do computador de bordo, com componentes de
aplicação espacial, não supera o valor especificado de 0,9600, como indicado pela Tabela 1 da
página 44. Entretanto, pelos dados intermediários de confiabilidade mostrados pela Figura 26,
observa-se que o valor de confiabilidade num intervalo de tempo de 11.680 horas,
correspondente a um ano e quatro meses, é 0,960791, o que atenderia ao valor especificado de
0,9600.
64
Figura 26 – Resultado do cálculo de confiabilidade do módulo da CPU obtido no software
Relex.
O resultado de confiabilidade obtido sugere a aplicação de técnicas para elevar a
confiabilidade e superar o valor especificado de 0,9600. Uma proposta para tal finalidade será
discutida no próximo capítulo.
65
5. Proposta de melhoria de confiabilidade do módulo da CPU do
computador de bordo
Após a análise de uma arquitetura de hardware para o computador de bordo do satélite
universitário ITASAT, abordada nas seções anteriores, este capítulo apresenta uma proposta
de melhoria de confiabilidade para o módulo da CPU, aplicando redundância em hardware.
Primeiramente é discutido o emprego da redundância cold standby no módulo da CPU e, em
seguida, são apresentadas as principais unidades envolvidas nesta redundância, denominadas
de unidade de gerenciamento de redundância e a unidade de chaveamento. Na seqüência, é
estimada a predição da taxa de falha e a confiabilidade da redundância aplicada ao módulo da
CPU utilizando componentes de aplicação espacial. Posteriormente, o mesmo procedimento é
adotado para estimar a predição da taxa de falha e confiabilidade para a redundância aplicada
ao módulo da CPU, porém utilizando componentes do tipo COTS. Por fim, é combinado
componente de aplicação espacial e do tipo COTS na redundância adotada ao módulo da CPU
do computador de bordo do satélite universitário ITASAT, concluindo com análises
comparativas dos resultados obtidos de confiabilidade.
5.1 Redundância de hardware aplicada ao módulo da CPU
Para aumentar o valor de confiabilidade, a técnica de redundância de hardware pode
ser adotada nos módulos que compõem o computador de bordo do satélite universitário
ITASAT (para mais detalhes, veja o Apêndice A.1.3). Dentre os módulos, este trabalho
abordará uma proposta de redundância de hardware para o módulo da CPU. Todavia,
trabalhos futuros poderão tratar da aplicação de redundância nos demais módulos do
computador de bordo, bem como aplicação de outras técnicas para aumentar a confiabilidade,
66
como por exemplo, a redundância de software, a aplicação de componentes com maior
confiabilidade individual ou a solicitação reduzida sobre componentes, entre outras [46].
O tipo de redundância de hardware escolhida para o módulo da CPU do computador
de bordo é a cold standby (para mais detalhes, veja o Apêndice A.1.4.1), pelo fato deste tipo
de redundância estar fundamentado em:
•
uma taxa de falha menor em relação à redundância ativa, pois componente
eletrônico no modo standby falha menos do que quando em operação [50];
•
um ganho de confiabilidade maior em relação à redundância ativa, já que o tempo
de operação do sistema em standby é menor, considerando que a unidade
redundante não venha a falhar durante o período de tempo em que permanecer
desenergizada [41]; e
•
um menor consumo de energia em relação à redundância ativa, necessário devido
as restrições no fornecimento de energia pelo subsistema de suprimento de energia
do satélite universitário ITASAT.
O valor de confiabilidade de um sistema está diretamente relacionado à quantidade de
componentes eletrônicos que o compõem, portanto, quanto menor for esta quantidade, maior
será, a influência positiva na confiabilidade [14]. Contudo, devido ao elevado número de
conexões elétricas entre os módulos do computador de bordo, o tipo de redundância
cold standby que mais favorece ao módulo da CPU é aquela na qual as interfaces de entrada e
saída das unidades redundantes já estão conectadas eletricamente. Sendo assim, apenas um
chaveamento da alimentação entre essas unidades redundantes resulta na troca de
operacionalidade entre elas (para mais detalhes, veja o Apêndice A.1.4.1.3).
Neste contexto, uma possível redundância cold standby para o hardware do módulo da
CPU do computador de bordo do satélite universitário ITASAT pode ser ilustrada pelo
diagrama de blocos da Figura 27 [51].
67
Figura 27 – Redundância cold standby para o módulo da CPU do computador de bordo.
Pela Figura 27, observa-se que a redundância de hardware proposta ao módulo da
CPU do computador de bordo é constituída por quatro itens principais:
•
unidade nominal do módulo da CPU;
•
unidade redundante do módulo da CPU;
•
unidade de gerenciamento de redundância; e
•
unidade de chaveamento.
As unidades nominal e redundante do módulo da CPU, apresentarão a mesma
característica elétrica e construtiva e serão consideradas com o mesmo tipo e quantidade de
componentes eletrônicos. As unidades de gerenciamento de redundância e de chaveamento
são incorporadas ao computador de bordo com a finalidade de viabilizar a redundância
cold standby.
A implementação de redundância ao módulo da CPU, além de aumentar a
confiabilidade, caracteriza-o como um sistema tolerante a falhas. Um sistema tolerante a
falhas é capaz de garantir a segurança deste sistema na presença de uma falha simples, num
período de tempo especificado [52]. Um conjunto de mecanismos com o objetivo de proteger
a integridade de um sistema evitando a perda de suas partes ou totalidade, de forma a
assegurar o desempenho da missão durante sua vida útil, é denominado de FDIR – Failure
68
Detection, Isolation and Recovery, o qual atribui a um sistema a capacidade de detectar, isolar
e se reconfigurar na presença de uma falha simples [36].
A detecção, isolação e reconfiguração de falhas nas unidades redundantes aplicada ao
módulo da CPU, como características do FDIR, requerem um dispositivo de monitoramento
da redundância, que por efeito comande o chaveamento operacional entre estas unidades em
caso de falha em uma delas [50]. Portanto, este dispositivo estará sintetizado nas unidades de
gerenciamento de redundância e chaveamento, incluídas ao computador de bordo do satélite
universitário ITASAT. O modo de monitoramento da redundância cold standby está
fundamentado nas funcionalidades atribuídas à missão do satélite, e pode apresentar-se como,
por exemplo:
•
executado pelo segmento solo: onde o monitoramento das unidades redundantes e
a decisão de executar o chaveamento em caso de falha são de responsabilidade do
segmento solo; ou
•
autônomo: onde o monitoramento das unidades redundantes e a decisão de
executar o chaveamento em caso de falha são gerenciados por uma unidade
autônoma embarcada no satélite.
Este trabalho, portanto, aborda um sistema autônomo embarcado no satélite
universitário ITASAT para o monitoramento e tomada de decisões para a redundância
cold standby proposta ao módulo da CPU do computador de bordo. No entanto, sua
característica de hardware permite, a partir de poucas alterações, modificar este modo de
monitoramento. Contudo, as características individuais das funcionalidades atribuídas à
unidade de gerenciamento de redundância e a unidade de chaveamento serão detalhadas nas
próximas seções.
69
5.1.1 Unidade de gerenciamento de redundância
A unidade de gerenciamento de redundância tem por função monitorar as atividades
das unidades redundantes do módulo da CPU do computador de bordo e tomar decisão
autônoma quando da detecção de falhas, comutando a operacionalidade para a unidade em
standby. A detecção de falhas requer independência das funções operacionais do satélite [52];
por esta razão, a unidade de gerenciamento de redundância não atuará em funções do satélite,
ficando restrita apenas às atribuições de monitoramento e tomada de decisão da redundância
cold standby aplicada ao módulo da CPU.
No contexto de um sistema FDIR, uma possível arquitetura para a unidade de
gerenciamento de redundância pode ser organizada em diagrama em blocos ilustrada pela
Figura 28.
Figura 28 – Diagrama em blocos da unidade de gerenciamento de redundância.
70
Pela Figura 28, observa-se que a unidade de gerenciamento de redundância é
caracterizada por uma plataforma processada, que por essência é composta por um
processador interligado ao circuito de reset, circuito de clock, memória de programa, memória
de dados e decodificador de endereços [53]. Além dos blocos que caracterizam um sistema
genérico com processador, a unidade de gerenciamento de redundância também apresenta um
circuito de watchdog timer (cão-de-guarda), um canal serial, uma memória compartilhada
entre a unidade nominal e redundante do módulo da CPU; e ainda, buffer de interface com o
módulo de I/O, sinais de status e comando da redundância. O processador utilizado na
unidade de gerenciamento de redundância, mostrado na Figura 28, é o 80C32 da Atmel® (para
mais detalhes, veja o Anexo A.4).
A plataforma processada proposta para a unidade de gerenciamento de redundância
proporciona a implementação de funcionalidades de detecção, isolação e reconfiguração,
como requerido para um sistema FDIR, para o módulo da CPU do computador de bordo em
caso de falha. Algumas das funcionalidades possíveis de serem implementadas na unidade de
gerenciamento de redundância são listadas a seguir:
•
monitoramento dos dados trafegados entre o módulo de comunicação e o módulo
da CPU pelo canal serial;
•
envio de parâmetros pelo canal serial para execução de rotinas de software, no
módulo da CPU, de detecção de falhas;
•
monitoramento de dados por sensores redundantes distribuídos pelo satélite,
disponíveis ao módulo da CPU pelo módulo de I/O [52];
•
monitoramento das unidades redundantes do módulo da CPU a partir de sinal de
status;
•
monitoramento do nível de tensão fornecido às unidades redundantes; e
71
•
monitoramento de dados de backup armazenados na memória compartilhada entre
as unidades redundantes do módulo da CPU, entre outros.
5.1.1.1 Detecção de falhas pelo canal serial
A interface de comunicação entre os subsistemas do satélite universitário ITASAT é
serial no padrão RS-422 [18]. Para monitoramento dos dados que trafegam pela interface
serial, a unidade de gerenciamento de redundância requer uma comunicação padrão RS-422.
A Figura 29 ilustra a solução adotada para interface de comunicação do canal serial da
unidade de gerenciamento de redundância.
Figura 29 – Canal serial da unidade de gerenciamento de redundância.
Pela Figura 29 pode ser observado que o processador da unidade de gerenciamento de
redundância faz comunicação com a unidade nominal e redundante do módulo da CPU, com o
módulo de comunicação e com um cordão umbilical. Portanto, o bloco canal serial tem por
função multiplexar o pino RX e demultiplexar o pino TX do processador para os drivers e
receivers de linha RS-422 em cada ponto da comunicação.
72
A interface de comunicação serial entre a unidade de gerenciamento de redundância e
a unidade nominal e redundante do módulo da CPU proporciona o monitoramento e a
detecção de falhas. Alguns destes monitoramentos poderão ser do tipo:
•
passagem de parâmetros: a unidade de gerenciamento envia um parâmetro à
unidade nominal (ou redundante) do módulo da CPU para que seja executado um
self test, e recebe o resultado para análise.
•
solicitação de telemetrias: a unidade de gerenciamento de redundância solicita à
unidade nominal (ou redundante) do módulo da CPU uma determinada telemetria
para ser comparada com a telemetria redundante, exclusiva à unidade de
gerenciamento de redundância;
•
solicitação log de status: a unidade de gerenciamento de redundância solicita à
unidade nominal (ou redundante) do módulo da CPU um log de status para
certificar o bom andamento das rotinas.
A unidade de gerenciamento de redundância apresenta uma interface serial com o
módulo de comunicação, que proporciona a recepção dos mesmos pacotes que chegam ao
módulo da CPU, o que oferece à unidade de gerenciamento de redundância a capacidade de
monitorar as tarefas solicitadas ao computador de bordo. Por fim, uma conexão entre o canal
serial e um cordão umbilical proporciona a depuração da unidade de gerenciamento de
redundância nas fases de projeto.
5.1.1.2 Detecção de falhas por sensores redundantes
Para detectar falha de telemetria destinada ao módulo da CPU, a unidade de
gerenciamento de redundância receberá telemetria de sensores redundantes distribuídos pelo
satélite. Os sensores redundantes destinados à unidade de gerenciamento de redundância
73
poderão ser de característica analógica, digital, termistores, ou ainda dos que compõem o
controle de atitude, como sensor solar ou magnetômetro. Assim como o módulo da CPU faz
interface com o módulo de I/O para receber telemetrias e enviar telecomando, a unidade de
gerenciamento de redundância também apresenta interface com o módulo de I/O.
Pelo diagrama em blocos da unidade de gerenciamento de redundância mostrado na
Figura 28 da página 69, observa-se que o processador disponibiliza buffers conectados ao seu
barramento de dados, para receber os dados de telemetria provenientes do módulo de I/O. Um
decodificador de endereços conectado ao barramento de endereços faz interface com o
módulo de I/O para selecionar o sensor a ser lido.
5.1.1.3 Detecção de falhas por monitoramento do processador
Uma funcionalidade atribuída à unidade de gerenciamento de redundância para
detectar anomalias no processador da unidade nominal (ou redundante) do módulo da CPU é
receber pulsos em intervalos de tempos predeterminados. Este sinal pode ser direcionado a
pinos dedicados no processador da unidade de gerenciamento de redundância reservados para
tal finalidade.
Pelo diagrama em blocos da unidade de gerenciamento de redundância mostrado na
Figura 28 da página 69, observa-se que o processador disponibiliza pinos dedicados para
recepção dos pulsos provenientes da unidade nominal e redundante do módulo da CPU do
computador de bordo. Como a unidade redundante do módulo da CPU estará desenergizada
durante a operacionalidade da unidade nominal, ela não enviará pulsos de status para a
unidade de gerenciamento de redundância neste intervalo. Para uma falha no processador da
unidade nominal que afete diretamente os pulsos de status destinados à unidade de
gerenciamento de redundância, ações serão ativadas para trocar a operacionalidade do
74
computador de bordo da unidade nominal para a unidade redundante do módulo da CPU. Para
isto, a unidade de gerenciamento de redundância enviará comandos para a unidade de
chaveamento, através das conexões mostradas na Figura 28 da página 69.
5.1.1.4 Memória compartilhada para variáveis de redundância
Dados de processo executado pela unidade nominal devem estar disponíveis para a
unidade redundante do módulo da CPU do computador de bordo, a partir do momento em que
for detectada uma falha na unidade nominal. O objetivo da disponibilização desses dados de
processo, aqui denominados de variáveis de redundância, é minimizar os efeitos sobre a
operacionalidade do satélite universitário ITASAT, causados por uma falha na unidade
nominal ou redundante do módulo da CPU [51]. Alguns exemplos de dados que devem estar
disponíveis são: variáveis atribuídas ao controle de atitude, log de status das cargas úteis,
necessidades específicas de outros subsistemas, entre outros. Portanto, uma solução para esta
disponibilidade de dados é armazenar estas variáveis de redundância numa memória
compartilhada entre as unidades nominal e redundante do módulo da CPU do computador de
bordo, localizada na unidade de gerenciamento de redundância, como mostrado na Figura 30.
A memória compartilhada é definida pelo fato de o barramento de endereços e de
dados serem compartilhados por dois ou mais processadores [19]. O conteúdo dos dados
armazenados na memória compartilhada pela unidade nominal do módulo da CPU do
computador de bordo é considerado backup de dados originais localizados na própria
estrutura de memória da unidade nominal. Num sistema com mais de um processador, como
no caso da redundância cold standby aplicada ao computador de bordo do satélite
universitário ITASAT, é possível o compartilhamento de uma única memória centralizada, no
qual esses processadores e a memória sejam interconectados por um barramento.
75
Figura 30 – Memória compartilhada centralizada, unidade de gerenciamento de redundância.
A memória compartilhada centralizada, mostrada na Figura 30, possui um único
barramento para conexão das linhas de endereços e de dados dos processadores das unidades
nominal e redundante do módulo da CPU e unidade de gerenciamento de redundância. Com a
finalidade de se evitar conflito entre os barramentos de endereços e dados dos três
processadores, buffers farão a proteção entre os barramentos de dados e endereços de cada
um. Um buffer unidirecional isola o barramento de endereços e um buffer bidirecional isola o
barramento de dados [54].
Estando a unidade nominal e redundante do módulo da CPU na configuração
cold standby, ou seja, energizadas em tempos diferentes, o acesso à memória compartilhada
centralizada por conseqüência também será em tempos diferentes, evitando assim conflitos
entre os barramentos de endereços ou de dados dessas duas unidades. Ao contrário da forma
com que a unidade nominal e redundante do módulo da CPU serão energizadas, a unidade de
gerenciamento de redundância estará em operação até o instante de tempo da detecção de uma
falha em seu funcionamento. Com isto, o acesso à memória compartilhada centralizada deve
76
apresentar técnicas de firmware para se evitar conflitos entre os barramentos de endereços e
de dados do módulo da CPU (nominal e redundante) e da unidade de gerenciamento de
redundância. Por exemplo, durante o intervalo de tempo sem falhas na unidade nominal, com
a unidade de gerenciamento de redundância operacional e a unidade redundante do módulo da
CPU em standby, a prioridade de acesso à memória compartilhada centralizada deverá ser da
unidade nominal do módulo da CPU. Isto se faz necessário devido à independência do
módulo da CPU em relação ao monitoramento da redundância [52]. Portanto, sinais de
controle deverão estar presentes entre os processadores das unidades nominal, redundante e
gerenciamento de redundância, para implementação de segurança contra conflitos de
barramentos.
Todo o conteúdo armazenado na memória compartilhada centralizada pela unidade
nominal (e redundante) do módulo da CPU estará disponível para a unidade de gerenciamento
de redundância para monitoramento, a qual certificará que os dados estão sendo armazenados
e que seu conteúdo não está danificado.
Considerando ainda uma circunstância de extrema degradação, com a presença de
falha dupla: unidade nominal e redundante do módulo da CPU, a unidade de gerenciamento
de redundância poderá enviar os dados armazenados na memória compartilhada centralizada
para o módulo de comunicação, para ser enviado ao segmento solo.
5.1.1.5 Isolação de falha pelo gerenciador de redundância
A unidade de gerenciamento de redundância fornece funções para isolar a unidade
redundante do módulo da CPU que falhar, para evitar a propagação de erro ou deterioração
dos equipamentos afetados [52]. Quando uma falha for detectada pela unidade de
gerenciamento de redundância, pelas técnicas descritas nas seções anteriores, haverá a troca
77
do módulo da CPU entre a unidade nominal e redundante. Este processo será executado com a
desenergização da unidade nominal e em seguida, a energização da unidade redundante do
módulo da CPU. Outras técnicas de detecção de falhas poderão ser implementadas em
trabalhos futuros, com a finalidade de isolar falhas pontuais dentro da unidade nominal e
redundante do módulo da CPU. No entanto, este trabalho considera que a presença de
qualquer falha simples na unidade nominal é suficiente para que haja a comutação da
operacionalidade para a unidade redundante do módulo da CPU.
Por exemplo, na condição de anomalia dos pulsos provenientes da unidade nominal do
módulo da CPU, a unidade de gerenciamento de redundância enviará um comando para a
unidade de chaveamento. A unidade de chaveamento, nesta condição, executa a
desenergização da unidade nominal e em seguida a energização da unidade redundante do
módulo da CPU do computador de bordo. O diagrama da Figura 31 ilustra a evolução no
tempo de uma falha detectada pela unidade de gerenciamento de redundância por não
recebimento de pulsos de status pela unidade nominal do módulo da CPU do computador de
bordo.
Figura 31 – Diagrama de tempo de pulsos de status da unidade nominal e redundante do
módulo da CPU destinados à unidade de gerenciamento de redundância.
78
O tempo t indicado no eixo horizontal dos diagramas da Figura 31 representa o
intervalo de tempo configurado na unidade de gerenciamento de redundância para
recebimento de pulsos de status, ora da unidade nominal, ora da unidade redundante do
módulo da CPU do computador de bordo.
5.1.1.6 Reconfiguração a partir de falhas
Caso as funções de detecção de falhas identifiquem uma anomalia na unidade nominal
do módulo da CPU, ações serão desencadeadas para recuperação da falha sem intervenção do
segmento solo [52]. Destaca-se que antes de a unidade de gerenciamento decidir em trocar a
unidade nominal pela unidade redundante, o dispositivo de proteção em hardware interno à
unidade, o watchdog timer, deverá atuar como medida corretiva. O não surgimento de efeito
satisfatório do reset imposto pelo circuito de watchdog timer, ao processador da unidade
nominal, é um dos fatores que contribui para o desencadeamento da troca pela unidade
redundante, sob comando da unidade de gerenciamento. Nesta circunstância, a primeira ação
será a desenergização da unidade nominal e a energização da unidade redundante do módulo
da CPU. A Figura 32 sintetiza os estados possíveis para as unidades nominal e redundante do
módulo da CPU do computador de bordo, durante a vida útil da missão do satélite
universitário ITASAT.
Da análise da Figura 32, pode-se concluir que a transição entre as unidades nominal e
redundante se faz de modo alternado, ou seja, mesmo na ocorrência de falhas transitórias,
ainda há a possibilidade de retomada da operacionalidade pela unidade que falhou. Por outro
lado, uma falha permanente descarta o retorno da unidade falha.
79
Figura 32 – Diagrama de estados das unidades redundantes do módulo da CPU.
Após a energização da unidade redundante do módulo da CPU do computador de
bordo, a segunda ação será a recuperação dos dados armazenados na memória compartilhada
centralizada. Estando desligada, a unidade redundante do módulo da CPU será energizada a
partir de um comando proveniente da unidade de gerenciamento de redundância. Ao ser
energizado, o módulo da CPU entra no estado de inicialização, como mostra o diagrama de
estados da Figura 32. No estado de inicialização, uma rotina de software leva o módulo da
CPU a recuperar os dados armazenados na memória compartilhada centralizada. Neste
instante, a unidade redundante terá acesso ao conteúdo armazenado como backup pela
unidade nominal do módulo da CPU do computador de bordo. Na seqüência, por rotina de
software, a unidade redundante do módulo da CPU é colocada no estado operacional; e assim,
direcionada para o modo seguro de operação, como descrito nos modos de operação do
satélite universitário ITASAT da Figura 13 da página 41.
Ocorrendo uma falha na unidade de gerenciamento de redundância, antes mesmo da
unidade nominal do módulo da CPU apresentar uma falha, o procedimento de inicialização da
80
unidade redundante do módulo da CPU será mantido. Dependendo da relevância da falha
ocorrida na unidade de gerenciamento, será possível recuperar os dados de backup
armazenados na memória compartilhada centralizada; ou sendo uma falha catastrófica, o
segmento solo deverá fornecer à unidade redundante os dados pertinentes à unidade nominal
anteriores à ocorrência da falha, minimizando assim os efeitos da troca de operacionalidade
entre as unidades redundantes.
5.1.2 Unidade de chaveamento
Uma importante característica da unidade de chaveamento, além de comutar a
alimentação entre as unidades redundantes do módulo da CPU, é apresentar alto nível de
confiabilidade dentro do sistema de redundância cold standby. A unidade de chaveamento
pode ser organizada em diagrama em blocos, ilustrado pela Figura 33.
Figura 33 – Diagrama em blocos da unidade de chaveamento.
81
A Figura 33 mostra que a unidade de chaveamento é composta por uma chave de dois
pólos, duas chaves de um pólo, um circuito de proteção, um bloco de controle de chave e
comandos provenientes da unidade de gerenciamento de redundância.
Em essência, a unidade de chaveamento recebe a energia elétrica proveniente do
módulo de condicionamento de energia do computador de bordo e redistribui à unidade
nominal e redundante do módulo da CPU e à unidade de gerenciamento de redundância. Para
redistribuição da alimentação, comandos provenientes da unidade de gerenciamento de
redundância atuam na unidade de chaveamento. A Figura 34 mostra o arranjo de chaves e os
sinais de controle para a redistribuição da alimentação pela unidade de chaveamento.
Figura 34 – Chaves e sinais de controle da unidade de chaveamento.
Na Figura 34, observa-se que o controle - 1 atua na chave de dois pólos, da qual
direciona a alimentação para a unidade nominal ou redundante do módulo da CPU do
computador de bordo. E o controle - 2 atua nas duas chaves de um pólo, as quais direcionam a
alimentação para a unidade de gerenciamento de redundância e também à unidade nominal do
módulo da CPU.
O controle - 1 provém do circuito de controle de chave da unidade de gerenciamento
de redundância, acionado pelo comando - 1, que tem como função comutar a alimentação
entre as unidades nominal e redundante do módulo da CPU. O controle - 2 provém do circuito
de proteção, que tem como função direcionar exclusivamente a alimentação para a unidade
redundante, caso uma falha seja detectada na unidade de gerenciamento de redundância.
82
Considerando que com nível lógico “0” o controle não atua na chave, mantendo seu estado
em repouso, e que com nível lógico “1” o controle atua na chave, mudando o estado, a Tabela
4 mostra os estados possíveis para o arranjo de chaves da Figura 34.
Tabela 4 – Estados das chaves da unidade de chaveamento.
Controle - 1
Controle - 2
0
1
0
0
0
1
Unidade de
gerenciamento de
redundância
Ligado
Ligado
Desligado
Unidade nominal
(módulo da CPU)
Unidade redundante
(módulo da CPU)
Desligado
Ligado
Desligado
Ligado
Desligado
Ligado
Pela Tabela 4, conclui-se que o controle - 1 atua na comutação da alimentação entre as
unidades nominal e redundante do módulo da CPU do computador de bordo, quando o
controle - 2 não estiver atuando. Quando o controle - 2 atuar, a condição de proteção é
estabelecida, sendo alimentada apenas a unidade redundante do módulo da CPU. Uma
possível solução para o circuito de controle de chave, que gera o controle - 1, é mostrada na
Figura 35.
Figura 35 – Circuito de controle de chave, unidade de chaveamento.
Pela Figura 35, observa-se que um circuito para o controle de chaves pode ser
composto por portas lógicas NAND, sendo as entradas o controle - 2, proveniente do circuito
de proteção e o comando - 1 proveniente da unidade de gerenciamento de redundância.
Através do comando - 1, a unidade de gerenciamento de redundância executa a troca entre o
83
nível lógico baixo e alto do controle - 1, isto reflete na comutação da alimentação entre as
unidades nominal e redundante do módulo da CPU do computador de bordo. O controle - 2
fixa o controle - 1 de saída em nível lógico baixo, resultando na alimentação apenas da
unidade redundante do módulo da CPU do computador de bordo.
5.1.2.1 Detecção de falhas na unidade de gerenciamento de redundância
A unidade de gerenciamento de redundância não está imune a falha, o que sugere
prever proteções durante sua operacionalidade. Uma proteção contra anomalias na unidade de
gerenciamento de redundância está presente na unidade de chaveamento. Da mesma forma
que a unidade nominal e redundante do módulo da CPU deve enviar pulsos de status para a
unidade de gerenciamento de redundância, esta deve fazer de forma análoga para com a
unidade de chaveamento. Uma possível solução para o circuito de proteção que gera o
controle - 2 indicado na Figura 34 da página 81, para o arranjo de chaves da unidade de
chaveamento, é mostrado na Figura 36.
Pela Figura 36, observa-se que um circuito de proteção pode ser composto por um
oscilador de onda quadrada e um contador binário, sendo a entrada o comando - 2 proveniente
da unidade de gerenciamento de redundância. A função do oscilador de onda quadrada é a
geração de clock para o contador binário. Na ausência de anomalias, a unidade de
gerenciamento de redundância deve enviar pulsos dentro de um intervalo de tempo
predeterminado, através do comando - 2, com o objetivo de reiniciar o contador binário. Caso
contrário, ocorrendo uma falha na unidade de gerenciamento de redundância, levando-o a um
estado de anomalia, o contador binário não será reiniciado. Como conseqüência, o controle - 2
será forçado ao nível lógico alto, fixando o controle - 1 da Figura 35, da página 82, em nível
lógico baixo. Este procedimento, adotado para energizar apenas a unidade redundante do
84
módulo da CPU do computador de bordo em caso de uma falha instalada na unidade de
gerenciamento de redundância, garante maior contribuição para a confiabilidade [50] do
computador de bordo.
Figura 36 – Circuito de proteção, unidade de chaveamento.
Outra proteção prevista para a unidade de gerenciamento de redundância refere-se à
implementação de um circuito de watchdog timer (cão-de-guarda) no seu processador [14]. A
Figura 37 ilustra a disposição do processador, do circuito de reset e do circuito de
watchdog timer para a unidade de gerenciamento de redundância.
85
Figura 37 – Circuito de watchdog timer para a unidade de gerenciamento de redundância.
O circuito de watchdog timer representado pela Figura 37 terá a função de retirar o
processador da unidade de gerenciamento de redundância de um estado de anomalia. Caso o
procedimento de proteção aplicada pelo circuito de watchdog timer não seja bem sucedido, o
circuito de proteção da unidade de chaveamento deverá atuar.
5.2 Predição da taxa de falha
As predições da taxa de falha da unidade de gerenciamento de redundância e da
unidade de chaveamento foram determinadas a partir da norma MIL-HDBK-217F –
Reliability Prediction of Electronic Equipment, pelo método da análise de esforços [44] (para
mais detalhes, veja o Apêndice A.1.7).
A determinação da taxa de falha foi realizada com a utilização da ferramenta
computacional Relex Reliability Studio [45], com os seguintes parâmetros de configuração:
86
•
Modelo de cálculo: MIL-HDBK-217 FN2;
•
Temperatura: 45,0°C; e
•
Ambiente: “Space Flight”.
Para a predição da taxa de falha total da unidade de gerenciamento de redundância e
da unidade de chaveamento, foram considerados que os componentes pertencentes ao mesmo
sistema estão na configuração série do ponto de vista da confiabilidade, resultando na falha de
todo o sistema quando falhar um componente [46]. Os componentes eletrônicos abordados
nesta seção são de aplicação espacial e foram especificados a partir da EPPL – European
Preferred Parts List [47] e da NPSL – NASA Parts Selection List [48]. A Tabela 5 lista os
códigos dos componentes utilizados na unidade de gerenciamento de redundância, com suas
respectivas taxas de falha em função das quantidades adotadas no circuito elétrico.
Tabela 5 – Predição da taxa de falha da unidade de gerenciamento de redundância.
Item
Componente
Código
Quantidade
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
Diodo
Conector de interface
Transistor NPN
Porta lógica Não E
Porta lógica Inversora
Porta lógica OU Exclusiva
Buffer 3-State
Decoder
Buffer 3-State
Transceiver 3-State
Multiplexer 3-State
Latch tipo D
Contador binário
Microcontrolador
Memória EEPROM
Capacitor cerâmico
Capacitor cerâmico
Capacitor cerâmico
Capacitor cerâmico
Latch endereçável
1N5416
MHD 300 44 30 121
2N2222AHR
M54HC00
M54HC04
M54HC86
M54HC125
M54HC138
M54HC244
M54HC245
M54HC251
M54HC373
M54HC4040
80C32E
3DEE1M08CS1193
M123A01BPB102%C
M123A02BXC104KC
M123A02BXB106KC
M123A01BPC330%C
HCF4099B
4
1
1
1
1
1
3
4
9
3
1
1
1
1
1
1
38
2
2
1
Predição da
taxa de falha
[Falhas / hora]
1,16216E-08
1,62037E-08
4,71993E-10
1,19505E-09
1,19505E-09
1,19505E-09
3,58515E-09
5,15573E-09
1,33149E-08
4,43832E-09
9,20546E-10
1,47944E-09
1,28893E-09
1,10374E-08
1,82220E-09
5,99395E-09
3,44744E-07
2,74627E-08
8,81880E-09
1,15113E-08
Nota
1
2
1
1
1
1
1
1
1
1
1
1
1
2
2
2
2
2
2
1
87
21
22
23
24
25
26
27
28
29
30
Cristal de Quartzo
CFPX-3750
1
1,28822E-09
2
Driver RS-422
HS-26CT31RH
2
1,18327E-09
2
Receiver RS-422
HS-26CT32RH
2
1,18327E-09
2
Amplificador operacional
LM124AJRQMLV
1
3,23488E-09
1
Memória SRAM
M65608E
2
1,72766E-08
2
Resistor
RBR52%10000#&
2
9,67690E-11
2
Resistor
RBR52%10001#&
2
5,63550E-11
2
Resistor
RBR52%100R0#&
3
1,45153E-10
2
Resistor
RBR52%10002#&
5
1,40887E-10
2
Placa de circuito impresso
4 camadas
1
1,36000E-08
1
Predição da taxa de falha
5,11661E-07
da unidade de gerenciamento de redundância
Notas: 1. item cujo código do componente consta no banco de dados do software Relex [45].
2. item cujo código do componente não consta no banco de dados do software Relex.
Taxa de falha obtida por um componente, pertencente ao banco de dados do software
Relex [45], com característica análoga ao item.
A taxa de falha determinada para a unidade de gerenciamento de redundância foi de
5,11661E-07 falhas / hora como mostrado na Tabela 5.
A Tabela 6 lista os códigos dos componentes utilizados na unidade de chaveamento,
com suas respectivas taxas de falha em função das quantidades adotadas no circuito elétrico.
Tabela 6 – Predição da taxa de falha da unidade de chaveamento.
Item
Componente
Código
Quantidade
1
2
3
4
5
6
7
8
9
10
11
12
Diodo
Conector de interface
Transistor NPN
Porta lógica Não E
Contador binário
Capacitor cerâmico
Capacitor cerâmico
Capacitor cerâmico
Amplificador operacional
Relé
Resistor
Resistor
1N5416
MHD 52 44 30 121
2N2222AHR
M54HC00
M54HC4040
M123A01BPB102%C
M123A02BXC104KC
M123A02BXB106KC
LM124AJRQMLV
317-200-E-P-5V
RBR52%10000#&
RLR05C5602%&
4
1
2
1
1
1
3
1
1
3
1
1
Predição da
taxa de falha
[Falhas / hora]
1,16216E-08
1,62037E-08
9,43986E-10
1,19505E-09
1,28893E-09
5,99395E-09
2,72166E-08
1,37313E-08
3,23488E-09
3,48000E-08
4,83840E-11
2,81770E-11
Nota
1
2
1
1
1
2
2
2
1
2
2
2
88
13
14
Resistor
RBR52%10002#&
6
1,69065E-10
2
Placa de circuito impresso
4 camadas
1
1,36000E-08
1
Predição da taxa de falha
1,30076E-07
da unidade de chaveamento
Notas: 1. item cujo código do componente consta no banco de dados do software Relex [45].
2. item cujo código do componente não consta no banco de dados do software Relex.
Taxa de falha obtida por um componente, pertencente ao banco de dados do software
Relex [45], com característica análoga ao item.
A taxa de falha determinada para a unidade de chaveamento foi de 1,30076E-07
falhas / hora como mostrado na Tabela 6.
5.3 Predição de confiabilidade
A predição de confiabilidade para o satélite universitário ITASAT deve ser
determinada para o intervalo de tempo de 2 anos, correspondente a 17.520 horas, período
estimado para a vida útil da missão. Portanto, as predições de confiabilidade da unidade de
gerenciamento de redundância e unidade de chaveamento foram calculadas para este intervalo
de tempo. Considerando a taxa de falha de 5,11661E-07 falhas / hora e um intervalo de tempo
de 17.520 horas, para a unidade de gerenciamento de redundância, aplica-se a definição de
sistema em série para o cálculo da confiabilidade (para mais detalhes, veja o Apêndice
A.1.4.1.1). A Figura 38 mostra o resultado do cálculo de confiabilidade para a unidade de
gerenciamento de redundância, obtido no software Relex.
89
Figura 38 – Resultado do cálculo de confiabilidade para a unidade de gerenciamento de
redundância, obtido no software Relex.
A Figura 38 mostra que o valor de confiabilidade da unidade de gerenciamento de
redundância num intervalo de tempo de 17.520 horas é de 0,991076, sendo o MTTF de
1.954.417,8 horas.
De forma análoga a unidade de gerenciamento de redundância, considerando a taxa de
falha de 1,30076E-07 falhas / hora e um intervalo de tempo de 17.520 horas, para a unidade
de chaveamento, aplica-se a definição de sistema em série para o cálculo da confiabilidade
(para mais detalhes, veja o Apêndice A.1.4.1.1). A Figura 39 mostra o resultado do cálculo de
confiabilidade para a unidade de chaveamento, obtido no software Relex.
A Figura 39 mostra que o valor de confiabilidade da unidade de chaveamento num
intervalo de tempo de 17.520 horas é de 0,997724, sendo o MTTF de 7.687.829,9 horas
90
Figura 39 – Resultado do cálculo de confiabilidade da unidade de chaveamento, obtido no
software Relex.
A partir dos valores de confiabilidade do módulo da CPU (mostrado na Figura 26 da
página 64), unidade de gerenciamento de redundância (mostrado na Figura 38) e unidade de
chaveamento (mostrado na Figura 39), é possível aplicar o diagrama de blocos de
confiabilidade, para determinar o valor de confiabilidade da redundância cold standby (para
mais detalhes, veja o Apêndice A.1.4.1). A Figura 40 mostra o diagrama de confiabilidade da
redundância cold standby proposta ao módulo da CPU do computador de bordo do satélite
universitário ITASAT.
91
Figura 40 – RBD da redundância cold standby para o Módulo da CPU do computador de
bordo.
Considerando para o diagrama de blocos da Figura 40 que a probabilidade de troca da
unidade nominal para a unidade redundante do módulo da CPU é igual a 1,0 (para mais
detalhes, veja o Apêndice A.1.4.1.3), juntamente com as taxas de falha de cada unidade e um
intervalo de tempo de 17.520 horas, calcula-se o valor de confiabilidade do arranjo. A Figura
41 mostra o resultado do cálculo de confiabilidade para o arranjo, obtido no software Relex.
A Figura 41 mostra que o valor de confiabilidade da redundância cold standby
proposta ao módulo da CPU do computador de bordo do satélite universitário ITASAT num
intervalo de tempo de 17.520 horas é de 0,987110, sendo o MTTF de 453.038,4 horas. O valor
de confiabilidade obtido para o módulo da CPU do computador de bordo com componentes
de aplicação espacial e com redundância cold standby supera o valor especificado de 0,9600,
como indicado pela Tabela 1 da página 44, ultrapassando com boa margem o valor de
0,941766 obtido para o módulo da CPU sem redundância, indicado na seção 4.2.4 da
página 63.
92
Figura 41 – Resultado do cálculo de confiabilidade da redundância cold standby para o
módulo da CPU do computador de bordo, obtido no software Relex.
Com base nos valores intermediários de confiabilidade para o módulo da CPU sem
redundância, mostrados na Figura 26 da página 64, e para o módulo da CPU com redundância
cold standby, mostrados na Figura 41, foi obtido o gráfico da Figura 42. As curvas levantadas
indicam as tendências dos valores de confiabilidade em intervalos de 1.460 horas,
correspondente a intervalos de 2 meses.
93
Figura 42 – Predição de confiabilidade da redundância cold standby para o módulo da CPU
do computador de bordo com componentes de aplicação espacial.
Pela Figura 42, é possível observar a influência positiva da aplicação da redundância
cold standby ao módulo da CPU do computador de bordo. Isto foi alcançado devido ao alto
valor de confiabilidade atribuído à unidade de chaveamento e unidade de gerenciamento de
redundância, em comparação ao módulo da CPU do computador de bordo. A predição de
confiabilidade da arquitetura analisada para o módulo da CPU do computador de bordo sem
redundância e com redundância cold standby estão sintetizadas na Tabela 7.
Tabela 7 – Predição de confiabilidade do Módulo da CPU do computador de bordo.
Redundância
cold standby
Sem
Com
Taxa de falha
[Falhas / hora]
3,42454E-06
8,35573E-07
MTTF
[horas]
292.009,8
453.038,4
Confiabilidade para
t = 17.520 horas
0,941766
0,987110
94
5.4 Análise por árvore de eventos
Caracterizadas as unidades que compõem a redundância cold standy e considerando o
diagrama de estados das unidades nominal e redundante da Figura 32 da página 79, para o
módulo da CPU do computador de bordo, é possível analisar as combinações de eventos
mutuamente exclusivos capazes de levar o sistema a falhar, aplicando a análise por árvore de
evento [46]. A Figura 43 mostra as combinações dos eventos que resultam em sucesso ou
falha da redundância cold standy para o módulo da CPU do computador de bordo no primeiro
ciclo de operação, ou seja, após ser energizado o sistema.
Figura 43 – Árvore de eventos da redundância cold standby para o módulo da CPU do
computador de bordo no primeiro ciclo de operação.
95
Por outro lado, é possível identificar as combinações dos eventos que resultam em
sucesso ou falha da redundância cold standy para o módulo da CPU do computador de bordo
depois do primeiro ciclo de operação do sistema. A Figura 44 mostra a árvore de eventos
considerando o sistema funcional a partir da unidade nominal do módulo da CPU.
Figura 44 – Árvore de eventos da redundância cold standby para o módulo da CPU do
computador de bordo depois do primeiro ciclo de operação.
Examinando as árvores de eventos da Figura 43 e Figura 44, observa-se que há trajetos
com os mesmos eventos que não resultam no mesmo sucesso ou falha, como é constatado nos
trajetos 6 e 13, 8 e 15, 13 e 6, e 15 e 8, respectivamente.
96
5.5 Redundância com componentes COTS
Todos os valores de confiabilidade obtidos nas seções anteriores foram determinados a
partir da utilização de componentes de aplicação espacial para o módulo da CPU do
computador de bordo do satélite universitário ITASAT. Contudo, esta seção leva em
consideração que os componentes utilizados são do tipo COTS – Commercial off-the-shelf, o
que a princípio reduz o custo de projeto, tamanho do equipamento e proporciona a
demonstração de novos conceitos com mais viabilidade, em comparação aos componentes de
aplicação espacial. Entretanto, recomenda-se a realização de testes de irradiação em solo para
cada componente COTS selecionado para uso no espaço, antes de ser colocado em órbita. Isto
reforça a garantia de sobrevivência do componente COTS no ambiente espacial, pois não há
dados de resistência à radiação disponíveis para estes componentes [5].
5.5.1 Predição da taxa de falha
Assim como para os componentes de aplicação espacial, a predição da taxa de falha do
componente COTS foi determinada a partir da norma MIL-HDBK-217F – Reliability
Prediction of Electronic Equipment, pelo método da análise de esforços [44] (para mais
detalhes, veja o Apêndice A.1.7).
A determinação da taxa de falha foi realizada com a utilização da ferramenta
computacional Relex Reliability Studio [45], com os seguintes parâmetros de configuração:
•
Modelo de cálculo: MIL-HDBK-217 FN2;
•
Temperatura: 45,0°C; e
•
Ambiente: “Space Flight”.
97
Para a predição da taxa de falha total, foi considerado que os componentes
pertencentes ao mesmo sistema estão na configuração série do ponto de vista da
confiabilidade, resultando na falha de todo o sistema quando falhar um componente [46]. A
Tabela 8 lista os códigos dos componentes para o módulo da CPU, com suas respectivas taxas
de falha em função das quantidades adotadas no circuito elétrico.
Tabela 8 – Predição da taxa de falha do módulo da CPU do computador de bordo com
componentes COTS.
Item
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
Componente
Código
Quantidade
Predição da
taxa de falha
[Falhas / hora]
3,26252E-07
3,24074E-08
1,08165E-09
9,56040E-08
4,78020E-08
4,64016E-07
5,91775E-07
7,36436E-08
3,55065E-07
5,15573E-08
2,08333E-06
6,30961E-07
2,54086E-07
1,99798E-08
3,35672E-06
9,15423E-08
2,93960E-08
1,03058E-07
2,71875E-08
3,78646E-07
1,29395E-07
1,09873E-06
1,40188E-07
3,75699E-08
1,12897E-07
8,45323E-08
2,72000E-08
Nota
Diodo
1N5416
49
1
Conector de interface
MHD 300 44 30 121
1
2
Transistor NPN
2N2222A
1
1
Porta lógica Não E
M54HC00
2
1
Porta lógica OU
M54HC32
1
1
Decoder
M54HC138
9
1
Buffer 3-State
M54HC244
10
1
Multiplexer 3-State
M54HC251
2
1
Latch tipo D
M54HC373
6
1
Contador binário
M54HC4040
1
1
Processador
TSC695FL-15MA
1
3
Memória PROM
HS-6664RH
10
2
Memória EEPROM
AS8E512K8
3
2
Capacitor cerâmico
08055A1R0CAT2A
1
2
Capacitor cerâmico
C0603C104J3RACTU
111
2
Capacitor cerâmico
TAJA106K010R
2
2
Capacitor cerâmico
06035A330JAT2A
2
2
Latch endereçável
CD4099B
2
1
Oscilador
SG-8002JF
1
2
Transceivers RS-422
ISL83080E
16
2
Amplificador operacional
LM124
1
1
Memória SRAM
CY62167DV30
3
2
Memória SDRAM
MT41J256M8
1
2
Resistor
MCR03EZPFX1002
4
2
Resistor
MCR10EZHF1000
7
2
Resistor
MCR03EZPFX1003
9
2
Placa de circuito impresso
4 camadas
1
1
Predição da taxa de falha
1,06446E-05
do módulo da CPU com componentes COTS
Notas: 1. item cujo código do componente consta no banco de dados do software Relex [45].
98
2. item cujo código do componente não consta no banco de dados do software Relex.
Taxa de falha obtida por um componente, pertencente ao banco de dados do software
Relex [45], com característica análoga ao item.
3. Item cujo código do componente não consta no banco de dados do software Relex.
Taxa de falha obtida pela documentação do componente [49].
A taxa de falha determinada para o módulo da CPU foi de 1,06446E-05 falhas / hora
como mostrado na Tabela 8.
A Tabela 9 lista os códigos dos componentes para a unidade de gerenciamento de
redundância, com suas respectivas taxas de falha em função das quantidades adotadas no
circuito elétrico.
Tabela 9 – Predição da taxa de falha da unidade de gerenciamento de redundância com
componentes COTS.
Item
Componente
Código
Quantidade
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
Diodo
Conector de interface
Transistor NPN
Porta lógica Não E
Porta lógica Inversora
Porta lógica OU Exclusiva
Buffer 3-State
Decoder
Buffer 3-State
Transceiver 3-State
Multiplexer 3-State
Latch tipo D
Contador binário
Microcontrolador
Memória EEPROM
Capacitor cerâmico
Capacitor cerâmico
Capacitor cerâmico
Capacitor cerâmico
Latch endereçável
Cristal de Quartzo
Transceivers RS-422
Amplificador operacional
1N5416
MHD 300 44 30 121
2N2222A
M54HC00
M54HC04
M54HC86
M54HC125
M54HC138
M54HC244
M54HC245
M54HC251
M54HC373
M54HC4040
80C32
AT28C010
08055A1R0CAT2A
C0603C104J3RACTU
TAJA106K010R
06035A330JAT2A
CD4099B
ECS-12-20-5PXDUTR
ISL83080E
LM124
4
1
1
1
1
1
3
4
9
3
1
1
1
1
1
1
38
2
2
1
1
8
1
Predição da
taxa de falha
[Falhas / hora]
2,66328E-08
3,24074E-08
1,08165E-09
4,78020E-08
4,78020E-08
4,78020E-08
1,43406E-07
2,06229E-07
5,32598E-07
1,77533E-07
3,68218E-08
5,91775E-08
5,15573E-08
4,41495E-07
7,28880E-08
1,99798E-08
1,14915E-06
9,15423E-08
2,93960E-08
2,41738E-08
5,15289E-08
1,89323E-07
1,29395E-07
Nota
1
2
1
1
1
1
1
1
1
1
1
1
1
2
2
2
2
2
2
1
2
2
1
99
24
25
26
27
28
29
Memória SRAM
BS62LV1024
2
6,91065E-07
2
Resistor
MCR03EZPFX1001
2
3,22562E-08
2
Resistor
MCR03EZPFX1002
2
1,87850E-08
2
Resistor
MCR10EZHF1000
3
4,83844E-08
2
Resistor
MCR03EZPFX1003
5
4,69624E-08
2
Placa de circuito impresso
4 camadas
1
2,72000E-08
1
Predição da taxa de falha
da unidade de gerenciamento de redundância com componentes
4,47437E-06
COTS
Notas: 1. item cujo código do componente consta no banco de dados do software Relex [45].
2. item cujo código do componente não consta no banco de dados do software Relex.
Taxa de falha obtida por um componente, pertencente ao banco de dados do software
Relex [45], com característica análoga ao item.
A taxa de falha determinada para a unidade de gerenciamento de redundância foi de
4,47437E-06 falhas / hora como mostrado na Tabela 9.
A Tabela 10 lista os códigos dos componentes para a unidade de chaveamento, com
suas respectivas taxas de falha em função das quantidades adotadas no circuito elétrico.
Tabela 10 – Predição da taxa de falha da unidade de chaveamento com componentes COTS.
Item
1
2
3
4
5
6
7
8
9
10
11
12
13
14
Componente
Código
Quantidade
Predição da
taxa de falha
[Falhas / hora]
2,66328E-08
3,24074E-08
2,16330E-09
4,78020E-08
5,15573E-08
1,99798E-08
9,07221E-08
4,57712E-08
1,29395E-07
6,61200E-08
1,61281E-08
9,39248E-09
5,63549E-08
2,72000E-08
Nota
Diodo
1N5416
4
1
Conector de interface
MHD 52 44 30 121
1
2
Transistor NPN
2N2222A
2
1
Porta lógica Não E
M54HC00
1
1
Contador binário
M54HC4040
1
1
Capacitor cerâmico
08055A1R0CAT2A
1
2
Capacitor cerâmico
C0603C104J3RACTU
3
2
Capacitor cerâmico
TAJA106K010R
1
2
Amplificador operacional
LM124A
1
1
Relé
AQZ200
3
2
Resistor
MCR03EZPFX1001
1
2
Resistor
MCR10EZHF5602
1
2
Resistor
MCR03EZPFX1003
6
2
Placa de circuito impresso
4 camadas
1
1
Predição da taxa de falha
6,21627E-07
da unidade de chaveamento com componentes COTS
Notas: 1. item cujo código do componente consta no banco de dados do software Relex [45].
100
2. item cujo código do componente não consta no banco de dados do software Relex.
Taxa de falha obtida por um componente, pertencente ao banco de dados do software
Relex [45], com característica análoga ao item.
A taxa de falha determinada para a unidade de chaveamento foi de 6,21627E-07
falhas / hora como mostrado na Tabela 10.
5.5.2 Predição de confiabilidade
Assim como para os componentes de aplicação espacial, a predição de confiabilidade
foi calculada para o intervalo de tempo de 2 anos, correspondente a 17.520 horas, período
estimado para a vida útil da missão. Considerando a taxa de falha de 1,06446E-05
falhas / hora e um intervalo de tempo de 17.520 horas, para o módulo da CPU, aplica-se a
definição de sistema em série para o cálculo de confiabilidade (para mais detalhes, veja o
Apêndice A.1.4.1.1). A Figura 45 mostra o resultado do cálculo de confiabilidade para o
módulo da CPU, obtido no software Relex.
A Figura 45 mostra que o valor de confiabilidade do módulo da CPU num intervalo de
tempo de 17.520 horas é de 0,829864, sendo o MTTF de 93.944,1 horas. O valor de
confiabilidade obtido para o módulo da CPU do computador de bordo, com componentes
COTS, não supera o valor especificado de 0,9600, como indicado pela Tabela 1 da página 44.
Entretanto, pelos dados intermediários de confiabilidade mostrados pela Figura 45, observa-se
que o valor de confiabilidade num intervalo de tempo de 2.920 horas, correspondente a quatro
meses, é 0,969396, o que atenderia ao valor especificado de 0,9600.
101
Figura 45 – Resultado do cálculo de confiabilidade do módulo da CPU com componentes
COTS, obtido no software Relex.
De forma análoga, considerando a taxa de falha de 4,47437E-06 falhas / hora e um
intervalo de tempo de 17.520 horas, para a unidade de gerenciamento de redundância, aplicase a definição de sistema em série para o cálculo de confiabilidade (para mais detalhes, veja o
Apêndice A.1.4.1.1). A Figura 46 mostra o resultado do cálculo de confiabilidade para a
unidade de gerenciamento de redundância, obtido no software Relex.
102
Figura 46 – Resultado do cálculo de confiabilidade para a unidade de gerenciamento de
redundância com componentes COTS, obtido no software Relex.
A Figura 46 mostra que o valor de confiabilidade da unidade de gerenciamento de
redundância num intervalo de tempo de 17.520 horas é de 0,924603, sendo o MTTF de
223.495,0 horas.
De forma análoga, considerando a taxa de falha de 6,21627E-07 falhas / hora e um
intervalo de tempo de 17.520 horas, para a unidade de chaveamento, aplica-se a definição de
sistema em série para o cálculo de confiabilidade (para mais detalhes, veja o Apêndice
A.1.4.1.1). A Figura 47 mostra o resultado do cálculo de confiabilidade para a unidade de
chaveamento, obtido no software Relex.
103
Figura 47 – Resultado do cálculo de confiabilidade da unidade de chaveamento com
componentes COTS, obtido no software Relex.
A Figura 47 mostra que o valor de confiabilidade da unidade de chaveamento num
intervalo de tempo de 17.520 horas é de 0,989168, sendo o MTTF de 1.608.682,4 horas.
O diagrama de blocos de confiabilidade da Figura 40 da página 91 ainda é válido para
a unidade nominal e redundante do módulo da CPU, a unidade de gerenciamento de
redundância e a unidade de chaveamento utilizando componentes COTS, porém com os
valores de taxas de falha e confiabilidades corrigidos. Portanto, considerando que a
probabilidade de troca da unidade nominal para a unidade redundante do módulo da CPU é
igual a 1,0 (para mais detalhes, veja o Apêndice A.1.4.1.3), juntamente com as taxas de falha
de cada unidade e um intervalo de tempo de 17.520 horas, calcula-se o valor de confiabilidade
104
do arranjo com componentes COTS. A Figura 48 mostra o resultado do cálculo de
confiabilidade para o arranjo com componentes COTS, obtido no software Relex.
Figura 48 – Resultado do cálculo de confiabilidade da redundância cold standby para o
módulo da CPU do computador de bordo com componentes COTS, obtido no software Relex.
A Figura 48 mostra que o valor de confiabilidade da redundância cold standby
proposta ao módulo da CPU do computador de bordo do satélite universitário ITASAT,
utilizando componentes COTS, num intervalo de tempo de 17.520 horas é de 0,900529, sendo
o MTTF de 106.492,1 horas. O valor de confiabilidade obtido para o módulo da CPU do
computador de bordo com componentes COTS e com redundância cold standby não chega a
satisfazer o valor especificado de 0,9600, como indicado pela Tabela 1 da página 44.
Entretanto, pelos dados intermediários de confiabilidade mostrados pela Figura 48, observa-se
105
que o valor de confiabilidade num intervalo de tempo de 7.300 horas, correspondente a dez
meses, é 0,960720, o que atenderia ao valor especificado de 0,9600. Por fim, observa-se um
aumento em relação ao valor de confiabilidade atingido para o módulo da CPU sem
redundância.
Com base nos valores intermediários de confiabilidade para o módulo da CPU sem
redundância, mostrados na Figura 45 da página 101, e para o módulo da CPU com
redundância cold standby, mostrados na Figura 48, foi obtido o gráfico da Figura 49. As
curvas levantadas indicam as tendências dos valores de confiabilidade em intervalos de
1.460 horas, correspondente a intervalos de 2 meses.
Figura 49 – Predição de confiabilidade da redundância cold standby para o módulo da CPU
do computador de bordo com componentes COTS.
Pela Figura 49 é possível observar a influência positiva da aplicação da redundância
cold standby aplicada ao módulo da CPU do computador de bordo com componentes COTS.
A predição de confiabilidade da arquitetura analisada para o módulo da CPU do computador
106
de bordo sem redundância e com redundância cold standby, utilizando componentes COTS,
está sintetizada na Tabela 11.
Tabela 11 – Predição de confiabilidade do Módulo da CPU do computador de bordo com
componentes COTS.
Redundância
cold standby
Sem
Com
Taxa de falha
[Falhas / hora]
1,06446E-05
6,76913E-06
MTTF
[horas]
93.944,1
106.492,1
Confiabilidade para
t = 17.520 horas
0,829864
0,900529
5.6 Combinação com componente de aplicação espacial e COTS
A partir das predições de taxas de falha dos componentes de aplicação espacial,
determinadas na seção 4.2.3 da página 61 e seção 5.2 da página 85, e dos componentes do tipo
COTS, determinadas na seção 5.5.1 da página 96, é possível montar arranjos com as duas
categorias de componentes, considerando o diagrama em blocos de confiabilidade da Figura
40 da página 91.
Uma possível mescla de componentes pode ser considerada utilizando a unidade
nominal do módulo da CPU com componentes COTS e as demais unidades com componentes
de aplicação espacial, da Figura 40 da página 91. Portanto, a Figura 50 mostra o resultado do
cálculo de confiabilidade para a combinação com componentes de aplicação espacial e
componentes COTS, obtido no software Relex.
107
Figura 50 – Resultado do cálculo de confiabilidade da redundância cold standby com a
unidade nominal do módulo da CPU com componentes COTS e as demais unidades com
componentes de aplicação espacial, obtido no software Relex.
Pela Figura 50, observa-se que o valor de confiabilidade da redundância cold standby
proposta ao módulo da CPU do computador de bordo do satélite universitário ITASAT,
utilizando a unidade nominal do módulo da CPU com componentes COTS e as demais
unidades com componentes de aplicação espacial, num intervalo de tempo de 17.520 horas é
de 0,983600, sendo o MTTF de 321.178,9 horas. O valor de confiabilidade obtido para o
módulo da CPU do computador de bordo, com a unidade nominal do módulo da CPU com
componentes COTS e as demais unidades com componentes de aplicação espacial e com
redundância cold standby, satisfaz o valor especificado de 0,9600, como indicado pela Tabela
1 da página 44. No entanto, observa-se um decréscimo em relação ao valor de confiabilidade
108
atingido para o módulo da CPU com redundância cold standby utilizando apenas
componentes de aplicação espacial, como indicado pela Figura 41 da página 92.
Outra possível mescla de componentes pode ser considerada utilizando a unidade
nominal e redundante do módulo da CPU com componentes COTS e as demais unidades com
componentes de aplicação espacial, da Figura 40 da página 91. Portanto, a Figura 51 mostra o
resultado do cálculo de confiabilidade para a combinação com componentes de aplicação
espacial e componentes COTS, obtido no software Relex.
Figura 51 – Resultado do cálculo de confiabilidade da redundância cold standby com a
unidade nominal e redundante do módulo da CPU com componentes COTS e as demais
unidades com componentes de aplicação espacial, obtido no software Relex.
109
Pela Figura 51, observa-se que o valor de confiabilidade da redundância cold standby
proposta ao módulo da CPU do computador de bordo do satélite universitário ITASAT,
utilizando a unidade nominal e redundante do módulo da CPU com componentes COTS e as
demais unidades com componentes de aplicação espacial, num intervalo de tempo de
17.520 horas é de 0,973620, sendo o MTTF de 172.167,1 horas. O valor de confiabilidade
obtido para o módulo da CPU do computador de bordo, com a unidade nominal e redundante
do módulo da CPU com componentes COTS e as demais unidades com componentes de
aplicação espacial e com redundância cold standby, satisfaz o valor especificado de 0,9600,
como indicado pela Tabela 1 da página 44. No entanto, observa-se um decréscimo em relação
ao valor de confiabilidade atingido para o módulo da CPU com redundância cold standby
utilizando apenas componentes de aplicação espacial, como indicado pela Figura 41 da
página 92.
E ainda, outra possível mescla de componentes pode ser considerada utilizando a
unidade redundante do módulo da CPU com componentes de aplicação espacial e as demais
unidades com componentes COTS, da Figura 40 da página 91. Portanto, a Figura 52 mostra o
resultado do cálculo de confiabilidade para a combinação com componentes de aplicação
espacial e componentes COTS, obtido no software Relex.
Pela Figura 52, observa-se que o valor de confiabilidade da redundância cold standby
proposta ao módulo da CPU do computador de bordo do satélite universitário ITASAT,
utilizando a unidade redundante do módulo da CPU com componentes de aplicação espacial e
as demais unidades com componentes COTS, num intervalo de tempo de 17.520 horas é de
0,909570, sendo o MTTF de 143.656,3 horas.
110
Figura 52 – Resultado do cálculo de confiabilidade da redundância cold standby com a
unidade redundante do módulo da CPU com componentes de aplicação espacial e as demais
unidades com componentes COTS, obtido no software Relex.
O valor de confiabilidade obtido para o módulo da CPU do computador de bordo, com
a unidade redundante do módulo da CPU com componentes de aplicação espacial e as demais
unidades com componentes COTS e com redundância cold standby, não chega a satisfazer o
valor especificado de 0,9600, como indicado pela Tabela 1 da página 44. Entretanto, pelos
dados intermediários de confiabilidade mostrados pela Figura 52, observa-se que o valor de
confiabilidade num intervalo de tempo de 7.300 horas, correspondente a dez meses, é
0,963280, o que atenderia ao valor especificado de 0,9600. Por fim, observa-se um aumento
em relação ao valor de confiabilidade atingido para o módulo da CPU com redundância
111
cold standby utilizando apenas componentes COTS, como indicado pela Figura 48 da
página 104.
Com base nos valores intermediários de confiabilidade para o módulo da CPU com
redundância cold standby na utilização de componentes de aplicação espacial (mostrados na
Figura 41 da página 92), na utilização de componentes COTS (mostrados na Figura 48 da
página 105) e na utilização mesclada de componentes de aplicação espacial e COTS
(mostrados na Figura 50, Figura 51 e Figura 52), foi obtido o gráfico da Figura 53. As curvas
levantadas indicam as tendências dos valores de confiabilidade em intervalos de 1.460 horas,
correspondente a intervalos de 2 meses.
Figura 53 – Predição de confiabilidade da redundância cold standby para o módulo da CPU
do computador de bordo com componentes de aplicação espacial e COTS.
Pela Figura 53 é possível observar as tendências e comparar as diferenças de valores
de confiabilidade entre a utilização de componentes de aplicação espacial e componentes
112
COTS, para o módulo da CPU do computador de bordo com redundância cold standby, dos
arranjos abordados neste trabalho.
5.7 Discussão dos resultados
A comparação entre a predição de confiabilidade da arquitetura sem redundância e
com redundância cold standby, assim como com a comparação entre a utilização de
componente de aplicação espacial e componente COTS, para o módulo da CPU do
computador de bordo do satélite universitário ITASAT, estão sintetizadas na Tabela 12.
Tabela 12 – Síntese das predições de confiabilidade para o módulo da CPU do computador de
bordo do satélite universitário ITASAT.
Componente
COTS
Aplicação
espacial
Redundância
cold standby
Sem
Com
Sem
Com
Taxa de falha
[Falhas / hora]
1,06446E-05
6,76913E-06
3,42454E-06
8,35573E-07
MTTF
[horas]
93.944,1
106.492,1
292.009,8
453.038,4
Confiabilidade para
t = 17.520 horas
0,829864
0,900529
0,941766
0,987110
Pela Tabela 12, conclui-se que a presença de redundância cold standby no módulo da
CPU do computador de bordo elevou o valor de confiabilidade em aproximadamente 0,07
pontos na utilização de componentes COTS e 0,05 pontos na utilização de componentes de
aplicação espacial, comparando com o módulo da CPU sem redundância para as respectivas
utilizações de componentes. E ainda, comparando a utilização entre os componentes COTS e
componentes de aplicação espacial, observa-se uma diferença entre os valores de
confiabilidades de aproximadamente 0,11 pontos para o módulo da CPU sem redundância e
0,09 pontos para o módulo da CPU com redundância.
113
A Tabela 13 mostra o tempo estimado para cada valor de confiabilidade indicado pela
Tabela 12 que não satisfez o valor especificado de 0,9600 para o computador de bordo do
satélite universitário ITASAT, como indicado pela Tabela 1 da página 44.
Tabela 13 – Síntese dos tempos para as predições de confiabilidade do módulo da CPU do
computador de bordo que não atingiram o valor especificado de confiabilidade.
Componente
Redundância
cold standby
Sem
COTS
Com
Aplicação
espacial
Sem
Taxa de falha
[Falhas / hora]
1,06446E-05
1,06446E-05
6,76913E-06
5,86351E-06
3,42454E-06
3,42454E-06
Tempo
[horas]
[meses]
17.520
24
2.920
4
17.520
24
7.300
10
17.520
24
11.680
16
Confiabilidade
0,829864
0,969396
0,900529
0,960720
0,941766
0,960791
Pela Tabela 13, conclui-se que a utilização de componentes COTS no módulo da CPU
requer maior redução do tempo de vida útil da missão, para satisfazer o valor de
confiabilidade especificado, comparando-se com a utilização de componentes de aplicação
espacial.
A predição de confiabilidade nas fases iniciais de um projeto espacial pode ser
decisiva na definição do sistema computacional a ser adotado, na seleção de arquiteturas mais
complexas para atingir o valor de confiabilidade pré-definido, na escolha de componentes
eletrônicos com menor taxa de falhas, ou até mesmo na redução da vida útil do satélite.
114
6. Conclusão
Confiabilidade e menor custo de projeto de um satélite artificial estão de algum modo
relacionados à unidade tolerante a falhas e aplicação de componentes comerciais,
respectivamente. No entanto, a combinação entre estes dois fatores para o sucesso de uma
missão espacial talvez ainda seja o ponto crucial no desenvolvimento de satélites em
ambientes universitários.
Uma arquitetura de hardware mínima para o módulo da CPU do computador de bordo
do satélite universitário ITASAT, além de não ser uma unidade tolerante a falhas, mostrou-se
com menor confiabilidade em relação ao valor especificado para este requisito.
Uma síntese dos resultados obtidos pela aplicação da redundância cold standby ao
módulo da CPU do computador de bordo é apresentada na Tabela 14.
Tabela 14 – Síntese dos resultados obtidos pela aplicação da redundância cold standby.
Proposta
1
2
3
4
5
Componentes para a redundância
cold standby
Todas as unidades com
componentes de aplicação espacial
Unidade nominal com COTS e as
demais unidades com componentes
de aplicação espacial
Unidade nominal e redundante
com COTS e as demais unidades
com componentes de aplicação
espacial
Unidade redundante com
componentes de aplicação espacial
e as demais unidades com COTS
Todas as unidades com
componentes COTS
Taxa de falha
[Falhas / hora]
MTTF
[horas]
Confiabilidade
para
t = 17.520 horas
8,35573E-07
453.038,4
0,987110
1,18278E-06
321.178,9
0,983600
2,31487E-06
172.167,1
0,973620
5,87844E-06
143.656,3
0,909570
6,76913E-06
106.492,1
0,900529
Em relação à arquitetura de hardware mínima para o módulo da CPU do computador
de bordo, a primeira proposta da redundância com todas as unidades com componentes de
115
aplicação espacial (proposta 1) contribuiu significativamente para o aumento da
confiabilidade, atendendo ao valor especificado para este requisito. Esta solução apresenta-se
com o maior custo em relação às demais propostas, já que o módulo da CPU é duplicado
utilizando componentes de aplicação espacial.
A segunda proposta da redundância com a unidade nominal com componentes COTS e
as demais unidades com componentes de aplicação espacial (proposta 2) também resultou em
um aumento significativo da confiabilidade, atendendo ao valor especificado para este
requisito. No entanto, esta solução apresenta-se com um custo menor em relação à proposta 1,
já que a unidade nominal do módulo da CPU apresenta-se com componentes comerciais.
A terceira proposta da redundância com as unidades nominal e redundante com
componentes COTS e as demais unidades com componentes de aplicação espacial
(proposta 3) da mesma forma resultou em um aumento da confiabilidade, atendendo ao valor
de confiabilidade especificado. Esta solução apresente-se ainda com o menor custo
comparado com as propostas 1 e 2, considerando que o componente comercial é mais barato
em relação ao componente de aplicação espacial, por não apresentar resistência à radiação em
sua construção. Nesta proposta, recomenda-se a realização de testes de irradiação em solo
para cada componente COTS selecionado, antes de ser colocado em órbita.
A proposta 4 e 5 não contribuem para o aumento da confiabilidade, em relação à
arquitetura de hardware mínima para o módulo da CPU, mas apresentam-se com o menor
custo de componente e menor tamanho de equipamento final, já que os componentes
comerciais possuem massa reduzida em relação aos componentes de aplicação espacial.
As propostas consideradas com a redundância cold standby apresentadas neste
trabalho caracterizam o módulo da CPU do computador de bordo como uma unidade tolerante
a falhas, atributo vital para o sucesso da missão espacial.
O presente trabalho deu origem a três publicações, como segue:
116
•
VINCI, Edson; SAOTOME, Osamu. Título: Arquitetura de hardware do
computador de bordo para o satélite universitário ITASAT e confiabilidade.
2009 BRAZILIAN SYMPOSIUM ON AEROSPACE ENG. & APPLICATIONS.
•
SHIBUYA, Lidia H.; SATO, Sandro S.; BASTOS, Moisés P.; VINCI, Edson;
SAOTOME, Osamu. Título: ITASAT – desenvolvimento de um computador de
bordo tolerante a falhas com comunicação padrão CCSDS.
2009 BRAZILIAN SYMPOSIUM ON AEROSPACE ENG. & APPLICATIONS.
•
VINCI, Edson; SAOTOME, Osamu. Título: Reliability of On-board Computer for
ITASAT University Satellite.
2010 11th Latin American Test Workshop.
A partir dos resultados da proposta apresentada, trabalhos futuros podem ser dirigidos
no sentido de:
•
Estudo e proposta de redundância para o módulo de I/O do computador de bordo;
•
Estudo e proposta de redundância para o módulo condicionador de energia do
computador de bordo;
•
Predição de confiabilidade para todo o computador de bordo;
•
Adequação das unidades de gerenciamento de redundância e de chaveamento às
novas redundâncias propostas para os demais módulos de computador de bordo;
•
Adequação das unidades de gerenciamento de redundância e de chaveamento para
monitoramento da redundância executado pelo segmento solo;
•
Avaliação de custo para as arquiteturas propostas;
•
Estudo e predição de confiabilidade dos demais subsistemas que compõem o
satélite ITASAT.
117
Referências bibliográficas
[1] FAVERA, Eduardo C. D. Interface mecânica entre o satélite e o lançador de satélites
miniaturizados. Santa Maria: INPE, 2008. (102221/2008-1).
[2] DUBOURG, Vincent et al. An innovative onboard computer for CNES microsatellites. In:
DIGITAL AVIONICS SYSTEMS CONFERENCE, 21., 2002, Irvine, California.
Proceedings... Irvine: IEEE, 2002. v.2, p.1-11.
[3] GRILLMAYER, G. et al. ILSE - first laboratory model of the small satellite program at
the university of Stuttgart. In: INTERNATIONAL ASTRONAUTICAL CONGRESS, 54.,
2003, Bremen, Germany. Proceedings... Bremen: IAC-03-IAA.11.1.09, 2003.
[4] ZHANG, Xiaomin et al. First micro-satellite and new enhanced small satellite series in
DFH satellite Co. Ltd. Acta Astronautica, v.61, n.5, p.234-242, may. 2007.
[5] GULDAGER, Peter B.; THUESEN, Gosta G.; JORGENSEN, John L. Quality assurance
for space instruments built with cots. Acta Astronautica, v.56, n.1, p.279-283, jan. 2005.
[6] CASTET, Jean-Francois; SALEH, Joseph H. Satellite and satellite subsystems reliability:
statistical data analysis and modeling. Reliability Engineering and System Safety, v.94,
n.11, p.1718-1728, nov. 2009.
[7] TAKANO, Tadashi et al. In-orbit experiment on the fault-tolerant space computer aboard
the satellite Hiten. IEEE Transaction on Reliability, v.45, n.4, p.624-631, dec. 1996.
[8] KOZENIESKI, Noli J. Sistema de processamento embarcado de arquitetura com
redundância de hardware ativa tolerante a falhas. 2007. 107f. Dissertação (Mestre em
Dispositivos e Sistemas Eletrônicos) – Instituto Tecnológico de Aeronáutica, São José dos
Campos.
[9] WANG, Xinsheng; SUN, Hanxu. Fault tolerance design on onboard computer using cots
components. In: INTERNATIONAL SYMPOSIUM ON SYSTEMS AND CONTROL IN
AEROSPACE AND ASTRONAUTICS, 1., 2006, Harbin, China. ISSCAA 2006. Harbin:
IEEE, 2006. p.1222-1224.
118
[10] XING, Lei; SUN, Zhaowei; XU, Guodong. FPGA on-board computer design based on
hierarchical fault tolerance. In: INTERNATIONAL SYMPOSIUM ON SYSTEMS AND
CONTROL IN AEROSPACE AND ASTRONAUTICS, 2., 2008, Shenzhen, China. ISSCAA
2008. Shenzhen: IEEE, 2008. p.1-5.
[11] TAFAZOLI, Mak. A study of on-orbit spacecraft failures. Acta Astronautica, v.64, n.2,
p.195-205, jan. 2009.
[12] INSTITUTO NACIONAL DE PESQUISAS ESPACIAIS. Satélite e seus subsistemas.
São José dos Campos, 2006. Disponível em:
<http://www6.cptec.inpe.br/~grupoweb/Educacional/MACA_SSS/>. Acesso em: 21 jul.
2009.
[13] SOUZA, Petrônio N. Curso introdutório em tecnologia de satélites. São José dos
Campos: Instituto Nacional de Pesquisas Espaciais, 2009. 468p. Apostila.
[14] LARSON, Wiley J.; WERTZ, James R. Space mission analysis and design. 3. ed. El
Segundo: Microcosm Press, 2005. 976p.
[15] DONATO, Claudinei J. Projeto e implementação de uma unidade de controle de
potência para o satélite universitário Itasat. 2007. 158f. Dissertação (Mestre em
Dispositivos e Sistemas Eletrônicos) – Instituto Tecnológico de Aeronáutica, São José dos
Campos.
[16] SILVA, Douglas F.. Análise de projeto preliminar de controle térmico do satélite
Itasat. 2009. 120f. Dissertação (Mestre em Aerodinâmica, Propulsão e Energia) – Instituto
Tecnológico de Aeronáutica, São José dos Campos.
[17] SOUZA, Primavera B.; NAKANISHI, Tatuo; CUNHA, João B. S. Um ambiente para o
desenvolvimento de software embarcado em satélite. In: WORCAP, 1., 2001, São José dos
Campos. Proceedings... INPE: I WORCAP, 2001. v.1, p.63-65.
[18] SHIBUYA, Lidia Hissae et al. Itasat – desenvolvimento de um computador de bordo
tolerante a falhas com comunicação padrão CCSDS. In: BRAZILIAN SYMPOSIUM ON
AEROSPACE ENG. & APPLICATIONS, 1., 2009, São José dos Campos. Anais
eletrônicos... São José dos Campos: CTA, 2009. Disponível em:
<http://www.cta-dlr2009.ita.br/>. Acesso em: 12 jan. 2010.
[19] HENNESSY, John L.; PATTERSON, David A. Arquitetura de computadores: uma
abordagem quantitativa. 3. ed. Rio de Janeiro: Campus, 2003. 827p.
119
[20] AGÊNCIA ESPACIAL BRASILEIRA. Satélites. Brasília, 2005. Disponível em:
<http://www.aeb.gov.br/indexx.php?secao=satelites>. Acesso em: 12 jan. 2010.
[21] INSTITUTO NACIONAL DE PESQUISAS ESPACIAIS. Programa CBERS. São
José dos Campos, 2007. Disponível em: <http://www.cbers.inpe.br/?content=index>. Acesso
em: 6 out. 2009.
[22] PESSOTA, Fernando A. Análise de arquiteturas de computadores de bordo para
missões espaciais de longa duração. 1999. 136f. Dissertação (Mestre em Dispositivos e
Sistemas Eletrônicos) – Instituto Tecnológico de Aeronáutica, São José dos Campos.
[23] FERNANDES, David; YAMAGUTI, Wilson; NETO, Thyrso V. Satélite tecnológico de
pequeno porte Itasat-1. In: WORKSHOP DE ASTRONOMIA ESPACIAL, 1., 2009. São
Paulo. Anais eletrônicos... São Paulo: IAG-USP, 2009. Disponível em:
< http://www.astro.iag.usp.br/~iwae/index.html >. Acesso em: 10 fev. 2010.
[24] SILVA, Adalberto C. da et al. Papel do Brasil no cenário internacional e cooperação
em atividades espaciais, modelagem e observação do sistema terrestre. São José dos
Campos: INPE, 2007. (CPA-032-2006).
[25] ITASAT SATÉLITE UNIVERSITÁRIO. Computador de bordo. São José dos
Campos, 2007. Disponível em:
<http://www.itasat.redecasd.ita.br/index.php/Computador_de_Bordo>. Acesso em: 10 jun.
2009.
[26] LOPES, Roberto V. F. et al. Amazonia 1 satellite attitude control and data handling
(ACDH) subsystem specification. São José dos Campos: INPE, 2008. (A12700-SPC-01).
[27] SANTOS, Walter A. dos. ITASAT attitude control and data handling (ACDH)
subsystem specification. São José dos Campos: ITASAT, 2009. (U1114-SPC-01/rev.2).
[28] GENTINA, Jonas; YAMAGUTI, Wilson; VAROTTO, Sebastião E. C. A proposal for
Itasat satellite configuration and its preliminary mission analysis. In: BRAZILIAN
SYMPOSIUM ON AEROSPACE ENG. & APPLICATIONS, 1., 2009, São José dos
Campos. Anais eletrônicos... São José dos Campos: CTA, 2009. Disponível em:
<http://www.cta-dlr2009.ita.br/>. Acesso em: 26 jan. 2010.
[29] CARVALHO, Terezinha R. de; VAROTTO, Sebastião E. C.; YAMAGUTI, Wilson.
ITASAT satellite specification. São José dos Campos: ITASAT, 2008. (U1100-SPC01/rev.0).
120
[30] EUROPEAN SPACE AGENCY. Electromagnetics and space environment.
Noordwijk, 2010. Disponível em:
<http://www.esa.int/SPECIALS/Space_Engineering/SEMHBM0P0WF_0.html>. Acesso em:
15 jan. 2010.
[31] VAROTTO, Sebastião E. C. ITASAT environmental specification. São José dos
Campos: ITASAT, 2008. (U1006-SPC-06/rev.0).
[32] NATIONAL AERONAUTICS AND SPACE ADMINISTRATION. Student features.
Washington, DC, 2009. Disponível em:
<http://www.nasa.gov/audience/forstudents/5-8/features/orbit_feature_5-8.html>. Acesso em:
9 nov. 2009.
[33] NATIONAL AERONAUTICS AND SPACE ADMINISTRATION. World book at
NASA. Washington, DC, 2007. Disponível em:
<http://www.nasa.gov/worldbook/artificial_satellites_worldbook.html>. Acesso em: 12 nov.
2009.
[34] VIEGAS, Wilder V. C.; WALDMANN, Jacques. Estudo de viabilidade do controle de
atitude do satélite universitário Itasat empregando duas rodas de reação. In: BRAZILIAN
SYMPOSIUM ON AEROSPACE ENG. & APPLICATIONS, 1., 2009, São José dos
Campos. Anais eletrônicos... São José dos Campos: CTA, 2009. Disponível em:
<http://www.cta-dlr2009.ita.br/>. Acesso em: 14 jan. 2010.
[35] YAMAGUTI, Wilson; DE CARVALHO, Terezinha R.; VAROTTO, Sebastião E. C.
ITASAT mission requirements and system definition. São José dos Campos: ITASAT,
2008. (U1000-SPC-01/rev.1).
[36] EUROPEAN SPACE AGENCY. ECSS-Q-ST-30C: space product assurance –
dependability. Noordwijk, 2009.
[37] LAFFOURCADE, Remy. Interface control document microsat obc. Martres
Tolosane, France: Steel Electronique, 2001. (SE-µSAT-OBC-T-DCI).
[38] SILVA, Durval S. Sistemas embarcados – técnicas para aumentar a confiabilidade
eletrônica. In: SIMPÓSIO DE GUERRA ELETRÔNICA, 4., 2007, São José dos Campos.
Anais eletrônicos... São José dos Campos: ITA, 2007. Disponível em:
<http://www.sige.ita.br/IX_SIGE/>. Acesso em: 23 jul. 2009.
[39] SOLVHOJ, Jonas; BREITING, Malte; THOMSEN, Morten B. Onboard computer for
pico satellite. Denmark: Technical University of Denmark, 2002. (ORSTED DTU).
121
[40] O’CONNOR, Patrick D. T. Practical reliability engineering. 3. ed. New York: John
Wiley & Sons, 1991. 409p.
[41] LAFRAIA, João R. B. Manual de confiabilidade,
disponibilidade. Rio de Janeiro: Qualitymark Petrobrás, 2001. 374p.
mantenabilidade
e
[42] EUROPEAN SPACE AGENCY. ECSS-Q-ST-30-02C: space product assurance –
failure modes, effects (and criticality) analysis (FMEA/FMECA). Noordwijk, 2009.
[43] CAMPELLO, Alexandre S. Modelagem e análise comparativa da confiabilidade em
sistemas de segurança e atuação com aplicação em foguetes. 2004. 108f. Dissertação
(Mestre em Dispositivos e Sistemas Eletrônicos) – Instituto Tecnológico de Aeronáutica, São
José dos Campos.
[44] UNITED STATES. Department of Defense. MIL-HDBK-217F: reliability prediction of
electronic equipment. Washington, DC, 1995. 205p.
[45] RELEX SOFTWARE CORPORATION. Relex reliability studio 2008: september 2008
update. Greensburg, 2008. Disponível em: <http://www.relexsoftware.com>. Acesso em: 20
jan. 2009.
[46] AZEVEDO, Irany A. Confiabilidade de componentes e sistemas. São José dos
Campos: Instituto Tecnológico de Aeronáutica, 2008. 226p. Apostila EA-160.
[47] EUROPEAN SPACE AGENCY. European preferred parts list. Noordwijk, 2008.
Disponível em: <https://escies.org/ReadArticle?docId=166>. Acesso em: 6 jul. 2009.
[48] NATIONAL AERONAUTICS AND SPACE ADMINISTRATION. NASA parts
selection list. Washington, DC, 2005. Disponível em: <http://nepp.nasa.gov/npsl/>. Acesso
em: 6 jul. 2009.
[49] ATMEL CORPORATION. Rad hard processors TSC695FL. San Jose, 2008.
Disponível em: <http://www.atmel.com/dyn/products/datasheets.asp?family_id=641>. Acesso
em: 15 jan. 2009.
[50] BILLINTON, Roy; ALLAN, Ronald N. Reliability evaluation of engineering
systems: concepts and techniques. 2. ed. New York: Plenum, 1992. 453p.
122
[51] JERNQVIST, Fredrik; PASQUET, Jean-Marie; PEDERSEN, Jan S. A fault tolerant
computer for space applications. In: DATA SYSTEMS IN AEROSPACE, 1998, Athens,
Greece. DASIA ’98 Conference. Athens: ESA, 1998. p.421-428.
[52] EUROPEAN SPACE AGENCY. ECSS-E-ST-70-11C: space engineering – space
segment operability. Noordwijk, 2008.
[53] SILVA JR., Vidal P. Aplicações práticas do microcontrolador 8051. 11. ed. São
Paulo: Érica, 2003. 244p.
[54] BALCH, Mark. Complete digital design. New York: McGraw-Hill, 2003. 444p.
[55] ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS. NBR 5462: confiabilidade
e mantenabilidade. Rio de Janeiro, 1994.
[56] RELEX SOFTWARE CORPORATION. Relex reliability studio 2008 reference
manual: september 2008 update. Greensburg, 2008. Disponível em:
<http://www.relexsoftware.com>. Acesso em: 20 jan. 2009.
[57] KOREN, Israel; KRISHNA, C. Mani. Fault-tolerant systems. San Francisco: Morgan
Kaufmann, 2007. 378p.
[58] UNITED STATES. Department of Defense. MIL-HDBK-338B: electronic reliability
design handbook. Washington, DC, 1998. 1046p.
[59] VIEIRA, Wilson J. Simulação Monte Carlo em armamento aéreo. São José dos
Campos: Comando Geral de Tecnologia Aeroespacial - Instituto de Aeronáutica e Espaço,
2010. 152p. Apostila AA-101.
[60] UNITED STATES. Department of Defense. MIL-STD-1629A: procedures for
performing a failure mode, effects and criticality analysis. Washington, DC, 1980. 80p.
[61] ATMEL CORPORATION. Rad hard processors 80C32E. San Jose, 2008. Disponível
em: <http://www.atmel.com/dyn/products/datasheets.asp?family_id=641>. Acesso em: 15
jan. 2009.
123
Apêndice A – Confiabilidade
A.1 Fundamentos de confiabilidade
Quando falha um equipamento ou parte de um satélite em órbita, é praticamente
impossível realizar uma manutenção. Portanto, para que uma falha não limite a operação do
satélite ou até mesmo aborte a missão, é necessário que o satélite seja altamente confiável. A
necessidade de confiabilidade muito alta em todas as partes e subsistemas de um satélite é a
base para a inclusão de um estudo de confiabilidade no projeto [14].
Neste apêndice, será definido o termo confiabilidade, bem como os conceitos de falha,
pane, defeito e erro. Serão apresentadas uma ferramenta para predição de confiabilidade e
métodos para aumentar a confiabilidade de um sistema. Por fim, duas técnicas de análise de
confiabilidade são conceituadas: análise de árvore de falhas e análise de modos de falhas e
efeitos.
A.1.1 Definição
A confiabilidade é um termo que define a probabilidade de um componente,
subsistema ou sistema, exercer continuamente sua função sob determinada condição, num
dado intervalo de tempo [55]. Esta definição reúne quatro partes básicas: probabilidade,
possibilidade de um evento ocorrer; exercer sua função, funcionar de acordo com a
especificação; determinada condição, circunstâncias ambientais requeridas; e tempo, período
requerido para o bom funcionamento [50].
Quando se trata de confiabilidade, alguns conceitos principais são abordados e
requerem definição. Segundo a norma NRB 5462, os principais termos e definições são [55]:
124
•
item: qualquer componente, subsistema ou sistema que pode ser considerado
individualmente;
•
falha: término da capacidade de um item desempenhar a função requerida;
•
pane: estado de um item caracterizado pela incapacidade de desempenhar uma
função requerida, durante sua operacionalidade;
•
defeito: desvio de uma característica de um item em relação aos seus requisitos; e
•
erro: diferença entre um valor ou uma condição observada ou medida e a
correspondente condição ou valor verdadeiro especificado ou teórico.
A.1.2 Parâmetro de confiabilidade
A probabilidade atrelada ao termo confiabilidade é a função que mede a possibilidade
de um evento ocorrer. Portanto, o inverso da confiabilidade é a probabilidade de um item
falhar. A Freqüência com que as falhas ocorrem num intervalo de tempo é medida pelo
número de falhas para cada hora de operação, denominada de taxa de falha e representada
pela letra grega λ [41].
Tradicionalmente representa-se a variação típica da taxa de falha de um componente
eletrônico em função do tempo pela curva da banheira [46]. A Figura 54 mostra a curva da
banheira com as fases de vida de um componente eletrônico.
Pela Figura 54 observa-se que um componente eletrônico apresenta três fases de vida
característica: fase de mortalidade infantil (ou falhas prematuras), onde a taxa de falha é
decrescente e se revela pela deficiência no processo de fabricação do componente; fase de
taxa de falha constante (ou vida útil), onde a taxa de falha é constante e se revela de forma
aleatória; e fase por desgaste (ou deterioração), onde a taxa de falha cresce continuamente e se
manifesta pelo término da vida útil do componente [41].
125
Figura 54 – Curva da banheira [56].
Este trabalho leva em consideração que os componentes estão na fase de vida útil,
desconsiderando, portanto, falhas prematuras ou por deterioração.
A.1.2.1 Função confiabilidade
A partir da taxa de falha de um componente, associada à distribuição exponencial de
falhas que satisfatoriamente representa o comportamento dos componentes eletrônicos na fase
de vida útil, é expressa a função confiabilidade para um tempo t > 0, conforme Equação (1):
R(t ) = e −λ t
(1)
onde λ é a taxa de falha, dada em falhas / hora; t é o tempo, dado em horas; e é a base do
logaritmo neperiano; e R(t), de Reliability, termo em inglês correspondente à confiabilidade, é
a probabilidade do componente operar sem falhas até o tempo t [14].
É possível, portanto, extrair dois resultados da função confiabilidade: sucesso e falha.
Define-se a probabilidade de falha F(t), conforme a Equação (2):
F (t ) = 1 − R (t )
(2)
126
Considerando λ = 1 falha / hora, é possível verificar o comportamento da função
confiabilidade R(t) e da função não-confiabilidade F(t) ao longo do tempo, pelo gráfico da
Figura 55.
Figura 55 – Função R(t) e F(t) para λ = 1 falha / hora.
Uma grandeza muito utilizada que está relacionada à medida de confiabilidade é o
MTTF – Mean Time to Failure, que corresponde à média do tempo até a falha de um item. A
Equação (3) mostra a expressão matemática para o MTTF, associada à distribuição
exponencial de falhas, expresso em horas [50] [56] [40].
MTTF =
+∞
∫0
+∞ −λt
e dt
0
R (t )dt = ∫
=
1
λ
(3)
Além do MTTF, costuma-se usar outras grandezas relacionadas à medida de
confiabilidade, como: MTFF – Mean Time to First Failure, MTBF – Mean Time Between
Failures e MOTBF – Mean Operation Time Between Failures [46].
127
A.1.3 Métodos para aumentar a confiabilidade
Para deixar um componente, um subsistema, ou um sistema mais confiável, aplicam-se
métodos para aumentar a confiabilidade. Alguns desses métodos são:
•
item com maior confiabilidade individual: a substituição de um item por outro de
maior confiabilidade resulta no aumento de confiabilidade de todo o sistema [46];
•
solicitação reduzida (derating): limita o estresse o qual pode ser aplicado a um
item, para níveis abaixo da especificação máxima, a fim de aumentar a
confiabilidade [40];
•
redundância: dois ou mais itens realizam funções semelhantes [41].
A.1.3.1 Redundância
A redundância é a propriedade de ter mais de um recurso que seja minimamente
necessário para realizar uma função. As falhas acontecem, e a redundância é explorada a fim
de mascarar ou contornar essas falhas, mantendo assim o nível desejado de funcionalidade
[57]. A redundância pode estar presente no [8] [46] [57]:
•
Tempo: consiste em repetir o mesmo processo de computação em diferentes
instantes no tempo, nos sistemas onde o tempo de processamento não é um fator
crítico;
•
Informação: consiste no envio ou armazenamento de dados redundantes de
informação, possibilitando a detecção de erros;
•
Software: quando mais de um processamento é utilizado, diferenciados quanto ao
programador, linguagem de programação, ferramenta de programação utilizada,
entre outros;
128
•
Hardware: quando componentes replicados criam novos meios físicos para o
sistema, possibilitando que na falha de algum componente, o componente
redundante assuma a funcionalidade.
Dentre os tipos de redundância, a que diretamente resulta em aumento físico do
sistema é a redundância de hardware, por isso decisões em quando e como aplicar
redundância em hardware dependem da criticidade do sistema ou função e sempre devem
estar equilibradas com a necessidade de minimizar complexidade e custos. Em muitos casos, é
possível melhorar a confiabilidade usando elementos de circuitos de hardware redundantes,
devido ao baixo custo da maioria dos dispositivos eletrônicos modernos [40].
A.1.3.1.1 Classificação da redundância
As aplicações de redundância de hardware são geralmente classificadas em dois tipos:
ativa e standby (ou prontidão). A redundância é ativa quando os componentes compartilhados
operam simultaneamente e a atividade é automaticamente absorvida pelos componentes
restantes se um ou mais vierem a falhar. A redundância é considerada standby quando os
componentes permanecem no estado inativo e são colocados em operação apenas quando o
componente principal falhar [50] [46].
A redundância do tipo standby pode ainda ser classificada conforme o modo como os
componentes são energizados durante as atividades [46]:
•
cold (fria): os
componentes
redundantes
permanecem
completamente
desenergizados durante todo tempo anterior à sua entrada em operação;
129
•
warm (morna): os
componentes
redundantes
permanecem
parcialmente
energizados durante todo tempo anterior à sua entrada em operação, abaixo da
condição de operação ativa;
•
hot (quente): os componentes redundantes permanecem totalmente energizados
durante todo tempo anterior à sua entrada em operação, muito próximo das
condições em que se encontrariam caso estivessem em operação.
A.1.3.2 Tolerância a falhas
Um sistema tolerante a falhas apresenta a capacidade de operar mesmo na presença de
falhas. Esta operação pode ser completa ou de forma degradada, porém a um nível aceitável.
Portanto, um dos objetivos de um sistema tolerante a falhas é evitar a propagação de falhas,
substituindo uma unidade falha por uma unidade redundante. Um sistema de aplicação
espacial tolerante a falhas requer a implementação de um conjunto de funcionalidades, tais
como [58]:
•
detecção de falha: determina a ocorrência de falha;
•
isolação de falha: determina a causa da falha, em nível de componente ou
subsistema defeituoso;
•
contenção de falha: impede a propagação da falha para não interferir em outros
serviços;
•
mascaramento de falha: assegura a passagem apenas dos valores corretos para o
próprio subsistema e aos outros;
•
compensação de falha: proporciona uma resposta para compensar a saída com
defeito.
130
Os itens relacionados acima convergem para implementação de uma unidade de
gerenciamento de redundância aplicada ao sistema. No entanto, apenas a redundância não
define se um sistema é tolerante a falhas. Um sistema tolerante a falhas aponta qual o
resultado redundante ou qual saída do sistema está correto. Portanto, o gerenciamento de
redundância controla os recursos não falhos do sistema para fornecer como saída o resultado
correto [58].
A.1.4 Confiabilidade de sistemas
Métodos são utilizados para determinar a confiabilidade de um sistema composto a
partir de vários arranjos de componentes isolados. Uma ferramenta muito utilizada para
determinação de confiabilidade é o diagrama de blocos.
A.1.4.1 Diagrama de bloco de confiabilidade
O diagrama de blocos de confiabilidade é uma ferramenta que reúne a visualização de
topologia de confiabilidade de sistemas, agregada ao método analítico para determinação de
valores de confiabilidade [46]. O arranjo dos blocos depende da forma como contribui para a
confiabilidade do sistema.
A.1.4.1.1 Sistema série
Numa topologia composta por n elementos não redundantes, sendo todos igualmente
essenciais para a operação do sistema, os componentes estão associados em série para a
confiabilidade [14]. Neste arranjo, a falha de qualquer componente provoca a falha de todo o
131
sistema [41]. A Figura 56 ilustra um sistema com associação em série com n elementos, na
visão da confiabilidade.
Figura 56 – Sistema com associação em série [50].
A confiabilidade do sistema com associação em série ilustrada pela Figura 56 é dada
pelo produto da confiabilidade individual dos blocos em função do tempo t, determinada pela
Equação (4):
n
RS (t ) = R1 (t ) R2 (t ) ... R n (t ) = ∏ R i (t )
(4)
i =1
onde RS(t) é a confiabilidade resultante da associação em série, Ri(t) é a confiabilidade do
componente i e n o número de componentes da associação.
Associada à distribuição exponencial de falhas, e considerando um tempo t > 0, a
Equação (4) também pode ser reescrita da seguinte forma:
−λ t
− (λ + λ + ... + λ n ) t
RS (t ) = e − λ1 t e − λ2 t ... e n = e 1 2
=e
n
− ∑ λi t
i =1
(5)
Do sistema com associação em série, conclui-se que a confiabilidade resultante RS(t) é
menor do que a confiabilidade do item Ri(t) de menor confiabilidade [46].
O MTTF para um sistema com associação em série pode ser obtido pela Equação (6)
[50] [56]:
MTTFS =
1
λS
=
1
n
∑ λi
i =1
onde s corresponde ao sistema com associação em série.
(6)
132
A.1.4.1.2 Sistema paralelo
Numa topologia composta por n elementos redundantes, onde cada elemento traz as
exigências do sistema por si próprio, os componentes estão associados em paralelo para a
confiabilidade [14]. Neste arranjo, a falha do sistema só ocorre quando todos os componentes
falharem [41]. A Figura 57 ilustra um sistema com associação em paralelo com n elementos,
sob a visão da confiabilidade.
Figura 57 – Sistema com associação em paralelo [50].
A não-confiabilidade do sistema com associação em paralelo ilustrada pela Figura 57 é
dada pelo produto da não-confiabilidade individual dos blocos em função do tempo t,
determinada pela Equação (7):
n
FS (t ) = F1 (t ) F2 (t ) ... Fn (t ) = ∏ Fi (t )
(7)
i =1
onde FS(t) é a não-confiabilidade resultante da associação em paralelo, Fi(t) é a nãoconfiabilidade do componente i e n o número de componentes da associação.
Aplicando a Equação (2), é possível extrair o valor da confiabilidade de cada
componente da associação em paralelo, dada pela equação (8):
Ri (t ) = 1 − Fi (t )
(8)
133
Portanto, a confiabilidade do sistema com associação em paralelo é determinada pela
Equação (9):
n
(
)
RS (t ) = 1 − FS (t ) = 1 − ∏ 1 − R i (t )
(9)
i =1
onde RS(t) é a confiabilidade resultante da associação em paralelo, Ri(t) é a confiabilidade do
componente i e n o número de componentes da associação.
Considerando λ = 1 falha / hora para n componentes associados em paralelo, é possível
verificar o comportamento da função confiabilidade do sistema RS(t) ao longo do tempo, pelo
gráfico da Figura 58.
Figura 58 – Função RS(t) para n componentes associados em paralelo [58].
Do sistema com associação em paralelo, conclui-se que a confiabilidade resultante
RS(t) é maior do que a confiabilidade do item Ri(t) de maior confiabilidade [46].
O MTTF para um sistema com associação em paralelo pode ser obtido pela
Equação (10) [50] [56]:
134
⎞
⎛ 1
1
1 ⎞ ⎛⎜ 1
1
1
⎟⎟ −
+
+ ... +
+ ...⎟
+ ... +
MTTFS = ⎜⎜ +
⎟
λn ⎠ ⎜⎝ λ1 + λ2 λ1 + λ3
λi + λ j
⎝ λ1 λ2
⎠
⎛
⎞
1
1
1
+⎜
+
+ ... +
+ ...⎟ ...
⎜ λ1 + λ2 + λ3 λ1 + λ3 + λ4
⎟
λi + λ j + λk
⎝
⎠
1
+ (− 1)n + 1
(10)
n
∑ λi
i =1
onde s corresponde ao sistema com associação em paralelo.
A.1.4.1.3 Sistema standby
Numa topologia composta por n elementos redundantes, onde cada elemento é ativado
somente quando há falha no elemento em operação, os componentes estão associados em
standby para a confiabilidade [41]. A Figura 59 ilustra um sistema com associação em
standby com dois elementos, sob a visão da confiabilidade.
Na Figura 59, os componentes identificados pelos números 1 e 2 podem ser
denominados como nominal e redundante, não necessariamente nesta ordem. Analisando o
item a) verifica-se que os componentes estão isolados eletricamente das interfaces de entrada
e saída, até o instante anterior à comutação das respectivas chaves. No item b), verifica-se que
os componentes estão ligados eletricamente às interfaces de entrada e saída. A troca de
operacionalidade entre os componentes se realiza essencialmente pela comutação da chave de
alimentação, e também pelas chaves de interfaces de entrada e saída, quando aplicada a
configuração do item a).
135
a)
b)
Figura 59 – Sistema com associação em standby: a) interface de entrada e saída e alimentação
chaveada, b) interface de entrada e saída comum e alimentação chaveada [58].
O chaveamento entre os componentes redundantes pode ser classificado como perfeito
ou imperfeito. No chaveamento perfeito, a chave não falha durante a operação do sistema e a
comutação para o componente redundante é bem sucedido. Portanto a probabilidade de falha
do sistema FS(t), assumido que as falhas de 1 e 2 são independentes, é dada pela Equação (11)
[58].
FS (t ) = F1 (t ) F2 (t )
(11)
Para um sistema em standby o tempo não é cumulativo para o elemento redundante,
até o instante de tempo seguinte à falha do item nominal. O sistema terá sucesso num
intervalo de tempo t se quaisquer umas das condições forem satisfeitas [58]:
•
o componente 1 é bem sucedido até o tempo t; ou
•
o componente 1 falhar no tempo t1 < t e o componente 2 opera do tempo t1 até o
tempo t.
136
Considerando n elementos de igual confiabilidade, a Equação (12) determina a
confiabilidade do sistema com associação em standby ilustrada pela Figura 59, em função do
tempo t [58] [56] [41].
n−k
⎛
(kλ t ) i
k 2 λ2 t 2
k (n −1)λ(n −1) t (n −1) ⎞⎟
= e − kλ t ∑
RS (t ) = e − kλ t ⎜ 1 + kλ t +
+ ... +
⎟
⎜
(n − 1) !
2!
i!
i =0
⎠
⎝
(12)
onde k é o número mínimo de unidades operacionais necessárias para a operação do sistema e
n é o número de elementos no sistema que estão dispostos em redundância standby.
Considerando λ = 1 falha / hora para n componentes associados em standby, é possível
verificar o comportamento da função confiabilidade do sistema RS(t) ao longo do tempo, pelo
gráfico da Figura 60.
Figura 60 – Função RS(t) para n componentes associados em standby [58].
No chaveamento imperfeito, a chave pode falhar durante a operação do sistema,
levando a considerar a probabilidade de chaveamento Pch. Portanto, a probabilidade de falha
FS(t) do sistema com chaveamento imperfeito, considerando Pch o chaveamento realizado e
(1 – Pch) o chaveamento não realizado, é dada pela Equação (13) [58].
137
FS (t ) = F1 (t ) F2 (t ) Pch + F1 (t ) (1 − Pch )
(13)
Do lado direito da igualdade mostrada pela Equação (13), o primeiro termo da soma
corresponde à probabilidade de falha do sistema com o chaveamento bem sucedido, e o
segundo termo à probabilidade de falha do sistema com o chaveamento mal sucedido. A
Equação (13) pode ser reescrita como mostrado na Equação (14):
FS (t ) = F1 (t ) − F1 (t ) Pch (1 − F2 (t ))
(14)
Contudo, ainda é preciso considerar a confiabilidade da chave dentro do sistema. A
Figura 61 ilustra um sistema com associação em standby com chaveamento imperfeito.
Figura 61 – Sistema com associação em standby com chaveamento imperfeito [50].
A confiabilidade do sistema com associação em standby ilustrada pela Figura 61 é
determinada pela Equação (15):
RS (t ) = Rch (t ) (1 − FS (t )) = Rch (t ) (1 − (F1 (t ) − F1 (t ) Pch (1 − F2 (t ))))
(15)
onde F1 (t ) = 1 − R1 (t ) e F2 (t ) = 1 − R2 (t ) .
O MTTF para um sistema com associação em standby pode ser obtido pela
Equação (16) [50] [56]:
MTTFS = ∫
+∞
0
R(t ) dt =
n+1
kλ
onde s corresponde ao sistema com associação em standby.
(16)
138
A.1.5 Análise de modos de falhas e efeitos
A análise de modos de falhas e efeitos ou FMEA – Failure Modes and Effects
Analysis, tem por objetivo identificar as causas e efeitos de cada modo de falha de um sistema
[41]. A FMEA apresenta-se ainda com uma variação identificando a criticidade, caracterizada
por uma FMECA – Failure Modes, Effects and Criticality Analysis [40].
Os dados identificados numa FMEA são estruturados numa planilha, que pode sofrer
alterações nos seus campos conforme a necessidade. Contudo, um exemplo de um formato de
planilha de FMEA pode ser visto no Anexo A.2.
Dentre as colunas de uma planilha de FMEA, destacam-se em resumo os campos [41]:
•
modo de falha: maneira pela qual um item falha no cumprimento de sua função;
•
causa básica da falha: determinada por um defeito de fabricação, de qualidade, de
projeto, ou ainda de má utilização, de interferências externas, entre outras, que
justifica o porque do modo de falha ter ocorrido;
•
efeito da falha: conseqüência evidente com que o modo de falha age sobre o item,
tanto no âmbito operacional, funcional ou de estado.
A FMEA pode ser considerada uma análise potencial, pois é esperado que os modos de
falha não ocorram. Em geral auxilia na decisão de confiabilidade, segurança do sistema, entre
outros [46].
A.1.6 Análise de árvore de falhas
A análise de árvore de falhas ou FTA – Failure Tree Analysis, tem por objetivo obter
um conjunto de falhas, por intermédio de um diagrama lógico, que levam ao evento sob
139
análise. Esta análise pode ser qualitativa, determinando as causas básicas ou seqüência de um
evento, ou quantitativa, determinando a probabilidade de ocorrência do evento [41].
A simbologia utilizada para desenhar um diagrama lógico de árvore de falhas pode
apresentar pequena diferenças uma das outras, contudo, a simbologia mais utilizada pode ser
vista no Anexo A.1.
Em geral a construção de uma árvore de falhas apresenta uma estrutura, de cima para
baixo, da seguinte forma [41]:
•
falha do sistema ou evento topo;
•
porta lógica que interliga o evento topo aos eventos intermediários;
•
seqüência de eventos intermediários que levam o sistema a falhar ou ao evento
topo;
•
portas lógicas que interligam o eventos intermediários aos eventos básicos;
•
seqüência de eventos básicos que levam aos eventos intermediários ou ao evento
topo.
A análise de árvore de falhas, também conhecida por análise de árvore de pane, além
de uma excelente ferramenta de comunicação visual que reúne um conjunto de falhas de um
sistema, ela se completa com a análise de modo de falhas e efeitos [46] [41].
A.1.7 Predição de confiabilidade para componentes eletrônicos
Há vários modelos de predição de confiabilidade, sendo provavelmente a fonte de
dados de taxas de falha mais conhecida a MIL-HDBK-217 – Reliability Prediction of
Electronic Equipment, desenvolvida pelo Departamento de Defesa dos Estados Unidos o
DoD/USA [40] [44]. A norma MIL-HDBK-217 utiliza-se de dois métodos para predição da
taxa de falha dos componentes eletrônicos [46]: a) Contagem de Partes (Parts Count):
140
aplicado nas fase iniciais do projeto quando ainda não é possível conhecer detalhes e
condições de operação dos itens; e b) Análise de Esforços (Stress Analysis): aplicado nas
fases do projeto quando detalhes e operação de cada item já pode ser conhecida, e como
efeito, modifica a taxa de falha básica do componente.
O modelo genérico de taxa de falha dado pela norma MIL-HDBK-217 para o método
de Análise de Esforços é dado por [40] [46]:
λ p = λb π Q π E π C ...
(17)
onde:
λp é a taxa de falha final do componente;
λb é a taxa de falha básica do componente;
πQ é o fator de qualidade que corresponde aos efeitos dos níveis de qualidade do
componente;
πE é o fator de ajuste ambiental que corresponde a influência dos fatores ambientais na
variação da taxa de falha, com exceção da temperatura;
πC é o fator de complexidade que corresponde ao efeito de dispositivos múltiplos em
encapsulamento único.
A aproximação mais comum dada para taxa de falha é expressa em torno de falhas por
milhões de horas [40]. Para determinar as taxas de falha dos componentes aplicados nos
circuitos eletrônicos, ferramentas computacionais podem auxiliar no trabalho, como por
exemplo, o Relex Reliability Studio [45] na versão 10.0. Além da taxa de falha, esta
ferramenta proporciona o cálculo de confiabilidade para os diversos arranjos possíveis com os
diagramas de blocos de confiabilidade, montagem de árvore de falhas, entre outros atributos
utilizados no estudo de confiabilidade.
141
A.1.7.1 Método de cálculo
A confiabilidade de um sistema pode ser calculada usando uma de duas abordagens
básicas, a técnica analítica direta ou a simulação estocástica. A técnica analítica representa o
sistema por um modelo matemático, como abordado nas seções anteriores deste apêndice, e
avalia o índice de confiabilidade usando soluções matemáticas direta. A técnica de simulação
estima o índice de confiabilidade através de simulação do processo e comportamento aleatório
do sistema. O processo de simulação freqüentemente usado para estimar o índice de
confiabilidade é o Monte Carlo [50]. A simulação por Monte Carlo é uma técnica de análise
numérica que utiliza a amostragem estatística para solução de problemas. Um modelo
estocástico é amostrado de uma distribuição de probabilidade associada, que representa o
sistema sendo simulado, e estima-se a resposta por médias estatísticas [59].
142
Anexos
A.1 Nomenclatura para árvore de falhas
Tabela 15 – Simbologia, nome e descrição para árvore de falhas [56] [46].
Símbolo
Nome
Descrição
Porta lógica
E
O evento de nível superior ocorre se todos os
eventos de nível inferior ocorrerem em conjunto.
Porta lógica
OU
O evento de nível superior ocorre se qualquer um
dos eventos de nível inferior ocorrer.
Transferência
Indica continuação de uma árvore desenvolvida em
outro gráfico.
Transferência
Indica que o evento em análise continua em outra
árvore desenvolvida em outro gráfico.
Evento Topo
Evento que se constitui na falha descrita pela árvore.
Evento
intermediário
Evento que resulta da combinação de eventos de
nível inferior e que contribui para a ocorrência do
evento de nível superior.
Evento
básico
Evento básico que não requer maior
desenvolvimento e é estatisticamente independente
de outros eventos.
Evento
básico
Evento básico que é estatisticamente dependente de
outros eventos de menor nível, mas que não são
desenvolvidos.
143
A.2 Planilha para FMEA
Figura 62 – Exemplo de formato de uma planilha de FMEA [60].
144
A.3 Descrição do processador ERC32
A Figura 63 ilustra através de diagrama em blocos a arquitetura interna do processador
ERC32 da Atmel®.
Figura 63 – Diagrama em blocos da arquitetura interna do processador ERC32 [49].
As principais características do processador ERC32 são:
•
Tolerante à radiação: 300 krads;
•
Unidade de inteiro baseado na arquitetura SPARC V7;
•
Unidade de ponto flutuante de 32/64 bit;
•
EDAC e gerador de paridade;
•
Interface de memória: gerador de chip select, geração de waitstate e proteção de
memória;
•
DMA;
•
Timers: propósito geral, real-time clock, watchdog timer;
•
Controlador de interrupção com 5 entradas externas;
•
Interface de propósito geral (GPI);
145
•
Dupla UART;
•
Interface de 8 ou 40 bits de boot-PROM (Flash);
•
Performance de 12 MIPs em SYSCLK = 15 MHz.
146
A.4 Descrição do microcontrolador 80C32
A Figura 64 ilustra através de diagrama em blocos a arquitetura interna do
microcontrolador 80C32 da Atmel®.
Figura 64 – Diagrama em blocos da arquitetura interna do microcontrolador 80C32 [61].
As principais características do microcontrolador 80C32 são:
•
Tolerante à radiação: 30 krads;
•
Pino e instrução compatível com o 8032;
•
Quatro portas de I/O de 8 bits;
•
Três temporizadores/contadores de 16 bits;
•
256 bytes de RAM;
•
UART full-duplex;
•
Porta de reset assíncrona;
147
•
6 fontes, estrutura de 2 níveis de interrupção;
•
64 kbytes de espaço de memória de programa;
•
64 kbytes de espaço de memória de dado;
•
Modos de controle de potência;
•
Modo idle;
•
Modo power-down;
•
Freqüência de operação: 30 MHz.
148
Glossário
Backup: denominação utilizada para cópia de dados armazenados como medida de segurança.
Cordão Umbilical: denominação utilizada para uma conexão física que possibilita a depuração
do computador de bordo, recebendo telemetrias e enviando comandos.
Derating: operação de um componente numa condição inferior a sua potência máxima, a fim
de prolongar sua vida útil.
EEPROM – Electrically Erasable Programmable Read Only Memory: memória não-volátil
que permite a reescrita durante a operação do sistema.
Falha catastrófica: falha de caráter repentino que resulta na falta de capacidade completa de
um item em desempenhar todas as suas funções requeridas.
Firmware: denominação utilizada para software embarcado no processador.
FPGA – Field Programmable Gate Array: hardware reconfigurável, com suas funções
definidas pelo usuário.
Housekeeping: dados sobre o monitoramento do satélite, por exemplo: posicionamento,
temperatura, corrente elétrica, tensão elétrica, estado dos subsistemas ligados, entre outras.
Memória de massa: usada para gravar grande quantidade de dados para uso posterior.
149
SDRAM – Synchronous Dynamic Random Access Memory: memória volátil de acesso
aleatório que mantém os dados armazenados por apenas algum tempo, havendo necessidade
de atualizá-los periodicamente.
Seft test: seqüência de testes responsável por verificar normalmente em início de operação, se
um sistema encontra-se em estado operacional.
SRAM – Static Random Access Memory: memória volátil de acesso aleatório que mantém os
dados armazenados desde que seja mantida sua alimentação.
Vida útil: intervalo de tempo entre o início das operações e o fim por deterioração de um item.
FOLHA DE REGISTRO DO DOCUMENTO
1.
5.
CLASSIFICAÇÃO/TIPO
DM
2.
DATA
23 de junho de 2010
3.
REGISTRO N°
4.
N° DE PÁGINAS
DCTA/ITA/DM-027/2010
149
TÍTULO E SUBTÍTULO:
Análise de confiabilidade da CPU do satélite universitário ITASAT e proposta de melhoria
6.
AUTOR(ES):
Edson Vinci
7.
INSTITUIÇÃO(ÕES)/ÓRGÃO(S) INTERNO(S)/DIVISÃO(ÕES):
Instituto Tecnológico de Aeronáutica - ITA
8.
PALAVRAS-CHAVE SUGERIDAS PELO AUTOR:
1. Satélite. 2. Computador de Bordo. 3. Predição de Confiabilidade. 4. Redundância. 5. Tolerância a falha.
9. PALAVRAS-CHAVE RESULTANTES DE INDEXAÇÃO:
Satélites artificiais; Sistemas de computadores embarcados; Análise de confiabilidade; Hardware;
Redundância; Tolerância a falhas; Engenharia eletrônica; Engenharia aeroespacial
10.
APRESENTAÇÃO:
X Nacional
Internacional
ITA, São José dos Campos. Curso de Mestrado. Programa de Pós-Graduação em Engenharia Aeronáutica
e Mecânica. Área de Sistemas Aeroespaciais e Mecatrônica. Orientador: Osamu Saotome. Defesa em
18/06/2010. Publicada em 2010.
11.
RESUMO:
Esta tese apresenta uma análise do computador de bordo para o satélite universitário ITASAT,
propondo redundância interna de hardware nos itens críticos e comparando índices de confiabilidade
entre a utilização de componentes de aplicação espacial e componentes COTS – Commercial off-theshelf. O ITASAT consiste num projeto de desenvolvimento de um satélite tecnológico de pequeno porte
pela parceria entre o Instituto Tecnológico de Aeronáutica – ITA, o Instituto Nacional de Pesquisas
Espaciais – INPE e a Agência Espacial Brasileira – AEB. Após uma breve explanação sobre os
subsistemas que compõem um satélite genérico, as principais características funcionais e requisitos
preliminares para o projeto do hardware do computador de bordo do satélite universitário ITASAT são
apresentadas. Em seguida, definido o sistema computacional do segmento espacial do ITASAT como
ACDH – Attitude, Control and Data Handling, é organizado o computador de bordo em módulos. O
módulo denominado de CPU é analisado com componentes de aplicação espacial e sua confiabilidade de
hardware calculada para uma vida útil de dois anos de missão, seguindo a norma militar MIL-HDBK217F com suporte da ferramenta computacional Relex Reliability Studio 2008. Não atingindo o nível
especificado de confiabilidade, aplicou-se redundância cold standby ao módulo da CPU, o que o tornou
um módulo tolerante a falhas. Esta técnica de redundância exigiu duas unidades adicionais, de
gerenciamento de redundância e de chaveamento. Baseando-se nesta configuração redundante, é
abordado um conjunto de mecanismos de verificação e projetos, conjuntamente denominados de FDIR –
Failure Detection, Isolation and Recovery, que têm como objetivo proteger a integridade do módulo da
CPU, evitando a perda de suas partes ou totalidade, na presença de uma falha simples, de forma a
assegurar o desempenho da missão durante sua vida útil. Novamente, foi calculada a confiabilidade do
módulo da CPU com redundância cold standby e os resultados obtidos mostraram um acréscimo do nível
de confiabilidade suficiente para atender a esse requisito. Por fim, foram substituídos os componentes de
aplicação espacial por componentes COTS e recalculada a confiabilidade para o módulo da CPU. Os
resultados obtidos com as configurações estudadas para o módulo da CPU mostraram que a aplicação de
tolerância a falhas eleva o índice de confiabilidade e a combinação da utilização de componentes de
aplicação espacial e componentes COTS garante, em algumas configurações, a superação do índice de
confiabilidade de hardware especificado.
12.
GRAU DE SIGILO:
(X ) OSTENSIVO
( ) RESERVADO
( ) CONFIDENCIAL
( ) SECRETO