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.