sistemas espaciais de computadores. introdução definindo o sistema –requisitos, arquitetura,...
Post on 22-Apr-2015
102 Views
Preview:
TRANSCRIPT
Sistemas Espaciais de Computadores
Sistemas Espaciais de ComputadoresSistemas 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 soloComputadores de Bordo + suporte em solo
• Tipos de sistemas # CaracterísticasTipos 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 Software Hardware
• Hardware• Software• Documentação
• Sistema Operacional
• Aplicativos
• Documentação
• 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 NÍVEL DE COMPUTADOR CAPACIDADES DE: Cronograma Custo Risco Funcionalidade Características Físicas:
Tamanho Pêso Potência
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) Testabilidadeb) Confiabilidadec) Usabilidaded) Disponibilidadee) Flexibilidadef) Mantenabilidadeg) Intercambiabilidadeh) 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
Centralizadaa) 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.
Distribuidaa) Barramento comum p/ todos os
processadores
b) Uso de protocolos nas comunicações, tipo comando/resposta
c) Facilidade de expansão.
Anela) Maior facilidade de adicionar
nós sem afetar a unidade central
b) Falha em uma unidade INTERFERE nas demais (alto risco).
Análise Funcional e Fluxo de Dados
Elementos do Sistema de Computadores
Primary ProcessingApplication
Commonly Available ISAor Supplier
General Purpose 1750 80C85680X0 80C86
Vector Processing ZoranAT&TITT
Not common inspace
Signal Processing Inmos (Transputer)Texas InstrumentsTRW
Classes of Instruction Set Arquiteture. Different ISAs do whatdifferent Application demand. Each of these commonly available ISAswould be considered off-the-shelf; however, the vector and signalprocessing units will contain custom circuitry for specializedprocessing
ISA Instruction Set Arquiteture
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-OrderLanguage.
Attribute Assembly LanguageDevelopment
Higher-Order LanguageDevelopment
ThroughputEfficiency
(+) More efficient.Implementor has control
(-) Less than or equal toassembly. Compiler mustoptimize.
Maintenability(-) Difficult to maintain.Implementation is notclear from code.
(+) Significant maintenanceadvantage. Language oftenself-documenting. Providefriendly interface.
Testability(-) Harder to test.Requiriments not clearlytraceable toimplementation.
(+) Structure and imposedstandards make HOL moretestable.
Size
(+) More efficient.Implementor has morecontrol.
(-) Compilers tend togenerate 30-35% more codethan hand assembly. *(50-65% with encapsulationprovided by Run-Timeloaders of some object-oriented languages)
DevelopmentEnvironment
(-) Often very meager (+) Many rich and robustenvironments
Life-cycleCosts
(-) Not well suited to largefunctions (> 30 K lines ofcode).
(+) Generally lower becauseof 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çõesRecursos para as aplicações
• Recursos para as Funções do Recursos para as Funções do Sistema OperacionalSistema Operacional.
Critérios de Seleção de LinguagensCRITERION COMMENTS and KEY ParametersCompatibility 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 warrantconfidence that it has few remaining errors, is wellmaintained., and will continue to be supported for therelevant future? Applies to the compiler and thedevelopment tools
Compiler Quality Several compilers may be available for a candidatelanguage, all of which run on the development platform andgenerate code for the target processor. How useful are thediagnostics; what is the effective rate for compilingstatements; are all language features implemented; is thecompiler standardized? Is it certified? (See Efficiency andPortability)
Data Structure The suitability and complexity of the dada handlingapproach: large common data bases; bit/byte-levelinstructions; kind of structure supported; data typingfeatures; specialized input and output.
Efficiency Language issue: uncomplicated syntax and semantics toclearly express tasks.
Portability (*) Language issue: If you want portability, select a standardlanguage and restrict its use to standard features (seebelow)Compiler issue: compilers for even standardized languagesmay implement unique features which defeat portability
Environment Is a completed and integrated set of automateddevelopment tools available for the candidate language andcompiler?
Personnel Skill Ease of use, especially in the domain of the problem
Other Development context: does a candidate language supportstructured methods, object-oriented design andprogramming, 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 ofConcern
Key Factor Comments
ManagingSoftwareRequirements
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
Traceability isdifficult to retrofit
ConfigurationManagement
Test designreviews
SoftwareDevelopment,Test, andSupport
Explicit decision as to specification-based,prototype, or approach to development.
Standards, reviews, and audits play keyroles.
Integrated software tool environment,including CASE tools, can increaseproductivity.
Test design and test resources must beconsidered 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 languageselection.
Tailor standards toproject.
Considerer inter-vendorcompatibility inselecting CASEtools.
Assess capabilitieswith pre-awardsurveys and sitevisits.
Note cost of testsupport software(e.g., simulationsand analysis tools)
Managing theSoftwareProject
Management excellence is key of success. Principal conceptual-stage concerns: project
scope; resources required; allocated budget;feasibility analyses; schedule realism.
Project organization concerns: division andassignment of tasks; delegation of authority;reporting mechanisms; informalcommunications.
Project staffing is critical to successfulsoftware development.
Project direction and control requires regularcollection and display of progress data.
Personnel issues: motivation, leadership,and communication are worthwhile areas forcontinuous improvement
Previous lessonslearned are rarelyapplied.
Informal technicalinterchangemeetings areimportant; butoften poorly used.
Contractors oftenresist datacollection andreporting becauseof 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 comprotocolo TCP/IP para aplicações espaciais envolvendo "rede desatélites".
BIBLIOGRAFIA:Autores:
Steven Glaseman; The Aerospace CorporationL. Jane Hansen, Microcosm, Inc.Craig H. Pollock, TRW, IncMerlin Thimlar, The Aerospace Corporation
Ref.Wertz, J. R.; Larson, Wiley J. ; Space Mission Analysis and Design, Dordrecht,Kluwer, Netherlands, 1991, p. 541-577.
top related