Simulação na validação de sistemas computacionais para a agricultura de precisão

Simulation in the validation of precision farming computing systems

MÁQUINAS AGRÍCOLAS

Simulação na validação de sistemas computacionais para a agricultura de precisão¹

Simulation in the validation of precision farming computing systems

Braulio A. de Mello; Luciano L. Caimi

DECC / Universidade Regional Integrada do Alto Uruguai e das Missões, Rua Universidade das Missões 464, CEP 98802-470, Santo Ângelo, RS. Fone: (55) 3313-7970. E-mails: [e-mail]; [e-mail]

RESUMO

Sistemas computacionais têm tido aplicação crescente na construção de sistemas para o setor agrícola; contudo, o trabalho de projeto desse tipo de sistemas tem-se tornado mais complexo devido à necessidade de se estabelecer cooperação entre componentes que não possuem uma interface comum e/ou construídos com tecnologias diferentes (heterogêneos); deste modo, os componentes são, geralmente, validados em separado e a observação do funcionamento do sistema completo ocorre somente nos testes com o uso de protótipos, retardando a identificação de problemas e gerando custos em tempo e recursos. O uso da simulação pode contribuir com a antecipação de experiências que permitam observar o comportamento da cooperação entre os componentes do sistema, com o objetivo de reduzir o tempo e o custo geral do projeto. Através de um sistema eletrônico de supervisão de plantio (SEP) como estudo de caso, o artigo apresenta o uso do DCB (Distributed Cosimulation Backbone) como ferramenta de modelagem e simulação de sistemas voltados para a agricultura de precisão para reduzir tempo e custos de projeto.

Palavras-chave: simulação heterogênea, modelos de representação, arquiteturas embarcadas, processo de projeto

ABSTRACT

Computing systems have been employed for agricultural purposes, mainly in the precision farming domain. However, their implementation is complex because the cooperation among system components formed by agricultural equipment and computing parts do not have a common interface and the components are developed over distinct technologies (heterogeneous components). Also, the components are individually validated and the cooperation among them can be observed only in experiments using prototypes, delaying the identification of errors and increasing general costs. Simulation techniques are used to observe the work of all systems using models. This paper discusses a heterogeneous simulation to improve the implementation process of precision agricultural systems that bind heterogeneous components. This article presents a solution based on DCB (Distributed Cosimulation Backbone) architecture of heterogeneous models simulation. A SEP (Electronic Plantation Supervisor) system is presented as a study case.

Key words: heterogeneous simulation, representation models, embedded architectures, project process

INTRODUÇÃO

Atualmente, as soluções existentes para mecanização e automação de processos têm proporcionado condições favoráveis para melhorar a precisão e a produtividade dos sistemas em que são utilizadas. O setor agrícola tem sido agraciado com expressivos benefícios no uso da computação e das tecnologias de comunicação, de que são exemplos de aplicações agrícolas que incorporam sistemas computacionais: sensores embarcados em equipamentos de manejo agrícola para coleta de dados, posicionamento global para mapeamento de áreas de plantio, controle automático de operação e sistemas de software para gestão de dados (de campo ou administrativos).

No setor agrícola o campo de atuação delimitado pela Agricultura de Precisão (AP) faz uso de recursos tecnológicos para identificar e tratar dados individualmente, alcançando ganho de precisão e melhorando as condições para aumento de produtividade (McBratney, 2005). Estudos de variabilidade sobre dados de uma área de produção, seguida do uso dos resultados desses estudos para atuar de forma pró ativa no cultivo agrícola, estão no contexto da AP, que transcende o uso de recursos de posicionamento global (Cox, 2002). Esta prática permite, por exemplo, que o uso de produtos ou insumos seja melhor ajustado à variabilidade (Umezu & Cappelli, 2006); como resultado, são maiores as perspectivas de redução de custos, melhor aproveitamento de recursos e, conseqüentemente, aumento da produtividade final; assim, a AP oferece técnicas que melhoram a 'precisão' em observações agronômicas, tais como testes de solo, produtividade em campo de colheita ou contagem de sementes.

Afora os benefícios, a construção de sistemas automáticos que combinam hardware e software e que podem operar de modo combinado com equipamentos de manejo agrícola (por exemplo, de tração, semeadoras, colhedoras), não é uma tarefa trivial. Apesar das diferenças das partes em termos de tecnologia de construção ou da incompatibilidade de interface de comunicação, elas devem executar tarefas de modo integrado; tomando-se como exemplo uma semeadora o fluxo de sementes provoca eventos que podem ser monitorados por sensores conectados a um módulo de software responsável pelo armazenamento e/ou tratamento dos dados coletados. Essas diferenças dificultam ou até inviabilizam a verificação e a correção de erros do funcionamento integrado (cooperativo) das partes do sistema antes da construção de um protótipo operacional; este é um dos fatores que elevam os custos de desenvolvimento e, neste contexto, o uso de recursos de simulação permite detecção e correção de problemas de cooperação entre partes distintas de um sistema, através do uso de modelos de representação.

A execução de atividades de verificação, antes da construção de protótipos para a realização de testes em condições reais de trabalho, contribui com a redução de custos e de tempo. Apresenta-se, em Rafull et al. (2006), um mecanismo para controle automático da altura de corte em colhedoras, desenvolvido e testado com o uso de recursos de modelagem e simulação; a simulação é citada como ferramenta útil para caracterização da dinâmica dos sistemas de controle, facilitando o estudo do comportamento de sistemas e contribuindo com a redução de custos, na medida em que aumenta a precocidade com que informações de viabilidade técnica e econômica são geradas.

