Sistemas Espaciais de Computadores
Sistemas Espaciais de Computadores
• Introdução
• Definindo o Sistema
– Requisitos, Arquitetura, Elementos do Sistema
• Estimação dos Recursos
– Processamento de Tarefas, Tamanho do Software e Throughput
• Discussão sobre as Fases de Desenvolvimento
– Seleção do Hardware, Ambientes/Custos/Ferramentas e Metodologias de
Desenvolvimento
• Integração e Teste de Sistema de Computadores
Introdução - Sistemas Modernos
• Computadores de Bordo + suporte em solo
• Tipos de sistemas # Características:
– Sistemas embarcados # controle de tempo-real, alta confiabilidade
– Computador de Bordo # utilizados para: navegação, monitoração, sensoriamento,
processamento, armazenamento dos dados e comunicações.
– Computador(es) de apoio de solo # pós-processamento, compressão de dados, interfaces
com usuário, comandos para o satélite e monitoração remota (“saúde” do veículo, status e
manutenção)
Definindo o Sistema
Introdução - Divisão de um sistema
Sistema
•
•
•
Hardware
Software
Documentação
Software
•
•
•
Sistema Operacional
Aplicativos
Documentação
•
•
Hardware
•
•
•
•
Periféricos
CPU
Memória
Documentação
Desenvolvidos pelo usuário ou sob-encomenda
Tempo-real ou não
Introdução - Características Observáveis
FATORES QUE DEVEMOS AVALIAR NA FASE DE PROJETO:





NÍVEL DE SISTEMA
Cronograma
Custo
Risco
Funcionalidade
Características Físicas:
 Tamanho
 Pêso
 Potência








NÍVEL DE COMPUTADOR
Troughput
Memória
Isolamento à Radiação
Arquitetura do Conjunto de
Instruções
Disponibilidade de Emulador
Disponibilidade de Software
Capacidade de Programação
Ferramentas de
Desenvolvimento
a)
b)
c)
d)
e)
f)
g)
h)
CAPACIDADES DE:
Testabilidade
Confiabilidade
Usabilidade
Disponibilidade
Flexibilidade
Mantenabilidade
Intercambiabilidade
De substituição
Modelo Típico de Sistema
•
•
•
•
Armazenamento (RAM)
Troughput
Processamento (CLOCK):
Tipo de CPU
Definindo o Sistema Típico
• Identificar os modos operacionais “payload”, barramento, etc.
Para chegarmos ao computador típico:
•
•
•
•
•
•
Def. modos e estados operacionais do sistema
Dividir funcionalmente e reservar os requisitos computacionais exigidos para os ambientes:
espaço e segmento solo, subsistemas, e para o hardware e software.
Avaliar interfaces internas e externas (análise de fluso de dados)
Avaliar as arquiteturas candidatas (arquiteturas de procesamento, de dados e de hardware)
Selecionar a arquitetura “típica”
Desenvolver a configuração do sistema “típico’ a partir da arquitetura e requisitos de missão.
Procedimentos para obter o
“Sistema Típico”
Atendendo às solicitações.
•
•
•
•
•
•
“O que o sistema deve fazer?
“Por que” deve ser feito
(desafiar as necessidades)?
“Como” concluí-lo e
“Quais”altenativas?
“Que funções” reservar para as
várias partes do sistema?
‘Tais Funções são tecnicamente
possíveis?”
“Como Testar” (solicitações
satisfeitas?)
Divisão Funcional - Modularização
•
•
•
•
•
•
•
Identificar e agrupar funções de sistema:
Similaridade funcional
Complexidade do proc.
Tipos de processamento (dados x sinais)
Urgência dos Processos
Solicitações de tempo e “throughput”
Necessidade de armazenamento
Necessidade de intervenção humana e
segurança de vôo.
•
•
•
•
•
•
•
Remodularização:
Isto funciona? Faz exatamente
o que se quer que faça?
É simples e óbvio? (Cada
componente faz exatamente 1
coisa?)
É Eficiênte? Rápido?
Proporciona uma interface
clara?
É confiável?
É possível a manutenção?
É possível ser testada?
Onde implementar, Bordo ou Solo?
 Sistemas bordo/solo são autônomos?
 Se não: Apresentam módulos com “tempo crítico”?
