Este documento descreve o desenvolvimento de um sistema embarcado para controlar um veículo aéreo não tripulado (VANT) bi-rotor utilizando técnicas de modelagem. A metodologia proposta utiliza o MATLAB/Simulink para simular e validar algoritmos de controle, SysML para modelar a arquitetura de software e hardware, e mapeamento do modelo SysML para código de implementação na plataforma embarcada. O trabalho ainda está em desenvolvimento, faltando detalhar mais a metodologia e apresentar resultados.

1. Sistema embarcado para o controle de um Bi-rotor de
¸˜
configuracao Tiltrotor
Fernando Silvano Goncalves, Wiliam Andrey Faustino Scotti, Rodrigo Donadel
¸
1
¸˜ ¸˜
Programa de P´ s-Graduacao em Engenharia de Automacao e Sistemas
o
Universidade Federal de Santa Catarina - UFSC
{goncalves, wiliam faustino, rodrigoVERVER}@das.ufsc.br
Resumo. AINDA TEMOS QUE ESCREVER O RESUMO DESTE TRABAIO
Palavras-chave: Tempo Real, Preempt-RT, Linux.
Abstract. WE NEED TO WRITE THIS ABSTRACT TO
Keywords: Real-Time, Preempt-RT, Linux.
¸˜
1. Introducao
¸˜
Introducao geral
Paragrafo sobre sistemas embarcados
Paragrafo sobre MDD
Paragrafo sobre sistemas aviˆ nicos
o
¸˜
Este projeto tem como objetivo a implementacao de algoritmos de controle
cont´nuo em uma plataforma embarcada para realizar o controle de um ve´culo a´ reo
ı ı e
¸˜
n˜ o tripulado (VANT) bi-rotor de configuracao tiltrotor. Em conformidade com o VANT
a
¸˜ ¸˜
tamb´ m ser´ modelado um sistema estacao base, buscando a comunicacao entre estes, a
e a
¸˜
definicao de miss˜ es e monitoramento de dados.
o
¸˜
Este trabalho est´ organizado da seguinte forma: a secao 2 apresenta uma
a
¸˜
descricao da liguagem sysml, alguns de seus diagramas e a ferramenta Artisan Studio
¸˜
utilizada para o desenvolvimento, a secao 3 descreve o matlab, bem como a ferramenta
¸˜ ¸˜
de modelagem simulink, a secao 4 apresenta a metodologia proposta, a secao 5 descreve
¸˜
os artefatos produzidos bem como os resutados, e a secao 6 apresenta as conclus˜ es.
o
2. SysML
´
Segundo a OMG, o SysML e uma linguagem de modelagem gr´ fica de prop´ sito geral
a o
¸˜ ¸˜ ¸˜
que suporta especificacao, an´ lise, projeto, verificacao e validacao de sistemas complexos
a
¸˜
que podem incluir hardware, software, informacao, processos, pessoas e infraestrutura.
´
Na figura 1, e poss´vel ver que o SysML utiliza alguns diagramas da UML e
ı
adiciona outros para atender os requisitos da UML SERFP (System Engineering Request
for Proposal), sendo que alguns diagramas n˜ o tiveram mudancas e outros foram alterados
a ¸
para o SysML.
O SysML classifica os diagramas em comportamentais, estruturais e diagrama de
requisitos. A figura 2 mostra todos os diagramas do SysML, bem como aqueles que foram
adicionados, modificados ou mantidos do UML.