O uso de recursos de simulação durante as fases intermediárias do processo de projeto de sistemas para a AP, permite que a cooperação entre as partes do sistema passe por etapas de verificação antes da construção de protótipos. Dentre as dificuldades para o uso da simulação, se destacam a complexidade dos modelos heterogêneos e a exigência de conhecimento em técnicas de simulação e, dentre os desafios para facilitar o uso da simulação em áreas distintas do conhecimento como, por exemplo, na área agrícola, tem relevância o aumento do nível de abstração oferecido por arquiteturas, ferramentas ou ambientes de simulação, ou seja, quanto menor o número de detalhes da simulação que um projetista de modelos precisa controlar, maior a sua produtividade.

Este artigo aborda o uso da simulação heterogênea (Reynolds Júnior, 1988) como instrumento de apoio do projeto de sistemas para a AP e discute estratégias para facilitar e agilizar o trabalho de construção e execução de modelos com base na arquitetura do DCB (Distributed Cosimulation Backbone) (Mello et al., 2005). O artigo propõe um conjunto de aspectos ou critérios fundamentais para o projeto de sistemas no domínio da AP; esses aspectos são discutidos na apresentação do processo de construção e execução do modelo do sistema SEP (Supervisor Eletrônico de Plantio) sobre o DCB; são apresentadas soluções essencialmente para aplicação da característica de 'independência entre elementos' do DCB sobre os aspectos de projeto de sistemas para a AP. Três fatores principais são considerados: a complexidade inerente ao uso de recursos de simulação computacional; a necessidade de se representar a variabilidade das condições de trabalho em campo e a cooperação entre os equipamentos de manejo agrícola e os sistemas de precisão neles acoplados (Saraiva & Cugnasca, 2000). O DCB permite que os elementos (componentes) de um modelo tenham sua integridade preservada, ou seja, elementos podem ser adicionados ao modelo mesmo que sua interface seja incompatível com a interface dos elementos já existentes; para tal, o DCB implementa, de forma transparente para os elementos (independência), as ações de sincronização, de tradução de interface e de comunicação.

MATERIAL E MÉTODOS

Inicialmente, o artigo apresenta uma breve abordagem sobre modelagem e simulação no projeto de equipamentos agrícolas, com maior ênfase nos sistemas eletroeletrônicos. Nesta parte, o artigo define e apresenta o uso da simulação heterogênea como instrumento de apoio em fases intermediárias do processo de projeto desses sistemas e, em seguida, ele indica uma arquitetura para suporte à construção e execução de modelos heterogêneos visando ao projeto de sistemas de aplicação agrícola.

Modelagem e simulação de equipamentos agrícolas

Os sistemas utilizados na atividade agrícola, mecânicos ou eletrônicos, são submetidos a uma grande variedade de situações hostis e não controláveis, em função da variabilidade das condições de trabalho a que são submetidos (Saraiva et al., 2000). Esta realidade torna o projeto desses sistemas mais complexo e, em geral, exige uma quantidade expressiva de experimentos em situações reais de produção ou trabalho para que problemas e falhas sejam resolvidos.

Tanto quanto os próprios sistemas, as condições em que eles trabalham podem ser representadas com o uso de modelos de simulação e, deste modo, problemas que seriam detectados apenas durante a realização de experimentos (em campo) podem ser resolvidos ainda durante as fases intermediárias do projeto. Contudo, na construção de modelos de representação desses sistemas a descrição das partes distintas (partes mecânicas, de hardware e de software) nem sempre pode ser realizada através de uma mesma tecnologia (uma mesma linguagem de programação, por exemplo). A variação das características de cada parte de um sistema pode inviabilizar esta tarefa. No projeto de sistemas embarcados (Edwards et al., 1997; Carro & Wagner, 2003), sistemas que combinam hardware e software, esta realidade é identificada na necessidade do uso de linguagens de descrição de hardware (VHDL e Verilog) e do uso de linguagens, tanto de alto nível (C e Java) quanto de baixo nível (assembly) para a implementação da parte de hardware e de software, respectivamente.

As fases de projeto e construção de um equipamento agrícola podem usufruir de recursos de simulação para representar não apenas a cooperação entre hardware e software do sistema computacional, mas, também, a cooperação do módulo computacional com o equipamento mecânico em que o módulo está instalado. Deste modo, problemas que seriam percebidos nas fases de teste podem ser detectados e corrigidos em etapas mais precoces do projeto, sobretudo antes da construção do primeiro protótipo. A antecipação do uso de medidas de verificação e validação com auxílio de recursos de simulação, geralmente contribui com a redução de custos (Rafull et al., 2006) e antecipa conclusões sobre viabilidade técnica e econômica. Quanto mais fiéis os modelos de representação da variabilidade das condições de trabalho no equipamento agrícola (em termos de clima, relevo e umidade) e das partes que compõem o sistema, melhores serão os benefícios do uso de recursos de simulação nas etapas intermediárias do processo de desenvolvimento de um sistema para uso em AP.

