ITA – Instituto Tecnológico de Aeronáutica
Relatório Final de Projeto
Sistemas Embarcados de Tempo Real – CE-235
Sistema de Coleta de Dados Específicos - SCDE
Marcelo de Lima Bastos Moreira
marcelolbm@yahoo.com.br
Prof. Adilson Marques da Cunha
São José dos Campos, 28 de Novembro de 2005
Índice
1. Introdução...3
1.1. Motivação...3
1.2. Contexto ...3
1.3. Objetivação do Protótipo de Sistemas de Software...4
1.4. Redução do Escopo...5
1.5. Especificação de Requisitos...5
1.5.1. Requisito #1 ...5
1.5.2. Requisito #2 ...5
1.5.3. Requisito #3 ...6
1.5.4. Requisito #4 ...6
1.6. Ordem de Apresentação do Projeto Final...6
1.6.1. Na seção 1: ...6
1.6.2. Na seção 2: ...6
1.6.3. Na seção 3: ...6
2. Desenvolvimento...7
2.1. Linha Base Funcional – 1ª Fase do RUP - Iniciação (Inception) ...7
2.2. Linha Base Alocada – 2ª Fase do RUP - Elaboração (Elaboration)...7
2.2.1. Da Geração de Relatórios e Papéis Assumidos. ...8
2.2.2. Da Compilação de Diagramas e Outros ...8
2.3. Linha Base de Produto - 3ª Fase do RUP – Construção (Construction) ... 12
2.3.1. Diagrama de Classes ... 12
2.3.2. Diagramas de Estrutura ... 13
2.3.3. Diagramas de Estados ... 16
2.3.4. Diagrama de Seqüência e Log ... 16
2.3.2. Código Gerado ... 19
2.3.3. Modelo do Rational Rose RealTime ... 19
2.4. Qualidade, Confiabilidade e Segurança de Software ... 19
3. Conclusões, Recomendações e Sugestões... 20
3.1. Conclusões ... 20
3.2. Recomendações... 20
3.3. Sugestões ... 20
2
1. Introdução 1.1. Motivação
O Projeto de Sistema Embarcado de Tempo Real, SCDE – Sistema de Coleta de Dados Específicos, foi desenvolvido com o objetivo de conseguir uma imagem de uma posição terrestre (expressada em latitude e longitude, por exemplo) de interesse especifica, e posteriormente transmitir essa imagem a uma estação de controle.
Dada a complexidade do projeto, optou-se dividir as diversas atividades do sistema entre os membros da equipe de desenvolvimento.
Este Projeto foi desenvolvido utilizando ferramentas CASE (“Computer Aided Software Engineering”), que automatizam e coordenam o desenvolvimento de sistemas complexos desenvolvidos em equipe.
1.2. Contexto
O SCDE tem o objetivo de conseguir uma imagem de uma posição da Terra. Para atingir essa missão é necessário cumprir certos requisitos como o controle de atitude, controle térmico de equipamentos, gerenciamento da câmera, controle e gerenciamento dos dispositivos envolvidos, etc. todas estas atividades devem ser programadas e testadas para logo serem embarcadas dentro do computador a bordo.
O caso de uso “Determinar Atitude”, encarrega-se de obter as medidas dos sensores do satélite, “Controlar Atitude”, aciona os atuadores correspondentes para atingir uma atitude pré-estabelecida.
Paralelamente o caso de uso “Controlar Temperatura” mantêm a temperatura dos
O caso de uso “Registrar Imagem” é responsável pela captura da imagem correspondente e finalmente “Transmitir Imagem” estará a cargo da transmissão da imagem do satélite até a estação de controle.
1.3. Objetivação do Protótipo de Sistemas de Software
Enunciado do Problema do Sistema: "Construção de um Sistema de apontamento do satélite na orientação desejada que seja capaz de funcionar em tempo real e cumprir uma missão de orientação da posição de um satélite (determinação e controle de atitude) de uma coordenada qualquer, para outra coordenada desejada anteriormente estabelecida.”
Solução Adotada para o Sistema: "Desenvolver um Protótipo de sistema que tenha como missão satisfazer a “Controlar Atitude” do satélite, composto por um sistema de software embarcado de aplicação em tempo real, que forme parte de um sistema mais complexo, ganhando com isto maior produtividade, eficiência, desempenho e lucros maiores."
Intitulação: Protótipo de Sub-sistema de Controle de Atitude – SCA_SCDE
Enunciado do Problema do Sistema: "Construção de um sistema de gerenciamento da câmera que também seja capaz de funcionar em tempo real e cumprir com as operações da captura da imagem para posteriormente transmitir a imagem a uma estação de
controle.”
Solução Adotada para o Sistema: "Desenvolver um Protótipo de sistema que tenha como missão cumprir a “Registrar Imagem” do satélite, composto por um sistema de software embarcado de aplicação em tempo real, que gerencia o funcionamento da câmera, segurando a imagem até que esta seja solicitada para sua posterior transmissão a uma
4
estação de controle.”
Intitulação: Protótipo de Sub-sistema de Aquisição de Imagens – SAI_SCDE
1.4. Redução do Escopo
O Projeto de Sistema de Software do SCDE limita-se ao desenvolvimento conceitual do sistema e a geração de fragmentos de software, para se estudar a viabilidade do projeto e principalmente verificar as vantagens do emprego de boas técnicas e procedimentos, tal como o RUP (Processo Unificado da Rational) e ferramentas CASE que auxiliam o desenvolvimento, tal como o Rose RealTime, da Rational.
A parte do hardware foi assumida como pronta e funcional, principalmente quanto aos diversos sensores e motores que o projeto exige, sendo necessária uma re-configuração no caso exista uma mudança de hardware. A título de exemplo, o caso de uso desenvolvido tem interface com atuadores do satélite os quais se assume que eles não se saturam, isto é, que estamos operando em condições nominais.
1.5. Especificação de Requisitos
A seguir, apresentam-se os requisitos do Sistema de Coleta de Dados Específicos dando ênfase a unidade de Software de Controle de Atitude.
1.5.1. Requisito #1
Obter a orientação atual do satélite, isto se consegue recuperando as medidas dos sensores.
1.5.2. Requisito #2
Enviar medidas para o SDAS e receber dados de volta para uma redução nos erros das mesmas.
1.5.3. Requisito #3
Cálculo do controle a ser aplicado no satélite baseado no erro entre a posição desejada e a atual.
1.5.4. Requisito #4
Aplicação do controle no satélite através dos atuadores presentes no mesmo.
1.6. Ordem de Apresentação do Projeto Final
A seguir é mostrada a ordem escolhida para a apresentação do Projeto Final com uma breve descrição de cada uma de suas partes.
1.6.1. Na seção 1:
Apresenta-se a Motivação, o Contexto, o Enunciado do problema e da solução escolhida (Objetivação do Protótipo de Sistemas de Coleta de Dados Específicos), a Redução de Escopo e a Especificação de Requisitos deste Projeto Final.
1.6.2. Na seção 2:
Apresentam-se os artefatos gerados nas fases de Iniciação (Inception) – Planos de Desenvolvimento, Plano de Iniciação e Iteração, Plano de Gerenciamento de Requisitos, Plano de Visão, Glossário, Solicitação dos Principais Envolvidos, Lista de Riscos, Especificação Suplementar, Modelo de Casos de Uso e Caso de Desenvolvimento – e Elaboração (Elaboration) – Casos de Uso Estendidos, Diagramas de Seqüências, Diagramas de Classe, Diagramas de Transição de Estado e Código Sincronizado.
1.6.3. Na seção 3:
Apresentam-se as conclusões, recomendações e sugestões.
6
2. Desenvolvimento
O Sistema de Coleta de Dados Específicos (SCDE) foi desenvolvido seguindo o Processo Unificado, de forma incremental e iterativa, a partir de cada USC até a integração do ICSC SUII. Os itens seguintes descrevem o processo de desenvolvimento dentro de cada fase do RUP.
2.1. Linha Base Funcional – 1ª Fase do RUP - Iniciação (Inception)
Os artefatos gerados na primeira fase do Processo Unificado, na primeira iteração do plano de desenvolvimento da Unidade de Software de Computador (USC) Sistema de Manutenção de Software de Bordo (SMSB), seguem listados abaixo:
SCAS_01_PDS: Plano de Desenvolvimento de Software SCAS_02_CD: Caso de Desenvolvimento
SCAS_03_VS: Visão
SCAS_04_SPE: Solicitações dos Principais Envolvidos SCAS_05_ES: Especificações Suplementares
SCAS_06_GLO: Glossário SCAS_07_LR: Lista de Riscos
SCAS_08_PI: Plano de Iteração - Iniciação SCAS_09_MCU: Modelo de Casos de Uso
SCAS_10_PGR: Plano de Gerenciamento de Requisitos
2.2. Linha Base Alocada – 2ª Fase do RUP - Elaboração (Elaboration)
Nesta seção são apresentados os artefatos trabalhados por mim na 2ª Fase do RUP para Pequenos Projetos, bem como definições sobre o funcionamento interno do SCDE e sua comunicação com módulos externos. Segue compilado aqui também um conjunto de diagramas que descrevem o comportamento e estrutura do sistema.
2.2.1. Da Geração de Relatórios e Papéis Assumidos.
Foi determinado que a minha Unidade de Software de Computador, Sistema de Controle de Atitude (SCAS), é a USC que deve implementar o controle de atitude do satélite.
Nesta etapa do projeto, além de participar da integração das USCs e modelagem inicial do SCDE, também fui responsável, junto aos outros membros, da elaboração e revisão dos seguintes artefatos:
03 – SCDE - Visão
07 – SCDE - Especificações Suplementares
Para isso, assumi os seguintes papéis previstos no RUP:
· Requirements Specifier
· Requirements Reviewer
· Software Architect
· Design Reviewer
· Technical Writer
2.2.2. Da Compilação de Diagramas e Outros
Segue descrita nesta seção o comportamento e estrutura definida para que o SCDE cumpra sua parte na missão atribuída ao VANT-EC-SAT, ou seja, Registrar uma Imagem sob demanda.
Missão: Registrar Imagem
O diagrama de blocos abaixo ilustra como os Itens, Componentes e Unidades de software irão colaborar para cumprir a missão principal d SUII, “Registrar Imagem”. A seguir, uma descrição do funcionamento interno desta missão, onde já consta a regra de negócio e detalhes estruturais (portas, comunicação, parâmetros, comandos, mensagens e comportamento) do sistema.
8
A numeração no diagrama acima indica os seguintes passos a cumprir para realizar a missão:
1. A Estação de Controle enviará para o satélite, via Telecomando, o comando
“Registre uma Imagem (latitude, longitude)”, onde latitude e longitude serão os parâmetros. O satélite irá receber esta mensagem através do componente SGCS, unidade SCTC.
2. O comando será então repassado para o componente SCDE. Isso ocorrerá em duas portas. A primeira será a Porta de Manutenção do Satélite, destinada a enviar comandos em geral e obter dados de telemetria sobre a Estrutura do satélite (tudo o que não for a carga útil). O comando recebido será “Preparar Registro da Imagem”. Esta porta estará diretamente conectada com a unidade SMSB.
3. A segunda porta é a Porta de Carga Útil. Esta porta está conectada à unidade SCIS, e receberá o mesmo comando (“Registrar Imagem”). Ao receber o comando, o SCIS irá se encarregar de preparar a câmera para registrar a imagem, mas ficará
num estado aguardando uma confirmação do SMSB de que a foto pode ser batida (item 7, abaixo)
4. O SMSB, recebendo o comando “Preparar Registro da Imagem”, irá enviar comandos para SCTS e SCAS, para que o satélite seja preparado para a foto. Para SCTS será enviado um comando “Envie o status da temperatura na área (câmera)”.
SCTS deverá possuir um diagrama de estado onde a temperatura seja sempre regulada, e deverá responder ao SMSB sobre o status em determinada área do satélite quando solicitado. A área, neste caso, é o parâmetro da mensagem.
1. SMSB também enviará um comando “Ajuste a atitude para apontar para (latitude, longitude)” para SCAS. Novamente, latitude e longitude são os parâmetros do comando.
2. SCAS irá então se comunicar com SDAS para que o ajuste da atitude seja feito.
Esta comunicação será melhor detalhada durante a próxima iteração deste projeto.
Tanto SCAS quanto SCTS irão retornar mensagens de “ok” para SMSB, informando que o satélite está pronto para registrar a imagem. SMSB irá repassar esta mensagem para SCIS, que efetua a fotografia. SCIS então irá enviar um registro de que a fotografia foi feita para SMSB, e irá transmitir os dados brutos da fotografia para o componente SGCS.
SMSB também irá enviar para SGCS uma mensagem com o status do satélite no momento da fotografia, para análise.
O comportamento do SGCS está fora do escopo desta iteração, mas em conversas iniciais com a equipe responsável, foi definido que:
• SCDE-SCIS estará conectado a SGCS-SCCD ou SGCS-SADC.
• SCDE-SMSB estará conectado a SGCS-SCTC e a SGCS-SCTM.
Ao receber a imagem de SCIS, SGCS-SCCD ou SGCS-SADC deverá analisar para ver se é aceitável (se não tem, por exemplo, cobertura de nuvens), e irá decidir se envia estes dados para EC ou se solicita uma nova fotografia.
10
Com base no comportamento descrito acima, foram criados Diagramas de Contexto (Caso de Uso) em diferentes níveis de abstração para o SCDE. Num nível maior de abstração, são mostrados os Itens de Configuração de Software que participam do caso de uso
“Registrar Imagem”:
Reduzindo o nível de abstração, temos a visualização dos Componentes e Unidades de Software que colaboram para a realização deste caso de uso.
2.3. Linha Base de Produto - 3ª Fase do RUP – Construção (Construction)
Esta Seção apresenta os produtos de software gerados com base nas especificações, casos de uso e requisitos levantados até a fase anterior, assim como o comportamento e comunicação definidos entre as USCs e as CSCs componentes do Satélite Universitário INPE-ITA (SUII).
2.3.1. Diagrama de Classes
Definida a forma inicial do sistema, foi possível criar as cápsulas (classes ativas do Rational Rose RealTime) componentes do sistema.
12
2.3.2. Diagramas de Estrutura
Nesta Seção são apresentados os diagramas de estrutura mais representativos do SCDE: o de interação com o SGCS e o de comunicação interna entre as USCs.
Conforme descrito na Seção 2.2.2, em discussões entre os grupos do SCDE e do SGCS foi definido que os componentes deveriam se comunicar através de duas portas distintas:
uma para manutenção e outra para a carga útil.
Isso permite que haja uma separação entre a carga útil e a estrutura do satélite, possibilitando a reutilização da mesma estrutura para uma nova carga útil futuramente.
Internamente ao SCDE, foi decidido manter protocolos distintos para a comunicação entre cada par de USCs. Isso simplificou o processo de entendimento e depuração do sistema, reduziu o número de sinais para cada protocolo (e conseqüentemente, o número de sinais disponíveis para cada porta) e tornou o modelo como um todo mais adaptável, uma vez que a alteração de um sinal de protocolo interno afetará apenas as cápsulas que realmente fazem uso deste sinal.
14
O diagrama de estrutura do SCAS é mostrado abaixo, juntamente com as portas de comunicação do mesmo.
2.3.3. Diagramas de Estados
Diagrama da Unidade Sistema de Controle de Atitude do SUII (SCAS)
O diagrama abaixo ilustra o comportamento do SCAS com relação à missão atribuída ao VANT-EC-SAT. Cada estado corresponde a um equipamento que estaria no satélite.
Primeiramente é feita a leitura da atitude atravás dos sensores. Essas medidas são enviadas para o SDAS, responsável por eliminar o ruído embutido nas medidas. Após receber de volta valores das medidas dos sensores o cálculo do controle é realizado.
Atuadores, então, são acionados para executar o controle no satélite. A dinâmica da planta é modificada e uma nova leitura da atitude é realizada. O processo é repetido até que a atitude desejada seja obtida.
O diagrama de estados abaixo é uma correspondência direta da definição do comportamento do sistema, no que se refere à sua parte no cumprimento da missão atribuída, descrita na Seção 2.2.2 deste documento, ainda na fase de elaboração (Linha Base Alocada).
2.3.4. Diagrama de Seqüência e Log
16
Durante o desenvolvimento do sistema, fizemos uso do Serviço de Log disponibilizado pelo Rational Rose RealTime para podermos acompanhar e depurar a execução do SCDE. Isso serviu como apoio às funções de depuração do Rose. Segue abaixo um exemplo de sessão de execução:
Como resultado da modelagem, o próprio Rational Rose RealTime gerou Diagramas de Seqüência que nos ajudaram a validar o correto funcionamento do sistema. O diagrama representando o cumprimento das funções que cabem ao SCDE na missão atribuída ao VANT-EC-SAT segue abaixo:
18
2.3.2. Código Gerado
O código gerado em C++ pelo Rational Rose se encontra disponibilizado à parte no link abaixo:
Código do SCDE Gerado Pelo Rational Rose RealTime 2.3.3. Modelo do Rational Rose RealTime
O modelo descrito neste relatório técnico se encontra disponibilizado, incluindo o código gerado, no link abaixo:
Modelo do SCDE / SUII do Rational Rose RealTime 2.4. Qualidade, Confiabilidade e Segurança de Software
[item a ser adicionado a partir do relatório técnico de Izilton Ferraiolo]
3. Conclusões, Recomendações e Sugestões 3.1. Conclusões
Cada USC foi modelada através de máquinas de estado de forma a retratar, melhor possível, a missão a que se desejou realizar.
O ICSC do satélite conseguiu fotografar a superfície terrestre em um ponto específico caracterizado pela sua latitude e longitude.
O ICSC do satélite propiciou a transmissão da fotografia para o ICSC da estação de controle.
3.2. Recomendações
Modelar os estados de cada USC de forma a retratarem os equipamentos reais que se encontram em um satélite, dessa forma o modelo de cada funcionalidade pode ser tão fiel quanto se deseje, bastando para isso modelar cada equipamento da forma mais completa possível.
Ter como processador alvo no momento da compilação algum processador qualificado para o espaço, que efetivamente possa ser embarcado em um satélite.
Fazer a análise do cumprimento dos requisitos temporais do software de tempo real do projeto, pois a correctividade de um sistema de tempo real não depende somente do resultado lógico da computação, mas também no tempo com o qual esse resultado é produzido.
3.3. Sugestões
Apresentar conteúdo teórico relativo a projetos de sistemas de tempo real.
20
Buscar obter como exercícios no Rational Rose RealTime, projetos onde a preocupação com a temporalidade dos processos estejam na ordem de microsegundos. Assim aplicações que requeiram essa ordem de grandeza no tempo de processamento também possam ser realizados no RRRT.
Tornar possível que os trabalhos do curso também possam ser realizados usando-se outras ferramentas de geração automática de código.