Resposta: Considerando a TELEMETRIA...
• Wideband (> veloc.) => Processo “pode” ficar em SOLO
(Transmissão de dados sem tratamento a bordo)?
• Narowband (< velocidade) => Processo “DEVE”
manipular/comprimir dados a bordo para uma posterior transmissão
ao Solo
Onde Executar? RAM e Firmware
• Firmware => processos permanentes (atualização desnecessária).
• RAM => Processos que podem ser atualizados após lançamento.
(“críticos” mas “não vitais” à missão).
• Hardware=> Operações “seletivas”. ( interfaces x soft-drivers).
Selecionando a Arquitetura
Perguntas:
1) A arquitetura permite satisfazer as necessidades da missão?
2) A arquitetura é complexa?
3) Pode-se testar o sistema considerando tal arquitetura?
4) Pode-se “manter” o sistema com esta arquitetura?
Tipos de Arquiteturas
Características das Arquiteturas
Centralizada
a) Interface entre unidades de
processamento e um
computador central (nó
central)
b) não permite adicionar nós sem
afetar hardware e software do
sistema central
c) CPU Central => ponto de falha
=> > risco.
d) falha em uma unidade não
interfere nas outras.
Distribuida
Anel
a) Barramento comum p/ todos os a) Maior facilidade de adicionar
processadores
nós sem afetar a unidade
central
b) Uso de protocolos nas
comunicações, tipo
b) Falha em uma unidade
comando/resposta
INTERFERE nas demais (alto
risco).
c) Facilidade de expansão.
Análise Funcional e Fluxo de Dados
Elementos do Sistema de Computadores
ISA Instruction Set Arquiteture
Primary Processing
Application
Commonly Available ISA
or Supplier
General Purpose
1750
680X0
80C85
80C86
Vector Processing
Zoran
AT&T
ITT
Not common in
space
Signal Processing
Inmos (Transputer)
Texas Instruments
TRW
Classes of Instruction Set Arquiteture. Different ISAs do what
different Application demand. Each of these commonly available ISAs
would be considered off-the-shelf; however, the vector and signal
processing units will contain custom circuitry for specialized
processing
ISA - Critério de Escolha
• Facilidades (instruções) para acessar o hardware
• Vantagens e desvantagens de utilizar ISAs de “uso-geral”(*) ou
“customizadas”
– (*) desvantagem: velocidade. (Não foram projetadas para algoritimos
particulares => (>) software
– (*) vantagem: Economia e riscos de desenvolvimento de uma ISA
dedicada.
• Firmware
• Linguagens de programação.
Códigos e Dados - Onde ficarão?
RAM ou ROM?
1) Códigos e dados não são modificados. ROM
2) Códigos e dados críticos para: o satélite, segurança da “payload”,
tripulantes e missão => ROM (problemas de radiação espacial das
RAMs)
3) Códigos e Dados para o lançamento. (Satélites sobem com
coomputador de bordo desligados!).
4) Onde se exige flexibilidade PÓS-LANÇAMENTO => download p/
RAM
Linguagens
TRADEOFFS between Development in Assembler vs. Higher-Order
Language.
Attribute
Throughput
Efficiency
Maintenability
Testability
Assembly Language
Development
(+) More efficient.
Implementor has control
(-) Difficult to maintain.
Implementation is not
clear from code.
(-) Harder to test.
Requiriments not clearly
traceable to
implementation.
(+) More efficient.
Implementor has more
control.
Size
Development
Environment
Life-cycle
Costs
(-) Often very meager
(-) Not well suited to large
functions (> 30 K lines of
code).
Higher-Order Language
Development
(-) Less than or equal to
assembly. Compiler must
optimize.
(+) Significant maintenance
advantage. Language often
self-documenting. Provide
friendly interface.
(+) Structure and imposed
standards make HOL more
testable.
(-) Compilers tend to
generate 30-35% more code
than hand assembly. *(5065% with encapsulation
provided by Run-Time
loaders of some objectoriented languages)
(+) Many rich and robust
environments
(+) Generally lower because
of ease in maintenance.
Estimando os Recursos
• Processamento de Tarefas
• Tamanho e Throughput do Software
• Critérios de Seleção de Linguagens
Tarefas
• Sistema de Controle de Bordo
– Determinação e Controle de Atitude e Órbita (processamento
matemático intensivo, exigindo rigorosamente: precisão e rapidez)
• Sistema de gerenciamento
– Detecção de falhas, correções, agendamento de eventos de longa
duração, gerenciamento do sistema da “payload”. Envolve fluxo de
controle e lógica intensiva. Pouco processamento de ponto-flutuante.
• Software de dados da Missão
– Manipulação (e compactação) de dados. Requer processador de sinais
e grande capacidade de armazenamento.
• Sistema Operacional
Tamanho do Software e Throughput
• Recursos para as aplicações
• Recursos para as Funções do
Sistema Operacional.
Critérios de Seleção de Linguagens
CRITERION
Compatibility
COMMENTS and KEY Parameters
Extent of match between language and types of
computations and applications the processor will face -Real-time, interactive, highly accurate, etc (See Efficiency)
Maturity
Has the language been widely enough used to warrant
confidence that it has few remaining errors, is well
maintained., and will continue to be supported for the
relevant future? Applies to the compiler and the
development tools
Compiler Quality
Several compilers may be available for a candidate
language, all of which run on the development platform and
generate code for the target processor. How useful are the
diagnostics; what is the effective rate for compiling
statements; are all language features implemented; is the
compiler standardized? Is it certified? (See Efficiency and
Portability)
Data Structure
The suitability and complexity of the dada handling
approach: large common data bases; bit/byte-level
instructions; kind of structure supported; data typing
features; specialized input and output.
Efficiency
Language issue: uncomplicated syntax and semantics to
clearly express tasks.
Portability (*)
Language issue: If you want portability, select a standard
language and restrict its use to standard features (see
below)
Compiler issue: compilers for even standardized languages
may implement unique features which defeat portability
Environment
Is a completed and integrated set of automated
development tools available for the candidate language and
compiler?
Personnel Skill
Ease of use, especially in the domain of the problem
Other
Development context: does a candidate language support
structured methods, object-oriented design and
programming, information hiding, abstraction, etc
Níveis de Testes
Integração e Testes de Sistemas de Computadores
•
Testes (software + hardware + documentação) caminham com o projeto.
– Alternativas: uso de procedimentos Top-Down.
•
•
•
Testa-se o sistema com o computador se tornando um sub-sistema na configuração
do sistema.
Calibração “só acontece em órbita” depois de procedimentos de inspeção do
sistema.
Métodos de Teste de software (DOD-STD-2167).
– Planos de Teste: Definido no início do projeto e mantido.
– Procedimentos de Teste:
•
•
•
Resultados 100% em todas as fases.
Tolerâncias <=> Resultados esperados
“Pro-leigo” (Documentação: Qualquer pessoa “leiga” deve ser capaz de realizar o teste).
– Documentação:
•
•
Textos sem erros ou interpretação dupla.
Identificar e entender todas as anormalidades (anotar)
Outras considerações no Desenvolvimento de Software
Areas of
Concern
Managing
Software
Requirements
Software
Development,
Test, and
Support
Managing the
Software
Project
Key Factor
 Software considered at operational level.
 Define explicit, derived, assumed