Em geral, torna-se difícil detectar problemas de cooperação entre elementos de um sistema ou equipamento, quando projetados para trabalhar em conjunto, mas desenvolvidos e avaliados em separado. Por outro lado, os testes que permitem a observação da cooperação entre esses elementos são baseados em protótipos, aumentando o custo final do projeto. O uso de recursos de modelagem e simulação computacional também contribui com a detecção e correção de problemas de cooperação entre elementos em etapas mais iniciais do processo de projeto.

Sistemas que combinam equipamentos de manejo agrícola com módulos computacionais (comuns na AP) podem ser caracterizados como sistemas heterogêneos; por exemplo, um equipamento de tração, uma semeadora e um supervisor de plantio. Esses sistemas combinam elementos mecânicos, eletroeletrônicos e de software que cooperam através de interfaces de comunicação diferentes. A heterogeneidade de um sistema aumenta a complexidade no trabalho de construção e execução de modelos computacionais.

Além das diferenças entre os elementos que integram um mesmo equipamento (heterogeneidade), é difícil tratar, medir, mensurar ou observar adequadamente o comportamento de um sistema de precisão quando submetido à variabilidade do objeto monitorado ou controlado; por exemplo, se em uma operação de plantio o objeto monitorado é a 'semente', as condições operacionais do campo interferem significativamente no comportamento das sementes ao serem manipuladas pelo equipamento mecânico e no monitoramento (ou atuação) realizado pelo sistema de precisão (computacional); nesta situação, a tendência de que a precisão dos sensores (de passagem de sementes) diminua em condições normais de trabalho em campo, é uma realidade; então, o modelo precisa tratar esta característica, o que interfere diretamente na redução do volume de testes sobre protótipos do sistema.

São destacados, a seguir, alguns aspectos existentes no projeto de sistemas para a AP em que o uso de recursos de simulação durante fases intermediárias do projeto pode contribuir com a redução de problemas ou falhas que seriam percebidas apenas durante os testes, através do uso de protótipos reais do sistema em construção.

Energia: Os projetos de sistemas que não possuem acesso a fontes perenes de energia (por exemplo, sensores isolados em campo) precisam de especial atenção ao consumo de energia; nesses casos, a dependência de baterias torna o consumo de energia um requisito importante; redes de sensores sem fio, com aplicação agrícola, convivem com esta dificuldade.

Características físicas do equipamento: As características físicas do equipamento mecânico de manejo em que o sistema de precisão deve ser instalado devem ser levadas em consideração no projeto do sistema; por exemplo: tamanho, peso, mobilidade, durabilidade e condições de trabalho.

Características do ambiente: As propriedades do ambiente agrícola em que são utilizados os equipamentos são importantes para decisões; por exemplo, sobre o nível de robustez do sistema de precisão. As variações da temperatura, da umidade e do nível de contato com quaisquer elementos nocivos ao sistema podem reduzir a precisão ou mesmo interromper o seu funcionamento.

Interface com dispositivos: Não são raras as situações em que dados coletados por sistemas de precisão são utilizados em outros sistemas com propósitos diferenciados (por exemplo o sistema de monitoramento de produtividade e sistema de controle de adubação); deste modo, é relevante um estudo criterioso sobre compatibilidade de interface para a troca de dados.

Precisão: Este tópico pode ser relacionado com as demais situações que interferem no projeto de sistemas de precisão agrícolas. A veracidade dos dados coletados e das decisões operacionais, tomadas a partir desses dados, deve ser confiável. O nível de precisão depende do propósito do sistema.

Custo x benefício: É um desafio desenvolver elementos de precisão (por exemplo sensores) a baixo custo e que resistam a condições difíceis de trabalho no ambiente de operação (campo).

Comportamento interno dos elementos: O comportamento interno de elementos (capacidade e funcionalidade) que combinam hardware e software, dificilmente é validado nas primeiras versões; em geral, variados testes de campo com protótipos reais são necessários para que o comportamento desejável seja alcançado.

Testes: Os testes de equipamentos, quando submetidos a variabilidade inerente às condições de trabalho em campo, comumente são onerosos.

No projeto de sistemas para a AP, a necessidade de combinar elementos distintos em termos de interface ou tecnologia de construção (mecânicos, elétricos, software) está entre os principais fatores que fortalecem a demanda por instrumentos computacionais que facilitem o uso da simulação. Tal necessidade justifica o propósito deste artigo ao discutir o Distributed Cosimulation Backbone (DCB) (Mello et al., 2005) como instrumento de simulação heterogênea no projeto desses sistemas.

Distributed Cosimulation Backbone (DCB)

Esta seção apresenta os principais aspectos do DCB, uma arquitetura de suporte à cooperação entre elementos heterogêneos de simulação. Concebido no domínio da co-simulação de hardware e software (Hubert, 1998) para o projeto de sistemas embarcados, o DCB é apto à execução de modelos heterogêneos que representam o comportamento de sistemas em outros diferentes de aplicação. Após a apresentação do DCB são propostas estratégias para a simulação de sistemas no domínio da AP, baseadas nesta arquitetura.

O DCB é uma estrutura de suporte para simulações distribuídas de modelos que combinam partes (ou elementos) com características distintas (heterogêneas). Ele incorpora mecanismos genéricos que permitem a comunicação e a sincronização entre elementos heterogêneos. O elemento de um modelo pode ser um módulo de software, um módulo de hardware, um elemento mecânico ou mesmo um participante físico.

