Professional Documents
Culture Documents
Emília Villani
Orientadora
Campo Montenegro
São José dos Campos, SP – Brasil
2007
Dados Internacionais de Catalogação-na-Publicação (CIP)
Divisão de Informação e Documentação
Véras, Paulo Claudino
Modelagem e análise do software embarcado de piloto automático de uma VANT / Paulo Claudino Véras.
São José dos Campos, 2007.
135f.
REFERÊNCIA BIBLIOGRÁFICA
VÉRAS, Paulo Claudino. Modelagem e análise do software embarcado de piloto automático de
um VANT. 2007. 135f. Tese de mestrado – Instituto Tecnológico de Aeronáutica, São José dos
Campos.
CESSÃO DE DIREITOS
NOME DO AUTOR: Paulo Claudino Véras
TÍTULO DO TRABALHO: Modelagem e análise do software embarcado de piloto automático de um
VANT
TIPO DO TRABALHO/ANO: Tese / 2007
É concedida ao Instituto Tecnológico de Aeronáutica permissão para reproduzir cópias desta tese e
para emprestar ou vender cópias somente para propósitos acadêmicos e científicos. O autor reserva
outros direitos de publicação e nenhuma parte desta tese pode ser reproduzida sem a sua autorização
(do autor).
___________________________
Paulo Claudino Véras
Pça Mal-do-Ar Eduardo Gomes, 50 – Vl. Acácias
12228-900 – São José dos Campos – SP
ii
ITA
iii
Agradecimentos
À minha orientadora Profa. Dra. Emília Villani, que sempre me orientou de forma
constante e precisa durante todo meu mestrado, me dando todo apoio necessário e sempre
Ao Prof. Dr. Luiz Carlos Sandoval Góes, pela orientação, direcionamento e todo apoio
A Benedito Carlos Oliveira Maciel e Nei Salis Brasil Neto que forneceram o estudo de
caso deste trabalho e a infra-estrutura da Flight Technologies, bem como pelas discussões,
Ao Prof. Dr. Adilson Marques da Cunha e Prof. Dr. Vieira Dias pela ajuda e sugestões
Aos meus pais e minha irmã que sempre me deram todo apoio necessário e
À minha namorada Raquel, que sempre me deu todo apoio e ajuda e sempre foi
Aos meus grandes amigos de Recife, Adriano, Anderson, Daniel e Eduardo por toda
ótima convivência durante este período e George, que mesmo de longe me deu valiosa ajuda.
apoio financeiro.
v
Resumo
importante, pois torna possível a análise das características do projeto e sua validação antes da
Rational® Rose® RealTime. A partir do modelo obtido são utilizadas três abordagens para
sua análise e avaliação: (1) aplicação de um conjunto de métricas no código gerado pela
comportamento do sistema em malha fechada; e (3) conversão do modelo em UML para redes
sistema.
viii
Abstract
One of the main difficulties of the embedded software development is the conceptual
specification and design. In this context, system modeling has an important role as it makes
possible the analysis of the system behavior and the design validation before the
implementation phase. This thesis approaches the problem of modeling and analyzing the
embedded software of a UAV automatic pilot using UML and the Rational® Rose®
RealTime CASE tool. It proposes three approaches for the analysis and assessment of the
UML model: (1) to apply a set of metrics to the code generated by the CASE tool; (2) to
integrate the CASE tool with a simulator of the VANT dynamics, developed in MatLab®, in
order to verify the behavior of the system in closed loop; and (3) to convert the UML model
to a Petri net model, which is a mathematic formalism that allows the formal verification of
Lista de Ilustrações
Figura 5.4 Diagrama de seqüência para a configuração de integração com o simulador de vôo.
..................................................................................................................................................90
Figura 5.5 Estrutura geral do simulador de vôo. ......................................................................91
Figura 5.6 Simulador de vôo desenvolvido no Simulink®.......................................................92
Figura 5.7 Bloco responsável pela comunicação serial com o modelo no RRRT....................94
Figura 5.8 Monitor de estados da cápsula “DataReceiver”......................................................96
Figura 5.9 Monitor de estados da cápsula “ElevatorController”. ............................................96
Figura 5.10 Monitor de estados da cápsula “Elevator”. ...........................................................97
Figura 5.11 Horizonte artificial no Simulink®. ........................................................................98
Figura 6.1 Exemplo de rede de Petri e sua representação matricial (Cardoso, Valette, 1997).
................................................................................................................................................103
Figura 6.2 Diagrama de estados da cápsula “DataReceiver”. ................................................111
Figura 6.3 Rede de Petri correspondente ao “DataReceiver”. ...............................................112
Figura 6.4 Diagrama de estados do “ElevatorController”. ....................................................113
Figura 6.5 Rede de Petri correspondente ao “ElevatorController”........................................113
Figura 6.6 Diagrama de estados do “Elevator”. .....................................................................115
Figura 6.7 Rede de Petri correspondente ao “Elevator”.........................................................115
Figura 6.8 Modelo completo em rede de Petri. ......................................................................116
Figura 6.9 Redes de Petri do sistema com mecanismos de tratamento de falhas...................118
Figura 6.10 Rede de Petri do modelo sem “User”. ................................................................120
Figura 6.11 Grafo de alcançabilidade da rede de Petri do modelo.........................................121
xi
Lista de Tabelas
Lista de Símbolos
Sumário
1 Introdução
(Veículos Aéreos Não Tripulados), também conhecidos pela sigla em inglês UAVs (Unmaned
Este capítulo inicia-se com alguns conceitos e definições necessários para melhor
compreensão da proposta, dos objetivos e das motivações deste trabalho. Apresenta-se uma
breve introdução sobre VANTs. Em seguida caracteriza-se o que são sistemas embarcados e
Um VANT pode ser definido como um veículo aéreo motorizado sem tripulação e
características. Possui a capacidade de levar vários tipos de carga útil (payload), o que o torna
observar que mísseis de cruzeiro e veículos balísticos não são considerados VANTs.
Os VANTs podem ser divididos em três grandes categorias (THE UAV INDUSTRY,
1999): com asas fixas, com asas rotatórias e mais leves que o ar (airships). O primeiro é o
segundo vem em seguida, é menos utilizado que o primeiro, porém o número de fabricantes
que são mais leves que o ar são os menos utilizados e também os que entraram em operação
há menos tempo. O número de pessoas que desenvolve este tipo de VANT cresce lentamente
civis têm aumentado, como por exemplo, no Japão, onde os VANTs são empregados na
A seguir estão listadas algumas das tarefas que podem ser realizadas por VANTs
OF DEFENSE, 2005; FABIANI, 2006; HOLDER, 2001; KIM, 2006; NEWCOME, 2004;
VASCONCELOS, 2006):
• Aplicações militares:
o Localização de alvos;
o Transporte de mantimentos;
Aplicações civis:
o Previsão do tempo;
o Pesquisa acadêmica;
o Busca e salvamento;
o Comunicação;
operador define a missão do sistema e são fornecidas para a aeronave habilidades de decisão e
processamento de informações a bordo. A Tabela 1.1 apresenta uma relação entre as ações do
Esta tese trata do problema de como desenvolver este software de forma confiável e eficiente.
19
como sistema embarcado de tempo real. Com base nesta caracterização, é identificada a
dispositivo computacional que desempenha uma função dedicada ou é projetado para uso com
pessoais (PCs ou desktops) da categoria de sistemas embarcados, pois eles não são projetados
representam uma parte de um produto com o qual o usuário final não interage diretamente”
(GUERROUAT, 2005).
capacidade de processamento.
20
2005).
outras. A diversidade das aplicações é ilustrada pela extensa coleção de trabalhos científicos
publicados. Alguns exemplos são Amir et al. (2005), que utiliza um sistema embarcado como
sensor para identificação de olhos, Kwakye (2006), que projetou um sistema miniaturizado
moldadas e Kroll (2003) que utiliza um sistema embarcado para inserir assinaturas digitais em
objetos padrões, como imagens, formas de onda e relatórios estruturados da área médica.
os sistemas embarcados têm se tornado cada vez mais sofisticados e complexos. Como
sistemas de tempo real. A próxima seção descreve o que são sistemas de tempo real.
21
De acordo com Laplante (2004), um sistema de tempo real pode ser definido como
como aquele que não pode satisfazer um ou mais dos requisitos estipulados na especificação
especificações de requisitos do sistema quanto ao tempo limite para fornecer suas respostas.
Kopetz (1997), por sua vez, define um sistema de tempo real como aquele onde a
exatidão de seu comportamento não depende apenas do resultado lógico, mas também do
Os sistemas de tempo real podem ser classificados em soft e hard. Labrosse (2002)
define sistemas soft como aqueles em que as tarefas são desempenhadas pelo sistema o mais
rápido possível, porém nem todas elas têm que ser finalizadas dentro de um limite de tempo
específico (deadline). Já nos sistemas hard, todas as tarefas devem ser desempenhadas não só
1999; LEWIS, 2001). Observa-se que a maioria dos sistemas de tempo real são aplicações
A Tabela 1.2 apresenta uma lista de domínios e aplicações de sistemas de tempo real
Tabela 1.2 Domínios e algumas aplicações típicas de sistemas de tempo real (LAPLANTE,
2004; BIHARI, 1992).
Domínio Aplicações
Navegação
Aviação Displays
Jogos
Multimídia
Simuladores
Cirurgia robotizada
Medicina Cirurgia remota
Imagem médica
Inspeção automática
Controle de elevador
Sistemas automotivos
Civil
Sistemas bancários
Sistemas de telecomunicação
(PAIGE, 2000). Dentre os objetivos das linguagens, podem ser destacadas a padronização,
uma vez que o conjunto deles forma um cenário completo do software. É possível ainda a
atende aos requisitos antes mesmo de sua codificação. Além disso, o software ficará
são utilizadas, estas atividades são deslocadas da fase de codificação para a fase de
requisitos do sistema através de casos de uso (IWU, 2007) antes da definição da estrutura do
gráficas, contudo também existem algumas que são notações formais, ou seja, fornecem um
linguagens gráficas são a SOMA (GRAHAM, 1998) e a MASCOT (SIMPSON, 1979). Está
24
última é uma abordagem de tempo real. Dois exemplos de linguagens formais são CSP
Neste sentido, métodos formais têm se mostrado uma alternativa para o projeto de sistemas
(GUERROUAT, 2005; LÜTTGEN, 2001). Iwu et. al. (2007) afirma que “a aplicação de
aeroespaciais. No Brasil o órgão responsável pela certificação de software para aviação civil é
a Agência Nacional de Aviação Civil – ANAC, e para aviação militar e sistemas espaciais, é o
de erros”.
1999). A UML tornou-se a linguagem padrão para modelagem orientada a objeto de sistemas
de software (IWU, 2007; PAIGE, 2000). A UML consiste de um conjunto de notações para
25
Rumbaugh (1999) define a UML como sendo “a linguagem padrão para especificar,
utilização da UML como padrão para modelagem de sistemas tem encorajado o uso de
Esta linguagem utiliza várias notações gráficas para capturar requisitos de sistemas e
realizar sua análise e projeto (GILMORE, 2005; IWU, 2007). A Seção 2.2 apresenta uma
descrição detalhada com os aspectos de todos os diagramas propostos pela UML. Douglass
(2003) destaca alguns motivos pelos quais a UML tornou-se a linguagem de modelagem de
possui um modelo semântico bem definido, que cobre a maioria dos aspectos necessários para
especificação e projeto de sistemas e é profundo, o que significa que é possível criar modelos
executáveis. Em segundo lugar, a UML é fácil para dominar e simples para entender. Embora
seja argumentado que a linguagem é composta por muitos diagramas, é possível desenvolver
sistemas complexos com apenas três diagramas (de classe, de estado e de seqüência). Em
terceiro lugar, a UML é um padrão, o que significa que a pessoa que desenvolverá poderá
Douglass (2003) afirma ainda que a UML “permite ao usuário definir um modelo do
sistema” e define modelo como sendo “um conjunto integrado e coerente de abstrações que
Além das vantagens apresentadas, a UML tem sido a base para o desenvolvimento de
bibliografia publicada sobre o assunto. Gilmore (2005), por exemplo, modela um sistema em
26
representação eficiente”. Baudry (2005) propõe uma medida da capacidade do sistema ser
testado através dos diagramas de classe da UML. Já Massink (2006) faz uma abordagem de
UML. Laitenberder (2000) faz uma comparação de técnicas de leitura para detecção de
defeito entre documentos de projeto de UML e uma tradicional abordagem de leitura baseada
1.5 Objetivo
embarcado de tempo real. Apresentou-se então a modelagem como possível solução para lidar
com esta complexidade. Podemos enquadrar nesta categoria os VANTs que realizam o
controle de atitude de forma autônoma durante o vôo, onde um erro pode ocasionar falhas que
Neste contexto, o objetivo deste trabalho consiste em utilizar a linguagem UML para
software propõem-se três abordagens distintas. Observa-se que estas três abordagens não têm
fonte gerado pelo RRRT. Esta abordagem visa demonstrar que o código gerado através da
modelagem em UML está dentro do limite estipulado nas métricas. São aplicadas as métricas
de comentário por arquivo fonte. Nesta abordagem utiliza-se o Rational® Test RealTime –
RTRT.
conjunto software de controle + planta1 controlada (Figura 1.1). Através desta abordagem é
controlada e vice-versa, permitindo assim detectar erros e falhas resultantes desta interação.
Usuário Usuário
Software de Software de
Controle Controle
Sistema
analisado
Planta
Planta
Sistema analisado
Abordagem tradicional Abordagem proposta
VANT. O RRRT é integrado a este simulador de vôo, cujo papel é gerar os sinais que seriam
1
A palavra ‘planta’ se refere ao objeto controlado, ou seja, o objeto que está sendo controlado pelo sistema de
controle, que neste caso é o VANT.
28
produzidos pelos sensores da aeronave e os enviar para o modelo, assim como receber o valor
do comando de atuação enviado pelo modelo no RRRT e calcular novos valores dos sensores.
estado, que são então integrados em uma única rede de Petri contendo também uma abstração
detalhada dos diagramas que compõem a UML e descreve a ferramenta CASE utilizada para
aplicação de algumas métricas aos arquivos de código fonte gerados pelo RRRT.
O Capítulo 6 faz uma breve introdução às redes de Petri e propõe a conversão dos
modelos em UML para este formalismo. São então verificadas algumas propriedades do
modelo construído.
Por fim, as conclusões deste trabalho são apresentadas no Capítulo 7, bem como
objeto, pode ser citada a maior facilidade para entender, adaptar e reutilizar o código
(BIHARI, 1992).
“objeto” e “classe”. Jacobson et al (1998) definem um objeto como uma entidade com
possuem atributos, que podem assumir diferentes valores de acordo com o estado do objeto, e
Um exemplo de classe pode ser “aeronave”. Exemplos de atributos são o tipo de asa, a
Exemplos de operações para esta classe são “decole” e “pouse”, que representam ações que
objeto pode solicitar um serviço de outro objeto através da passagem de uma mensagem
contendo ou não algum valor (atributo) para outro objeto, que por sua vez, executará o serviço
(operação) e enviará de volta o resultado através de outra mensagem. Uma mesma operação
30
pode assumir vários comportamentos, pois sua execução pode depender dos atributos a ela
utilização de classes muito parecidas, que possuem a mesma estrutura, porém diferem entre si
em algum detalhe. Neste caso, não há a necessidade de se criar uma nova classe, é possível
novas a esta nova classe (subclasse). Isto caracteriza o conceito de herança, que é definida
como “um mecanismo através do qual, elementos mais específicos incorporam a estrutura e o
Como exemplo de herança, pode-se citar “aeronave” como uma superclasse (que pode
conter propriedades como potência e autonomia de vôo) e “VANT” como uma subclasse, que
herda todas as características da classe e adiciona as suas específicas, como por exemplo,
ausência de tripulação.
a objeto, foram criadas várias linguagens. A próxima seção apresenta a Unified Modeling
orientados a objetos.
A UML surgiu a partir de outras três linguagens de modelagem de software que eram
as mais utilizadas no final da década de 80 e início dos anos 90. São elas: OMT, Objectory e
Grady Booch. Cada uma destas linguagens possuía seus pontos fortes e fracos. A OMT era
muito forte em análise, Booch Methodology era mais adequada para projeto, e Objectory era
uma linguagem apreciada por usuários mais experientes (QUATRANI, 2003). Em 1994
desenvolvimento de uma nova linguagem, até que em outubro de 1995 foi lançado o Unified
Method. Em seguida Jacobson foi incorporado ao grupo e em 1997 a UML foi proposta e
A UML propõe que a modelagem seja realizada através de vários diagramas que
mostram de forma visual as características do software modelado. São ao todo oito diagramas,
cada qual com sua função, que em conjunto possibilitam o entendimento do funcionamento
como pode ser visto na Figura 2.2 (OBJECT MANAGEMENT GROUP, 2005).
32
UML
Diagrama de colaboração
Diagrama de estados
Figura 2.2 Diagramas propostos pela UML (OBJECT MANAGEMENT GROUP, 2005).
• Diagrama de atividades
apresenta o fluxo de uma atividade para outra atividade, de forma abstrata e relativamente
simples, utilizando uma notação de fácil compreensão (JACOBSON et al, 1998). Uma
atividade descreve uma unidade lógica de trabalho e pode ser dividida em ações, que
2005).
Percorrer
trajetória
Retornar para
base
Pousar
O propósito deste diagrama é fornecer uma visão dos serviços em alto nível a serem
supridos pelo sistema, as relações entre eles e os atores envolvidos (LAITENBERGER et. al.,
2000). Os atores são quaisquer entidades externas ao sistema que interagem com ele.
Definidos os atores, o próximo passo é definir os casos de uso, que são as funcionalidades que
o sistema deve fornecer, ou seja, uma capacidade do sistema nomeada (DOUGLASS, 2002).
34
Os casos de uso capturam os requisitos do sistema, porém, eles devem ser bem
documentados, pois o simples nome dado a ele não o descreve completamente. A melhor
atores são representados por “pessoas” (mas não significa que os atores devem ser humanos,
eles podem ser quaisquer objetos que interagem diretamente com o sistema) e os casos de uso
são representados por balões. Cada caso de uso deve ser documentado com o fluxo de evento
a ser executado. Este fluxo mostra o(s) evento(s) que inicia(m) o caso de uso, o(s) evento(s)
que deve(m) ser executado(s) e o(s) evento(s) que finaliza(m) o caso de uso. Devem ser
documentados os possíveis eventos e possíveis caminhos que o sistema pode percorrer (mas
Então, através deste diagrama é possível verificar quais são os atores que interagem
com o software e as funcionalidades que ele deve fornecer. A Figura 2.4 apresenta um
exemplo de um diagrama de casos de uso, no qual um ator (Boom, que representa os sensores
de pressão estática e dinâmica) fornece dados de entrada para um VANT, que por sua vez
Boom fornece tanto a velocidade do VANT quanto sua altitude, permitindo calcular o sinal de
A última consideração sobre os casos de uso é a forma como ele realiza suas tarefas.
• Diagrama de seqüência
(DIPIPPO, 2000). O fluxo de eventos pode ser usado para determinar quais objetos e
bastante útil para a verificação dos requisitos do sistema. Cada linha no diagrama que parte de
um ator (que representa uma mensagem) mostra que ele necessita de alguma funcionalidade
do sistema. A melhor maneira de verificar os requisitos é com a ajuda do cliente que usará o
programa.
Desta forma, diagramas de seqüência são úteis para mostrar o que está acontecendo,
para definir os requisitos e para trabalhar com os clientes. Fazer um diagrama de seqüência
para cada fluxo básico de cada caso de uso é o suficiente para abranger todo o sistema. A
estação de controle em solo e o VANT em vôo, a partir do momento em que a aeronave passa
computador de bordo recebe os dados dos sensores e os envia para a estação. Em seguida,
envia a potência de operação para o motor e os ângulos de inclinação para cada superfície de
controle (ailerãos, leme e profundor) de acordo com a missão estabelecida antes do início do
vôo. Esta seqüência de ações se repete continuamente até o final da missão, quando então o
computador superfícies
motor sensores
de bordo de controle
Estação
1: enviar status da aeronave
N: missão finalizada
• Diagrama de colaboração
Este diagrama também permite visualizar as trocas de mensagens entre dois ou mais
objetos dentro de um caso de uso particular ou de um cenário. No entanto, ele apresenta uma
visão diferente de um cenário com objetos, onde o objetivo principal não é ilustrar a ordem
cronológica das mensagens, mas enfatizar as ligações entre os objetos. Um exemplo deste
diagrama é apresentado na Figura 2.6, que ilustra o cenário de comunicação entre a estação de
missão e manda o sinal de início da mesma para o computador de bordo da aeronave, que por
sua vez, se comunica com seus atuadores, formados pelo motor e pelas superfícies de
37
controle, e com os dispositivos de detecção de sinais, formados pelos sensores e pelo receptor
de GPS.
1: atribuir missão
2: iniciar missão
computador:
ComputadordeBordo
1: finalizar missão
detectoresdeSinais:
superfíciesdeControle: SensorPressão
motor: Ailerãos
Motor SensorInercial
Leme GPS
Profudor
Figura 2.6 Diagrama de colaboração.
• Diagrama de estados
Este diagrama apresenta a história da vida de uma determinada classe. Ele mostra os
eventos que causam uma transição de um estado para outro e as ações que resultam de uma
mudança de estado. Ele deve ser elaborado para classes de objetos que possuem
comportamento dinâmico. Douglass (2002) define estado como sendo uma “condição de
Para que o sistema passe de um estado a outro, é necessário que ocorra algum evento
que constitui um gatilho (trigger) para esta mudança. As tarefas podem ser desempenhadas
2
O estado pode ser distinguido em termos de:
Comportamento do objeto enquanto entra, sai ou existe naquele estado;
Eventos aceitos enquanto naquele estado; e
Gráfico de alcançabilidade de estados subseqüentes.
38
tanto na passagem de um estado a outro, quanto dentro do estado (em sua entrada ou em sua
saída). O primeiro estado é aquele que recebe a seta do círculo escuro e o diagrama é
finalizado numa circunferência com um círculo dentro. Um estado pode possuir uma transição
Na Figura 2.7 é possível visualizar um exemplo deste diagrama que ilustra como
iniciado no primeiro estado e logo em seguida avança-se para o segundo estado, cuja função é
obter a altitude atual e a altitude de referência da aeronave. Feito isto, o próximo estado
calcula o erro (diferença entre as duas altitudes obtidas) e então é realizada a atuação no
profundor no estado seguinte. Em seguida retorna-se para o segundo estado para obter
Obtenha Altitude
Calcule erro
Atuacao
• Diagrama de classes
e como elas se relacionam entre si. Um modelo pode ser ilustrado em vários diagramas de
39
classes. O fato de duas classes estarem conectadas indica que pode haver troca de mensagens
entre elas.
UML elas são representadas por retângulos divididos em três compartimentos: o primeiro
contém o nome da classe, o segundo apresenta sua estrutura (atributos) e o terceiro apresenta
são:
analisando-se os requisitos.
A associação é uma conexão bidirecional entre classes e significa que uma classe pode
mandar uma mensagem para outra, pois conhece a existência da mesma. Este relacionamento
é representado por uma linha conectando as classes. A agregação é uma forma mais forte
onde o relacionamento é entre um todo e suas partes. É representada por uma linha
dependência é uma forma mais fraca que mostra o relacionamento entre um cliente e um
UML por uma linha tracejada apontando do cliente para o fornecedor. Estes relacionamentos
são ilustrados na Figura 2.8, que exemplifica uma forma de como pode ser feito o controle de
destas grandezas.
Estacao
ControleVoo
recebaAtitude()
ajusteAtitude() envieMissao()
envieAtitude()
recebaMissao()
ControleProfundor
ControleVelocidade Profundor
altitude
angulo
velocidade erro angulo
potencia
erro ajusteAngulo(ângulo)
ajusteAltitude(altitude)
ajusteVelocidade(potencia)
Motor CalculoAtuacao
potencia erro
ajustePotencia(potencia) calculeAtuacao(erro)
instâncias de uma classe relacionada a uma instância de outra classe. Ela é representada por
instâncias seja muito grande, pode ser utilizado um asterisco. A navegação diz respeito ao
porém, sempre que possível, é aconselhável definir o sentido da mensagem, caso esta ocorra
41
em apenas um sentido. Ele é representado com uma seta ligando as duas classes, partindo da
2.1. É a relação entre uma superclasse e uma subclasse e é ilustrada por um triângulo no
terminal da linha próximo à superclasse. A Figura 2.9 apresenta um diagrama de classes com
de instâncias nas relações e o sentido da comunicação nos casos em que ela ocorre em apenas
um sentido.
ControleVoo Estacao
0...1 1...*
ajusteAtitude() recebaAtitude()
envieAtitude() envieMissao()
recebaMissao()
ControleProfundor
ControleVelocidade 1
Profundor
altitude
angulo 1
velocidade erro angulo
potencia
erro ajusteAngulo(ângulo)
ajusteAltitude(altitude)
ajusteVelocidade(potencia)
1
1...4
Motor CalculoAtuacao
potencia erro
ajustePotencia(potencia) calculeAtuacao(erro)
• Diagrama de componentes
Controle.exe
Guiamento.exe
Sistema de
Comunicação
Sensoriamento
Atuadores.dll Sensores.dll
Atuação
• Diagrama de implantação
distribuição dos componentes através do sistema. É uma forma visual de saber quais
enquanto que microcontroladores dedicados fazem a interface entre ele e sensores e atuadores,
Computador
de Bordo
(VANT)
Estação de
Controle Satélite
Acionamento e
Sensoriamento
(VANT)
Entende-se por ferramenta CASE “uma coleção integrada de ferramentas projetadas para
Schulmeyer (1992) lista alguns dos benefícios da utilização de uma ferramenta CASE,
dentre os quais estão benefícios de custo, retrabalho reduzido, suporte automático para o
C++ e JavaTM. Ele gera o código fonte a partir dos diagramas da UML do modelo
o arquivo executável a partir deste código fonte gerado. É possível gerar o código para ser
comportamento detalhado de estado. Os 15% restantes são detalhes que são melhor expressos
o RRRT e a UML para capturar o projeto do sistema, então o compilador de UML (e não o
próprio projetista) traduz o projeto em código. Desta forma, o projetista deve se preocupar
apenas com os detalhes de projeto. Além do mais, a geração automática de código diminui
estáticas, que não possuem comportamento. No restante deste texto, o termo classe será
utilizado para referenciar classes estáticas, enquanto o termo cápsula será utilizado para classe
dinâmica.
modelo é gerado um arquivo fonte (extensão .c) e um arquivo de cabeçalho (extensão .h).
Além destes arquivos, são necessários alguns arquivos relativos aos serviços oferecidos pelo
45
RRRT, como por exemplo, de temporização (em geral, são criados quatro arquivos de código
Os arquivos gerados referentes às cápsulas possuem várias funções que refletem sua
construção. Dentre elas, há uma função onde é refletido o comportamento da cápsula, ou seja,
estados, transições, a interligação entre estes elementos e os possíveis eventos que disparam
estas transições). Existe também uma função para cada transição do diagrama, que possui
algumas chamadas de funções que são executadas ao ocorrer um evento que dispare esta
Além destas funções, estes arquivos possuem uma estrutura de mapeamento dos sinais
de protocolo que podem ser utilizados para comunicação com outras cápsulas através de suas
portas. Também há várias definições de vetores que contêm, dentre outras coisas, os nomes
dos estados do diagrama de estados, índices associados a cada um deles, as portas da cápsula
Já os arquivos gerados referentes às classes são bem mais simples do que os das
declarações dos atributos da classe e seus tipos, de suas operações e descrição do tipo da
classe.
estudo de caso, é realizada uma breve descrição deste VANT, bem como seu hardware e
funcionamento, para então, por fim, apresentar a modelagem em UML. Observa-se que neste
Esta modelagem pode ser expandida de forma semelhante para as demais superfícies de
controle.
O VANT considerado neste trabalho é de asas fixas, para aplicações civis e com nível
autônoma sua trajetória e efetuar seu guiamento. Observa-se que este VANT não possui
comunicação em tempo real com a estação em solo. Uma vez dominadas estas tecnologias, os
três metros e sessenta centímetros (3,6m) de envergadura e capacidade de carregar carga útil
de até doze quilogramas (12 kg). A plataforma aérea utilizada foi desenvolvida no Centro de
3
O profundor é uma das superfícies de controle de uma aeronave. As superfícies de controle são os atuadores do
sistema que controlam sua atitude, fazendo o veículo efetuar determinada trajetória.
47
3.1.1 Hardware
também conhecido como Blackfin. Este microprocessador opera com clock de 300 MHz,
apresentado de forma simplificada na Figura 3.1, onde estão indicados os periféricos ligados
ao processador. Os dispositivos que estão do lado esquerdo fornecem dados de entrada, que
atuação do VANT. O sinal enviado pelo processador também segue o padrão de comunicação
RS-232, que é então convertido por um conversor de sinais usando a técnica de Modulação
por Largura de Pulso (Pulse Width Modulation – PWM). Os sinais de saída deste conversor
são enviados para servomotores (designados na figura por SM), que por sua vez são
GPS Ailerãos
PWM SM
PWM Motor de
Receptor SM combustão
rádio-
controle
3.1.2 Software
trajetória da aeronave para chegar a um determinado destino quando o piloto automático está
enviado aos servomotores de forma que a direção de vôo seja aquela definida pelo
“Guiamento”, no caso de piloto automático, ou aquela definida pelo piloto em terra, caso o
piloto automático esteja desativado. Para tanto, o módulo “Pilotagem” recebe os dados do
receptor de GPS e dos demais sensores. O objetivo deste trabalho se restringe ao módulo
“Pilotagem”.
usuário, onde a diferença entre eles é a lei de controle utilizada para calcular o sinal de
que caracterizam a diferença entre os modos de operação para o módulo “Pilotagem”. O sinal
Deflexão
do manche
CAS
Simulador
Piloto 1 Controlador 2 Controlador 4
Profundor
automático PID de θ 3 PID de q 5
qm
θm
Figura 3.2 Malha de controle do profundor.
abaixo:
Modo 0: a aeronave é controlada pelo piloto e o software não realiza nenhum tipo de
Simulador
Deflexão
do manche Profundor
qm
θm
Figura 3.3 Malha de controle para o modo de operação 0.
Figura 3.4.
50
Simulador
Deflexão Controlador
CAS Profundor
do manche PID de q
qm
θm
Figura 3.4 Malha de controle para o modo de operação 1.
arfagem) e um controlador PID para o erro desta variável. Sua malha de controle é
Simulador
Piloto Controlador Controlador
Profundor
automático PID de θ PID de q
qm
θm
que ilustra, em alto nível, as tarefas desempenhadas pelo software e sua interação com o
mundo externo, representado pelos atores. A Figura 3.6 apresenta este diagrama.
51
Signal Conditioning
Rec eive Input Data Adjust Attitude Send Output Data
Boom
(from Use Cases and its diagrams)(from Use Cases and its diagrams) (from Use Cases and its diagrams)
Pilot
Motor
Rudder
Ailerons
O caso de uso central é “Adjust Attitude”, que é a principal tarefa do software. Ela é
executada através de várias outras tarefas mais detalhadas, como controlar o ângulo do
profundor, controlar o ângulo do leme, a velocidade do motor, entre outras. Os atores que
estão do lado esquerdo da figura são os que enviam sinais de entrada para o sistema, como o
GPS e o sensor inercial. Eles enviam seus respectivos dados para o condicionador de sinal,
também representado por um ator (por ser um elemento externo que interage diretamente com
o sistema). Para este ator, existe um caso chamado “Receive Input Data”, cuja função é
enviam seus dados diretamente ao software modelado, sem o intermédio do ator “Signal
Conditioning”.
Para ajustar a atitude, o caso de uso principal recebe os dados dos atores e calcula as
posições dos atuadores: elevator, ailerons, rudder e motor, como pode ser visto nos casos de
52
uso que estão na parte superior da figura. Em seguida, estas posições são enviadas aos
atuadores que são representados pelos atores ilustrados na parte inferior pelo caso de uso
“Send Output Data”, por intermédio do ator “Signal Converter”. Para modificar a posição das
superfícies de controle, o sistema interage com os servomotores, que por sua vez, atuam nas
superfícies de controle. A Tabela 3.1 apresenta uma lista dos atores e uma breve descrição da
Observa-se que este diagrama não tem efeito na compilação do modelo dentro do
Uma vez elaborado o diagrama de casos de uso, o próximo passo consiste em detalhar
atividades, que detalham em alto nível as ações desempenhadas no cenário de cada caso de
“Receive Input Data”, cuja função é receber os dados provindos dos sensores e do receptor de
input data”.
[Autonomous mode]
[Else]
Rec eive data from Rec eive data Rec eive data
Signal Conditioning from Pilot from Guidanc e
[Else]
Os dados recebidos pelo sistema de cada sensor, GPS e piloto ou guiamento têm uma
amostragem de 20 ms, pois o sistema de aquisição trabalha numa freqüência de 50 Hz. Desta
forma, ao ser iniciado o sistema, é disparado um timer e logo em seguida o caso de uso recebe
(modo autônomo) e os envia para o caso de uso que o utilizará. Em seguida o sistema verifica
se a execução do software foi finalizada. Em caso positivo, o diagrama passa para o estado
final. Em caso negativo, ele verifica se ocorreu timeout. Estas verificações são repetidas até a
acima descritos.
apresentado na Figura 3.8 e seu papel é receber os dados provindos de atores (que
Select operation
mode
Calc ulate elevator Calc ulate ailerons Calc ulate Calc ulate rudder
positioning positioning motor power positioning
Comunic ate
output data
[ Else ]
Para realizar o caso de uso Adjust Attitude, este diagrama de atividades mostra que,
primeiramente são recebidos os dados vindos do caso de uso “Receive Input Data” através da
atividade “Comunicate input data”. Em seguida, ele verifica o modo de operação do VANT,
pois isto altera a forma com que será realizado o controle. São, então, calculados os comandos
que devem ser enviados aos atuadores com utilização de funcionalidades fornecidas por
outros casos de uso, para em seguida serem enviados aos respectivos atuadores pelo caso de
uso “Send Output Data” através da atividade “Comunicate output data”. Caso a execução do
56
software tenha sido finalizada, o diagrama passa para o estado final, em caso negativo, ele
Elevator Positioning”.
Send elevator
positioning
posição do profundor sempre que solicitado pelo caso de uso “Adjust Attitude”. Assim, suas
atividades consistem em receber os dados necessários para este cálculo, em seguida calcular a
nova posição do profundor (elevator) e enviar a resposta para o caso de uso solicitante.
potência do motor possuem diagramas de atividades semelhantes a este, onde a diferença está
apenas no atuador para o qual eles vão calcular as novas posições/potência. As atividades em
seus diagramas são as mesmas do diagrama da Figura 3.9. Portanto, estes diagramas não são
Comunicate
output data
[ Else ]
Este caso de uso possui o papel de enviar os comandos calculados aos atuadores do
entre os objetos, como explicado na seção 2.2. Como no caso dos diagramas de atividades,
nesta e nas próximas seções são apresentados apenas os diagramas referentes ao cálculo do
semelhantes.
entrada do sistema em modo não autônomo. Este recebimento é realizado pela cápsula
“DataReceiver”, cuja função é explicada mais à frente. Ele é apresentado na Figura 3.11.
58
/ dataRec eiverR1
: DataRec eiver
1: send attitude
1: send c ommand
Ac tiv e
Figura 3.11 Diagrama de seqüência do recebimento dos dados de entrada do sistema em modo
não autônomo.
serial. A partir daí, as trocas de mensagens são um ciclo em que o ator “Signal Conditioning”
recebe os dados dos sensores do sistema, os envia para a cápsula “DataReceiver”, que
/ dataRec eiverR1
: DataRec eiver
1: send attitude
1: send c ommand
Ac tiv e
Figura 3.12 Diagrama de seqüência do recebimento dos dados de entrada do sistema em modo
autônomo.
A diferença deste diagrama para o anterior é que quando o sistema entra no modo
aeronave ainda estava em modo não autônomo), descartando esta etapa, e o piloto é
“ElevatorController” o comando que deve ser repassado ao profundor, o que é realizado por
Conditioning” recebe mensagens dos atores “GPS”, “Inertial Sendor” e “Boom” e os envia à
/ gPSR1
: GPS
/ inertial_SensorR 1 / signal_ConditioningR1
: Inertial Sensor : Signal Conditioning
/ boomR1
/ pilotR1 : Pilot
: Boom
Para o cenário de vôo autônomo, basta substituir o ator “Pilot” pelo ator “Guidance”
na figura acima.
possível verificar que há troca de mensagens entre a cápsula responsável por receber os dados
sua vez, troca mensagens com a cápsula responsável por enviar dados ao atuador (Elevator).
visualizado na Figura 3.17. Este diagrama mostra que o atuador é controlado por uma cápsula
63
responsável pela atuação (Elevator) por intermédio do ator “Signal Condiotining”, que por
sua vez, troca mensagens com uma cápsula de controle, chamada “ElevatorController”
Cada cápsula possui um diagrama de estados que modela seu comportamento. São
“ElevatorController” e “Elevator”.
Este diagrama pode ser visto na Figura 3.18. Ele possui três estados em seqüência,
onde o último estado possui uma transição para ele mesmo (Transition to Self) para
“open_serial_port” é disparada tão logo o modelo é executado, pois seu gatilho (trigger) é
disparado por timeout e sua função é apenas de abrir a comunicação com a porta serial, definir
suas configurações, como por exemplo, a taxa de transferência de dados (baud rate), e enviar
para a cápsula “Elevator” uma variável ponteiro que aponta para a porta serial. A transição
guiamento, e enviá-los para a cápsula “ElevatorController”. Seu gatilho pode ser disparado
64
por timeout (apenas na primeira vez em que é executado) ou por requerimento da cápsula
“ElevatorController”, que faz esta requisição sempre que o software estiver pronto para
Initial open_serial_port
port_opened
Idle
send_mode
rec eiv e_and_send_v ec tor
Ac tiv e
(Elevator) para que a aeronave mantenha ou alcance a altitude requerida pelo controlador
(piloto ou módulo de guiamento). Seu diagrama pode ser visto na Figura 3.19.
False Mode 2?
Mode 1?
Initial Mode 0? False
False Mode2
mode_rec eiv ed Mode1
Mode0
Idle True
True
True
Mode0_2
Mode1_2
Mode2_2
c alc ulating
c alc ulating c alc ulating
False False
False
comando de atuação de acordo com o modo. Caso o modo de operação enviado para esta
cápsula seja um valor inválido (diferente de 0, 1 ou 2), a cápsula assume o modo 0. Após o
de flexão do profundor intermitentemente até que o modo de operação seja alterado, fazendo
acordo com os dados recebidos e enviada para a cápsula correspondente a este atuador. Caso
o modo de operação tenha sofrido alguma alteração, o programa volta para o estado “Idle” e
imediatamente passa para a o estado correspondente ao novo modo. Caso o modo não tenha
sido alterado, o programa se mantém no laço de recebimento dos dados e cálculo da atuação
Está cápsula tem como única função mandar o sinal de atuação do profundor através
Initial
W aiting_for_pointer
Ac tiv e
send_c ommand
transição é disparada diversas vezes durante a execução, sempre que é calculado um novo
comando de atuação.
Este diagrama é gerado automaticamente pelo RRRT, assim não é necessária sua
VANT.
67
<<Capsule>>
<<Capsule
Elev ator
TOP
port : int
<<Capsule>>
Elev atorController
<<Capsule>>
DataReceiv er mode : float
e_theta0 : float =0
c ont : int = 0 e_theta1 : float =0
e_theta2 : float =0
tilt : float
# / timer : CTiming q : float
+ / to_elev atorController : elev atorProtoc ol~ theta : float
+ / to_elev ator : elevatorProtoc ol~ i : int = 0
theta_ref : float
t : int = 0
u_theta1 : float =0
e_q0 : float = 0
Serial Vector e_q1 : float = 0
e_q2 : float = 0
serial_port : int* mode : float u_q1 : float = 0
stic k _tilt : float Controller port : int
read()
q : float
write() A : int
theta : float
open() + / to_elev ator : elevatorProtoc ol~
theta_ref : float
read_teste() PID() # / timer2 : CTiming
+ / to_dataRec eiv er : elev atorProtoc ol
entre as classes e a estrutura de cada uma – seus atributos, suas operações e suas portas de
explicação de seus respectivos diagramas de estados. A cápsula “TOP” foi criada apenas para
Figura 3.22. A classe chamada “Serial” foi criada para fornecer as funcionalidades de
comunicação através da porta serial. Nela foram criadas operações para abrir, ler e escrever na
68
porta serial. Estas operações são utilizadas pelas cápsulas que precisam destes serviços. A
classe “Vector” foi criada para ser utilizada como tipo de dado para a variável que recebe os
que manipulam estes dados. Por fim, a classe “Controller” foi criada para fornecer a
funcionalidade de cálculo do controlador PID do sistema. Ela possui uma operação chamada
“PID” que efetua estes cálculos. Caso seja necessária a implementação de outras leis de
controle, pode-se adicionar novas operações a esta classe para realizar os cálculos
embarcado de piloto automático para permitir sua simulação dentro do ambiente utilizado
serial do computador (PC), para possibilitar a integração entre o modelo dentro do RRRT e o
estruturas, que é específico do RRRT e não faz parte do conjunto de diagramas proposto pela
quem troca dados com quem, através de qual porta de comunicação e através de qual
protocolo. A Figura 3.22 apresenta este diagrama para o software modelado, considerando
apenas o controle do profundor. As portas são representadas por pequenos quadrados na borda
portas-base. A diferença entre elas é o sentido das mensagens dos sinais utilizadas por seu
entrada são utilizados para mensagens de saída e os sinais de saída para mensagens de entrada
na porta.
/ elev atorControllerR1
: Elev atorController
/ elev atorR 1
: Elev ator
software modelado não apenas através da observação do valor de variáveis do sistema, mas
também através da evolução dos diagramas de estado das cápsulas. Para esta finalidade o
RRRT apresenta monitores dos diagramas de estado e uma janela de prompt de comando que
modelado:
Com a execução do modelo, foi testada a troca de dados entre as diversas cápsulas,
verificando a existência de erros na comunicação entre elas. Esta verificação é suportada pelo
modo de simulação do RRRT, que indica a ocorrência de erro quando uma cápsula tenta
enviar um dado para outra sem que esta última esteja preparada para recebê-lo. Foi também
testada a execução do software nos três modos de operação e a mudança entre eles,
correta execução das tarefas necessárias ao piloto automático do VANT. O próximo capítulo
Métrica de qualidade de software pode ser definida como “uma função cujas entradas
são dados de um determinado software e cuja saída é um único valor numérico que pode ser
interpretado como o grau em que o software possui um dado atributo que afeta sua qualidade”
(IEEE, 2005).
de software (GRADY, 1987; SCHULMEYER, 1992). Alguns destes atributos que podem ser
realização de estimativas de custo e esforços”. Algumas das razões pelas quais um software é
As métricas da última categoria são aplicadas ao produto final para avaliar sua conformidade
com os requisitos.
72
Pressman (1995) apresenta uma segunda classificação, onde as métricas são divididas
em duas categorias principais, cada uma das quais dividida ainda em três subcategorias. A
métricas orientadas às pessoas. A Tabela 4.1 apresenta uma breve descrição destas duas
primeira visa à correção, confiabilidade e desempenho. Já a segunda, tem por objetivo auxiliar
como “a facilidade com que um sistema de software ou componente pode ser modificado para
facilidade com que um sistema ou componente pode ser modificado para uso em aplicações
ou ambientes diferentes daqueles para os quais ele foi especificamente projetado” (IEEE,
1990).
automático das mesmas. A métrica de complexidade ciclomática tem sido alvo de pesquisa
por parte de diversos autores (NURMINEN, 2003; JUNG, 2000; TAKAHASHI, 1997;
dificuldade de desenvolvimento do código fonte. Por fim, a métrica de Linhas de Código trata
cada uma destas métricas, assim como sua aplicação para o código fonte gerado pelo RRRT a
partir dos caminhos básicos possíveis que um software pode percorrer. No entanto, qualquer
programa que possui uma ramificação regressiva potencialmente tem um número infinito de
possíveis caminhos. Desta forma, McCabe propõe que sejam considerados apenas os
caminhos linearmente independentes, cujas combinações entre eles formam todos os possíveis
pode ser expresso através de uma combinação linear de circuitos deste grafo. A complexidade
V (G ) = e − n + p (4.1)
é o número máximo de nós conectados por um arco. Como exemplo, a Figura 4.1 apresenta
um grafo de fluxo de controle. Para este grafo, e = 12, n = 9 e p = 2, resultando em V(G) igual
a 5 (V(G) = 12 – 9 + 2 = 5).
fluxo, através da identificação da quantidade de regiões do mesmo. Uma região pode ser
informalmente definida como uma área incluída no plano do gráfico. O número de regiões é
computado contando-se todas as áreas delimitadas e a área não delimitada fora do gráfico. A
2
3
4
Figura 4.2 Exemplo de grafo de fluxo de controle com contagem das regiões.
iterações serão necessárias para se percorrer todos os caminhos possíveis a fim de se testar
software de acordo com o valor obtido do V(G). Esta associação entre o valor do V(G) e o
risco é baseada no fato do V(G) oferecer uma medida quantitativa da dificuldade de se fazer
testes que avaliem de forma completa os possíveis cenários de execução, garantindo assim a
ausência de erros. A Tabela 4.2 apresenta esta associação entre o valor do V(G) e o risco.
Todos os arquivos dos códigos fontes gerados automaticamente pelo RRRT a partir
resultados obtidos para o V(G) dos arquivos gerados são apresentados na Tabela 4.3. Estes
valores de métricas foram obtidos com uso do RTRT cujo cálculo é feito automaticamente
O V(G) é calculado para cada função dentro de cada arquivo gerado pelo RRRT. O
V(G) máximo de cada arquivo listado na tabela é o maior valor obtido dentre suas funções. O
V(G) médio é a média de todos os valores obtidos de todas as funções de cada arquivo.
classe ou protocolo criados pelo usuário do RRRT, mas são arquivos gerados pelo RRRT para
cápsulas ou classes do modelo criadas pelo usuário. Uma descrição do procedimento adotado
pelo RRRT para gerar o código fonte a partir dos modelos foi apresentada na Seção 2.3.
Para cada função de cada arquivo listado na tabela analisou-se o valor de V(G) obtido.
Verificou-se que, com exceção da função que possui o maior V(G) de cada arquivo, todas as
77
ou 3), resultando em 91,67% das funções classificadas como simples, sem muito risco. Isto
apenas uma) com o V(G) mais elevado. Não coincidentemente, estes são os arquivos dos
códigos fontes das três cápsulas que implementam as principais funções do modelo, que
realmente executam suas tarefas (de receber os dados do simulador, tratá-los e enviar o
Foi verificado que a função que possui o V(G) mais alto de cada arquivo é a que
complexidade desta função é alta devido à forma como ela é criada pelo RRRT. Basicamente,
ela é composta por um laço principal com diversos comandos de decisão internos, o que gera
esta função são o estado atual do diagrama de estados, a porta por onde eventualmente é
recebido um determinado sinal e o sinal eventualmente recebido. Desta forma, dentro do laço
existem três níveis de comando switch, um para cada índice que é passado para a função.
No primeiro nível (verificação do estado atual) haverá tantos case quantos forem os estados
mais um. No segundo nível (verificação da porta de onde vem o sinal) haverá tantos case
quantos forem as portas disponíveis para chegada de sinais que disparem uma transição mais
um. Enfim, no último nível (verificação do sinal recebido pela cápsula), haverá tantos case
quantos forem os sinais que estão habilitados para serem recebidos pela porta em questão para
disparar a transição.
de código automatizada para evitar que o software entre em deadlock. De acordo com o
78
percorrido no grafo de fluxo formado a partir do diagrama de estados, mesmo que não haja
nenhum sinal chegando, ou ocorra alguma falha em outro ponto do software que cause o
Em geral, este grafo de fluxo é mais simples do que aquele correspondente ao código gerado
desconsideração das portas e sinais é válida uma vez que independentemente da porta de
código em cada transição. Este resultado indica que em geral, para um mesmo diagrama de
estados, é possível obter códigos fontes com menor V(G) do que aquele gerado
transição “mode_received” pode ser disparada por dois sinais provindos de duas portas
será o mesmo. Desta forma, numa geração de código visando à minimização do V(G), isto não
False Mode 2?
Mode 1?
Initial Mode 0? False
False Mode2
mode_rec eiv ed Mode1
Mode0
Idle True
True
True
Mode0_2
Mode1_2
Mode2_2
c alc ulating
c alc ulating c alc ulating
False False
False
1 8
2
4 6
3 5 7
Fazendo-se uma rápida inspeção visual deste grafo de fluxo, chega-se a um valor de
V(G) igual a 8, muito inferior a 43, valor este obtido a partir do código gerado
Foi verificado ainda que uma cápsula que não possui diagrama de estados, ou seja, não
ciclomática igual a 8. Isto é uma indicação da complexidade da estrutura criada pelo RRRT
cápsulas e dividindo-se as tarefas da função original com alto V(G). Observa-se, no entanto,
que este procedimento não garante necessariamente uma diminuição do número de erros ou
do risco, uma vez que estas cápsulas devem se comunicar e esta comunicação deve ser
definida pela pessoa que está modelando o sistema. Em outras palavras, deve-se balancear a
realizada de forma automática (a princípio, livre de erros) pelo RRRT, enquanto que a
estudadas são aquelas resultantes da teoria de Halstead (1977). Halstead propõe o cálculo de
algumas métricas a partir de quatro grandezas básicas medidas diretamente do código fonte
n = n1 + n 2 (4.2)
N = N1 + N 2 (4.3)
A partir destas métricas básicas, Halstead desenvolve expressões para obter diversas
V = N e log 2 n (4.5)
⎛ n ⎞⎛ N ⎞
D = ⎜ 1 ⎟⎜⎜ 2 ⎟⎟ (4.6)
⎝ 2 ⎠⎝ n 2 ⎠
E = VD (4.7)
As demonstrações destas expressões estão fora do escopo deste trabalho, e podem ser
Todos os arquivos gerados pelo RRRT também foram analisados de acordo com as
métricas propostas por Halstead listadas na Tabela 4.4. Os valores obtidos estão listados na
Tabela 4.5.
82
considerados aqui os quatro últimos arquivos listados na tabela, uma vez que estes não são
A utilização das métricas de Halstead serve de referência para fazer comparações entre
vários arquivos de código fonte de um ou mais softwares, mas não são sugeridos ou impostos
limites máximos e/ou mínimos para cada um dos valores obtidos. Assim, as conclusões que
podem ser tiradas dos dados obtidos a partir do código gerado são de certa forma, similares às
esforço e a dificuldade para seu desenvolvimento são os maiores de todo o software. Isto pode
ser explicado pelo fato de esta cápsula possuir o maior diagrama de estados, com a maior
quantidade de estados e transições, além de ser a cápsula que efetua a maior parte do
Diferentemente das duas métricas anteriores, que são medidas indiretas do software, a
métrica de linhas de código é uma medida obtida diretamente do código fonte produzido e é
uma métrica orientada ao tamanho. Ela fornece a quantidade de linhas de código fonte, como
também a quantidade de linhas que são comentários. A relação entre estas duas grandezas
entender e manter programas”, porém, “comentários sem sentido ou incorretos podem ser
nocivos” (WEISSMAN, 1974). Qualquer programa que não seja trivial e não contenha
comentários é difícil de ser compreendido e oferece risco de introdução de erros durante sua
Exemplos de outras métricas orientadas ao tamanho e que são medições diretas são o
Como para as métricas anteriores, foi calculada a quantidade de linhas de código fonte
total e percentual de linhas de comentários para todos os arquivos gerados pelo RRRT. Yang
como valor padrão utilizado em diversos projetos de software uma média de 1 linha de
comentário para cada 3 linhas de código fonte, ou seja, uma média de 25% das linhas
formadas por comentários. A Tabela 4.6 apresenta os valores obtidos com uso do RTRT para
esta métrica.
84
portanto, não possui diagrama de estados. Desta forma, ela não possui nenhum código
inserido pelo usuário, o que acarreta que o código fonte produzido é totalmente elaborado
pelo RRRT, incluindo os comentários. Neste caso, a taxa obtida foi de 13,84% das linhas
modelo definido pelo usuário), para os demais arquivos a taxa obtida foi superior aos 25%,
pois todos estes possuem comportamento ou operações criadas pelo usuário, o que possibilita
a inclusão de comentários por ele, de forma a melhor documentar o arquivo fonte produzido.
Nos quatro últimos arquivos listados na tabela acima, o usuário não participa de sua geração,
A quantidade total de linhas produzidas pelo RRRT nos arquivos de código fonte
referentes aos elementos criados pelo usuário no modelo (cápsulas e classes) foi de 2578, com
De uma forma geral, a aplicação das métricas selecionadas ao código fonte gerado
mais complexo, pode ser considerada mais segura, uma vez que as regras para construção da
De acordo com este diagrama o dispositivo de realização de controle interage com o ambiente
físico (objeto de controle, ou planta controlada) através de sensores e atuadores. Além disso,
2005), além de informar o usuário sobre o estado atual do sistema através dos dispositivos de
monitoração.
Dispositivo de Dispositivo de
comando atuação
Operador/ Dispositivo
Objeto de
Usuário de realização
controle
de controle
Dispositivo de Dispositivo de
monitoração detecção
Sistema de controle
Figura 5.1 Diagrama conceitual básico de um sistema de controle (MIYAGI, 1996).
87
Neste caso, o usuário é o piloto do VANT que, através do joystick, envia os dados de
a malha de controle e envia os dados de atuação de volta para o simulador de vôo, onde está
também é realizada através do simulador de vôo, que contém elementos que permitem a
Atuador do
Joystick
Profundor Veículo
Piloto Computador Aéreo Não
Tripulado
GPS, sensor
Monitor
inercial e boom
Sistema de controle
Figura 5.2 Diagrama conceitual básico do sistema de controle do VANT em estudo.
foram utilizados dois computadores que se comunicam através de suas respectivas portas de
(Universal Serial Bus) do computador onde é executado o simulador de vôo para simular o
comando do piloto no manche nos casos em que o software é executado em algum modo de
Comunicação
Comunicação via porta USB
serial
finalização da simulação são comandadas pelo simulador, através do qual o usuário interage
dados do simulador, para então realizar suas tarefas e enviar a resposta referente aos
Para que a simulação integrada ocorra sem conflitos e erros, o modelo no RRRT deve
ser executado num intervalo de tempo menor do que aquele resultante da freqüência de
trabalho do simulador. A troca de mensagens pela porta de comunicação serial ocorre numa
taxa de transferência (baud rate) de 115200 bits por segundo (bps) e a troca de dados ocorre
numa freqüência de 20 Hz, ou seja, a cada 50 ms. O modelo deve, portanto, receber os dados,
simulador de vôo. Sendo assim, modifica-se a cápsula “DataReceiver” para interação com um
único ator externo ao sistema, o Simulator, que substitui não apenas o Signal Conditioning e
os atores a ele conectados (GPS, Inertial Sensor, Boom), mas também o Pilot, Guidance,
profundor nesta nova configuração. Este diagrama contempla o cenário completo de cálculo
deste comando, desde o envio dos dados de entrada do modelo, até o envio do comando de
atuação de volta para o simulador. Nos diagramas mostrados na Seção 3.2, este cenário é
/ simulatorR1
: Simulator
1: send input data
2: send input data
Figura 5.4 Diagrama de seqüência para a configuração de integração com o simulador de vôo.
O simulador de vôo utilizado neste trabalho foi desenvolvido por Nei Salis Brasil Neto
como plataforma aérea para testes do sistema de controle projetado para aeronaves.
Neste simulador a aeronave é considerada um corpo rígido com seis graus de liberdade
(6DOF), formados pelas rotações em torno de cada um dos três eixos do sistema de referência
eixos. A estrutura básica do simulador é composta por cinco blocos, conforme ilustrado na
Figura 5.5: Actuators, Atmosphere Model, Auto Pilot, Interfaces e 6 DOF Non-Linear Aircraft
Model.
91
Atmosphere Model
Auto Pilot
Neste trabalho, a versão do simulador de vôo utilizada não inclui o bloco “Atmosphere
Model”, pois desconsideraram-se perturbações atmosféricas. O “Auto Pilot”, por sua vez, foi
cujas entradas são os comandos que devem ser enviados para eles e, no caso deste trabalho,
são provindos do modelo do RRRT. Suas saídas são os dados de controle da aeronave. O
próximo bloco (6 DOF Non-Linear), que recebe como entrada as saídas do primeiro bloco,
representa o modelo não-linear da aeronave. Neste bloco está modelada a dinâmica de vôo da
plataforma aérea utilizada através das equações de movimento. Em seguida tem-se um bloco
de interface (Interfaces), cuja função é organizar seus dados de entrada (saídas do bloco
anterior), de forma que cada saída deste bloco possua os dados necessários para seu destino.
Por exemplo, a saída chamada “Auto Pilot” possui os dados que devem ser enviados para o
software embarcado do VANT (neste caso, para o modelo no RRRT). Estes dados estão
listados na Tabela 5.1. Por fim, o bloco chamado “HARDWARE” possui a interface de
93
única função deste bloco é enviar os dados para o RRRT através da porta de comunicação
(dados de saída do modelo). Estes dados são então processados pelo simulador no bloco “No
são vetores cujos elementos têm valor zero (0), o que indica que o modelo atmosférico
considerados são ideais, não foram considerados ruídos de nenhuma natureza para a
simulação.
em tempo real (‘pseudo real time’), onde cada segundo de execução corresponde a um
Figura 5.7 Bloco responsável pela comunicação serial com o modelo no RRRT.
Este bloco coloca os dados a serem enviados no formato correto, descartando os dados
não utilizados. O envio dos dados ao RRRT é realizado por uma ‘s-function’ do MatLab®,
chamada através do bloco “Comunicação Serial”. Após o envio, o simulador aguarda os dados
respectivamente. Estes dados não são necessários para o controle do profundor e são,
portanto, descartados. O segundo vetor apresenta os ângulos de Euler (φ, θ e ψ). Destes,
velocidade de arfagem (q), que está contida dentro do quarto vetor de entrada. Este vetor é
Além de θ e q, este bloco envia para o modelo pela porta de comunicação serial a
valor varia entre -0,5 e 0,5 e é diretamente proporcional ao ângulo que o profundor deve
assumir, onde -0,5 é o menor ângulo possível (que resulta num movimento de subida da
aeronave) e 0,5 é o maior ângulo possível (que resulta num movimento de descida da
aeronave).
5.4 Simulação
de vôo, uma vez que o software embarcado aguarda o recebimento de dados do simulador.
modelagem, conforme descrito no Capítulo 3. Desta forma, pode-se verificar em que estado
impressos em uma janela DOS os dados recebidos pelo software e o dado de comando do
transição, que está em destaque na figura, é executada seguidamente pelo modelo durante toda
sua simulação num intervalo de aproximadamente 20ms, pois a freqüência de envio dos dados
“mode_received”.
cápsula recebe o vetor com os dados provindos da cápsula “DataReceiver”, onde também é
feito o cálculo do comando de atuação na superfície de controle em questão, que neste caso é
o profundor. Ainda nesta mesma transição, a cápsula envia este comando calculado para a
positivo, passa-se para o estado Idle e imediatamente para o estado correspondente ao novo
modo de operação. Em caso negativo, o modelo retorna ao estado do modo atual, recebe
novamente o vetor e realiza o cálculo. Este laço se mantém enquanto o modo de operação não
for alterado.
que é iniciada a execução do modelo, é executada a transição que recebe o ponteiro da cápsula
deve ser enviado para o simulador, o que ocorre na transição “send_command”. Durante o
monitoramento do valor das variáveis manipuladas pelo modelo. Além disso, o simulador
dispõe de um horizonte artificial, ilustrado na Figura 5.11, que responde aos comandos
sistema para os diferentes modos de operação, uma vez que o modo 0 passa o comando do
manche direto para o atuador, enquanto que no modo 1 existe realimentação e um controlador
PID para a variável controlada (θ). De uma forma geral, foi possível observar que a resposta
assim como a sua resposta a esta dinâmica (VANT → software). Também é possível observar
como o conjunto VANT+software reage aos comandos do piloto. Neste sentido, foram
software a ser embarcado ainda na forma de modelos (diagramas de estado), mas de forma
vôo fecha a malha de controle com dados “reais” provenientes do simulador. O comando de
atuação calculado pelo modelo do software embarcado enviado para o simulador de vôo
tipos de erros. Além da abordagem apresentada neste capítulo, foram utilizadas também as
seguintes abordagens:
ambiente (ex.: Simulink®) a lei de controle e a dinâmica da planta. Neste caso o software
embarcado com demais dispositivos, interação com o usuário, recursos para detecção de
• Modelagem e simulação do tipo hardware in the loop. Neste caso, o software de controle
neste capítulo apresenta um maior grau de abstração do software de controle, ela permite
além de representar, num mesmo diagrama, a dinâmica dos diversos componentes e suas
interfaces.
101
Rede de Petri é um formalismo matemático proposto por Carl Adam Petri para
eventos discretos, as variáveis que descrevem o estado do sistema são modificadas de forma
dinâmica do sistema é dirigida pela ocorrência de eventos. De acordo com esta definição, o
software embarcado do VANT pode ser claramente classificado como um sistema dirigido a
eventos discretos, onde os estados e eventos que caracterizam o sistema podem ser
tipos de propriedades analisadas neste tipo de modelo. Em seguida a Seção 6.2 traz uma breve
revisão bibliográfica das propostas de utilização em conjunto dos diagramas da UML e redes
de Petri, de forma a melhor caracterizar a contribuição deste capítulo. Finalmente, a Seção 6.3
define as regras para conversão do modelo construído no RRRT para um modelo em redes de
Petri. Estas regras são aplicadas ao modelo do software embarcado do VANT gerando uma
com a modelagem em redes de Petri, esta última apresenta como principal vantagem a
De acordo com Gomes (1999), uma rede de Petri é um grafo bipartido com dois tipos
eventos. Uma possível interpretação é que os lugares de entrada de uma transição (conectados
à transição por um arco que sai do lugar e chega à transição) e os lugares de saída (conectados
à transição por um arco que sai da transição e chega ao lugar) representam as pré-condições e
Os lugares de uma rede de Petri podem conter um número inteiro e não negativo de
Do ponto de vista matemático, uma rede de Petri marcada (Cardoso; Valette, 1997) é
• R é uma rede de Petri definida pela 4-tupla <P, T, Pre, Pos>, onde:
− P={p1, p2, p3, …, pm} é um conjunto finito de lugares.
− T={t1, t2, t3, …, tn} é um conjunto finito de transições.
− P ∩ T = Ø, P ∪ T ≠ Ø.
Pre e Pos podem ser representados na forma de matrizes, onde as linhas representam
lugares e as colunas transições. O valor de um elemento da matriz indica o peso do arco ligando
o correspondente lugar à correspondente transição. Um elemento igual a zero indica que não
existe arco entre os correspondentes lugar e transição. Um exemplo é apresentado na Figura
6.1.
T1 T3
t1 3 t3
t1 t2 t3 t4
3 ⎡0 1 0 0⎤ p1 ⎡ 1 0 0 0⎤ ⎡0⎤
P1 p1 P3
p3 Pre = ⎢ 1 0 3 0⎥ p2 Pos = ⎢0 1 0 3⎥ M0 = ⎢3⎥
⎢ ⎥ ⎢ ⎥ ⎢ ⎥
p ⎢⎣0 0 0 1⎥⎦ p3 ⎢⎣0 0 1 0⎥⎦ ⎢⎣0⎥⎦
P2 2
T2 t2 3 3 Tt44
Figura 6.1 Exemplo de rede de Petri e sua representação matricial (Cardoso, Valette, 1997).
ocorre através do disparo de transições. Uma transição ti está habilitada para disparo quando
todos os lugares à sua entrada (lugares pj, onde Pre (pj, ti)>0) possuem um número de marcas
M(pj) ≥ Pre (pj, ti). Quando uma transição ti dispara, de cada lugar pj de entrada da transição,
removem-se Pre (pj, ti) marcas, e para cada lugar pj de saída da transição adicionam-se Pos (pj, ti)
104
marcas. A matriz de incidência (W) de uma rede de Petri representa o balanço das alterações
W = Post – Pre
M = M0 + W*s
ordinária (Cardoso, Valette, 1997). Este é o tipo de rede utilizado nesta tese. São também
utilizados arcos habilitadores e inibidores, que não fazem parte das redes de Petri ordinárias,
lugares a transições, e tem como finalidade habilitar o disparo da transição quando o lugar de
origem possui um número de marcas igual ou superior ao peso do arco. À diferença dos arcos
orientados, no entanto, eles não alteram a marcação do lugar de origem quando do disparo da
impedem o disparo da transição quando o lugar de origem possui marcas em número igual ou
Uma vez construída a rede de Petri que modela o comportamento de um sistema, esta
pode ser analisada através de simulação ou através da verificação formal. No primeiro caso,
mais transições estão em conflito, o simulador dispara uma delas e escolhendo assim o
cenário a ser executado (de forma aleatória). A simulação permite, portanto, observar uma das
possíveis evoluções para o sistema, não garantindo a ausência de erros para os cenários que
qualquer cenário possível de ser executado na rede de Petri, ou seja, considera-se todo o
propriedade depende da marcação inicial definida para a rede de Petri. A Tabela 6.2 apresenta
rede de Petri em análise. Este grafo contém todas as marcações alcançáveis pela rede de Petri
marcação inicial, sendo definida pela estrutura da rede (lugares, transições e arcos). As
isto é, uma transição pode disparar antes ou depois ou em paralelo com a outra. Duas
transições ti e tj são paralelas estruturalmente se Pre (p, ti) ∩ Pré (p, tj) = Ø, ou seja, se as
• Conflito estrutural: indica uma situação que pode levar a uma disputa não determinística
que Pre(pi, tj).Pre(pi, tk) ≠ 0, isto é, se as duas transições têm pelo menos um lugar de
entrada em comum.
• Invariante de lugar: indica um determinado conjunto de lugares cuja soma ponderada das
marcas contidas nestes lugares é constante para qualquer seqüência possível de disparos
um vetor f, tal que, f(1).M(p1) + f(2).M(p2) + ... + f(n).M(pn) = cte, onde p1, p2, ..., pn
inicial. Um invariante de transição pode ser representado por um vetor s, tal que, cada
UML com a modelagem baseada em redes de Petri. Vários autores argumentam a falta de
a maioria dos trabalhos consiste em, de alguma forma, apresentar procedimentos para migrar
modelos de sistemas baseados em UML para algum tipo de formalismo, como por exemplo, a
107
rede de Petri. A seguir apresentam-se alguns dos diversos trabalhos disponíveis na literatura
que abordam este tema, e a relação entre estes e a abordagem proposta neste capítulo.
especificações. Assim, as ferramentas CASE, que dão suporte a este tipo de metodologia,
apesar de disporem de uma grande capacidade de análise para propriedades sintáticas e para
semânticas estáticas, não são efetivas para a análise semântica da dinâmica, como por
largamente conhecidos. A UML, apesar da riqueza sintática, de ser amigável para usuário,
simples e flexível, carece da formalidade requerida para suportar simulação e análise. Visando
preencher esta lacuna, o trabalho de Baresi busca complementar a UML com redes de Petri
temporizadas de alto nível (high-level timed Petri nets – HLTPN) de forma a permitir a
Petri Nets – GSPNs). Este trabalho também é motivado pela falta de semântica formal nos
diagramas da UML. No entanto, neste caso, utiliza-se apenas um subconjunto dos diagramas,
uma vez que, de acordo com o autor, podem existir ambigüidades entre os diversos diagramas
da UML.
Hee et. al. (2006) discursa sobre a importância de manter a consistência entre os
diversos diagramas fornecidos pela UML. Como solução é proposto o uso de modelos
integrados que são derivados dos demais modelos nos estágios iniciais do processo de
ciclos de vida de objetos como simples redes de Petri. A integração das redes em uma rede
única é realizada através da fusão de lugares. Desta forma, o modelo integrado pode ser
2.0 para rede de Petri orientada a objeto (Object Petri Nets - OPNs). O propósito deste
que são definidos como um conjunto de atividades de negócio e ordenadas de acordo com um
(2007), a abordagem proposta neste capítulo limita-se às redes de Petri ordinárias, uma vez
que se considera o poder de modelagem desta rede suficiente para representar, de forma
conversão.
Comparando com o trabalho de Hee et. al. (2006), a proposta aqui apresentada não usa
as redes de Petri nas atividades iniciais do ciclo de desenvolvimento do software (como por
exemplo para a modelagem da relação entre casos de uso). Esta tese limita a utilização das
redes de Petri para modelagem do sistema após a elaboração dos diagramas de estado,
seqüência, casos de uso e classes, isto é, quando o modelo em UML é passível de simulação
oferecidos pela ferramenta CASE, para então executar a conversão para redes de Petri e a
detecção de grande parte dos erros na ferramenta CASE, uma vez que a verificação formal de
projetista.
109
trabalhos apresentados na literatura, neste caso a modelagem em redes de Petri não se limita
comunicação entre eles é realizada através de troca de mensagens e/ou dados. Esta
comunicação, porém, não está explícita no diagrama de estados, assim como também não está
sentido, a conversão dos diagramas de estado para um único modelo em redes de Petri
Como para o caso do modelo no RRRT, o modelo em redes de Petri pode ser
trabalho, optou-se por incluir apenas um modelo simplificado da dinâmica da planta, onde são
comportamento do piloto.
Para cada estado no diagrama de estados da UML, deve ser definido um lugar
correspondente na rede de Petri. Uma transição entre dois estados do diagrama de estados é
escolha do diagrama de estados representa uma situação de conflito, desta forma, ele é
modelado na rede de Petri por um lugar com duas transições de saída em conflito. Caso haja
Petri. O estado inicial na UML é o primeiro estado que o diagrama alcança, representado na
rede de Petri por uma marca inicial dentro do lugar correspondente a este estado. Por fim, a
troca de mensagens entre duas cápsulas é modelada na rede de Petri por um lugar de interface
que é simultaneamente um lugar de saída de uma transição do modelo da cápsula que envia
mensagem e lugar de entrada de uma transição do modelo da cápsula que recebe a mensagem.
Uma forma alternativa de modelagem da troca de mensagens é por uma transição em comum
estado, é possível que sejam executados trechos de código diferentes em cada disparo de uma
determinada transição. Se for desejável distinguir na rede de Petri entre a execução de cada
um dos possíveis trechos de código, cada trecho deve ser associado a uma transição distinta,
Outro caso particular que não se inclui no conjunto de regras definido é a existência de
dois eventos distintos que disparam a mesma transição no diagrama de estados da UML.
Neste caso, pode-se também inserir duas transições em conflito na saída do mesmo estado,
estudo de caso neste trabalho foi convertido para redes de Petri usando as regras definidas na
seção anterior. Foram convertidos para redes de Petri o modelo do software embarcado, um
comportamento do piloto.
estados e 3 transições, sendo uma delas uma transition to self. O componente correspondente
a este diagrama em redes de Petri é apresentado na Figura 6.3, que também possui 3 lugares
Initial open_serial_port
port_opened
Idle
send_mode
rec eiv e_and_send_v ec tor
Ac tiv e
O lugar correspondente ao estado inicial da UML (Idle) é o que possui uma marca
inicial (P2). Os arcos de entrada e saída das transições que aparecem cortados na rede de Petri
da Figura 6.3 correspondem às trocas de mensagens entre esta cápsula e as demais cápsulas
comunicação serial do computador, há um arco de saída que envia uma variável que é um
arco de chegada por onde são recebidos os valores dos sensores provenientes do simulador de
vôo e dois de saída, por onde são fornecidos o modo de operação e os demais valores das
quatro estados, seis pontos de escolha e várias transições. A Figura 6.5 apresenta o modelo
False Mode 2?
Mode 1?
Initial Mode 0? False
False Mode2
mode_rec eiv ed Mode1
Mode0
Idle True
True
True
Mode0_2
Mode1_2
Mode2_2
c alc ulating
c alc ulating c alc ulating
False False
False
transição “calculating” e o lugar identificado como “Verifica modo”, com duas transições de
rede (P1). Existem seis transições agrupadas duas a duas (T4 e T8, T9 e T13, T14 e T18)
devido ao fato de que existem duas situações descritas nas regras que ocorrem
código para mesma transição, bastariam três transições (uma para o modo 0, outra para o
modo 1 e outra para o modo 2, que seriam T4, T9 e T14, respectivamente). Porém, devido aos
trechos de código fonte diferentes, é necessária mais uma transição em conflito para cada
modo (T8, T13 e T18). Observa-se que as transições de saída dos modos de operação são
habilitadas apenas se o modo de operação for alterado, caso contrário, o sistema se mantém no
mesmo modo.
Os arcos que entram ou saem da rede são relativos às trocas de dados entre o
habilitadores e inibidores são utilizados apenas para comunicações entre o modelo e o usuário
Initial
W aiting_for_pointer
Ac tiv e
send_c ommand
Conforme definido nas regras propostas na seção anterior, este componente possui
dois lugares (P4 e “Aguarda atuação”) conectados por um arco-transição-arco (T19) e outro
(T20) retornando para o segundo lugar. O arco que chega à transição T19 representa o
As redes correspondentes a cada uma das cápsulas compõem uma única rede de Petri
4 3
interfaces entre os componentes. Existem tantos lugares de interface quantas são as trocas de
novos dados de sensores do segundo para o primeiro (circunferência número 2) e envio dos
de número 5.
Simulink®. Para tornar possível esta escolha na rede de Petri, foi introduzido um componente
chamado “User”, como pode ser observado na Figura 6.8. A comunicação entre este
pelo usuário, pois o mesmo habilita as transições de entrada do modo atual e inibe as
simulador de vôo (bloco chamado “Flight Simulator (MatLab – Simulink). Observa-se que
estes eventos não incluem o equacionamento da dinâmica da aeronave, uma vez que esta não
pode ser modelada como um sistema a eventos discretos. O objetivo é apenas representar a
troca de dados entre o software embarcado e o simulador de vôo. Desta forma, este modelo
outro correspondente ao envio dos novos dados de sensores para o software embarcado.
alterada para incluir a simulação da ocorrência de falhas. O objetivo neste caso é verificar
como o software embarcado responde a estas falhas. Como resultado desta simulação, são
118
das falhas. Dois tipos de falhas foram considerados nesta análise. O novo modelo, com a
3
1 2
valores dos sensores não são enviados para o sistema. A modificação proposta neste caso
por estes valores. Caso o software não receba os dados dos sensores dentro do tempo
estipulado, ele executa uma rotina de tratamento de falha (representada por um lugar), onde
119
permanece até que os dados sejam recebidos. Estas transições e lugares estão destacados pelas
elipses 1, 2 e 3 (transições T29, T31 e T33). Caso os dados sejam recebidos enquanto está
ocorrendo o tratamento de falha, então a transição T30 ou T32 ou T34 (depende do modo de
usuário. Neste caso, o sistema passa a operar no modo de operação 0 como padrão. Foi
necessária a inserção do lugar e das transições destacadas pela elipse de número 4 (lugar
“Modo Inválido” e transições T25 e T26) e das transições destacadas pelas circunferências
isto é, partes do modelo que não podem ser executadas. As propriedades de segurança e
limitação garantem que nenhum lugar da rede terá mais do que uma marca em qualquer
rede, a presença de duas ou mais marcas não tem significado no modelo proposto. Por fim os
invariantes de lugar garantem que as redes correspondentes a cada uma das cápsulas possuem
sempre e exatamente uma marca em seus lugares. Isto equivale a garantir que cada cápsula
possui apenas um estado ativo em cada instante, o que reforça a consistência entre o modelo
grafo de alcançabilidade da rede, que apresenta todos os seus possíveis estados alcançáveis
pelo sistema de um ponto de vista global, com todas as possíveis seqüências de disparo de
transições. Este grafo é obtido a partir da rede da Figura 6.10 e é apresentado na Figura 6.11.
120
As siglas dentro dos balões representam os lugares da rede, cujos significados estão
listados na Tabela 6.4, que possui ainda na última linha o significado da transição “CNS”.
P1,P2,P4,DI
T1
T2 T19
P1,P3,P4,DI,EP
P1,AR,P4,EP,EMO,RV P1,P3,AA,DI
T19 T2
T4 T14
P1,AR,AA,EMO,RV
T9
T13
P1,AR,
AA,P5
T8 T18
Figura 6.11 Grafo de alcançabilidade da rede de Petri do modelo.
122
rede, pois o mesmo possui a única função de possibilitar ao usuário a escolha do modo de
operação durante a simulação do modelo. Sem ele, o modo escolhido pelo HPSim é aleatório.
Neste grafo de alcançabilidade, a presença de uma sigla dentro do balão indica que há
uma, e apenas uma, marca dentro do lugar com o referente nome no estado corrente. Desta
forma, percebe-se que o número máximo de marcas em qualquer lugar, para qualquer estado
alcançável, é um. Assim, como cada lugar é binário, a rede também o é, o que caracteriza a
propriedade de segurança.
uma dada marcação. Assim, pelo grafo de alcançabilidade, percebe-se que as transições T1,
T2, T19, T4, T9 e T14 podem disparar apenas uma vez, o que as torna quase vivas. Esta
característica corresponde ao comportamento desejável para o sistema uma vez que estas
alcançabilidade também é possível afirmar que não existem situações de deadlock no modelo.
Após o disparo de T4, T9 ou T14 o modelo entra numa seqüência de disparos onde todas as
invariante de lugar corresponde a uma expressão no formato da Eq. 6.1 que permanece válida
Nesta equação f é um vetor em que f(n) indica a quantidade de marcas no lugar M(pn).
Aplicando esta expressão a cada componente separadamente, obtêm-se as Equações 6.2, 6.3 e
respectivamente.
M (P 4) + M (AA) = 1 (6.4)
uma marca. Para o “DataReceiver” pode-se concluir, por exemplo, que o sistema nunca estará
vôo ao mesmo tempo. Para o “ElevatorController”, pode-se concluir que o sistema nunca
funcionará em dois modos de operação ao mesmo tempo, o que não é possível. E para o
último componente, o sistema não ficará aguardando o ponteiro da porta serial e o comando
discretos e contínuos.
7 Conclusões
RRRT. Além da simulação do software modelado no ambiente RRRT, neste trabalho são
forma geral, os valores obtidos na aplicação das métricas satisfazem os limites encontrados na
do software de controle. Esta abordagem é uma etapa intermediária entre o uso de uma única
controle e planta controlada, e uma abordagem do tipo “hardware in the loop”, onde o sistema
de controle é substituído pelo sistema embarcado real que se comunica com o simulador de
vôo. Na abordagem que utiliza uma única plataforma, apenas a lei de controle é modelada, as
considerados. Assim, o tipo de erro que pode ser detectado é limitado. Por outro lado, quando
podendo assim acompanhar o estado atual do software em execução através dos monitores
dos diagramas de estado, e verificar os valores das variáveis do sistema através de uma janela
de prompt de comando.
livre de bloqueios (deadlocks) e não apresenta inconsistências, como, por exemplo, operar em
mais de um modo de operação ao mesmo tempo. Além disto, foram introduzidos dois tipos de
Fazendo-se uma comparação entre estas abordagens, pode-se perceber que elas, de
certa forma, se complementam, uma vez que a primeira é útil para avaliar a qualidade do
verificação formal do sistema, o que não é possível com as duas primeiras. Ou seja, elas
Este trabalho apresenta uma importante ‘lacuna’ que abre espaço para futuras
contribuições no que se refere à definição dos requisitos que servem de base para validação e
verificação do sistema. Neste trabalho, os requisitos foram definidos de modo informal pelo
modo informal, isto é, verificou-se que o sistema funciona de acordo com o ‘esperado’, mas
127
requisitos do sistema e relacionar esta especificação com as abordagens propostas para análise
do modelo em UML. Em outras palavras, devem ser propostos procedimentos para, a partir
dos requisitos, especificar seqüências de testes no RRRT, definir valores desejados para as
Outro ponto a ser explorado é o detalhamento das abordagens propostas nos Capítulos
5 e 6 para o desenvolvimento de sistemas tolerantes a falhas. Uma vez que estas abordagens
sistema a estas falhas. A partir desta resposta, devem ser especificados procedimentos para
Referências
AMIR, Arnon et. al. An embedded system for an eye-detection sensor. Computer Vision and
Image Understand, v. 98, n. 1, p. 104-123, Apr. 2005.
BARESI, Luciano; PEZZÈ, Mauro. Improving UML with Petri nets. Electronic Notes in
Theoretical Computer Science, v. 44, n. 4, p. 107-119, July 2001.
BAUDRY, Benoit; TRAON, Yves Le. Measuring design testability of a UML class diagram.
Information and Software Technology, v. 47, n. 13, p. 859-879, Oct. 2005.
BELL, Donald. UML Basics: An introduction to the Unified Modeling Language. 2003a.
Disponível em: <http://www-128.ibm.com/developerworks/rational/library/769.html> Acesso
em 16 mai. 2006.
BELL, Donald. UML Basics: Part II: The activity diagram. 2003b. Disponível em:
<http://www.therationaledge.com/content/sep_03/f_umlbasics_db.jsp> Acesso em 29 mai.
2006.
BELL, Donald. UML Basics: Part III: The class diagram. 2003c. Disponível em:
<http://www.therationaledge.com/content/nov_03/t_modelinguml_db.jsp> Acesso em 29 mai.
2006.
BIHARI, Thomas E.; GOPINATH, Prabha. Object-oriented real-time systems: concepts and
examples. Computer, v. 25, n. 12, p. 25-35, Dec. 1992.
BLYENBURGH, Peter van. UAVs: an Overview. Air & Space Europe, v. 1, n. 5-6, p. 43-
47, Sept.-Dec. 1999.
BYTE CRAFT LIMITED. First Steps with Embedded Systems. Waterloo, Ontario. 2002.
202 p.
CESTINO, Enrico. Design of solar high altitude long endurance aircraft for multi payload &
operations. Aerospace Science and Technology, v. 10, n. 6, p. 541-550, Sept. 2006.
COX, Timothy H. et al. Civil UAV Capability Assessment: Draft Version. Dec. 2004.
Disponível em: <http://www.nasa.gov/centers/dryden/research/civuav/civ_uav_doc-n-
ref.html>. Acesso em 15 set. 2006.
DIPIPPO, Lisa Cingiser; MA, Lynn. A UML package for specifying real-time objects.
Computer Standards & Interfaces, v. 22, n. 5, p. 307-321, Dec. 2000.
DOUGLASS, Bruce Powel. Real-Time Design Patterns: Robust Scalable Architecture for
Real-Time Systems. Boston, MA: Addison-Wesley, 2003. 500 p. (The Addison-Wesley
Object Technology Series).
DOUGLASS, Bruce Powel. Real-Time UML: Developing Efficient Objects for Embedded
Systems. 2. ed. New York, NY: Addison-Wesley, 2002. 328 p. (The Addison-Wesley Object
Technology Series).
FABIANI, P. et. al. Autonomous flight and navigation of VTOL UAVs: from autonomy
demonstrations to out-of-sight flights. Aerospace Science and Technology, v. 11, n. 2-3, p.
183-193, Mar-Apr. 2007.
FRANCE, R. et. al. The UML as a formal modeling notation. Computer Standards &
Interfaces, v. 19, n. 7, p. 325-334, Nov. 1998.
GILMORE, Stephen; KLOUL, Leïla. A unified tool for performance modelling and
prediction. Reliability Engineering & System Safety, v. 89, n. 1, p. 17-32, July 2005.
GOMES, Luís. Redes de Petri e Sistemas Digitais: uma introdução. Revisão 1.2.
Universidade Nova de Lisboa, 1999.
GUERROUAT, Abdelaziz; RICHTER, Harald. A Formal Approach for Analysis and Testing
of Reliable Embedded System. Electronic Notes in Theoretical Computer Science, v. 141,
n. 3, p. 91-106, Dec. 2005.
HALSTEAD, Maurice, H. Elements of Software Science. New York, New York: Elsevier,
1977. 127 p.
131
HATTON, Les. Embedded System Paranoia: a tool for testing embedded system arithmetic.
Information and Software Technology, v. 47, n. 8, p. 555-563, June 2005.
HEE, Kess von et. al. Consistency in model integration. Data & Knowledge Engineering, v.
56, n. 1, p. 4-22, Jan. 2006.
HOLDER, Bill. Unmanned Air Vehicles: an illustrated study of UAVs. Atglen, PA: Schiffer
Publishing, 2001. 72 p.
IWU, Frantz et. al. Integrating safety and formal analyses using UML and PFS. Reliability
Engineering & System Safety, v. 92, n. 2, p. 156-170, Feb. 2007.
JORGENSEN, Paul C. Software Testing: A Craftsman’s Approach. 2 ed. Boca Raton, FL:
CRC, 2002. 359 p.
KIMOUR, Mohamed T.; MESLATI, Djamel. Deriving objects from use cases in real-time
embedded systems. Information and Software Technology, v. 47, n. 8, p. 533-541, June
2005.
KROLL, M. et. al. Embedded systems for signing medical images using the DICOM
standard. International Congress Series, v. 1256, p. 849-854, June 2003.
MACIEL, Paulo Romero Martins; LINS, Rafael Dueire; CUNHA, Paulo Roberto Freire.
Introdução às Redes de Petri e Aplicações. Campinas, SP: Universidade Estadual, 1996,
187 p.
MURATA, Fellow Tadao. Petri Nets: Properties, Analysis and Applications. Proceedings of
the IEEE, v. 77, n. 4, p. 541-580, Apr. 1989.
NEEMA, Sandeep et. al. Autonomic fault mitigation in embedded systems. Engineering
Applications of Artificial Intelligence, v. 17, n. 7, p. 711-725, Oct. 2004.
PAIGE, R. F.; OSTROFF, J. S.; BROOKE, P. J. Principles for modeling language design.
Information and Software Technology, v. 42, n. 10, p. 665-675, July 2000.
PHILIPPI, Stephan. Automatic code generation from high-level Petri-Nets for model driven
systems engineering. Journal of Systems and Software, v. 79, n. 10, p. 1444-1455, Oct.
2006.
RTCA Inc. and EUROCAE. DO-178B: Software considerations in airborne systems and
equipment certification, Dec. 1992.
SPIVEY, J. M. The Z notation: a reference manual. Upper Saddle River, NJ: Prentice-Hall,
1989. 155 p.
The UAV industry. Air & Space Europe, v. 1, n. 5-6, p. 48-50, Sept.-Dec. 1999.
UAVs: Launch and Recovery. Air & Space Europe, v. 1, n. 5-6, p. 59-62, Sept.-Dec. 1999.
YANG, Hong Iris; ZHAO, Yiyuan J. Trajectory Planning for Autonomous Aerospace
Vehicles amid Known Obstacles and Conflicts. Journal of Guidance, Control and
Dynamics, v. 27, n. 6, p. 997-1008, Nov.-Dec. 2004.
FOLHA DE REGISTRO DO DOCUMENTO
1. 2. 3. 4.
CLASSIFICAÇÃO/TIPO DATA DOCUMENTO N° N° DE PÁGINAS
6.
AUTOR(ES):
8.
PALAVRAS-CHAVE SUGERIDAS PELO AUTOR:
11.
RESUMO:
12.
GRAU DE SIGILO: