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.