Na abordagem do DCB, modelos de simulação heterogênea são compostos de elementos autônomos e distribuídos. Elementos podem ser descritos com diferentes linguagens e/ou representados por simuladores distintos. Com o objetivo de participar de um modelo heterogêneo, um elemento precisa ter uma interface pública disponível, significando que atributos de interface precisam ser visíveis e controláveis pela sua interface. Por este motivo os aspectos internos de um elemento não interferem na sua integração a um modelo. Usando esses atributos, o DCB pode configurar o modo como a cooperação entre os elementos de um modelo é realizada e também permite a construção de mecanismos para a configuração automática de modelos heterogêneos.

Os mecanismos de controle da simulação são encapsulados pelo DCB, em que cada elemento visualiza apenas a interface com um módulo de software do DCB responsável pelo elemento; esta característica permite que elementos possam ser adicionados a um modelo sem a necessidade de alterações ou adaptações; basta que a comunicação entre o módulo local do DCB denominado Gateway (Figura 1) e a interface do elemento (atributos de entrada e saída) seja estabelecida; para minimizar possíveis interferências na interface do elemento: a estrutura do Gateway possui flexibilidade para adaptação de interface como, por exemplo, para tradução de tipos de dados. O DCB também não é restritivo quanto ao tipo de simulações ou de elementos que possam ser integrados a um modelo heterogêneo, características que também favorecem o reuso de elementos existentes.

A Figura 1 apresenta a arquitetura do DCB. Os módulos do DCB encapsulados entre o módulo Gateway e o barramento de comunicação, são responsáveis pelas tarefas de sincronização e comunicação; basicamente, esses mecanismos estão divididos em três módulos maiores: DCBS (DCBSender), DCBR (DCBReceiver) e DCBK (DCBKernel).

O DCBS controla as solicitações para envio de mensagens iniciadas por elementos que atualizam valores nos atributos de saída; para realizar o controle das mensagens, o DCB atribui um rótulo baseado em um contador de tempo virtual; este contador de tempo é mantido por um relógio interno do DCB.

O DCBR é responsável pela decodificação de mensagens provenientes de elementos origem; este módulo, por sua vez, mantém gerenciamento sobre uma fila de mensagens, de acordo com configurações de sincronização, de elementos origem e destino e de ordenação; as referidas configurações definem os critérios para a entrega do conteúdo das mensagens ao elemento destino, via interface controlada pelo módulo Gateway do DCB.

O DCBK implementa mecanismos internos do DCB, transparentes ao usuário ou programador de um modelo, que oferecem condições para se realizar, essencialmente, as atividades de sincronização de mensagens, configuração de modelos e preservação da integridade dos elementos.

O uso de recursos de simulação heterogênea permite que o comportamento do sistema, incluindo-se as ações de cooperação entre os elementos, seja observado e testado; com isto, os problemas ou desafios são mais facilmente solucionados em fases mais precoces do ciclo de projeto. A redução de custos e de tempo geralmente é expressiva. Na apresentação do processo de modelagem de um SEP (Supervisor Eletrônico de Plantio), a seção 'Resultados e Discussão' discute os benefícios do uso de recursos de simulação no projeto de sistemas de uso agrícola.

RESULTADOS E DISCUSSÃO

Os próximos cinco subitens apresentam o processo de desenvolvimento de um sistema para supervisão da atividade de plantio em semeadoras, denominado Supervisor Eletrônico de Plantio (SEP) em duas etapas, em que na primeira se apresenta o processo de projeto original, executado por uma empresa no ramo de automação sem o uso da simulação ou de uma metodologia de projeto, baseado essencialmente em testes sobre protótipos, comentando aspectos que dificultaram a construção do SEP; na segunda, é construído e apresentado um modelo para o SEP com o uso de recursos de simulação, identificando e demonstrando estratégias e aspectos positivos no uso da simulação heterogênea, com base na arquitetura do DCB, para a definição e especificação das características dos sistemas computacionais voltados para a AP.

Componentes de hardware e de software do SEP

O SEP, atualmente comercializado por uma empresa do ramo de automação, foi projetado sem o uso de recursos de simulação. Este primeiro projeto previa o desenvolvendo de um equipamento de medição de área plantada e de tempo de plantio, conhecido como "hectarímetro" (este termo é utilizado por empresas fabricantes de equipamentos com estas características). Este tipo de equipamento permite o cálculo de diversas grandezas importantes no gerenciamento da produção como, por exemplo, tempo efetivo e área de plantio (diário e acumulado), velocidade instantânea e velocidade média de plantio. Este equipamento, mais simples que o SEP, possui um sensor de velocidade e um outro sensor que verifica se a semeadora está ou não em atividade de distribuição de sementes (sensor de plantio). Pela sua simplicidade, o equipamento possui apenas uma central que coleta os dados dos sensores e gerencia a interface com o usuário (display), permitindo a configuração do equipamento, o cálculo das grandezas e a visualização dos dados (Figura 2).

A tarefa de definição da arquitetura do SEP foi um dos primeiros problemas encontrados no seu processo de desenvolvimento. Em virtude da necessidade de se utilizar sensores dedicados para o monitoramento das sementes em cada linha de plantio, a arquitetura com controle centralizado, utilizada no hectarímetro, teve de ser descartada em função da alta demanda por processamento, o que a inviabilizava. Os resultados de testes em bancada permitiram constatar que o tempo consumido para realizar a amostra de todos os sensores era insuficiente perante a freqüência com que as sementes passavam em cada um dos sensores.

