Uma Metodologia para o Desenvolvimento de Sistemas

Universidade Federal de Santa Catatina
Departamento de Automação e Sistemas
Programa de Pós-Graduação em Engenharia de Automação e Sistemas
Jonatas Pavei, Marcelo Teixeira, Rafael Garlet, Rafael
Marana, Vinicius Peccin
Uma Metodologia para o Desenvolvimento
de Sistemas Embarcados através de Lustre e
AADL
Relatório: Tópicos Especiais em Desenvolvimento de Sistemas Embarcados
Florianópolis, dezembro de 2009
Sumário
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
1
INTRODUÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
2
A LINGUAGEM LUSTRE . . . . . . . . . . . . . . . . . . . . . .
7
7
8
3
A LINGUAGEM AADL
4
A LINGUAGEM FIACRE
5
ESTUDO DE CASO - PAPARAZZI
6
MODELO DE ESCALONABILIDADE . . . . . . . . . . . . . . .
22
7
CONCLUSÕES E TRABALHOS FUTUROS . . . . . . . . . . .
25
8
ANEXOS - ESPECIFICAÇÕES DO PAPARAZZI . . . . . . . .
27
RESUMO
2.1
2.2
3.1
Conceitos da linguagem Lustre . . . . . . . . . . . . . . . . . . . . . . .
Recursos estruturais da linguagem Lustre . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . .
10
Recursos estruturais da linguagem AADL . . . . . . . . . . . . . . . . . 10
5.1
5.1.1
5.1.2
5.1.3
Modelagem proposta para o Paparazzi .
Modelagem em Lustre . . . . . . . . . .
Modelagem em AADL . . . . . . . . .
Modelagem em FIACRE . . . . . . . .
REFERÊNCIAS
12
. . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
14
15
15
19
20
30
Resumo
Considerando-se as dimensões e a complexidade observadas atualmente na modelagem de Sistemas Embarcados, é essencial o desenvolvimento e aprimoramento de
técnicas automatizadas que permitam uma melhor compreensão desses sistemas obtendo, consequentemente, modelos mais coerentes com sua especicação.
Nesse sentido, é proposta nesse trabalho uma metodologia para o desenvolvimento de sistemas embarcados em tempo real. Nosso objetivo é melhorar o processo
de construção desses sistemas através da utilização de modelos, obtidos juntamente
a uma abordagem oriantada a simulação.
Nossa abordagem utiliza-se da linguagem Lustre para prover um protótipo comportamental do sistema, que represente elmente as suas funcionalidades. Então, a
partir da simulação desse protótipo são extraídas evidências funcionais que auxiliam
na compreensão do domínio do problema e no desenvolvimento de um modelo de
mais alto nível utilizando, para isso, a linguagem AADL.
A partir de um modelo AADL coerente às especicações, o que é garantido
pela utilização de um modelo comportamental em Lustre, pretende-se propor um
mecanismo de transformação do modelo AADL para Fiacre. Com isso torna-se
possível, dentre outras coisas, a veriicação formal das propriedades do modelo.
Adicionalmente, é proposto um modelo de escalonabilidade de tarefas, apoiado
no estudo de caso proposto.
Palavras-chave:
Lustre, AADL, Fiacre, Formal Verication, Paparazzi..
5
Capítulo 1
Introdução
A modelagem e implementação de sistemas embarcados, particularmente sistemas
em tempo real, diferem-se do desenvolvimento de outros tipos de sistemas por apresentarem requisitos altamente críticos, onde os aspectos como os de segurança, conabilidade e desempenho são fundamentais.
Essa particularidade induz, tanto a indústria quanto a academia, ao desenvolvimento de ferramentas e linguagens que propiciem a incorporação dessas características nos sistemas.
Nesse sentido, a linguagem Lustre [Ver09] é apontada como uma alternativa para
a implementação de sistemas embarcados, através da qual é possível visualizar detalhes comportamentais de um sistema. Características como modularidade, possibilidade de vericação de propriedades, simplicidade do código, integração com outras
ferramentas, etc., tornam Lustre aplicável, principalmente, ao desenvolvimento de
aplicações complexas, críticas e em grande escala.
Como Lustre aborda a implementação de um sistema em um nível de abstração tal que torna-se possível sua representação comportamental, então a utilização
dessa linguagem, teoricamente, pode contribuir com outros aspectos de modelagem,
como arquitetural por exemplo, principalmente por proporcionar o entendimento do
domínio do problema, por meio de ambientes de simulação.
Embora seja intuitivo pensar que a linguagem Lustre possa auxiliar no entendimento do domínio do problema, por dispor de um ambiente de simulação, se faz
necessário comprovar se, de fato, o esforço despendido com a implementação de
um protótipo inicial em Lustre, resulta em aspectos benécos para a modelagem
do sistema. Por isso, nesse trabalho propõe-se a modelagem de um estudo de caso
utilizando uma implementação em Lustre como ponto de partida para a geração de
um modelo em AADL.
A implementação proposta baseia-se no modelo operacional do sistema Paparazzi [Pap09]. Nossa abordagem consiste na utilização da linguagem Lustre para
aprendizado do domínio do sistema, sendo usada então como marco inicial da modelagem arquitetural. A partir de uma representação do comportamento do sistema,
um novo modelo é gerado, dessa vez utilizando-se da AADL, uma linguagem que
permite uma modelagem com um nível maior de abstração, sendo teoricamente mais
adequada à representação de aspectos abrangestes do sistema, com um nível menor
de detalhamento.
Além disso, após a modelagem do sistema em AADL, elabora-se a transformação
desse modelo Fiacre. Nosso objetivo com essa compilação é gerar um modelo que
6
possibilite a vericação formal de propriedades, o que é possível em Fiacre.
Portanto, nesse trabalho, parte-se de uma especicação inicial de um problema,
disponível em linguagem natural, e elabora-se uma série de modelagens, implementações e transformações até que se obtenha uma representação nal do sistema,
coerente com a especicação e formalmente vericada. Essa sequência de atividades obedece uma metodologia própria de desenvolvimento que, até onde é de nosso
conhecimento, consiste em uma proposta inovadora e original.
7
Capítulo 2
A Linguagem Lustre
Lustre é uma linguagem declarativa e síncrona para programação de sistemas reativos, que permite a modelagem de sistemas críticos e de tempo real [HR02] [Ver09].
É considerada uma linguagem declarativa, pois permite a descrição de um conjunto
de equações que deve ser sempre vericado pelas variáveis do programa. Já sua
característica síncrona possibilita garantir que eventos externos sejam interpretados
de modo instantâneo, característica esta que é fundamental para sistemas reativos,
uma vez que estes devem reagir continuamente com o ambiente.
A semântica funcional do Lustre segue a abordagem DataFlow, ou seja, descreve
uxos de saída de acordo com uxos de entrada por meio de equações, ressaltando
assim seu caráter formal. Dene-se um uxo como sendo uma sequência de valores
nitos ou innitos associados a uma variável, onde para cada reação há um valor
para a mesma [Hal05].
A partir da linguagem Lustre, é possível a simulação do comportamento discreto
do sistema. No caso da necessidade de se mapear diferentes comportamentos além
desse, essa linguagem pode ser integrada com outras ferramentas, como por exemplo:
• SIMULINK: caso sejam necessárias informações sobre modelos de tempo contínuo. A ferramenta Simulink/Lustre S2L gera equações discretizadas que
podem ser manipuladas pela linguagem Lustre;
• LESAR: ferramenta utilizada para realizar a vericação das propriedades de
segurança de um sistema;
• SCADE/LUSTRE: ferramenta gráca proprietária para a linguagem Lustre.
A seguir apresentam-se algumas características técnicas da linguagem Lustre.
2.1
Conceitos da linguagem Lustre
A linguagem tem como premissa a "Hipótese Síncrona" cujo princípio infere que o
ambiente não interfere no sistema (ou o programa) durante o(s) processamento(s)
das reações e na recepção dos eventos de entrada. Assim, após o cálculo das equações
implementadas, a resposta é emitida simultaneamente à entrada, o que caracteriza
uma reação instantânea [FFO00]. Essas premissas atribuem a Lustre as propriedades
de causalidade e limitabilidade [CPHP87].
A estrutura da linguagem é denida essencialmente por:
8
X1 = f1 (x1 , . . . , xn , u1 , . . . , um )
X2 = f2 (x1 , . . . , xn , u1 , . . . , um )
onde: x = variáveis internas (de saída);
u = variáveis externas (de entrada).
As variáveis de entrada e saída são associadas à tupla: (υ, τ ), onde:
• υ representa uma sequência innita de valores;
• τ representa uma sequência innita de momentos.
A forma com que as variáveis são constituídas no tempo usa a noção de tempo
esparso [SA02], onde o espaço temporal é dividido em uma sequência innita de
durações alternadas de atividade e silêncio. Observe na Fig. 2.1 essa característica
[SA02].
Figura 2.1: Noção de tempo esparso em Lustre
Percebe-se que assim os eventos podem ocorrer em diferentes locais e no mesmo
tempo global. Esses eventos são considerados simultâneos. Já, os eventos com
diferentes durações e que são separados por intervalos de silêncio, são ordenados
pela ordem de duração.
2.2
Recursos estruturais da linguagem Lustre
A nível de implementação, os recursos abaixo fazem parte do ferramental técnico
disponível em Lustre.
Variável: a variável de programa em Lustre é considerada um sistema de equações em função do tempo e seus domínios;
Clock: é o relógio associado a uma variável que dene a sequência de instantes
ativos.
Tipos básicos de constantes e variáveis:
• Booleano;
• Inteiro;
• Real.
Operadores Básicos:
• Aritméticos (+, −, ∗, /,div,mod);
• Booleanos (and, or, not);
9
• Relacionais (=, <, <=, >=);
• Condicionais (if then else)
Operadores Temporais:
Operador pre(< var >): funciona como uma memória que recupera o valor
imediatamente anterior ao primeiro clock. Exemplo:
X = (x0 x1 x2 x3 x4 · · ·)
pre(X) = (nil x0 x1 x2 x3 · · ·)
Obs2: nil não é um operador válido em LUSTRE.
Operador Inicialização (⇒):
(< var1 >) ⇒ (< var2 >)
As variáveis, ambas com o mesmo clock, geram uma expressão igual ao uxo de
< var2 >, com exceção para a primeira sequência de tempo.
Exemplo:
X = (x0 x1 x2 x3 x4 . . .)
Y = (y0 y1 y2 y3 y4 . . .)
X ⇒ Y = (x0 y1 y2 y3 y4 . . .)
igual a y exceto no primeiro instante.
When (quando): Utilizado para interferir no valor de uma variável, de acordo
com o resultado de um teste. Exemplo: < var1 > when < var2 : bool >. Dene
um valor de < var1 > quando < var2 > for verdadeira.
Um aspecto interessante a ressaltar é que Lustre não dispõe de elementos que
mapeiam atividaes de loop. Também, a tipagem dispõe apenas de valores inteiros,
reais e booleanos, o que de certa forma, pode ser interpretado como deciências da
linguagem.
10
Capítulo 3
A Linguagem AADL
A Analysis and Design Language (AADL)[AAD09], é uma linguagem de descrição
de arquitetura padronizada pela SAE e foi desenvolvida no campo da aviação, sendo
inicialmente conhecida como Avionics Architecture Description Language.
Essa linguagem é derivada do MetaH, uma linguagem de descrição de arquitetura
feita pelo Centro Tecnológico Avançado da Honeywell. A AADL é usada para o
modelar a arquitetura de software e hardware de um sistema embarcado e em tempo
real. Devido à ênfase no domínio de sistemas embarcados, essa linguagem contém
construções para a modelagem de software e componentes de hardware.
Este modelo de arquitetura pode então ser usado como uma documentação do
projeto, para as análises (como escalonabilidade e controle de uxo) ou para geração
de código (da parte de software), como por exemplo a linguagem UML.
3.1
Recursos estruturais da linguagem AADL
Os principais componentes estruturais de AADL, bem como a descrição básica de
cada um, são listados a seguir:
• System: é o responsável pela organização hierárquica dos componentes do
sistema na modelagem;
• Process: utilizado para as questões de endereçamento do sistema;
• Threads: são unidades de execução escalonadas e concorrentes dos processos;
• ThreadsGroup: coordena a organização das threads nos processos;
• Subprogram: possibilita a chamada de códigos seqüenciais do sistema;
• Processor: possibilita a conguração do processador que será utilizado, in-
cluindo serviços de execução, capacidade de processamento e escalonamento
das threads;
• Bus: provê a conectividade física entre os componentes de hardware;
• VirtualBus: possibilita a representação de canais virtuais e protocolos;
• Device: realiza a interface entre componentes físicos externos ao sistema;
11
• Mode: permite que características funcionais do projeto possam ser modeladas.
Isso se dá através do levantamento dos possíveis estados dos componentes. A
abstração de uma máquina de estados relaciona os possíveis estados com os
eventos do sistema;
• Fluxo: permite que o caminho das informações dentro dos blocos possam ser
mapeadas desde a fonte até o seu destino.
Esses componentes descritos, fazem parte tanto do ambiente gráco, quanto do
textual de AADL. A seguir, na Fig. 3.1, mostra-se um correspondente entre essas
duas alternativas de modelagem em AADL.
Figura 3.1: Relação Textual e Gráca em AADL
A modelagem gráca em AADL é feita a partir de um plugin nomeado de
ADELE, que está incorporado ao ambiente de desenvolvimento TOPCASED. Esse
plugin incorpora à modelagem de um problema, um tom bastante intuitivo, sendo
também possivel gerar o código a partir do modelo, automaticamente.
Os aspectos textuais da linguagem AADL são compostos por um conjunto de
declarações que permitem ao projetista representar e descrever a arquitetura do
sistema, tanto em termos de software quanto em plataforma de execução (hardware).
Em determinados ambientes, como o Topcased, usado nesse trabalho para a
modelagem em AADL, a linguagem textual pode ser gerada automaticamente a
partir do modelo gráco, traduzindo-se as características arquiteturais desenhadas
no modelo gráco, para o renamento e extensão do modelo no ambiente textual.
A linguagem AADL associa cada componente implementado a uma "declaração"e a uma "implementação", permitindo uma rápida familiarização com o código
gerado.
12
Capítulo 4
A Linguagem Fiacre
A linguagem FIACRE representa tanto aspectos temporais como comportamentais
de sistemas. Foi inicialmente desenvolvida como linguagem pivô para vericação de
modelos em linguagens de alto nível, baseada em pesquisas em teoria de concorrência e tempo real. É possível, contudo, modelar sistemas diretamente em FIACRE
pois a linguagem oferece algumas características interessantes nesse sentido. Seu
nível de abstração permite que se tenha visão da arquitetura como também do comportamento do sistema, permitindo também que a vericação de propriedades do
sistema seja intuitiva.
Dois conceitos fundamentais embutidos em FIACRE são Processos e Componentes:
• Processos descrevem comportamentos seqüenciais de operação do sistema. É
denido por um conjunto de estados, cada qual associado com o que seria
um trecho de código de uma linguagem tradicional como C e JAVA. Utiliza
também funcionalidades tipicamente incluídas nestas linguagens, como condições se-então, atribuições, laços, etc., além de construções não-determinísticas,
eventos de comunicação através de portas e transições de estado.
• Componentes são composições de processos, podendo ser tanto uma composi-
ção paralela quanto um conjunto de processos que se comunicam através de
portas e variáveis compartilhadas. Um componente também encapsula variáveis e portas, além de denir restrições de tempo, precedência e prioridade.
Os demais elementos da linguagem FIACRE são os seguintes:
• Porta: ponto de comunicação, a princípio, assíncrono (o sincronismo pode ser
programado através dos estados e transições do processo), podendo opcionalmente ser denida como entrada ou saída (caso não seja, é usada como ambos).
É tipada, isto é, o valor lido e enviado nas portas pode ser de um determinado
tipo primário, como bool, none, int, nat (natural), etc.
• Transição de Estado: uma expressão regular que leva de um estado a outro.
Pode ser um evento, uma atribuição, uma leitura de porta de um determinado
tipo, uma expressão condicional, etc.
• Variáveis: como nas linguagens de programação comuns. Também são tipadas.
13
• Restrição de Tempo: quanto às primitivas de tempo, aquelas usadas em FIA-
CRE são as mesmas das redes de Petri temporizadas e são usadas para criar
as restrições. Caso o projetista deseje utilizar uma restrição de tempo, deve
modelar o sistema de modo que, dado uma expressão regular que só pode ser
executada em um determinado intervalo (e será executada naquele intervalo)
o processo em questão passa a um outro estado.
• Precedência: as relações de precedência são dadas relacionando estados expli-
citamente precedentes dentro de um processo e, dentro de componentes, estas
relações são dadas através de transições relacionadas com a mesma expressão
regular. As restrições de tempo e denição de prioridades foram integradas
de tal modo que as propriedades de componentes podem ser inferidas a partir
dos seus constituintes (processos e outros componentes), ou seja, a composição
entre processos (e eventualmente componentes) implica, quando for o caso, em
relações de precedência entre processos.
• Prioridade: denida explicitamente em reação a portas (uma porta ou conjunto
de portas é declarada mais prioritária que outra porta ou conjunto)
14
Capítulo 5
Estudo de caso - Paparazzi
O estudo de caso utilizado como exemplo de modelagem em Lustre e AADL é o
Paparazzi[Pap09]. Esse projeto iniciou-se em 2003, mantém o código aberto e tem
por objetivo manter e aperfeiçoar um sistema autônomo de voo em uma aeronave
não tripulada.
Pesquisadores e instituições de diversas partes do mundo utilizam o Paparazzi
como objeto de estudo, desenvolvendo, propondo e otimizando extensões ao projeto,
de forma a habilitar o Paparazzi a missões cada vez mais extremas e críticas, como
coletas amostrais em ambientes hostis, onde a presença humana seria imprópria.
A arquitetura do Paparazzi é tal qual mostrada na Fig. 5.1.
Figura 5.1: Projeto Paparazzi
Observa-se que existem dois componentes essenciais do Paparazzi, responsáveis
pelo funcionamento técnico do sistema, que são:
• Estação de solo (Ground Station): é onde são instalados receptores, transmis-
sores, centrais de processamento, etc.;
• Aeronave Aircraft: é o objeto que interage com a estação de solo, no sentido
de enviar e receber comandos, que se sobrepõem, em quaisquer circunstâncias,
às ações do vôo automático.
A comunicação entre a base e avião se dá por meio de links redundantes de envio
e recebimento de dados. Os dados que trafegam nessa estrutura de comunicação envolvem desde comandos enviados pela estação de solo pertinentes ao funcionamento
15
da aeronave, quanto dados de medições efetuadas de acordo com a execução de um
plano de missão.
A estrutura física do avião é dotada de sensores que o habilitam a operar de forma
autônoma, controlando automaticamente métricas como: velocidade, distância da
base, altura, temperatura, etc. Assim, através desses dados, a aeronave consegue
se manter estável, de acordo com o conjunto de denições estipuladas pelo software
que dirige a aeronave.
5.1
Modelagem proposta para o Paparazzi
Tendo em vista as denições do projeto Paparazzi e os objetivos desse projeto,
propõe-se uma modelagem obedecendo-se os requisitos do sistema, tais quais descritos no ANEXO 1. A seguir descrevem-se os modelo.
5.1.1
Modelagem em Lustre
Lustre permite que o código seja editado em ambientes comuns, como por exemplo
o Notpad ou bloco de notas, sendo que a primeira opção foi a utilizada aqui. Esse
código é então salvo com a extensão ".lus" e compilado. Vale ressaltar que, até onde
tem-se conhecimento, Lustre possui distribuições apenas para o sistema operacional
Linux. Nesse trabalho, a implementação foi desenvolvida em ambiente Windows,
através do Sygwin, um emulador de comandos Linux no Windows.
A compilação de um código Lustre é dada através do comando:
Lustre + nome_do_arquivo.lus + nome_do_nodo_principal
Dada a corretude do código e do mapeamento dos caminhos que referenciam o
compilador "Lustre", devem ser gerados automaticamente dois arquivos especícos
a partir dessa compilação: um com a extensão ".ec"e outro com a extensão ".oc", que
possibilitam, dentre outras coisa, a transposição do código Lustre para C e também
a invocação de ambientes de simulação, no caso através do compilador simec ou
luciole. Nesse trabalho não consideramos a geração de código C, mas utilizamos o
ambiente de simulação invocado através do disparo do compilador simec. Para isso,
basta que o arquivo gerado (".ec"), seja executado, através do seguinte comando:
simec + nome_do_nodo_principal.ec
Então, o ambiente gráco mostrado na Fig. 5.2 é gerado e pode ser usado para a
simulação da aplicação. De acordo com os requisitos do sistema, é denido o modo
automático de voo como padrão para o sistema. Todavia, qualquer comando manual
que seja feito, deve ter obrigatoriamente prioridade sobre qualquer procedimento
automático.
O ambiente de simulação desenvolvido conta com alguns parâmetros que denem
o comportamento da aeronave, onde alguns deles são descritos na Tabela 5.1.1.
Como pode ser observado no ambiente gráco, existe um menú de comandos à
esquerda da janela de simulação. Esses comandos se referem a interferências manuais
no funcionamento da eoronave e se relacionam basicamente ao comnado de início
da operação, carregamento de missões, comando de pouso, etc. Também, é possível
que manualmente se interra na altura, distância e temperatura da aeronave, a m
de simular diferentes comportamentos.
A sequência de eventos mostrados à direita da janela de simulação, se referem às
ações comportamentais do sistema, ou seja, descreve a sequência de passos observado
16
Figura 5.2: Interface gráca da simulação em modo inicial
na aeronave. Assim, após o acionamento do botão Start, um contador (Wait) irá
ser decrementado até atingir o valor 0, o que indica o início do procedimento de
decolagem automática. Da mesma forma, após o acionamento da aeronave existe
um contador que representa o nível de energia disponível no avião.
Ao iniciar o procedimento de decolagem, observa-se que os eventos Decolando,
Solo e SemMissão passam para o status habilitado, como mostra a Fig. 5.3(a).
Concorrentemente, a velocidade e a distância da base aumentam, indicando a
proximidade de um evento de voo. O desacoplamento da aeronave do solo se dá no
momento em que a velocidade e a distância percorrida na pista se tornam compatíveis com as denições da Tabela 5.1.1. Essa ação é determinada pela migração
do evento Decolando para Decolou. Assim que Decolou é habilitado, inicia-se a
contagem da altura tomada pela aeronave em relação ao solo.
Ressalta-se, conforme a Tabela 5.1.1, que existe uma altura, velocidade e distância pré-denidas, dentro das quais a aeronave deve enquadrar-se. Por exemplo,
após o voo, ao atingir determinada distância da base, a aeronave deve entrar em
modo Standby, caso a estação de base não tenha informado nehuma rota de missão.
Semelhantemente, o evento Estável deve ser habilitado ao atingir-se uma determinada altura e velocidade. A habilitação desses eventos podem ser observadas na
Fig. 5.3(b).
Uma vez que a aeronave esteja estabilizada e em Standby, pois não lhe foi informada nenhuma missão, essa permanece sobrevoando em círculos o espaço em volta
Tabela 5.1: Parâmetros do modelo em Lustre
Parâmetro
Valor Unidade
Comprimento total da pista
100
metros
Distância para decolagem
80
metros
Distância para início do pouso
200
metros
Velocidade de decolagem
50
km/h
Velocidade média de voo
100
km/h
Distância para a fronteira
300
metros
Altura para estabilização
400
metros
Carga máxima da bateria
10
volts
Carga mínima para pouso
1
volt
17
Figura 5.3: Simulação de voo em Lustre
da base. No momento em que uma missão é informada, a aeronave abandona imediatamente o modo Standby e inicia a execução do plano de missão, que consiste
em alcançar determinadas coordenadas no espaço, coletando dados no momento
em que um alvo (ponto geográco) é atingido. Após passar pela coordenada do
alvo, a aeronave regressa ao perímetro denido para o modo Standby, aguardando
novo comando de missão e o processo se repete sucessivamente. O procedimento
de aproximação da aeronave do alvo, bem como sua distanciação desse, podem ser
acompanhadas pelo contador DistAlvo. As Fig. 5.4(a), (b) e (c) ilustram o momento
em que um alvo é buscado, alcançado e abandonado, respectivamente.
Figura 5.4: Simulação do cumprimento de uma Missão
Ressalta-se que para que uma missão seja executada, a quantidade de energia
necessária para tal é vericada com relação à carga total disponível na aeronave,
anteriormente ao início do trajeto. Esse cálculo já envolve o acréscimo da evergia
exigida para o procedimento de pouso. Assim, automaticamente a missão só será
iniciada perante a viabilidade do percurso. Caso essa vericação resulte em uma rota
inviável, a aeronave aborta imediatamente a missão. Caso contrário, dois marcadores (ConsumoRota e SaldoRota) indicam a energia total necessária para completar
a missão e a energia restante desse total, respectivamente. De acordo com esse
cálculo, pode-se observar que no momento em que a aeronave atinge seu alvo, ela
consumiu em média a metada da carga necessária para completar a missão, sendo
que o restante é destinado ao percurso de volta.
Finalmente, dene-se o procedimento de pouso da aeronave. Existem duas situações em que a aeronave pousa, sendo uma o reexo do nível crítico de energia
18
e a outra causada pelo comando manual Pousar. As Fig. 5.5(a), (b) e (c) ilustram
momentos distintos durante o procedimento de pouso.
Figura 5.5: Simulação do procedimento de pouso
Em qualquer um dos casos, o evento Abortar é habilitado e a aeronave inicia
um processo de regressão da distância da base, sendo que a velocidade e a altura
permanecem constantes. Ao atingir a distância pré-determinada e própria para
o pouso, automaticamente a velocidade e a altura são decrementados. No exato
momento em que a aeronave toca o solo, o evento Solo é habilitado, sendo esse um
evento síncrono com a variável que dene a altura, ou seja, ao tocar o solo a altura
vericada é igual a 0. Por outro lado, a velocidade e a distância permanecem maiores
que 0, pois existe ainda um percurso de pista a percorrer até a parada denitiva da
aeronave.
O modelo implementado em Lustre oferece ainda inúmeras outras funcionalidades, como a simulação da recarga automática da bateria no solo, o início automático
de nova decolagem perante a completude da recarga, etc.
Outra característica importante do modelo implementado é o fato de permitir a
interferência manual da estação de solo. Assim, caso uma missão envolva particularidades especícas, como a coleta de dados a alturas extremas, a estação de base
está apta a habilitá-las. Da mesma forma, se necessário for, é possível posicionar a
aeronave fora dos padões automáticos de distância e altura, o que possibilita coletas amostrais muito próximas do solo ou em ambientes hostís, como a temperatura
observada a x metros da erupção de um vulcão, por exemplo.
Constata-se, de acordo com o modelo implementado em Lustre, que esse oferece
uma simulação muito póxima ao comportamento observado em uma aplicação real,
o que não seria possível no caso da mesma modelagem em uma linguagem de mais
alto nível, como AADL, por exemplo.
Então, estima-se que a partir da observação do comportamento desse modelo,
torna-se possível o reconhecimento de detalhes de modelagem que tendem a simplicar, exemplicar e enriquecer um modelo mais abstrato. Por isso, a simulação em
Lustre é utilizada como referência para o desenho do processo em AADL, conforme
descrito a seguir.
19
5.1.2
Modelagem em AADL
A AADL pode ser utilizada em vários ambientes e ferramentas de desenvolvimento.
Neste trabalho a apoia-se no ambiente Topcased1 [Top09] para a modelagem do
estudo de caso proposto.
Para a implementação do projeto Paparazzi em AADL, parte-se de uma modelagem e simulação em LUSTRE, vericando-se as características comportamentais
do sistema. Essa metodologia torna a representação em AADL mais próxima do
comportamento real, o que tende a diminuir signicativamente a complexidade dos
aspectos a serem modelados.
Além do auxílio ao entendimento do problema, uma implementação prévia do
sistema em Lustre permite que, a qualquer tempo durante a modelagem em AADL,
a simulação comportamental em Lustre seja refeita, transpondo mesmo que involuntariamente o comportamento do sistema real, para o modelo AADL.
Inicialmente elabora-se a modelagem do sistema de maneira modular, permitindo
a visualização dos principais macro-módulos desse. Os macro-módulos distinguem
os componentes funcionais do sistema em Base, Modem e Aeronave, conforme pode
ser vericado na Fig. 5.6, já em uma sintaxe AADL.
Figura 5.6: Macro-módulos do modelo Paparazzi em AADL
Posteriormente a denição dos macro-módulos e com auxilio da simulação em
Lustre, foram vericados todos os modos de funcionamento e denidas as propriedades de cada um dos macro-módulos, sendo que o principal, e que deveria ser
detalhado devido a sua complexidade, é o macro-módulo Aeronave, cujo detalhamento é mostrado na Fig. 5.7.
Através das especicações do Paparazzi e da avaliação da simulação em Lustre, foi possível identicar os principais componentes do macro-módulo Aeronave,
sendo esse constituido de quatro dispositivos (devices) principais: GPS, Sensor Infravermelho, giroscópio e uma bateria de alimentação. Também são determinados mais
dois sistemas internos do macro-módulo Aeronave: o sistema de processamento dos
dados e o sistema de atuadores.
Vericados os subsistemas da Aeronave, foi possível um maior detalhamento de
cada um deles permitindo a entrada de características provenientes dos requisitos
do projeto, incluindo restrições de tempo real. Na Fig. 5.8 é possível perceber a
1A
ferramenta Topcased foi desenvolvida com base no ambiente open source Eclipse, que provê
uma vasta gama de ambientes e ferramentas de modelagem.
20
Figura 5.7: Detalhamento do Macro-módulo Aeronave em AADL
entrada de componentes que permitem ótima caracterização do processamento do
sistema, como os dois processadores utilizados.
Figura 5.8: Detalhamento do processamento do sistema em AADL
Os processadores comunicam-se através de um barramento SPI e possuem funcionalidades especícas para cada um deles. O processador AutoPilot é responsável
por todo o condicionamento de sinais e geração da rota da aeronave, já o processador
FlayByWire é o responsável pelo controle das variáveis de entrada e saída que determinarão o acionamento dos servo motores que, por sua vez, resultam no movimento
da aeronave.
A linguagem ainda permite a modelagem do comportamento das threads do sistema, possibilitando a avaliação de escalonabilidade dos processadores e vericação
das restrições do mesmo. Através da Fig. 5.9, pode-se vericar a conexão de todos
os dispositivos que atuam no sistema e permitem o seu funcionamento.
5.1.3
Modelagem em FIACRE
O modelo do sistema, escrito na linguagem FIACRE, pode ser obtido a partir de uma
ferramenta de transformação que ainda está em desenvolvimento e será integrada
ao ambiente TOPCASED. O objetivo de se obter o modelo FIACRE é a vericação
21
Figura 5.9: Detalhamento da conexão entre os dispositivos do sistema
formal das propriedades comportamentais do sistema, ou seja, do modelo AADL,
garantindo seu correto funcionamento.
Visto que a ferramenta utilizada apresenta ainda algumas limitações, o modelo
AADL desenvolvido teve de ser simplicado para que a transformação pudesse acontecer. Isso implica que a parte comportamental do sistema, citando os modos, anexos
comportamentais e uxos, foi excluída no momento da tradução dos modelos.
Assim, o modelo FIACRE gerado representa apenas as características estruturais
do sistema. Por esta razão não existe a possibilidade de pensar-se em vericação
comportamental do sistema a partir do modelo FIACRE.
22
Capítulo 6
Modelo de Escalonabilidade
Como visto anteriormente, o sistema Paparazzi é composto por dois processadores.
Um deles é chamado FlybyWire, responsável pelo processamento das tarefas de estabilização e pelo seguimento de trajetória. Já o segundo processador, o AutoPilot,
executa as tarefas TrataSinais, CalculaMissao e GerenciadorComunicacao.
Para realizar uma análise de escalonamento, vericando assim a viabilidade da
execução das tarefas desejadas, foi utilizada a ferramenta Times Tool [Upp09]. Essa
ferramenta, desenvolvida pela Universidade de Uppsala, na Suécia, possui um propósito voltado ao desenvolvimento de sistemas embarcados.
A análise é feita separadamente para cada processador denido na modelagem
AADL. Os dados das tarefas foram retirados das especiações do problema e de
estimações vindas da literatura associada. O primeiro processador a ser analisado
foi o FlyByWire. Ele opera com duas Threads, como citado anteriormente. A thread
SeguimentoTrajetoria possui um periodo de 50ms, deadline igual ao periodo e tempo
de execução denido como 14 unidades de tempo. Enquanto a thread Estabilizacao
tem o mesmo periodo e deadline, porém tempo de execução menor, 10 unidades de
tempo. As threads a serem analisadas são mostradas na Fig. 6.1.
Figura 6.1: Detalhamento das threads analisadas no modelo de escalabilidade
Podemos notar que foi utilizado como algoritmo de escalonabilidade a denição
manual de prioridades para as tarefas. Essa abordagem se dá pelo fato de atribuirse uma importancia maior para a thread "Estabilizacao"à "SeguimentoTrajetoria".
Outra caracterisca é a utilização de preempção na análise. Realizado o teste de
escalonabilidade, foi concluído que o sistema é escalonável e possui os WCRT (Worst
Case response Time) de acordo com a Fig. 6.2.
Com a denição da viabilidade de escalonamento das tarefas no processador
FlybyWire, foi possivel simular o escalonamento através da ferramente Times Tool.
23
Figura 6.2: Tempos do pior caso
A simulação ocorre em uma linha de tempo, onde as tarefas vão chegando de acordo
com sua periodicidade e são então executas de acordo com a politica de escalonamento atribuída. Na Fig. 6.3 pode-se observar a simulação.
Figura 6.3: Análise de escalabilidade via Simulação
Como o mínimo multíplo comum entre as tarefas é 50, a cada 50 intervalos de
tempo repete-se o escalonamento.
O outro processador analisado foi o AutoPilot. Esse processador possui as tarefas:
• TrataSinais, que possui periodo igual a 25ms, deadline igual ao periodo e
tempo de execução igual a 5 unidades de tempo;
• CalculaMissao, que possui período igual a 250ms, deadline igual ao periodo e
tempo de execução igual a 50;
• GerenciadorComunicacao, que se trata de uma tarefa esporádica com deadline
igual a 15 unidades de tempo e tempo de execução igual a 6 unidades de tempo.
A declaração das tarefas esta denida na Fig. 6.4.
Figura 6.4: Análise de escalabilidade do processador AutoPilot
24
Para esse processador também foi utilizada a denição manual de prioridades
como política de escalonamento, assim como a utilização da preempção. A tarefa "GerenciadorComunicacao"foi denida com uma prioridade maior pois, a partir
dela, a rota e a missão podem ser alteradas. As outras tarefas possuem a mesma
prioridade, porém elas possuem um grafo de precedência conforme mostrado na
Fig. 6.5.
Figura 6.5: Grafo de precedência da análise de escalabilidade
Como pode-se observar, a tarefa "TrataSinais"precede a tarefa "CalculaMissao".
Isso se da em razão da dependência da tarefa "CalculaMissao"com relação à tarefa
"TrataSinais".
Denidas as tarefas e suas atribuições foi realizado o teste de escalonabilidade
que provou ser escalonável esse conjunto de tarefas com os WCRT mostrados na
Fig. 6.6.
Figura 6.6: Tempos de resposta gerais da análise de escalabilidade
A simulação mostrada na Fig. 6.7 nos fornece uma visualização do comportamento do processador AutoPilot.
Figura 6.7: Simulação da escalabilidade no processador AutoPilot
Através das análises feitas para os dois processadores envolvidos na modelagem
do sistema Paparazzi, podemos concluir que há viabilidade na utilização dessas
tarefas na prática.
25
Capítulo 7
Conclusões e Trabalhos Futuros
Neste trabalho, propõe-se uma metodologia para a modelagem e implementação
de sistemas, principalmente sistemas embarcados e em tempo real, onde métricas
como segurança, desempenho e disponibilidade são consideradas críticas e interferem
diretamente na viabilidade do sistema.
Nossa metodologia consiste em identicar e avaliar alternativas de modelagem
de sistemas, que possam suprir o gap que existe[ACGR09] entre os diferentes níveis
de abstração observados durante o ciclo de desenvolvimento dos modelos de sistemas. Para isso, propomos um método de modelagem através de AADL, associado
intimamente à observância do comportamento do sistema real, por vez representado
por um protótipo implementado em Lustre. A partir do modelo AADL, propõe-se
também um mecanismo de transposição para um modelo Fiacre que, dentre outras
coisas, permite a vericação formal do modelo.
Algumas considerações podem ser feitas com relação à metodologia desenvolvida.
A primeira delas é que ao basear-se em um modelo comportamental do sistema para
modelá-lo com um nível maior de abstração, foi claramente observável a projeção
de um modelo bastante el às suas especicações.
As experiências de projeto mostram que em várias oportunidades, questões que
se mostravam subjetivas na modelagem em AADL, sob o ponto de vista de entendimento humano, eram rapidamente e convincentemente esclarecidas com através de
pequenas consultas no modelo comportamental.
Ademais, arma-se que, com relação ao estudo de caso implementado, o esforço
despendido com uma implementação inicial em Lustre, não possui relevância signicativa frente as vantagens possíveis relativas à compreensão do sistema. Até porque
Lustre mantém uma sintaxe bastante simples e uma semântica clara e compreensível.
Outra importante contribuição fornecida é a construção de um mecanismo de
transformação do código AADL para Fiacre. Entende-se essa transformação agrega
a um modelo de alto nível a possibilidade de vericação formal, tal qual pode ser
submetido o modelo comportamental. Até onde se tem conhecimento, esse fato
torna nossa abordagem inovadora.
Futuros esforços devem ser gastos no aprimoramento da metodologia proposta.
Dentre eles, é aconselhável que se estabeleça um método de vericação formal de
propriedades na implementação inicial, em Lustre. Isso pode ser estabelecido com
base na ferramenta LESAR, disponível no pacote do Lustre. Com isso, estabelece-se
um caráter formal ao modelo comportamental, e prova-se que protótipo do sistema
é válido com relação à sua especicação.
26
Também deve ser aprimorado o mecanismo de transposição para Fiacre, de forma
a abranger todas as características de código possíveis em AADL. A vericação
formal das propriedades do modelo Paparazzi, no código Fiacre gerado, por questões
de cronograma, também é considerada trabalho futuro.
27
Capítulo 8
ANEXOS - Especicações do
Paparazzi
28
29
30
Referências
[AAD09] AADL.
Analysis and design language, 2009.
Disponível em:
<http://www.sae.org/technical/standards/AS5506A>. Acesso em: Dezembro 2009.
[ACGR09] M. Alras, P. Caspi, A. Girault, and P. Raymond. Model-based design
of embedded control systems by means of a synchronous intermediate
model. International Conference on Embedded Software and Systems,
2009.
[CPHP87] P. Caspi, D. Pilaud, N. Halbwachs, and J. A. Plaice. Lustre: A declarative language for programming synchronous systems. ACM Journal,
1987.
[FFO00] J. M. Farines, J. S. Fraga, and R. S. Oliveira. Sistemas de tempo real.
Escola de Computação. IME-USP, page 105, 2000.
[Hal05] N. Halbwachs. A synchronous language at work: the story of lustre.
IEEE Journal, 2005.
[HR02] N. Halbwachs and P. Raymond. A tutorial of lustre. Do not specied,
2002.
[Pap09] Paparazzi.
Paparazzi project, 2009.
Disponível em:
<http://paparazzi.enac.fr/wiki/Main_Page>. Acesso em: Novembro 2009.
[SA02] I. Smaili and A. Ademaj. Setting break-points in distributed timetriggered architecture. High-Level Design Validation and Test Workshop,
2002.
[Top09] Topcased. The open osurce toolkit for critical systems, 2009. Disponível
em: <http://www.topcased.org/>. Acesso em: Dezembro 2009.
[Upp09] Uppsala.
The times tool, 2009.
Disponível
<http://www.timestool.com/>. Acesso em: Dezembro 2009.
em:
[Ver09] Laboratory Verimag. Lustre - the core language, 2009. Disponível em:
<http://www-verimag.imag.fr/SYNCHRONE/index.php?page=langdesign>. Acesso em: Outubro 2009.