requirements
 Complete traceability of software
requirements.
 Requirements instability to be managed, not
suppressed.
 Requirements testability is crucial to cost and
schedule
 Explicit decision as to specification-based,
prototype, or approach to development.
 Standards, reviews, and audits play key
roles.
 Integrated software tool environment,
including CASE tools, can increase
productivity.
 Test design and test resources must be
considered from the conceptual stage on.
 Quality management is key to reliability.
 Software must tolerate faults for manned
missions.
 Post-deployment support resource must be
part of initial software costing and language
selection.
 Management excellence is key of success.
 Principal conceptual-stage concerns: project
scope; resources required; allocated budget;
feasibility analyses; schedule realism.
 Project organization concerns: division and
assignment of tasks; delegation of authority;
reporting mechanisms; informal
communications.
 Project staffing is critical to successful
software development.
 Project direction and control requires regular
collection and display of progress data.
 Personnel issues: motivation, leadership,
and communication are worthwhile areas for
continuous improvement
Comments
 Traceability is
difficult to retrofit
 Configuration
Management
 Test design
reviews
 Tailor standards to
project.
 Considerer intervendor
compatibility in
selecting CASE
tools.
 Assess capabilities
with pre-award
surveys and site
visits.
 Note cost of test
support software
(e.g., simulations
and analysis tools)
 Previous lessons
learned are rarely
applied.
 Informal technical
interchange
meetings are
important; but
often poorly used.
 Contractors often
resist data
collection and
reporting because
of costs.
CONCLUSÕES:



Integração e dependência: Hardware x Software x Documentação
Hardware: Condições altamente Particulares (espaço), "CAPACIDADES"
(Solo) => Custo x Risco => Missão
Software: Real-time (on-board+Solo) / Tempo Crítico (Solo) => confiabilidade
(compiladores + ferramentas // precisão + segurança).
 Considerar Critérios de Seleção da Linguagem => Capacidade de
armazenamento (Código + Dados).
COMENTÁRIOS


Repararam que um sistema de computadores em aplicações espaciais é
semelhante a uma Rede de computadores num ambiente serviços /
cliente?
Estudos recentes consideram a utilização do modelo de rede com
protocolo TCP/IP para aplicações espaciais envolvendo "rede de
satélites".
BIBLIOGRAFIA:
Autores:
Steven Glaseman; The Aerospace Corporation
L. Jane Hansen, Microcosm, Inc.
Craig H. Pollock, TRW, Inc
Merlin Thimlar, The Aerospace Corporation
Ref.
Wertz, J. R.; Larson, Wiley J. ; Space Mission Analysis and Design, Dordrecht,
Kluwer, Netherlands, 1991, p. 541-577.