Uma abordagem descentralizada com o uso de dois centros de processamento foi então utilizada; um centro localizado junto ao equipamento de tração (responsável por parte dos cálculos e controle do display e teclado) e outro localizado na unidade de plantio (responsável pela coleta dos dados junto aos sensores e se usando cálculos preliminares ou intermediários). Nesta abordagem, as tarefas de monitoração, cálculo, configuração e visualização das informações, ficavam divididas entre os dois centros de processamento, contornando o problema da freqüência de passagem das sementes pelos sensores; por outro lado, foi necessário o desenvolvimento de um mecanismo de comunicação entre os centros de processamento para que as informações obtidas em um estejam disponíveis no outro possibilitando, desta forma, além da distribuição de processamento, a consistência dos dados. A Figura 3 mostra a primeira arquitetura do SEP utilizando a abordagem descentralizada.

Utilizando a arquitetura do SEP apresentada na Figura 3 (em que cada centro de controle utiliza um microcontrolador PIC16F877 a 20MHz): e se considerando uma situação de plantio da soja onde se deseja uma densidade de plantio de 18 sementes por metro, a uma velocidade de plantio de 1,66 m s^-1 (6 km h^-1), o tempo entre sementes é de 33 ms; visto que, para percorrer 1 metro a esta velocidade, são consumidos 0,6 segundos; então, neste intervalo de tempo caem 18 sementes, resultando em uma semente a cada 0,033 s (33 ms) em cada linha de plantio, significando que o microcontrolador tem, no máximo, 33 ms para amostrar todas as linhas em funcionamento; nesta configuração os testes de bancada mostraram que o microcontrolador mantém precisão de contagem para, no máximo, 9 linhas, simultaneamente.

Este impasse foi contornado através da alocação de um microcontrolador dedicado a cada uma das linhas de plantio, como apresentado na Figura 4; cada um deles monitora um único sensor, armazena a contagem de sementes do mesmo (em intervalo de tempo pré definido) e as repassa para a central da unidade de plantio, que então totaliza os dados e oferece condições para a realização de outros cálculos.

Em relação ao desempenho geral do sistema, níveis suficientes foram alcançados com esta nova abordagem. Os valores conhecidos utilizados na validação do sistema foram obtidos pela contagem e cálculos realizados manualmente. Estes valores foram comparados com os resultados apresentados pelo sistema computacional no mesmo experimento com o uso de 10 (dez) linhas de plantio. O sistema foi também testado em campo com 20 (vinte) linhas de plantio onde os resultados apresentados pelo sistema foram similares; porém, neste teste os resultados não foram verificados manualmente.

Embora uma versão confiável do sistema tenha sido alcançada, o consumo de tempo e de recursos para o alcance de uma primeira arquitetura viável foi demasiado; a dependência da construção de protótipos sem o uso da simulação, seguida da realização de testes de bancada, torna o projeto excessivamente demorado e depende da disponibilidade de equipamentos reais, muitas vezes inutilizados em experimentos sem sucesso. Com o uso da simulação a dependência de protótipos é expressivamente reduzida no trabalho de verificação do sistema, resultando na redução de custos.

A partir das informações coletadas pelo SEP durante a atividade de plantio (velocidade e sementes plantadas por linha) e das informações de configuração (quantidade de linhas de plantio e distância entre linhas), torna-se viável, aos módulos de software, o cálculo de uma vasta gama de informações; por exemplo: área plantada, número de sementes plantadas por metro linear (cada linha e também a média delas), população de sementes por hectare, velocidade média de plantio, tempo efetivo de plantio, quantidade de hectares por hora plantados, área acumulada de plantio e tempo acumulado de plantio. É possível, ainda, gerar alarmes para alertar o operador de anomalias no plantio, tais como: linha de plantio ou disco alveolado interrompido, falha de rendimento no plantio de cada linha (número de sementes por metro fora de uma faixa percentual configurada) e excesso na velocidade de plantio.

Além deste processamento em tempo real, é possível armazenar algumas informações no próprio equipamento (tal como a velocidade instantânea e número de sementes por metro linear em cada linha) em uma memória permanente, para análise posterior; essas informações e os eventos relativos aos alarmes, são armazenados e associados à informação de dia e hora de ocorrência.

O volume de processamento é significativo em função da característica de monitoração em tempo-real e da rapidez e variabilidade das informações coletadas, já que elas são obtidas enquanto a semeadora realiza o plantio de várias linhas a velocidade compatível com as características desejadas; há, também, o aspecto da entrega da informação, de forma rápida e automática ao operador. Se, por exemplo, o operador está visualizando informações relativas à área plantada e uma ou mais linhas de plantio atingem um nível de alarme de rendimento, o sistema deve visualizar esta informação de forma automática e independente do manuseio do operador.

Os cálculos que requerem o acúmulo de informações (como velocidade média, média de sementes por metro e população de sementes por hectare) para o seu processamento, possuem restrições críticas de tempo para a verificação do comportamento como, por exemplo, as sementes no SEP.