2. ¸˜
Figura 1. Relacao entre SysML e UML Fonte: Adaptado de OMG
2.1. Diagrama de requisitos
´
Em um projeto de Sistemas Embarcados, e necess´ rio definir os requisitos funcionais e
a
n˜ o funcionais.
a
• Requisitos funcionais: representam o que o sistema pode fazer;
• Requisitos n˜ o funcionais: s˜ o restricoes indicando como o sistema realizar´ os
a a ¸˜ a
requisitos funcionais.
´
SysML tem um diagrama de requisitos, onde e poss´vel representar os requisitos,
ı
normalmente em formato textual, permitindo associar um determinado requisito a outro
¸˜ ¸˜
modelo que est´ tratando a sua satisfacao e verificacao (Oliveira, 2008).
a
Para Marques (2011), o diagrama de requisitos representa as hierarquias e
¸˜
derivacoes existentes nos requisitos, que possibilitam associar um determinado requisito
a outro modelo tornando vis´vel o rastreamento dos requisitos. Diagrama de requisitos
ı
¸˜
propicia a visualizacao gr´ fica dos requisitos ou em forma de tabela , tornando f´ cil o
a a
entendimento dos mesmos.
Segundo Friedenthal (2008), os requisitos podem conter propriedades adicio-
¸˜
nais como status da verificacao, criticidade, risco e categoria de um requisito. Para
¸˜
a verificacao, um requisito pode estar assinalado como n˜ o verificado, verificado pela
a
¸˜ ¸˜ ¸˜
inspecao, verificado pelo analista, verificado pela demonstracao ou verificacao pelo teste.
Quanto ao n´vel de criticidade ou risco, podem ser assinalados como alto, m´ dio ou baixo
ı e
`
risco. Quanto a categoria de um requisito, podem ser categorizados como funcionais, de
desempenho ou f´sicos.
ı
2.2. Diagrama de componentes
O diagrama de componentes demonstra o sistema de uma forma funcional, descrevendo
os componentes e suas dependˆ ncias que representam a estrutura do c´ digo gerado. Di-
e o
¸˜
agrama de componentes capturam a estrutura f´sica da implementacao e se divide em
ı
blocos, que combinados constroem o sistema pretendido (Campos).

3. Figura 2. Diagrama de linguagem SysML Fonte: Adaptado de OMG
´
Para Faria (2001), um componente e uma parte f´sica (feita de bits e bytes) e subs-
ı
¸˜
titu´vel de um sistema, que proporciona a realizacao de um conjunto de interfaces. Repre-
ı
sentam um empacotamento f´sico de elementos relacionados logicamente (normalmente
ı
classes).
¸˜
Podem ser implementados com base em linguagens de programacao, tabelas ou
equipamentos. Os pacotes de componentes podem ser utilizados para modelar a arquite-
´
tura f´sica. Uma das suas principais vantagens e a modularidade.
ı
2.3. Diagrama de blocos
Segundo Santos (2011), o diagrama de blocos tem a responsabilidade de mostrar as ca-
¸˜
racter´sticas estruturais e comportamentais, assim como as relacoes entre os blocos.
ı
Diagrama de blocos modela a arquitetura do sistema, representando os componen-
tes de hardware (CPU, sensores, atuadores, entre outros) e os componentes de software.
Os v´ rios compartimentos servem para descrever as caracter´sticas do bloco, como
a ı
¸˜ ¸˜ ¸˜
propriedades, operacoes, restricoes, alocacao ao bloco e requisitos que o bloco satisfaz
(OMG).
2.4. Diagrama de pacotes
2.5. M´ quina de estados
a
VER SE VAMOS COLOCAR
2.6. Diagrama de atividades
AINDA PRECISAMOS FAZER

4. 3. Matlab
3.1. Simulink
4. Sistema de controle do Bi-rotor
Conforme j´ destacado este projeto tem o objetivo de implementar de algoritmos de con-
a
¸˜
trole cont´nuo, aplicados a uma plataforma embarcada para realizacao do controle de um
ı
ı e a ¸˜
ve´culo a´ reo n˜ o tripulado (VANT) bi-rotor de configuracao tiltrotor.
´ ¸˜
A proposta principal da aeronave e a realizacao de voos em conformidade com
miss˜ es pr´ -estabelecidas, as quais estabelecem a trajet´ ria a ser seguida pela mesma.
o e o
¸˜ ¸˜
O VANT possui uma estacao base respons´ vel pela definicao das miss˜ es e
a o
¸˜ ´
integracao com o mesmo. Seu sistema e composto basicamente por trˆ s modos:
e
¸˜ ¸˜
inicializacao, operacao e seguranca.
¸
¸˜ ´
No modo de inicializacao a aeronave e ligada, onde s˜ o realizados uma rotina
a
de testes internos visando verificar a integridade do sistema, assim como o canal de
¸˜ ¸˜ ´ ´
comunicacao com a estacao base e testado. Ap´ s estes procedimentos e definido o forma
o
¸˜
de operacao da aeronave, se em modo de testes ou em modo autˆ nomo. No caso de
o
¸˜
operacao autˆ noma faz-se necess´ rio que seja carregado a miss˜ o para o VANT antes de
o a a
defini-lo como em modo de operacao.¸˜
¸˜ ´ ¸˜
Quando a forma de operacao de testes e selecionada, a estacao base pode atuar
diretamente sobre cada um dos sensores e atuadores, visando calibra-los, ou a realizar
testes nestes equipamentos, neste modo a aeronave n˜ o realiza voos.
a
a o ¸˜
J´ na forma autˆ noma de operacao, quando ativado a aeronave inicia automati-
¸˜ ¸˜
camente a execucao da miss˜ o. Visando a viabilidade da operacao de forma autˆ noma,
a o
faz-se necess´ rio que sejam desenvolvidos alguns sistemas tais como controle de estabi-
a
lidade, controle de trajet´ ria, monitoramento de bateria, controle de pouso e decolagem e
o
¸˜
identificacao de obst´ culos.
a
´
Para garantir a integridade da aeronave, esta possui um modo de seguranca, que e
¸
ativado automaticamente pela UAV quando esta identifica alguma falha nos componentes
a ´
do sistema, ent˜ o e efetuado um pouso de emergˆ ncia a fim de evitar acidentes.
e
4.1. Metodologia utilizada
A cadeia de desenvolvimento proposta est´ exposta na figura 3. A ferramenta MATLAB
a
SIMULINK R ser´ utilizada para simular e validar os algoritmos de controle cont´nuo.
a ı
Posteriormente, pretende-se realizar a convers˜ o desta para a linguagem SysML, com
a
o intuito de modelar uma arquitetura de software e hardware que ofereca suporte a
¸
¸˜
implementacao dos algoritmos de controle no sistema embarcado do VANT. Por fim,
objetiva-se realizar o mapeamento da convers˜ o do modelo SysML para c´ digo fonte
a o
capaz de ser utilizado na plataforma embarcada.
FALTA DETALHAR MAIS

5. Figura 3. Motodologia proposta
5. Resultados
6. Conclus˜ o
a
A. Digrama de requisitos
B. Digrama de blocos