Post on 09-Dec-2018
Uma infraestrutura de software para uso de veículos aéreos não tripulados
na agricultura de precisão
Malcon Miranda Mikami1, Alaine Margarete Guimarães2, Petraq Papajorgji3
1 PPG em Computação Aplicada, Universidade Estadual de Ponta Grossa, Ponta Grossa,
Paraná, Brasil, malconmikami@gmail.com
2 Departamento de Informática, Universidade Estadual de Ponta Grossa, Ponta Grossa,
Paraná, Brasil, alainemg@uepg.br
3 Canadian Institute of Technology, Tirana, Albania, petraq@gmail.com
RESUMO
Coletar, interpretar e entender, de maneira simples e eficaz, dados que apresentem as causas
da variabilidade no campo, são alguns dos principais problemas para o avanço da agricultura
de precisão (AP). O uso de veículos aéreos não tripulados (VANT) para realizar o
sensoriamento remoto na AP apresenta vantagens em relação aos métodos tradicionais. O uso
de sistemas de informação para a integração das etapas de coleta, processamento e análise das
informações se faz fundamental. Apesar de existirem muitos softwares disponíveis no
mercado, muitos são proprietários ou experimentais, impedindo o uso em larga escala. Assim,
a associação de VANTs e a AP envolve uma variedade de técnicas de análise, tratamento de
dados e perfis de usuário, o que torna uma ferramenta de software para esse domínio
complexa do ponto de vista da engenharia de software. Nesse trabalho foi desenvolvida uma
infraestrutura de software para integração e automação dos processos relacionados ao uso de
VANTs para coleta de dados em AP. A utilização dos padrões de desenvolvimento
demostrou-se adequada. A implementação de novos componentes permitiu a evolução da
solução sem grandes alterações arquiteturais.
PALAVRAS-CHAVE: VANT, Design Dirigido por Domínios, Segregação de
Responsabilidade de Comando, Padrões de desenvolvimento, Sensoriamento remoto.
ABSTRACT
Collecting, interpreting and understanding, in a simple and effective way, data that present the
causes of the field variability, are some of the key issues for the advancement of precision
agriculture (PA). The use of unmanned aerial vehicles (UAV) to perform remote sensing has
advantages to traditional methods. Using information systems to promote the integration of
the data collection, processing and analysis steps becomes fundamental. Although there are
many available software packages, most of them are proprietary or experimental, which
hinders their use in wide scale. Thus, the combination of UAV and PA involves a variety of
analytical techniques, data processing and user profiles, which makes a software tool for this
domain complex in the software engineering context. In this work a PA software
infrastructure was developed for identification, integration and automation of processes for
collecting data using UAVs. The use of development patterns demonstrated to be appropriate.
The implementation of new components allowed the evolution of the solution without major
architectural changes.
KEYWORDS: UAV, Domain Driven Desing, Command & Query Responsibility
Segregation, Desing Pattern, Remote sensing.
INTRODUÇÃO
O interesse em Veículos Aéreos Não Tripulados (VANT) ou Unmanned Aerial Vehicle
(UAV), ou ainda popularmente conhecidos como drones (zangão, em inglês), têm crescido no
mundo. Com o desenvolvimento de sensores robustos, autônomos, leves e baratos, os VANTs
se apresentam como uma alternativa para os sistemas de sensoriamento remoto, oferecendo
informações com elevada resolução espacial e temporal, de uma forma não invasiva. Segundo
(TORRES-SÁNCHEZ, 2014) seu uso na Agricultura de Precisão (AP) mostra vantagens em
relação à obtenção de imagens aéreas por meios tradicionais como aviões e satélites, visto que
os VANTs apresentam uma solução de baixo custo de aquisição, com obtenção de imagens de
alta resolução e alta frequência de revisita. (BOEING RESEARCH & TECHNOLOGY, 2013)
afirma que as imagens obtidas por meio do uso de VANT podem atingir resolução de 0.3 a
1.0 m por pixel, contra 5 a 10 metros dos meios aéreos tradicionais.
Pode-se considerar que o uso de VANTs na AP envolve uma série de etapas
estabelecidas em um plano de execução com objetivo de obter informações úteis para apoiar a
tomada de decisão agrícola. Essas etapas compreendem desde a determinação do objetivo até
a captura e processamento das imagens obtidas.
Percebe-se que em trabalhos relacionados ao uso de VANT na AP, as pesquisas utilizam
várias soluções para fazer parte das análises necessárias. Em Boeing et al. (2014), cujo
objetivo foi a aplicação de VANT para o mapeamento digital do terreno, foi necessário a
utilização de diversos softwares e integrações para geração do plano de voo, ortorretificação
das imagens e geração do modelo digital do terreno. Em (MASCARIN et al.,2006), foi
necessário a utilização de um software para realizar a análise geoestatística e outro para
obtenção dos mapas de produtividade. Em (TANAKA et al. ,2013) utilizou-se o software do
fabricante do VANT para geração do plano de voo, outro para geração do mosaico de
imagens obtidas dos voos e para fusão final dos dados obtidos pelo VANT e os dados dos
receptores GPS (Sistema de Posicionamento Global – do inglês Global Positioning System)
em solo. Os autores ainda citam que na etapa de fusão dos dados, foi necessário realizar a
conversão dos dados obtidos pelos equipamentos, para a correta utilização no software.
Os trabalhos relatados mostram dois importantes aspectos: os pesquisadores precisam
conviver com uma heterogeneidade de softwares para realizar seus experimentos, e a maioria
dos softwares se restringe a geração dos dados de imagens, deixando uma lacuna em relação à
análise dos mesmos.
A interoperabilidade entre sistemas através da padronização da comunicação e
processos envolvidos no uso de VANTs em AP é um desafio para os atores envolvidos no
processo como: pesquisadores, agrônomos, agricultores, fornecedores de equipamentos,
indústria, comunidade acadêmica, entre outros. As experiências têm mostrado que o uso da
AP exige a integração de diferentes sistemas de informação, o que obriga o usuário a aprender
a trabalhar com vários pacotes de software. Com objetivo de resolver este problema e atender
a necessidade do usuário a obter informações sobre sua propriedade e cultura através do uso
de VANTs, propõe-se o desenvolvimento de uma arquitetura voltada a AP e suas áreas
correlatas para identificação, integração e automação dos processos e posteriormente anáalise
de informações, utilizando-se de componentes “plugáveis” e de padrões abertos de
comunicação na distribuição de serviços.
MATERIAL E MÉTODOS
A arquitetura desenvolvida neste trabalho utiliza um padrão de desenvolvimento em várias
camadas (N-Layers) indiretamente conectadas através de inversão de controle (IoC –
Inversion of Control) e utiliza os padrões Segregação de Responsabilidade de Comando e
Consulta (CQRS - Command & Query Responsibility Segregation) (YOUNG, 2010) e Design
Dirigido por Domínios (DDD – Domain-Driven-Desing) (EVANS; FLOWER, 2013) em
camadas específicas.
A adoção do CQRS neste trabalho promove a utilização da arquitetura por múltiplos
agentes, possibilitando a construção de sistemas distribuídos e permitindo ainda construir
aplicações mais escaláveis em termos de arquitetura. Como não é possível escapar dessa
complexidade, deve-se restringir a própria complexidade do domínio sobre a qual a aplicação
está sendo desenvolvida. O uso do DDD auxilia no desenvolvimento, focado nos conceitos ou
nas regras do domínio independente da tecnologia (CALVARRO, 2010). A criação de
modelos de representação do conhecimento ajuda o projetista a visualizar melhor o sistema,
permitindo a especificação da estrutura ou do comportamento do mesmo, além de
proporcionar um guia para o seu desenvolvimento e documentar as decisões tomadas Booch
(2000 apud MIRALLES; LIBOUREL, 2009).
Segregação de responsabilidade de comando e consulta
O padrão CQRS é caracterizado por separar os papéis e responsabilidades no sistema, de
maneira que a arquitetura se torne mais eficiente, aplicando limites muito restritos na
aplicação, de modo a que se torne consistente no final. É direcionado para suportar um grande
número de agentes e saber lidar com o fato de que o sistema possa crescer cada vez mais sem
grandes complexidades e sem deterioração (KORKMAZ, NILSSON, 2014). A Figura 1 exibe
a implementação da responsabilidade de leitura (query) e de escrita (command).
Figura 1 – Padrão CQRS
Fonte: (Internet, 2015)
Essa implementação tem como objetivo e benefício, manter o foco no modelo original a
medida que novos objetos são adicionados ao domínio. Quando os diversos usuários
começam a interagir com o modelo, ocorre a multiplicação das informações. Essa estrutura
com múltiplas camadas de representação pode se tornar bastante complexa, mas quando os
modelos evoluem dessa maneira, o problema pode ser resolvido criando-se uma representação
conceitual única que funcione como um ponto de integração entre todas as apresentações
(FLOWER, 2003).
O outro principal benefício está em manipular aplicações de alta performance. CQRS
permite que seja separado o carregamento dos leitores e escritores, possibilitando escalar cada
um independentemente (GUELEN, 2015). Um exemplo é o uso de diferentes técnicas de
acesso a banco de dados para leitura e atualização.
Design dirigido por domínios
Nenhum software robusto e confiável pode ser desenvolvido com base em informações
ambíguas ou falhas. Como todo modelo, os domínios são representações incompletas da
realidade, com objetivo de resolver um problema em particular.
Contudo, não se pode construir um modelo qualquer. Linguagens orientadas a objeto
facilitam essa compreensão, já que permitem a construção de estruturas abstratas como
objetos e classes. Porém, a orientação a objetos pode ser mal-usada. Um dos sintomas é o uso
incorreto do paradigma de todo comportamento da aplicação em serviços, consequentemente,
há uma separação entre dados e comportamento, o que costuma levar a duplicação de código,
falta de coesão e alto acoplamento das classes (EVANS; FLOWER, 2013).
No DDD a modelagem do domínio e a implementação da aplicação não são vistas como
atividades distintas. Em modo geral, o DDD propõe que o modelo seja expresso em código, o
que implica que todos os demais artefatos são secundários. O código deve transmitir aos
desenvolvedores o conhecimento sobre o domínio e este deve refletir a linguagem dos
especialistas, as regras e a relação entre os conceitos.
A utilização do DDD contribui para criação de softwares independentes da plataforma,
com modelos ricos em conhecimento, feitos diretamente no código, com maior
interoperabilidade e de fácil manutenção, já que os modelos criados podem ser
constantemente alterados, terem novas funcionalidades adicionadas e serem recombinados
(MELLOR, 2000).
Padrões do desenvolvimento em DDD
Dentro do DDD, há um conjunto de padrões que ajudam a organizar o desenvolvimento com
foco no domínio. Esses padrões possuem um significado bem definido e enfatizam as boas
práticas em orientação a objetos, sendo eles (EVANS; FLOWER, 2013):
Entidades: Corresponde a uma característica de um objeto que possui uma identidade e
que pode ser rastreada por um período de tempo independente de seu estado ou seus
atributos.
Objetos de valor: ao contrário das entidades, não possuem uma identidade conceitual, eles
são caracterizados apenas pelos seus atributos. Do ponto de vista do domínio, dois objetos
de valor com os mesmos atributos são indistinguíveis e intercambiáveis.
A distinção entre objeto de valor e entidade depende do contexto. Na arquitetura proposta
neste trabalho, o objeto SoilType é um objeto de valor, pois apenas armazena o tipo
característico do solo independente do tempo-espaço. Por outro lado, em uma situação em que
se deseja analisar o solo em diferentes amostras e comparar sua composição química, o objeto
Soil passa a ser considerado uma entidade para esse domínio por se tratar de objetos com
identidades diferentes.
Serviços: devem representar as regras do negócio e coordenar as operações que envolvem
outros objetos do domínio. Tradicionalmente em orientação a objetos, as próprias classes
devem representar seus estados, porém o uso desorganizado da codificação dentro das
próprias classes pode torná-las incompreensíveis e inflexíveis.
Módulos: são particionamentos do domínio que facilitam a compreensão dos conceitos
pelos desenvolvedores.
Raiz de agregação: são entidades responsáveis por garantir e definir um limite para a
propagação de uma mudança. Ao ser definido um limite para essa propagação,
proporciona-se maior eficiência ao sistema, pois menos objetos precisam ser alterados.
Algumas regras devem ser obedecidas para que se tenha uma raiz de agregação. Como
exemplo, a exclusão da raiz deve remover todos os seus agregados afim de manter a
integridade de suas informações.
Fábricas: são metáforas relacionadas à construção de objetos complexos, afim de
assegurar suas associações internas. Elas não possuem nenhum significado para o modelo
em termos de regras de negócio, apenas uma necessidade de implementação.
Repositórios: estão diretamente relacionados com o armazenamento e recuperação de
informações com o objetivo de omitir os detalhes da implementação dos níveis mais
baixos da manipulação de dados.
RESULTADOS E DISCUSSÃO
A arquitetura construída nesse trabalho é dividida logicamente em dois fluxos distintos de
processamento, de acordo com o tipo de usuário que utilizará a ferramenta:
agricultor/agrônomo ou especialistas/pesquisador. (Figura 2). Dessa forma, ambos os tipos de
usuário podem compartilhar informações, técnicas, resultados e parâmetros para evolução dos
métodos de processamento.
Figura 2 - Fluxos e processos da arquitetura
Fonte: (Autor, 2015)
Uma das premissas é que o usuário final do sistema (agricultor ou técnico agrícola) não
precise conhecer os parâmetros de voo do VANT como altitude, velocidade, resolução
espacial de captura das imagens para atender a um determinado objetivo.
Especialistas e pesquisadores, por meio de ensaios de voo, irão alterar esses parâmetros bem
como métodos de processamento informações adquiridas para que um motor de inferência
determine os melhores parâmetros para resolução do objetivo. Assim, espera-se obter o
melhor rendimento operacional dos VANTs em tempo de voo, área de cobertura, entre outros.
A visão da arquitetura em camadas proposta pode ser visualizada na Figura 3.
Figura 3 - Objetos utilizados no MVC e suas interações
Fonte: (Autor, 2015)
A organização da arquitetura em camadas aumenta a reusabilidade e a modificabilidade
dos sistemas. Para tanto, há uma separação lógica entre as camadas adjacentes através de suas
interfaces. Há cinco camadas distintas, descritas a seguir:
Camada de apresentação: Nesta, estão as interfaces para os dispositivos de acesso às
aplicações como web browsers, tablets, celulares. Através desses dispositivos clientes, o
usuário fornece dados e recebe respostas. Na arquitetura proposta, há duas interfaces
distintas criadas: Uma aplicação estilo terminal denominada CONSOLE, usada para
validar a arquitetura suprimindo detalhes de padronização de telas, layout, estilos, etc. E
uma aplicação web browser, onde se usa o padrão arquitetural Model-View-Controller
(MVC). Esta é uma forma de quebrar uma aplicação, ou até mesmo um pedaço da
interface de uma aplicação, em três partes: A Figura 4 demonstra que a modelagem
(Model) e o feedback visual (View) para o usuário são separados e gerenciados pelos
objetos controladores (Controller).
Figura 4 - Objetos utilizados no MVC e suas interações
Fonte: (Autor, 2015)
Nesta arquitetura foram excluídos os objetos que representam os modelos, pois estes são
representados pela camada de domínio. Ao invés destes, há uma representação de um
conjunto de objetos, denominado View Models (VM) conforme Figura 5.
Figura 5 - Representação de um View Model
Fonte: (Autor, 2015)
A vantagem de uso de VM é não precisar alterar o modelo para atender as necessidades
de uma interface. Os conjuntos de objetos da camada de apresentação encontram-se na Figura
6.
Figura 6 - Componentes da camada de apresentação
Fonte: (Autor, 2015)
Camada de aplicação: Responsável pela integração das aplicações com serviços internos
ou externos, necessários para um processo de negócio completo. A camada consiste de
dois grupos de objetos distintos; Command Model e Query Model, onde o padrão CQRS é
implementado.
No Command Model se faz o uso do DDD, suas regras de negócio e validações e devem
ser aplicadas as regras para que toda alteração de estado sobre as entidades seja válida. Como
o processamento é assíncrono, para o usuário parecerá instantâneo. As exceções aqui são
tratadas por eventos, em um modelo publish/subcriber. Cada comando deve conter o mínimo
possível de informação para funcionar, não é necessário enviar entidades inteiras dentro de
um comando, pois isso geraria um consumo desnecessário de recursos e este não é o propósito
deste modelo. A Figura 7 ilustra os principais objetos da camada.
Figura 7 - Objetos utilizados no MVC e suas interações
Fonte: (Autor, 2015)
O Query Model, responsável pela consulta, assim como a base desnormalizada, não respeita
muito a programação orientada a objeto e é específico para a visualização que o utiliza,
geralmente são DTOs (Data Transfer Objects), não podem possuir regras, cálculos ou
validações. Seu processamento tem que ser o mínimo possível e sua resposta necessita ser
rápida, conforme Figura 8.
Figura 8 - Objetos utilizados no MVC e suas interações
Fonte: (Autor, 2015)
Camada de domínio: É o coração de todas as aplicações orientadas a domínio,
responsável por capturar os conceitos chaves e suas responsabilidades perante outras
classes. A medida que o modelo evolui, o número de classes e associações tende a
aumentar. Pensar em todos os conceitos simultaneamente é simplesmente proibitivo em
alguns sistemas. O critério de separação por contexto deve seguir o princípio de alta
coesão e baixo acoplamento. Para a arquitetura proposta, os contextos são: VANT,
Agricultura, Processamento de Imagem e Mineração de dados, ilustrados pela Figura 9.
Figura 9 - Contextos e suas entidades
Fonte: (Autor, 2015)
Uma mesma entidade pode ter significados diferentes para em determinado contexto.
No contexto de Agricultura, a entidade Farm é uma raiz de agregação para a entidade
ProductionArea, pois apenas pode-se incluir ProductionArea através de uma Farm, e se uma
Farm for excluída do sistema suas ProductionArea devem também ser removidas. Já no
contexto de VANT, Farm é apenas uma entidade que representa uma área, sendo Vehicle uma
raiz de agregação para os elementos Camera e Mission.
SoilType, CameraType e VehicleType são objetos de valor, pois estes não possuem uma
identidade conceitual.
Camada de persistência: Tem a responsabilidade de representar a camada de dados na
aplicação. Foi implementado o padrão Repositórios (Repository Pattern), sendo que
através dele é possível tirar a responsabilidade de persistência das entidades de negócio,
mantendo a lógica na camada de domínio. Para facilitar a criação dos repositórios da
aplicação, foi criado um repositório genérico BaseRepository. Este contém os métodos
comuns entre todos os repositórios da aplicação, os quais os demais repositórios herdam,
conforme Figura 10.
Figura 10 - Objetos utilizados no MVC e suas interações
Fonte: (Autor, 2015)
Os repositórios não conhecem detalhes de infra-estrutura, assim é necessário uma
abordagem para realizar a tradução objeto-relacional. O padrão DAO (Data-Acess-Object)
tem o trabalho de traduzir as chamadas à persistência em chamadas de infraestrutura, sejam
elas banco de dados, webservices, arquivos em disco ou outra abordagem qualquer. Para
garantir as alterações no contexto, é utilizado o padrão de Unidade de Trabalho (UoW - Unit
of Work) que tem por objetivo acompanhar as alterações das entidades de negócio durante
uma transação, sendo também responsável pelo gerenciamento dos problemas de concorrência
que podem ocorrer oriundos dessa transação.
Camada de infraestrutura: Esta camada normalmente suporta operações como
autenticação, autorização, armazenamento em cache, comunicação e gerenciamento de
exceções. Essa camada é geralmente descrita como CrossCutting ou camada de
infraestrutura vertical, pois afeta as demais camadas da aplicação, conforme Figura 11.
Figura 11 - Objetos utilizados no MVC e suas interações
Fonte: (Autor, 2015)
A camada de infraestrutura também provê acesso a serviços externos de terceiros. Na
aplicação desenvolvida há a integração dos serviços do software “R” (R DEVELOPMENT
CORE TEAM, 2008), o qual é um software livre para computação estatística e gráficos;
OpenCV (Open Source Computer Vision Library) (BRADSKI, 2000), o qual é uma biblioteca
livre de visão de computacional, para realizar o processamos de imagens; e o software WEKA
(Waikato Environment for Knowledge Analysis) (MARK, 2009), que é um conjunto de
bibliotecas que agrega algoritmos com diferentes abordagens na sub-área da inteligência
artificial dedicada ao estudo da aprendizagem de máquinas. A exposição destes serviços
através de uma interface Facade (Fachada) permite as demais camadas da aplicação
consumirem estes serviços para obtenção de informações através uma interface simplificada e
padronizada sem conhecer os detalhes internos de sua implementação ou integração.
CONCLUSÕES
Os resultados do estudo sobre a arquitetura de sistemas para AP com o uso de VANTs
permitiu concluir que, independente da origem dos sistemas, comerciais ou experimentais
desenvolvidos pela pesquisa, o problema em grande parte, está relacionado como as
arquiteturas que esses sistemas são projetados. Em razão da evolução dos sistemas, a sua
complexidade e abrangência demandam de integração com outros sistemas e recursos.
Este trabalho demonstrou que é possível modelar um ambiente de software para uso de
VANTs em AP, com capacidade de evolução de uma infraestrutura baseada em padrões. O
uso do DDD, através de refatorações e processos iterativos, permitiu que o modelo de
domínio continue a evoluir junto com o software. A arquitetura, apesar de simples por conter
apenas partes dos elementos do domínio real, mostrou que pode ser uma alternativa
interessante para publicação e disponibilização de serviços especializados desenvolvidos por
pesquisadores para uso na AP.
REFERÊNCIAS
BOEING RESEARCH & TECHNOLOGY. Using UAVs to Enhance the Quality of Precision
Agriculture [s.l.: s.n.], 2013.
BRADSKI, G. The Opencv library. Dr. Dobb's Journal of Software Tools. 2000
CALVARRO, Miguel Á. R. J. et al. Guía de Arquitectura N-Capas orientada al Dominio con
.NET 4.0. Microsoft DPE – Spain. 2010
GUELEN, J. P. Informed CQRS design with continuous performance testing. MSc Information
and Computing Sciences. Utrecht University. 2015
MARK, H., et al. The WEKA Data Mining Software: An Update; SIGKDD Explorations, Volume
11. 2009
EVANS, E.; FOWLER, M. Domain-Driven Design: Tackling Complexity in the Heart of
Software. Prentice Hall. 2003
KORKMAZ, N. NILSSON, M. Practitioners’ view on command query responsibility segregation.
MSc Information Systems. School of Economics and Management. Department of Informatics. 2014
MASCARIN, L. S.; MOLIN, J. P. Geração de mapas de produtividade para citros. 2º Congresso
Brasileiro de Agricultura de Precisão. São Pedro – SP. 2006.
MIRALLES, A; LIBOUREL, T. A New Methodology to Automate the Transformation of GIS
Models in na Iterative Development Process. Advances in Modelling Agricultural Systems. 2009.
Springer.
R DEVELOPMENT CORE TEAM: A language and environment for statistical computing. R
Foundation for Statistical Computing, Vienna, Austria. 2008
TANAKA, E.M. et al. Validação de levantamento planialtimétrico realizado pelo veículo aéreo
não tripulado (vant) - sensefly na cultura de cana-de-açúcar. IV Encontro de Mecanização em
Agricultura de Precisão. Pompeia – São Paulo. 2013.
TORRES-SÁNCHEZ, J. et al. Multi-temporal mapping of the vegetation fraction in early-season
wheat fields using images from UAV. Computers and Electronics in Agriculture. 2014
YOUNG, G. CQRS and Event Sourcing, 2010. Disponível em
</http://codebetter.com/gregyoung/2010/02/13/cqrs-and-event-sourcing /> Acessado em: 10 mai 2015.