Em resumo, o software responsável pelo cálculo e tratamento das informações possui complexidade elevada; o desenvolvimento e a verificação do seu funcionamento correto necessitam de protótipos e de exaustivos testes de bancada ou de campo. Estabelecer, em bancada, uma seqüência de eventos que possam levar à verificação do atendimento de todos os requisitos, requer tempo. Levando-se em consideração, ainda, o fato de que, a cada constatação de funcionamento inadequado e correção do software, se exige nova bateria de testes de bancada, existe o risco de comprometimento da relação entre custo e benefício do projeto fazendo com que a demanda de tempo nos testes de bancada tenha implicações grandes negativas nos custos finais do equipamento.

Construção e execução do modelo

Esta seção apresenta o trabalho de construção e execução de um modelo do SEP com base na arquitetura do DCB. No decorrer desta abordagem são comentados alguns dos problemas e dificuldades identificados nas etapas do projeto do SEP, descritos na seção anterior (processo de construção do SEP sem uso da simulação ou método) e se discutem benefícios que o uso da simulação pode oferecer para identificar e solucionar problemas em etapas mais precoces do projeto, resultando em economia de tempo e de recursos. O modelo representa, com mais detalhes, os módulos de software do SEP; por outro lado, as partes de hardware são representadas de modo simplificado; por exemplo, o sensor, no modelo, é implementado por um trecho de código que controla um contador simples para representar a queda de sementes.

A Figura 5 apresenta os elementos (partes) básicos modelados do SEP. Foram considerados aqueles que interferem diretamente na atividade de supervisão. Alguns elementos foram abstraídos no modelo como, por exemplo, o sistema para aquisição de velocidade, que também deve ser acoplado à semeadora. Neste modelo, a velocidade é fornecida diretamente em km h^-1, via interface do elemento 'Semeadora' (Figura 5).

A arquitetura do DCB permite que um novo elemento seja adicionado ao modelo sem que os elementos existentes sofram alterações ou adaptações; isto é possível em função do encapsulamento dos elementos implementados pelo DCB; assim, um refinamento do modelo pode incluir, por exemplo, o elemento que representa o sistema de aquisição de velocidade ou a comunicação com um nodo central (computador) sem comprometer os elementos já existentes e em funcionamento. Esta característica não é comum em ferramentas ou ambientes de simulação existentes.

A Figura 6 apresenta a configuração das relações de cooperação entre os elementos do SEP e nela se observa que os elementos 'Disco' e 'Sensor' possuem uma ocorrência com a linha contínua e uma ocorrência com a linha pontilhada, significando que o modelo atual implementa um conjunto 'Disco e Sensor' porém múltiplos conjuntos podem ser adicionados ao modelo sem qualquer alteração nos elementos existentes (Figura 6); assim, linhas múltiplas de plantio de uma semeadora podem ser representadas individualmente, ou seja, cada linha (modelada por um conjunto 'Disco e Sensor') irá enviar, ao elemento 'Centro de Controle', informações individuais que podem ser modeladas com o uso de, por exemplo, distribuições de probabilidade ou de modelos matemáticos.

Para estabelecer esta cooperação o DCB utiliza a interface dos elementos em que são identificados apenas atributos de entrada e de saída. O destino de cada atributo de saída não é conhecido pelo elemento origem. A estrutura de suporte à execução de modelos implementada pelo DCB, permite que o projetista do modelo estabeleça a configuração da comunicação, de modo independente dos elementos; assim, um elemento pode ser substituído por outro elemento ou mesmo pelo componente real que, então, irá cooperar com os demais elementos simulados, cuja facilidade permite que as características específicas de sistemas computacionais agrícolas como, por exemplo, a variabilidade e hostilidade das condições de trabalho em campo a que os sistemas são submetidos, sejam melhor representadas pelos modelos.

Discutem-se, em seguida, as implicações dos dados enviados e recebidos, no comportamento interno dos elementos e na cooperação entre eles; por exemplo, a alteração da velocidade e do número de furos do disco interfere no comportamento do sensor. Durante a abordagem dos detalhes da variável 'velocidade' e das características do disco alveolado são apresentados os atributos de entrada e saída de acordo com a Figura 6, os detalhes internos dos elementos e os benefícios que o uso de modelos oferece para o projeto de sistemas para a AP, ambos exemplificados no modelo do SEP.

Velocidade

A velocidade de deslocamento do elemento 'Semeadora' interfere diretamente em dois outros elementos: no 'Disco' e no 'Centro de Controle' (atributo de saída 1.0 na Figura 6); no primeiro, este dado interfere no tempo entre as quedas das sementes (plantio) e, no segundo, interfere nas fórmulas que calculam informações de controle, tais como: número médio de sementes por metro, área plantada, volume de sementes consumido, dentre outros, razão por que, no modelo representado na Figura 6, este dado é fornecido via atributos controlados pelo DCB para os dois elementos destino (atributos de entrada 2.0 e 3.1, respectivamente). A interface do elemento 'Semeadora' é apresentada na Figura 7 na qual são também fornecidos dados sobre o número de furos do disco alveolado (Portela, 1997) e do número de metros por volta. Na simulação, exemplo em que se utilizam os valores representados na Figura 7, a semeadora está a uma velocidade de 12 km h^-1, utiliza um disco alveolado com 20 furos e possui uma regulagem que requer 4,5 metros para que o disco complete uma volta (do furo 1 ao 20).

Na construção do SEP sem uso da simulação, a variabilidade da velocidade (Mercante et al., 2005) e sua interferência, principalmente nas fórmulas de controle, puderam ser testadas somente após a construção do primeiro protótipo e da realização de testes de campo ou bancada. A existência de problemas naquele momento resultou em esforço de retrabalho (e custos de tempo e material) para correção de erros relacionados à dependência de equipamentos de teste.

As condições oferecidas pelo modelo de simulação para observação, por exemplo, dos efeitos da variação da velocidade nos processos implementados no centro de controle, nas simulações realizadas neste trabalho, permitiram observar que problemas na implementação das fórmulas podem ser totalmente sanados, independentemente da existência de um protótipo. O trecho de código a seguir, implementado na linguagem Java, (do elemento 'Centro de Controle') programa a fórmula para cálculo do tempo entre as quedas das sementes (intervalo); ao final deste intervalo o 'Centro de Controle' solicita ao 'Sensor' o número acumulado de sementes do último intervalo usando da primitiva Gateway4.UpdateAttribute("4.2","2","0"). As ações desta primitiva são encapsuladas pelo DCB.

while (true)

{

// espera a semeadora percorrer 1 metro

try {Thread.sleep((int)((1/veloc)*1000));}catch (InterruptedException e){}

// solicita ao sensor a contagem de sementes mantida pelo acumulador

Gateway4.UpdateAttribute("4.2","2","0");

}

O número acumulado de sementes do último intervalo é repassado ao método Recebesinalsensor(...). Este método, cujo trecho de código Java é apresentado a seguir, implementa a fórmula para cálculo do número médio de sementes por metro, entre outras informações.

public void Recebesinalsensor (String sementes)

{

// calcula média de sementes por metro desde inicio do plantio

// variável 'sementes' informa número de sementes do último metro percorrido

acumsemente = Integer.parseInt(sementes) + acumsemente;

metrospercorridos = metrospercorridos + 1;

sementespormetro_sensor = acumsemente / metrospercorridos;

// mostra no painel de controle o número médio de sementes por metro desde o inicio

// do plantio

fnome.setText(String.valueOf(sementespormetro_sensor)); this.show();

// mostra no painel de controle o número de sementes do último metro percorrido

finstantaneo.setText(String.valueOf(sementes)); this.show();

}

Características do disco alveolado

Outras duas variáveis essenciais ao funcionamento da semeadora, são: o número de furos do disco alveolado e a distância percorrida em uma volta do disco; estes dados são também fornecidos na interface do elemento 'Semeadora' (Figura 7) e enviados aos elementos 'Disco' e 'Centro de Controle' através dos atributos de saída 1.1 e 1.2, respectivamente, além de utilizados no atendimento aos propósitos do 'Centro de Controle'.

Alterações em qualquer uma dessas variáveis exigem o recálculo do intervalo entre a queda de sementes. Esta propriedade do elemento 'Disco', permite ao projetista do sistema simular diferentes situações de funcionamento da semeadora para o projeto do SEP (comentados à frente, na apresentação do elemento 'Centro de Controle'). O 'Disco' não possui interface de visualização. As informações necessárias são recebidas pelos atributos de entrada cuja origem é o elemento 'Semeadora'.

Outra vantagem do modelo é a possibilidade de tratamento individualizado de cada conjunto 'Disco e Sensor' (comentado anteriormente) em relação às condições de trabalho; por exemplo, no trabalho de plantio a pressão do conjunto de plantio sobre o solo difere, em geral, de uma linha para outra, de acordo com a ondulação do terreno. Na solução por simulação, proposta neste trabalho, tal característica pode ser representada mais facilmente que em bancadas de teste com equipamento real; a mesma afirmação pode ser válida para outras variáveis, tais como resistência do solo ao dispositivo de sulcagem, umidade e temperatura, dentre outros. Naturalmente, a quantidade de informações e variáveis controladas depende da necessidade, que varia de acordo com o tipo de equipamento em construção.

Controle do processo de plantio

O elemento 'Centro de Controle' é responsável pelo tratamento de dados gerados pelo funcionamento dos demais elementos combinados com os dados fornecidos através do elemento 'Semeadora'; para isto, este elemento recebe informações do elemento 'Semeadora' e solicita, ao elemento 'Sensor', o número de sementes contabilizadas a cada metro de distância percorrido. A variação dos dados fornecidos através da interface do elemento 'Semeadora', afeta os resultados dos cálculos realizados pelo 'Centro de Controle'.

A Figura 8 apresenta a interface do elemento 'Centro de Controle' no qual se visualizam informações sobre o processo de plantio. A primeira informação, sementes esperadas por metro, é dada pela divisão do número de furos do disco alveolado pela distância (em metros) necessária para que o disco complete uma volta; seria, no caso, a situação ótima de plantio.

A segunda informação da Figura 8 mostra a média de sementes distribuídas por metro percorrido pela semeadora, durante o trabalho de plantio. Inicialmente, a partir das informações fornecidas por 'Semeadora' o 'Centro de Controle' identifica o tempo para que a semeadora percorra um metro. Este intervalo é utilizado para separar, no tempo, os pedidos de leitura do acumulador de sementes implementado pelo sensor; a cada leitura o acumulador é zerado. O 'Centro de Controle' utiliza o valor deste acumulador e a velocidade (em m s^-1) para o cálculo da média de sementes por metro. Observa-se, na Figura 8, que esta média difere ligeiramente do valor resultante da divisão do número de furos do disco pela distância em metros necessária para uma volta (plantio ótimo).

Esta variabilidade é conseqüência da passagem da semente pelos elementos que compõem o SEP e das informações da semeadora; por exemplo, aqui o disco alveolado utiliza 4,5 metros para completar uma volta (Figura 7); isto significa que o número de sementes por metro (quarta informação da Figura 8) varia entre 4 e 5; não há 0,5 semente em cada metro para efeito de contagem; características como essas são rápida e facilmente alteradas ou controladas em um modelo de simulação, diferente da realização de testes com o uso de equipamento real (bancada ou em campo) e protótipos do sistema em construção.

CONCLUSÕES

1. O uso da simulação em fases intermediárias do processo de projeto de sistemas computacionais para a AP reduz o tempo total do projeto e contribui com a identificação de falhas antes da execução de experimentos em protótipos reais.

2. No estudo de caso apresentado a construção, o teste e a correção das fórmulas para cálculo de média de plantio e área plantada, dentre outras, foram realizados com o uso de um modelo que simula a bancada de testes exemplificando a viabilidade da simulação para a verificação e validação de sistemas.

3. Na realização de testes com o modelo foram utilizados dados de entrada com resultados conhecidos anteriormente observados no funcionamento do sistema real (no que tange aos cálculos realizados pelo sistema). A execução do modelo apresentou resultados similares. Nesta fase não foram considerados fatores existentes no ambiente de trabalho em campo que reduzem a precisão.

4. A principal vantagem do DCB na simulação de sistemas para a AP é a independência total entre os elementos que permite, por exemplo, que mais conjuntos 'Disco e Sensor' (do estudo de caso) sejam adicionados ao modelo sem qualquer alteração nos elementos existentes.

5. Como perspectiva, o modelo utilizado no estudo de caso terá alguns dos elementos substituídos pelo elemento real (possivelmente o sensor) e serão incluídos mais conjuntos 'Disco e Sensor' com o objetivo de observar os aspectos de sincronização entre elementos e a capacidade (em números de linhas) do sistema sem perda de precisão dos dados.

LITERATURA CITADA

Protocolo 014.07 - 13/02/2007 - Aprovado em 23/04/2008

• Carro, L.; Wagner, F. R. Sistemas computacionais embarcados. Jornadas de atualização em informática. Campinas: UNICAMP, 2003, 50p.
• Cox, S. Information technology: The global key to precision agriculture and sustainability. Computers and Electronics in Agriculture, v.36, n.2-3, p.93-111, 2002.
• Edwards, S.; Lavagno, L.; Lee, E. A.; Sangiovanni-Vincentelli, A. Design of embedded systems: Formal models, validation, and synthesis. IEEE, v.85, n.3, p.366-390, 1997.
• Hubert, H. A Survey of HW/SW Cosimulaton techniques and tools. Kista: Electronic Systems Design Laboratory, Royal Institute of Technology, 1998, 48p. Thesis
• Mcbratney, A.; Bouma, J.; Whelan, B.; Ancev, T. Future directions of precision agriculture. In: Precision agriculture, Springer Netherlands Publisher, v.6, n.1, p.7-23, 2005.
• Mello, B. A.; Souza, U. R. F.; Sperb, J. K.; Wagner, F. R. Tangram-virtual integration of heterogeneous IP components in a distributed co-simulation environment. IEEE - Design and Test of Computers, v.22, n.5, p.462-471, 2005.
• Mercante, E.; Silva, S. L.; Modolo, A. J.; Silveira, J. C. M. Demanda energética e distribuição de sementes de milho em função da velocidade de duas semeadoras. Revista Brasileira de Engenharia Agrícola e Ambiental, v.9, n.3, p.424-428, 2005.
• Portela, J. A. Mecanismos dosadores de sementes e de fertilizantes em máquinas agrícolas. Passo Fundo: EMBRAPA/Centro Nacional de Pesquisa de Trigo, 1997. 39p.
• Rafull, L. Z. L.; Queiroz, D. M.; Souza, M. A.; Pinto, F. A. C. Modelagem e análise de um sistema de controle automático da altura de corte em colhedoras. Revista Brasileira de Engenharia Agrícola e Ambiental, v.10, n.3, p.751-758, 2006.
• Reynolds Jr., P. F. Heterogeneous distributed simulation. In: Winter Simulation Conference, 20, 1988, Tokyo. Proceedings... Tokyo: WSC, 1988. p.206-209.
• Saraiva, A. M; Cugnasca, C. E. Equipamentos de automação agrícola. In: Congresso e Mostra de Agroinformática, 2000, Ponta Grossa. Anais... Ponta Grossa: Universidade Estadual de Ponta Grossa, 2000. CD Rom
• Umezu, C. K.; Cappelli, N. L. Desenvolvimento e avaliação de um controlador eletrônico para equipamentos de aplicação de insumos. Revista Brasileira de Engenharia Agrícola e Ambiental, v.10, n.1, p.225-230, 2006.

1

Trabalho com apoio FAPERGS/ARD

Datas de Publicação

• Publicação nesta coleção
  15 Out 2008
• Data do Fascículo
  Dez 2008

Histórico

• Recebido
  13 Fev 2007
• Aceito
  23 Abr 2008