Monografia - SIAPE - R07

PONTIFÍCIA UNIVERSIDADE CATÓLICA DE MINAS GERAIS Curso de Engenharia da Computação

Vinícius Silva Arruda

SIAPE - Sistema Integrado de Automação em Pequena Escala

Belo Horizonte, 2013


SIAPE – Sistema Integrado de Automação em Pequena Escala

Monografia apresentada ao Curso de Engenharia da Computação da Pontifícia Universidade Católica de Minas Gerais, como requisito parcial para obtenção do título de Engenheiro da Computação.

Orientador: Luis Enrique Zárate.



SIAPE – Sistema Integrado de Automação em Pequena Escala

Monografia apresentada ao Curso de Engenharia da Computação da Pontifícia Universidade Católica de Minas Gerais, como requisito parcial para obtenção do título de Engenheiro da Computação.

_________________________________________ Prof. Dr. Luis Enrique Zárate (Orientador) – PUC Minas

_________________________________________ Prof. Dr. – PUC Minas

_________________________________________ Prof. Dr. – PUC Minas


Aos meus pais,

pelo apoio, carinho

e incondicional incentivo.

RESUMO

Uma demanda significativa para automação está além da área industrial onde empresas de diversos setores procuram automatizar processos simples gerando economia de recursos e maiores facilidades no trabalho humano. Dentro deste cenário existe como grande empecilho para estes novos perfis de clientes o custo relativamente elevado dos produtos prontos de automação, que muitas vezes oferecem recursos excessivos que não são totalmente aproveitados em pequenas aplicações dedicadas. O objetivo deste trabalho é implementar um Sistema Integrado de Automação em Pequena Escala (SIAPE) que utilize um framework baseado em tecnologias recentes open-source (Android, Arduino etc), diminuindo o esforço de implementação em hardware e aumentando a agilidade de entrega do produto, com um maior custo-benefício. Para modelar esta nova concepção e torná-la possível em diversas aplicações foi estudado e proposto um modelo em UML para a automação, que ajudou a definir desde a lógica de hardware até a usabilidade do sistema para o usuário final. Foram avaliadas dentre as estruturas de representação UML quais eram as possíveis notações de maior utilidade para o tema. A partir destas notações levantadas foi determinado um conjunto de artefatos UML direcionados aos sistemas de pequena escala, e uma proposta de metodologia. Foi realizado um levantamento de alguns casos de estudo da automação em pequena escala onde são aplicados sensores, atuadores, controladores, interfaces homem-máquina etc. A partir deste levantamento foi especificada uma planta de automação que simulava uma aplicação real e o SIAPE deveria ser modelado de forma a atender satisfatoriamente os requisitos do usuário. Seguindo a metodologia e modelo UML proposto o SIAPE foi implementado, e foram feitos experimentos de validação do produto para análise dos resultados e eficiência do sistema implementado, comprovando sua viabilidade como produto comercial.

Palavras-Chave: Automação; Open-Source; Android, Arduino; UML; Modelagem.

ABSTRACT

Many of demands for automation are beyond the industrial area where companies from various sectors try to automate simple processes, generating resource savings and facilities in human labor. In this scene exists as major impediment to these new customer profiles the high cost of the automation products, which often provide excessive resources that are not fully utilized in small and dedicated applications. The objective in this work is to implement a Sistema Integrado de Automação em Pequena Escala (SIAPE) [Small Scaled Integrated Automation System] using a framework based on recent and open-source technologies. That reduces implementation effort in hardware and increases the delivery speed of the product, with a bigger cost-benefit. To model this new design and make it possible for various applications an UML model has been studied and proposed for automation, which helped to define the logic from the hardware and system`s usability for the end user. Among several representation structures in UML were evaluated the most useful possible notations for the theme. From these notations was chosen a set of UML artifacts targeted to small-scale systems, and was proposed a methodology. A survey was made with some case studies on small-scale automation where are applied sensors, actuators, controllers, human-machine interfaces etc. From this survey was specified a plant automation that simulated a real application and a SIAPE should be modeled in order to satisfactory the requirements of the user. Following the proposed methodology and the UML model a SIAPE was implemented, and experiments were performed to validate the product analyzing the results and efficiency of the implemented system, proving its viability as a commercial product.

Keywords: Automation; Open-Source; Android; Arduino; UML; Modeling.

LISTA DE FIGURAS

Figura 1 - Estrutura de um SIAPE com IHM Android, Controlador Arduino e Supervisório Desktop .......................................................................................................................... 14

Figura 2 - Exemplo de uma planta em Blocos de Funções ............................................ 18

Figura 3 - Exemplo de uma planta em Diagrama Ladder ............................................... 19

Figura 4: Exemplo de Rede de Petri .............................................................................. 19

Figura 5 - Exemplo do modelo utilizando UML/Statecharts ............................................ 21

Figura 6 - Modelo UML a partir de um projeto de produção ........................................... 22

Figura 7 – Projeto genérico UML na ferramenta Astah .................................................. 25

Figura 8 – Diagrama de concepção ............................................................................... 26

Figura 9 – Casos de uso ................................................................................................ 27

Figura 10 – Requisitos funcionais .................................................................................. 28

Figura 11 – Diagrama de classes ................................................................................... 29

Figura 12 – Diagrama de sequências ............................................................................. 29

Figura 13 – Requisitos não-funcionais ........................................................................... 30

Figura 14 – Monitoramento climático reduz em 42% o uso de agrotóxicos em lavouras de tomate no Rio ............................................................................................................ 32

Figura 15 – Diagrama de concepção do SIAPE ............................................................. 34

Figura 16 – Casos de uso do SIAPE .............................................................................. 35

Figura 17 – Requisitos funcionais do CME..................................................................... 36

Figura 18 – Requisitos funcionais do SCADA ................................................................ 37

Figura 19 – Requisitos funcionais da IHM ...................................................................... 38

Figura 20 – Tabela de requisitos do SIAPE .................................................................... 38

Figura 21 – Diagrama de classes da CME ..................................................................... 40

Figura 22 – Diagrama de classes do SCADA ................................................................. 41

Figura 23 – Diagrama de classes da IHM ...................................................................... 42

Figura 24 – Diagrama de sequências do SIAPE ............................................................ 43

Figura 25 – Casos de teste CME ................................................................................... 44

Figura 26 – Requisitos não-funcionais do SIAPE ........................................................... 45

Figura 27 – Implementação do CME .............................................................................. 46

Figura 28 – Implementação do SCADA ......................................................................... 48

Figura 29 – Implementação da IHM ............................................................................... 49

LISTA DE TABELAS

Tabela 1 - Crescimento percentual no faturamento do ramo Eletroeletrônico................ 13

Tabela 2 - Testes do CME .............................................................................................. 49

Tabela 3 - Testes do SCADA ......................................................................................... 51

Tabela 4 – Testes da IHM .............................................................................................. 53

Tabela 5 - Comparativo de gastos no projeto ................................................................. 55

Tabela 6 – Periféricos da placa de sensores.................................................................. 47

LISTA DE SIGLAS

ABNT Associação Brasileira de Normas Técnicas

CLP/PLC Controlador Lógico Programável/Programmable Logic Controller

CME Central de Medição Eletrônica

FBD Function Blocks Diagram

GPS Global Positioning System

IEC International Electro-Technical Comission

IHM Interface Homem-Máquina

LD Ladder Diagram

NEMA National Electrical Manufacturers Association RF Requisito Funcional

RNF Requisito Não-Funcional

SCADA Supervisory Control and Data Acquisition

SEBRAE Serviço Brasileiro de Apoio às Micro e Pequenas Empresas

SIAPE Sistema Integrado de Automação em Pequena Escala

UML Unified Modeling Language

SUMÁRIO

1. INTRODUÇÃO......................................................................................................... 13

1.1 Justificativa .............................................................................................................. 14

1.2 Objetivos .................................................................................................................. 15

1.2.1 Objetivo Geral ................................................................................................... 15

1.2.2 Objetivos Específicos ........................................................................................ 15

2. REVISÃO DE LITERATURA ................................................................................... 16

2.1 Arquitetura de um Sistema de Automação .............................................................. 16

2.2 Automação em Pequena Escala ............................................................................. 17

2.3 Modelos para Sistemas Industriais .......................................................................... 17

2.3.1 Blocos de Funções ............................................................................................ 18

2.3.2 Diagramas Ladder ............................................................................................. 18

2.3.3 Redes de Petri .................................................................................................. 19

2.4 Modelagem UML ..................................................................................................... 20

2.5 Modelos UML para Automação e Sistemas Embarcados ........................................ 20

3. METODOLOGIA ...................................................................................................... 23

3.1 Etapas de Desenvolvimento .................................................................................... 24

3.1.1 Etapa A: Análise ................................................................................................ 24

3.1.2 Etapa B: Design ................................................................................................ 24

3.1.3 Etapa C: Testes e Otimização ........................................................................... 24

3.2 Modelo UML Proposto ............................................................................................. 25

3.2.1 Diagrama de Concepção ................................................................................... 25

3.2.2 Casos de Uso .................................................................................................... 26

3.2.3 Requisitos Funcionais ....................................................................................... 27

3.2.4 Diagrama de Classes ........................................................................................ 28

3.2.5 Diagrama de Sequências .................................................................................. 29

3.2.6 Requisitos Não-Funcionais ............................................................................... 30

4. DESENVOLVIMENTO DO PROTÓTIPO ................................................................ 31

4.1 Caso de Estudo – Monitoramento Climático ............................................................ 31

4.2 Aplicação ................................................................................................................. 32

4.3 Metodologia UML Aplicada ...................................................................................... 33

4.3.1 Etapa A: Análise do SIAPE ............................................................................... 33

4.3.2 Etapa B: Design do SIAPE ................................................................................ 39

4.3.3 Etapa C: Testes e Otimização do SIAPE .......................................................... 43

4.4 Produto Final ........................................................................................................... 46

5. EXPERIMENTOS E ANÁLISE DOS RESULTADOS ............................................... 49

6. CONCLUSÃO .......................................................................................................... 55

REFERÊNCIAS BIBLIOGRÁFICAS ............................................................................... 56

13

1. INTRODUÇÃO

No mercado atual vem se constatando um crescimento cada vez maior das empresas que atuam na área de automação, é apresentado na Tabela 1 um crescimento significativo no faturamento brasileiro sobretudo das empresas de Equipamentos Industriais e Automação Industrial segundo ABINEE (2012). É possível observar que atualmente surgem demandas para automação que estão além da área industrial, áreas tais como a doméstica, hospitalar ou comercial, onde se procura automatizar processos simples gerando economia de recursos e maiores facilidades no trabalho humano. Dentro deste cenário existe como grande empecilho para estes novos perfis de clientes o custo relativamente elevado dos produtos prontos de automação, que muitas vezes oferecem recursos excessivos que não são totalmente aproveitados em pequenas aplicações (CLPs expansivos, supervisórios avançados, IHMs complexas etc). Outro aspecto relevante nesta nova demanda é o tempo de desenvolvimento: muitas vezes algo que a princípio seria um processo simples se torna um desenvolvimento complexo e longo, pois o sistema implementado não foi devidamente modelado nem dimensionado para atender os reais requisitos do cliente.

Tabela 1 - Crescimento percentual no faturamento do ramo Eletroeletrônico

Fonte: ABINEE (2012)

A abertura comercial no mundo vem permitindo o acesso a diversos gadgets1 e equipamentos eletrônicos que muitas vezes têm um custo mais vantajoso do que uma confecção própria, ou permite uma redução crucial no tempo de desenvolvimento. Outro aspecto do mundo globalizado que começa a afetar o mercado da engenharia

1 O Dicionário Houaiss da Língua Portuguesa (2001) consigna a palavra, pode ser utilizada para descrever equipamentos eletrônicos populares.

14

está na facilidade do acesso à informação, onde iniciativas Open-Source e ferramentas de busca disseminam facilmente conhecimentos que por muito tempo foram restritos a especialistas. Exemplo disto está em iniciativas como Android2 e Arduino3, onde as pessoas conseguem trocar informações e disponibilizar códigos prontos criando uma grande fonte de desenvolvimento na Internet.

Neste trabalho será implementado o SIAPE – Sistema Integrado de Automação em Pequena Escala, um framework para automação que usufrui destas novas tecnologias disponíveis no mercado como placas Arduino, tablets e smart-phones (ver Figura 1), visando um custo mais acessível e uma interface mais próxima do que o usuário está acostumado em seu cotidiano. Para projetar e customizar este framework será também proposta uma modelagem em UML direcionada à automação e sistemas embarcados, que permitirá descrever uma planta nos aspectos de hardware, software e processos.

Figura 1 - Estrutura de um SIAPE com IHM Android, Controlador Arduino e Supervisório Desktop

Fonte: Elaborada pelo autor

1.1 Justificativa

Este trabalho apresenta um novo produto que poderá atender vários nichos industriais, comerciais ou até mesmo domésticos. O modelo UML proposto descreve um processo de automação de uma forma complementar aos usuais diagramas elétricos (blocos de funções, ladder, petri etc.), incorporando análises funcionais ao sistema que estão além das suas características eletrônicas. Os diagramas UML do sistema permitem projetar um conjunto de hardware que atende à aplicação e ainda adotar algumas análises da engenharia de software no design das interfaces e usabilidade do sistema como um todo, de acordo com THRAMBOULIDIS (2004). Através desta modelagem o SIAPE se torna um produto customizável, robusto e com desenvolvimento ágil, atendendo os principais diferenciais no mercado competitivo da automação.

2 Sistema Operacional de desenvolvimento livre para dispositivos móveis, baseado em Java. 3 Plataforma Open-Source para criação de protótipos com documentação e códigos abertos.

15 O modelo apresentado nesta proposta se aplica aos setores onde a automação

não é o primordial, mas existe uma demanda que pode ser lucrativa desde que a solução proposta seja bem modelada para atender especificamente as necessidades do cliente, sobretudo no que diz respeito à proporção de recursos e usabilidade. Ao lidar com automação em setores diversos é preciso considerar outros aspectos que transcendem esquemas elétricos, como uma interface específica para determinado perfil de usuários, mobilidade e portabilidade dos equipamentos ou até mesmo regras de negócios para aplicações comerciais.

1.2 Objetivos

Esta seção descreve os objetivos gerais e específicos da proposta de trabalho.

1.2.1 Objetivo Geral

O objetivo deste trabalho é implementar a arquitetura de um SIAPE - Sistema Integrado de Automação em Pequena Escala, um framework simplificado e genérico que poderá ser aplicado a diversos processos de automação, exigindo menos tempo com a implementação e cedendo mais tempo para questões como a usabilidade, customização e ergonomia do sistema, que geralmente são pouco relevadas em um projeto usual.

Para modelar esta nova concepção e torná-la possível em diversas aplicações será estudado e proposto um modelo em UML para a automação, que ajudará a definir desde a lógica de hardware até a usabilidade do sistema.

1.2.2 Objetivos Específicos

Os objetivos específicos deste trabalho são:

• Desenvolver um modelo que descreva as ferramentas UML necessárias para analisar e estruturar o SIAPE. • Projetar a arquitetura de hardware e software do SIAPE a partir do modelo UML proposto. • Implementar um SIAPE considerando uma planta protótipo que simulará uma aplicação real.

16

2. REVISÃO DE LITERATURA

Esta sessão aborda os principais conceitos e trabalhos relacionados de modo a fundamentar a implementação do SIAPE desde sua modelagem. Na seção 2.1 são abordados os conceitos da arquitetura de um sistema de automação, descrevendo a função de um CLP, IHM e SCADA. Já a seção 2.2 é apresenta o conceito de automação em pequena escala exemplificando algumas aplicações relacionadas. A seção 2.3 aborda os principais modelos utilizados na modelagem de sistemas de automação descrevendo Diagramas Ladder, Blocos de Funções e Redes de Petri. A seção 2.4 apresenta o conceito da modelagem UML como um todo, citando as fases de desenvolvimento utilizadas na engenharia de software. Por fim, na seção 2.5 serão apresentados os principais trabalhos relacionados ao uso de UML na área de automação.

2.1 Arquitetura de um Sistema de Automação

Para estudar a arquitetura de sistemas de automação de forma sistemática é utilizado o recurso de dividir a mesma em níveis, conforme RIBEIRO (2003):

• Nível 0: É o nível de aquisição e atuação diretamente no processo. Neste nível estão os elementos sensores e atuadores como sensores de nível, pressão, temperatura, fins de curso, relés, válvulas, inversores de frequência, multi-medidores de grandezas elétricas etc.

• Nível 1: Neste nível estão os Controladores Programáveis recebendo informações do nível 0.

• Nível 2: Considera-se como nível 2 as estações de controle que permitem configurar o sistema, através das Interfaces Homem-Máquina (IHM).

• Nível 3: Por fim o nível 3 consiste nas estações de supervisão e gestão que são computadores executando softwares de supervisão que se comunicam com os controladores através de redes de comunicação industriais.

O Controlador Lógico Programável, segundo a ABNT 4 , é um equipamento eletrônico digital com hardware e software compatíveis com aplicações industriais. Ainda segundo a NEMA (National Electrical Manufacturers Association), é um aparelho eletrônico digital que utiliza uma memória programável para armazenar internamente instruções e para implementar funções específicas, tais como lógica, sequenciamento,

4 Associação Brasileira de Normas Técnicas.

17

temporização, contagem e aritmética, controlando, por meio de módulos de entradas e saídas, vários tipos de máquinas ou processos.

A IHM é um hardware industrial composto normalmente por uma tela de cristal líquido e um conjunto de teclas para navegação ou inserção de dados que se utiliza de um software proprietário para a sua programação, segundo RIBEIRO e SILVESTRE (2010).

O autor ainda definem os sistemas supervisórios, ou SCADA, como monitores que rastreiam informações de um processo produtivo ou instalação física. Tais informações são coletadas através de equipamentos de aquisição de dados e, em seguida, manipuladas, analisadas, armazenadas e posteriormente, apresentadas ao usuário.

2.2 Automação em Pequena Escala

O termo Automação segundo o dicionário Houaiss significa:

"Sistema em que os processos operacionais em fábricas, estabelecimentos comerciais, hospitais, residências etc. são controlados e executados por meio de dispositivos mecânicos ou eletrônicos, substituindo o trabalho humano; automatização."

Desta forma a automação em pequena escala envolve sistemas normalmente utilizados na automação doméstica, comercial (vendas, controle de estoques, cadastro de clientes, consultas em bases de dados etc.) ou até mesmo na indústria em processos mais simples ou dedicados. Segundo o SEBRAE (2009) com o uso de processos mecânicos e computadorizados nestes nichos é possível atingir taxas de eficiência mais altas - o que resulta em registros de maior qualidade - com menores taxas de erro - além de diminuir o tempo dessas tarefas.

Com os avanços obtidos com a automação comercial é que foi possível conceber ideias como grandes redes de lojas, supermercados, fast-foods, locadoras e muitos outros comércios largamente espalhados pelo planeta.

2.3 Modelos para Sistemas Industriais

Devido à necessidade de um padrão para CLPs por parte da comunidade industrial internacional, em 1979, foi designado um grupo de trabalho com o IEC (International Electro-technical Comission) voltado para o propósito de regulamentar a IEC1131-3 (1993), que originaram entre diversas linguagens o Diagrama Ladder (LD) e o Diagrama de Blocos de Funções (FBD).

18 Com a diversidade de fabricantes de equipamentos industriais surgiu também

diversas formas de modelar sistemas, normalmente focados na estrutura lógica de programação de um CLP. Nesta pesquisa serão consideradas as três formas de representação mais significativas ao tema proposto: Diagramas de Blocos de Funções, Diagramas Ladder e Redes de Petri. As Redes de Petri foram criadas a partir tese de doutorado de Carl Adam Petri, intitulada Kommunication mit Automaten (Comunicação com Autômatos), apresentada à Universidade de Bonn em 1962.

2.3.1 Blocos de Funções

Segundo RIBEIRO (2003), Blocos de Funções são equivalentes a circuitos integrados representando uma função de controle especializada. Como um CI ou uma caixa preta, eles possuem uma interface bem definida, permitindo separar bem os níveis de programação e manutenção conforme exemplificado na Figura 2.

Figura 2 - Exemplo de uma planta em Blocos de Funções

Fonte: RIBEIRO (2003)

2.3.2 Diagramas Ladder

A linguagem Ladder, ou diagrama de escada, é um auxílio gráfico para programação de Controladores Lógicos Programáveis (CLPs) no qual as funções lógicas são representadas através de contatos e bobinas, de modo análogo a um esquema elétrico com os contatos dos transdutores e atuadores. Segundo ZANCAN (2011), existem 3 tipos de elementos na linguagem Ladder:

• Entradas (ou contatos), que podem ler o valor de uma variável booleana; • Saídas (ou bobinas) que podem escrever o valor de uma variável booleana; • Blocos funcionais que permitem realizar funções avançadas.

19

Figura 3 - Exemplo de uma planta em Diagrama Ladder

Fonte: ZANCAN (2011)

2.3.3 Redes de Petri

Uma rede de Petri ou rede de transição é uma das várias representações matemáticas para sistemas distribuídos discretos. MARRANGHELLO (2005) a define como uma linguagem de modelagem, ela define graficamente a estrutura de um sistema distribuído como um grafo direcionado com comentários. Possui nós de posição, nós de transição, e arcos direcionados conectando posições com transições. A qualquer momento durante a execução de uma rede de Petri cada posição pode armazenar um ou mais tokens. Diferente de sistemas mais tradicionais de processamento de dados, que podem processar somente um único fluxo de tokens entrantes, as transições de redes de Petri podem consumir e mostrar tokens de múltiplos lugares. Uma transição só pode agir nos tokens se o número requisitado de tokens aparecer em cada posição de entrada.

Transições agem em tokens de entrada por um processo denominado disparo. Quando uma transição é disparada, ela consome os tokens de suas posições de entrada, realiza alguma tarefa de processamento, e realoca um número específico de tokens nas suas posições de saída. Isso é feito atomicamente. Como disparos são não determinísticos, redes de Petri são muito utilizadas para modelar comportamento concorrente em sistemas distribuídos.

Figura 4: Exemplo de Rede de Petri

Fonte: MARRANGHELLO (2005)

20

2.4 Modelagem UML

A Unified Modeling Language (UML) é uma linguagem de modelagem não proprietária de terceira geração, segundo FOWLER (2004). A UML não é uma metodologia de desenvolvimento, o que significa que ela não diz para você o que fazer primeiro e em seguida ou como projetar seu sistema, mas ela lhe auxilia a visualizar seu desenho e a comunicação entre objetos. Basicamente, a UML permite que desenvolvedores visualizem os produtos de seus trabalhos em diagramas padronizados. Junto com uma notação gráfica, a UML também especifica significados, isto é, semântica.

De acordo com STADZISZ (2002) existem cinco fases no desenvolvimento de sistemas de software: análise de requisitos, análise, design (projeto), implementação e testes. Estas cinco fases não são executadas na ordem descrita acima, mas concomitantemente de forma que problemas detectados numa certa fase modifiquem e melhorem as fases desenvolvidas anteriormente de forma que o resultado global gere um produto de alta qualidade e desempenho. Para que esta mesma modelagem seja utilizada em um sistema de automação alguns conceitos precisam ser adaptados ou ignorados, direcionando a modelagem para o escopo do hardware.

2.5 Modelos UML para Automação e Sistemas Embarcados

Normalmente os sistemas de automação são representados como blocos de funções que descrevem as etapas e processos de uma planta. Esta notação proposta pelo IEC1131-3 (1993) para a engenharia permite descrever as características de um sistema modular reutilizável, e segundo VOGEL-HEUSER, BRAUN, et al. (2011) pode ser assemelhado ao paradigma da Orientação a Objetos na engenharia de software onde:

• Cada etapa do processo representada por um bloco poderia ser modelada como um objeto de uma classe composta de atributos e métodos.

• Os atributos de cada bloco são as características físicas ou lógicas do hardware, que descrevem os equipamentos utilizados no sistema.

• Os métodos são definidos pelas funções e operações que cada equipamento desempenha no processo.

• O fluxo de execução do processo e as linhas de conexão entre os equipamentos representam a dinâmica existente entre os objetos, quais são suas relações e comportamento no sistema.

21 Se uma planta de automação pode ser analisada como um modelo orientado a

objetos que possui visões estáticas e dinâmicas, seus processos podem ser modelados com UML ainda de acordo com PATARICZA, ROMÁN, et al. (2001).

Grande parte das aplicações industriais exige um software para PLC que seja de alta confiança, e alguns desenvolvedores como YOUNIS e FREY (2006) adotaram o UML para ajudar a modelar e testar esses softwares. MOURA, COUTO e GUEDES (2009) desenvolveram um trabalho que apresenta uma técnica para modelagem e validação do software de controle para aplicações industriais que envolvem operações sequenciais e paralelas, um exemplo típico da área de manufatura é discutido como estudo de caso para ilustrar a ideia. A proposta utiliza o formalismo Statechart5 (ver Figura 5) para representar, analisar e validar os modelos quanto à reiniciabilidade, vivacidade e deadlocks. Um procedimento para traduzir o modelo do controlador para código Ladder também foi discutido com o objetivo de realizar testes e analisar os resultados em aplicações reais.

Figura 5 - Exemplo do modelo utilizando UML/Statecharts

Fonte: MOURA, COUTO e GUEDES (2009)

Outra aplicação encontrada para o UML é no projeto de sistemas embarcados, o trabalho de FERNANDES, MACHADO e SANTOS (2001) mostra a aplicação em uma modelagem baseada nas redes de Petri. O caso de estudo foi baseado na empresa Blaupunkt Auto-Rádios Portugal (Bosch Group), uma companhia europeia que produz rádios para a indústria automobilística. Os responsáveis desta empresa desenvolveram um projeto com o intuito de aprimorar seus processos de produção, baseado nas seguintes metas:

• Fase 1: Modelar o sistema de controle a partir do fluxo de materiais nas linhas de produção.

• Fase 2: Modelar a implementação deste controle.

5 Diagrama baseado em máquina de estados para descrever comportamento de sistemas.

22

• Fase 3: Diagnosticar disparidades entre o sistema requisitado e o de fato implementado, adicionando otimizações no processo.

• Fase 4: Criar o protótipo do sistema otimizado utilizando dispositivos re-configuráveis e softwares customizados.

O autor emprega o UML nas duas primeiras fases (especificação e implementação) que antes eram feitas com redes de Petri, e a partir do projeto de produção da empresa criou o modelo da Figura 6 que permite validar todo o processo.

Figura 6 - Modelo UML a partir de um projeto de produção

Fonte: FERNANDES, MACHADO e SANTOS (2001)

23

3. METODOLOGIA

A primeira etapa do trabalho consistiu na criação de um modelo UML voltado à automação por meio de:

• Pesquisa bibliográfica: Foi realizado um levantamento bibliográfico sobre o tema UML abordado na automação através de consultas em periódicos, livros e artigos em congressos, tanto em fontes nacionais quanto internacionais. Também foram relacionados os principais aspectos de outras representações empregadas na automação para agregar no modelo UML proposto.

• Pesquisa exploratória: Foram avaliadas dentre as estruturas de representação UML quais eram as possíveis notações de maior utilidade para o tema. A partir destas notações levantadas foi determinado um conjunto de artefatos UML direcionados aos sistemas de automação, e uma proposta de metodologia.

A segunda etapa consistiu na implementação do SIAPE utilizando a modelagem proposta aplicada a um caso de estudo por meio de:

• Pesquisa descritiva: Foi realizado um levantamento de alguns casos de estudo da automação em pequena escala onde são aplicados sensores, atuadores, controladores, supervisórios, interfaces homem-máquina etc. A partir deste levantamento foi especificada uma planta de automação que simula uma aplicação real onde deveria ser modelado um SIAPE – Sistema Integrado de Automação em Pequena Escala.

• Desenvolvimento do protótipo: Teve como objetivo sistematizar e estruturar o SIAPE utilizando as técnicas de modelagem UML desenvolvidas. Considerando a planta de automação especificada na pesquisa descritiva, o sistema pode ser implementado e simulado para análise dos resultados e eficiência do produto obtido.

24

3.1 Etapas de Desenvolvimento

A metodologia UML proposta foi baseada em 3 fases que são abordadas de forma iterativa e incremental, exemplificando um processo espiral de desenvolvimento segundo NUNES e O'NEILL (2003). Desta forma cada etapa deve ser aplicada de acordo com os progressos do projeto, com o objetivo de enriquecer e detalhar cada vez mais os modelos UML e documentações do sistema a partir de retornos do cliente.

3.1.1 Etapa A: Análise

Nesta etapa foram levantadas todas as informações relevantes ao processo como os principais casos de uso, os agentes (atores), os requisitos funcionais e o diagrama de concepção do projeto. Além de um texto descritivo de cada entidade do sistema foram feitos diagramas para os casos de uso que mostram o que os atores externos, ou seja, os usuários do futuro sistema, deverão esperar da aplicação, conhecendo toda sua funcionalidade sem importar como será implementada. Os artefatos UML utilizados foram: Diagrama de Concepção, Diagrama de Casos de Uso, Diagrama de Requisitos e Tabela de Requisitos.

3.1.2 Etapa B: Design

A fase de Design definiu as abstrações que estarão presentes no domínio do problema. As classes foram modeladas e ligadas através de relacionamentos com outras classes, e foram descritas nos Diagramas de Classe. As colaborações entre classes também foram criadas em um diagrama dinâmico em UML para representar o fluxo de mensagens entre seus componentes. As classes fornecem todas as especificações funcionais de cada etapa do sistema, e junto com os diagramas de requisitos permitiram definir um conjunto de hardware que atendesse a aplicação. O Design resultou no detalhamento das especificações para a fase de implementação do sistema, e os artefatos UML acrescentados foram: Diagrama de Classes e Diagrama de Mensagens.

3.1.3 Etapa C: Testes e Otimização

Nesta fase foram elaborados os testes da aplicação para validar a etapa desenvolvida, sendo levantadas as melhorias e otimizações para as etapas seguintes.

25

Descrevendo requisitos não-funcionais foram propostas melhorias no sistema focando o desempenho, a usabilidade e a simplificação das interfaces para o usuário final.

3.2 Modelo UML Proposto

Para familiarizar com as ferramentas gráficas do UML 2.0 foi elaborado um modelo para os artefatos utilizados em cada fase de desenvolvimento utilizando a plataforma Astah Professional6. Um projeto genérico foi exemplificado de forma sucinta conforme a estrutura da Figura 7.

Figura 7 – Projeto genérico UML na ferramenta Astah

Fonte: Elaborada pelo autor utilizando a ferramenta Astah Professional

3.2.1 Diagrama de Concepção

A etapa da Análise teve como início o Diagrama de Concepção, que é uma representação visual do projeto como um todo e formaliza as intenções do cliente de forma objetiva conforme a Figura 8.

6 Astah é uma ferramenta de modelagem UML criada pela empresa japonesa CHANGE VISION (2013).

26

Figura 8 – Diagrama de concepção


O objetivo deste artefato foi destacar as principais funções do sistema dividindo-o em módulos e hierarquias, formalizando o brainstorm inicial do projeto através de um diagrama.

3.2.2 Casos de Uso

Os casos de uso foram utilizados para representar os comportamentos que cada sub-sistema deveriam atender de acordo as ações efetuadas pelos usuários, sendo utilizada para descobrir e registrar os requisitos funcionais do sistema como um todo. Desta forma cada caso de uso representa uma unidade discreta de interação entre determinado ator (usuário ou máquina) e o sistema a ser implementado, exemplificado pela Figura 9.

27

Figura 9 – Casos de uso

Fonte: Elaborada pelo autor utilizando a ferramento Astah Professional

3.2.3 Requisitos Funcionais

Os Requisitos Funcionais definiram funções específicas de cada sub-sistema ou seus componentes. Foram representados em um diagrama que resulta em uma Tabela de Requisitos (Figura 10) contendo comportamentos, detalhes técnicos, manipulações de dados e respostas que permitem especificar a arquitetura que atende às necessidades da aplicação.

28

Figura 10 – Requisitos funcionais


Baseado nas regras de negócio e funcionalidades levantadas foi possível dimensionar e mensurar a arquitetura no ponto de vista do hardware, gerando a Lista de Componentes e materiais que foram utilizados nos diagramas elétricos do projeto (Anexo A).

3.2.4 Diagrama de Classes

O Diagrama de Classes é a representação da estrutura e relações entre os módulos do sistema, que são instanciados como objetos. Componentes do hardware foram modelados a partir de seus atributos (propriedades) e operações, conforme exemplifica a Figura 11.

29

Figura 11 – Diagrama de classes


Este modelo é flexível à programação de cada módulo do sistema, podendo representar classes que se adequam ao tipo de controle envolvido e sua linguagem que pode ser um software, firmware, batch, Ladder, script etc.

3.2.5 Diagrama de Sequências

Para representar a troca de mensagens e iteração entre os módulos do sistema foi utilizado o Diagrama de Sequências, exemplificado pela Figura 12.

Figura 12 – Diagrama de sequências


30 O objetivo deste diagrama foi representar comportamentos dinâmicos do sistema,

que envolve sequências de requisições e respostas por exemplo.

3.2.6 Requisitos Não-Funcionais

Os Requisitos Não-Funcionais foram utilizados para representar as necessidades da aplicação em termos de desempenho, usabilidade, confiabilidade, segurança, disponibilidade, manutenção e tecnologias envolvidas. Além de avaliar o desempenho e otimização do sistema, outro objetivo desta etapa foi considerar a ergonomia para o usuário final que pode ser leigo à automação, e pode rejeitar um produto devido a sua complexidade que demandaria treinamentos (por exemplo). A Figura 13 exemplifica o diagrama e sua respectiva Tabela de Requisitos Não Funcionais.

Figura 13 – Requisitos não-funcionais


31

4. DESENVOLVIMENTO DO PROTÓTIPO

Para validar e analisar a modelagem UML proposta foi desenvolvido um produto SIAPE que atendia uma aplicação básica de automação, e exige um sistema com os 3 principais módulos: Controle, Interface Homem-Máquina e Supervisório. Analisando possíveis demandas de mercado nacional foi escolhido um Caso de Estudo que será descrito a seguir, e a partir de sua aplicação foi empregada a metodologia proposta na execução do projeto que resultou no produto final.

4.1 Caso de Estudo – Monitoramento Climático

Técnicas recentes de monitoramento climático têm se mostrado de grande utilidade não apenas em laboratórios e ambientes controlados, mas também em campos abertos como plantações, pastos e reservas naturais. Na agricultura muitos gastos podem ser evitados conciliando-se as técnicas de rega com informações do clima, e a cultivação em rodízio pode ser otimizada analisando as médias climáticas da região no decorrer do ano. Outra grande vantagem está na redução do uso de agrotóxicos, principalmente no Brasil que é o maior utilizador destas substâncias e ocorre inúmeros casos de intoxicações em operários devido ao uso abusivo segundo a EMPRESA BRASIL DE COMUNICAÇÃO (2013). Analisando fatores como temperaturas máximas, mínimas, umidade e pressão do ar é possível estabelecer os períodos corretos e suficientes para aplicação de agrotóxicos, evitando por exemplo o uso excessivo em épocas chuvosas onde a maior parte das substâncias vai para o solo poluindo lençóis freáticos e reduzindo a proteção dos vegetais, conforme Figura 14.

32 Figura 14 – Monitoramento climático reduz em 42% o uso de agrotóxicos em

lavouras de tomate no Rio

Fonte: EMPRESA BRASIL DE COMUNICAÇÃO (2013)

4.2 Aplicação A aplicação implementada se trata de uma estação que registra diversos

sensores em um ambiente de clima monitorado. Esta estação deveria conter diversos dispositivos como sensores de temperatura, pressão, umidade, GPS, além de uma interface para monitoramento e exportação das informações. Estas informações deviam ser armazenadas permitindo análises futuras de médias e gráficos, possuindo uma interface de tempo real que exibe as informações atuais dos sensores.

A Central de Medição Eletrônica deveria ser micro-controlada e exerceria as seguintes funções:

• Com um dispositivo GPS registrar os dados em função da localidade e data\hora obtida.

• Armazenar os dados em um cartão de memória SD. • Enviar as medições acumuladas e em tempo real para um software supervisório comunicando via TCP-IP.

• Exibir as informações de tempo real em uma Interface Homem-Máquina.

33

• Monitorar os seguintes sensores através de entradas analógicas\digitais: temperatura, umidade e pressão atmosférica.

O software supervisório SCADA deveria exercer as seguintes funções:

• Receber os dados coletados via TCP-IP ou pen-drive.

• Exibir para cada sensor uma tabela e gráfico dos registros coletados informando a data e a hora.

• Oferecer um plug-in do Google Maps para informar ao usuário a localização do dispositivo de coleta via GPS.

• Permitir exportar os dados em outros formatos como texto ou Excel.

Por fim a Interface Homem-Màquina teria as seguintes funcionalidades:

• Receber os últimos dados coletados em tempo real via TCP-IP.

• Exibir em medidores gráficos as grandezas medidas (temperatura, pressão, umidade).

• Exibir a Data, Hora e Local da última medição fornecidos pelo GPS.

4.3 Metodologia UML Aplicada

Nesta sessão é apresentada as etapas da metodologia proposta que foram aplicadas no desenvolvimento do projeto assim como os artefatos UML gerados.

4.3.1 Etapa A: Análise do SIAPE

Considerando as especificações descritas na sessão 4.2 foi gerado o Diagrama de Concepção da Figura 15.

34

Figura 15 – Diagrama de concepção do SIAPE


Este diagrama representa o sistema de forma global e sucinta, expondo de forma visual as intenções finais do cliente com o sistema proposto. A partir dele foi possível levantar os principais casos de uso que o sistema deveria atender, gerando o Diagrama de Casos de Uso da Figura 16.

35

Figura 16 – Casos de uso do SIAPE


Com os Casos de Uso definidos foi possível levantar os Requisitos Funcionais de cada sub-sistema, que serviram como base para especificar o hardware necessário para atender a aplicação. Na Figura 17 foram modelados os requisitos da Central de Medição Eletrônica, especificando o tipo de controle, interfaces, entradas e saídas necessárias para integração no sistema.

36

Figura 17 – Requisitos funcionais do CME


De forma análoga foi modelado o supervisório SCADA na Figura 18, que possui

requisitos mais lógicos (software) do que físicos (hardware).

37

Figura 18 – Requisitos funcionais do SCADA


O último módulo do sistema consistia na Interface Homem-Máquina (IHM) exibida na Figura 19.

38

Figura 19 – Requisitos funcionais da IHM


Por fim a ferramenta permitiu que fosse gerada uma Tabela de Requisitos a partir de todos os diagramas elaborados, e que pôde ser utilizado como roteiro de desenvolvimento e testes conforme Figura 20.

Figura 20 – Tabela de requisitos do SIAPE


39 A partir dos Requisitos levantados foi definida a seguinte configuração de

componentes para o sistema:

• Central de Medição Eletrônica (CME): Foi utilizada uma placa Arduino-Uno devido ao baixo custo de mercado e agilidade de desenvolvimento, pois na Internet é disponibilizado bibliotecas e exemplos de código para utilização dos principais periféricos do sistema.

• Supervisório SCADA: Foi desenvolvido um aplicativo desktop para a plataforma Windows devido à sua popularidade e simplicidade de desenvolvimento, com interface comercial semelhante à aplicativos de escritório utilizando o framework C#.NET.

• Interface Homem-Máquina (IHM): Foi desenvolvido um aplicativo móvel para a plataforma Android que é uma iniciativa gratuita com grande suporte de desenvolvimento na web. Esta plataforma permite que a IHM seja executada em tablets e smart-phones de menor custo, com uma interface semelhante ao que os usuários estão habituados em seu cotidiano.

4.3.2 Etapa B: Design do SIAPE

A fase de desenvolvimento teve início com a confecção dos diagramas eletrônicos do hardware envolvido, e após confeccionar a montagem foi possível modelar a lógica de funcionamento de cada módulo do sistema. Nesta etapa foram utilizados os Diagramas de Classe para modelar a estrutura do firmware programado no micro-controlador Arduino conforme Figura 21.

40

Figura 21 – Diagrama de classes da CME


Para o Supervisório SCADA o diagrama representou as classes modeladas para o framework Windows Forms C#.NET, conforme a Figura 22.

41

Figura 22 – Diagrama de classes do SCADA


As classes da IHM foram baseadas no modelo Java Android e são exibidas na Figura 23. Apesar da simplicidade do aplicativo desenvolvido, sua documentação ficou relativamente grande por ter considerado muitos objetos gráficos de baixo nível utilizados para gerar uma interface customizada.

42

Figura 23 – Diagrama de classes da IHM


43

Outro artefato desenvolvido nesta etapa foi o Diagrama de Mensagens, que representa a comunicação TCP-IP entre os módulos do sistema e são descritos na Figura 24.

Figura 24 – Diagrama de sequências do SIAPE


4.3.3 Etapa C: Testes e Otimização do SIAPE

As etapas finais visam garantir a qualidade da solução proposta assim como a satisfação do cliente, e utilizam como artefatos UML os Casos de Teste e Requisitos Não-Funcionais. Os Casos de Teste foram gerados a partir dos requisitos funcionais que permitiram validar o funcionamento correto do sistema conforme a Figura 25.

44

Figura 25 – Casos de teste CME


Com a conclusão dos testes e validação do sistema implementado foi efetuada a análise de otimização através de um Diagrama de Requisitos Não-Funcionais, que gera uma nova Tabela de Requisitos conforme a Figura 26.

45

Figura 26 – Requisitos não-funcionais do SIAPE


46

4.4 Produto Final

Nesta seção será demonstrada apenas o produto implementado com suas principais características, sendo disponibilizados no Anexo I as documentações técnicas e especificações elaboradas.

• Central de Medição Eletrônica (CME):

Conforme a Figura 27, foi utilizada uma placa Arduino Uno que é baseada no processador ATmega328, possui 14 pinos de i\o, 6 entradas analógicas, conector USB e fonte externa de 12V. Para comunicação foi utilizado o Ethernet Shield Arduino baseado no controlador W5100 que possui velocidade de 10/100Mb, e foi confeccionada em placa padrão um shield de sensores que possui os periféricos listados na Tabela 6.

Figura 27 – Implementação do CME


47

Tabela 2 – Periféricos da placa de sensores Imagem Componente Função Características

DHT11

Sensor de Temperatura e Umidade

Mede uma faixa de 0 a 50C de temperatura e detecta de 20 a 90% de umidade relativa do ambiente, pode ser alimentado entre 3 e 5.5V.

MPX5010

Sensor de Pressão

Pode ser utilizado para medir pressões atmosféricas, hidráulicas, níveis de líquidos entre várias aplicações, funciona com 5V e possui saídas analógicas ou diferenciais.

ME1000-RW

Módulo GPS

Módulo GPS completo com bateria, antena e interface de comunicação serial pronto para comunicar com o Arduino, além de informações de latitude e longitude também informa: data, hora, variações de campo magnético, inclinações, velocidades e acelerações.


48

• Supervisório SCADA:

Foi utilizado um pacote de interfaces gráficas RadControls 7 para criar um aplicativo desktop moderno, leve e de fácil implementação conforme a Figura 28.

Figura 28 – Implementação do SCADA


• Interface Homem-Máquina (IHM):

Foi utilizado um tablet de 10” com sistema operacional Android conforme a Figura 29.

7 Framework de User Interface para C#.Net disponibilizado pela empresa Telerik.

49

Figura 29 – Implementação da IHM


5. EXPERIMENTOS E ANÁLISE DOS RESULTADOS

Os experimentos realizados basicamente consistiram em validar o funcionamento do sistema de acordo com os Casos de Testes elaborados anteriormente. Os resultados foram satisfatórios e atenderam todos os requisitos (funcionais e não-funcionais) do sistema, testados pontualmente após a implementação. Os roteiros de teste foram executados para cada módulo do sistema, e as respostas verificadas são mostradas nas Tabelas 2, 3 e 4.

Tabela 3 - Testes do CME

Caso de Teste Requisito Descrição Resultado mcu01.a RF: MCU Energização A energização é

sinalizada pelo acionamento dos leds no Arduino.

mcu01.b RF: MCU Dados do sensor de pressão

Os dados coletados foram consistentes com os fornecidos pelo portal ClimaTempo.

mcu01.c RF: MCU Dados do sensor de umidade

Os dados coletados foram consistentes com

50

os fornecidos pelo portal ClimaTempo.

mcu01.d RF: MCU Dados do sensor de temperatura

Os dados coletados foram consistentes com os fornecidos pelo portal ClimaTempo.

mcu01.e RF: MCU Re-Inicialização O Arduino registra no SD-Card quando é re-inicializado

mcu01.f RF: MCU Dados do GPS Os dados de data e hora do GPS foram precisos, porém a localização apresenta um desvio médio de 1km de raio.

mcu01.g RF: MCU Gravação do SD-Card

Os dados são persistidos e recuperados do SD-Card

mcu01.1.a RF: TCP-IP Cabos de rede desconectados

Esta falha não gerou exceções críticas no funcionamento do Arduino

mcu01.1.b RF: TCP-IP Falha durante transmissão


mcu01.1.c RF: TCP-IP Falha durante recebimento


mcu01.1.d RF: TCP-IP Shutdown recebido pelo SCADA

O Arduino entra em rotina de re-conexão até o servidor voltar a ficar diponível

mcu01.1.e RF: TCP-IP Conexão por IP e Porta inválidos

Esta falha não gerou exceções críticas no

51

funcionamento do Arduino

mcu01.2.a \ mcu01.3.a \ mcu01.4.4 \ mcu01.5.a

RF: INPUTs TEMPERATURA \ UMIDADE \ PRESSAO \ GPS

Fios desconectados Esta falha não gerou exceções críticas no funcionamento do Arduino

mcu01.5.b RF: INPUT GPS Falha de sinal GPS Esta falha não gerou exceções críticas no funcionamento do Arduino

mcu01.6.a RF: INPUT SD-CARD

Reconhecimento do cartão


cme01.1.a RNF: Intervalo de Medições

Medir de 5 em 5 segundos

O Arduino foi capaz de coletar, armazenar e enviar os dados neste intervalo crítico

cme01.2.a RNF: Comunicação serial GPS

Testar GPS em baudrate 9600 e 115200

Devido às restrições do componente utilizado, foi possível validar apenas o baudrate de 9600

Fonte: Dados do experimento

Tabela 4 - Testes do SCADA

Caso de Teste Requisito Descrição Resultado scada01.1.a RF: TCP-IP

CME Recebimento de dados da CME

Os dados são transmitidos através de uma string única a cada intervalo de medição

scada01.1.b RF: TCP-IP CME

Falha de conexão com CME

Esta falha não gerou nenhuma exceção crítica no funcionamento do SCADA

scada01.2.a RF: TCP-IP IHM Recebimento de dados da IHM

Os dados são transmitidos

52

através de uma string única toda vez que a IHM conecta ou solicita atualização

scada01.2.b RF: TCP-IP IHM Falha de conexão com IHM


scada01.3.a RF: Internet Falha de conexão com Internet


scada01.4.1.a \ scada01.5.1.a \ scada01.6.1.a

RF: Gráficos Temperatura \ Umidade \ Pressão

Atualização do gráfico em tempo real

Os dados que chegaram em tempo real foram anexados e exibidos nos gráficos

scada01.4.2.a \ scada01.5.2.a \ scada01.6.2.a

RF: Tabela Temperatura Temperatura \ Umidade \ Pressão

Atualização da tabela em tempo real

Os dados que chegaram em tempo real foram anexados e exibidos nas tabelas

scada01.7.a RF: Mapa Exibição dos dados do GPS no Google Maps

A string de coordenadas do GPS foi convertida para o padrão utilizado pela Google e exibida corretamente

scada01.8.a RF: Excel Exportação de dados em formato Excel

Os dados de todas as tabelas de medição foram serializadas em um arquivo *.xls

scada01.a RNF: Área de Trabalho

Customização do ambiente de trabalho

A interface de docks permite re-arranjo de todas as janelas de visualização a gosto do usuário

Scada01.b RNF: Status View

Visualização de status dos servidores

Na janela inferior de log ficaram registradas todas

53

CME\IHM as operações dos servidores: inicialização, conexão com cliente, desconexão com cliente e falhas de conexão na rede.


Tabela 5 – Testes da IHM

Caso de Teste

Requisito Descrição Resultado

ihm01.1.a RF: Temperatura Dados de temperatura em tempo real

Os dados foram exibidos corretamente de acordo com a última medição registrada no SCADA

ihm01.2.a RF: Umidade Dados de umidade em tempo real


ihm01.3.a RF: Pressão Dados de pressão em tempo real


ihm01.4.a RF: Data-Hora Dados de data e hora da última medição


ihm01.5.a RF: Manual Exibição do manual do usuário

Foi criado um manual como exemplo e disponibilizado no aplicativo para visualização

ihm01.6.a RF: Configurações Configuração do dispositivo

Foram configurados o IP e a Porta de conexão do aplicativo

ihm01.7.a RF: Coordenadas GPS

Dados das coordenadas GPS em tempo real


54 ihm01.1.b RNF: Interface

Touch Funcionamento de botões e teclado

Os controles da interface gráfica funcionaram corretamente

ihm01.2.b RNF: Resposta de Comandos

Tempo de resposta dos comandos

Os tempos foram medidos com o aplicativo em debug e foram abaixo de 1 segundo

ihm01.3.b RNF: Customização do Aplicativo

Ajuste de brilho e volume

O aplicativo conseguiu acessar as configurações de tela e som do dispositivo

ihm01.4.b RNF: Árvore de Comandos

Comandos no menu principal

Todos os comandos foram implementados no menu principal


Dentro do escopo definido na seção 4.2 podemos perceber que o produto final atende as necessidades do cliente, e seus recursos foram corretamente dimensionados com os artefatos UML. Os experimentos comprovam ainda que é possível utilizar tecnologias open-source em aplicações de tempo real, economizando esforços no desenvolvimento de hardware e consequentemente agilizando a entrega do produto. Uma vez que o hardware foi aproveitado de dispositivos prontos no mercado (computadores, tablets, Arduino), os esforços maiores de desenvolvimento ficaram centrados no design e na qualidade do produto oferecido, proporcionando interfaces naturais e agradáveis ao usuário final.

Outro aspecto relevante está no custo envolvido no projeto que chegou a ser 80% menor que outras soluções prontas no mercado de automação convencional. Conforme a Tabela 5, foi realizado um comparativo com a média de preços de produtos disponíveis na região sudeste do Brasil e os gastos envolvidos em cada módulo do SIAPE.

55

Tabela 6 - Comparativo de gastos no projeto

Módulo Solução Convencional

Custo Médio

Solução do SIAPE Custo Médio

CME - Placa Processadora

Controlador Lógico

Programável (CLP) 8in/4out

R$450,00 Arduino Uno R$55,00

CME - Interface Ethernet

Módulo Ethernet para CLPs

R$300,00 Shield Ethernet para Arduino

R$60,00

IHM IHM com touch-screen e

comunicação via cabo Ethernet

R$3.000,00 Tablet de 10” com sistema operacional

Android e comunicação via

WiFi

R$600

Fonte: Pesquisa realizada no portal Mercado Livre

6. CONCLUSÃO

O presente trabalho buscava desenvolver uma metodologia que conciliasse a utilização de um modelo UML com a engenharia de automação, englobando o desenvolvimento de hardware e software. A partir deste modelo UML foi proposta uma arquitetura para automação que utilizou as tecnologias Android, Arduino e Windows Forms para constituir um Sistema Integrado de Automação em Pequena Escala (SIAPE). O modelo UML proposto permitiu que o framework do SIAPE pudesse ser modelado para uma aplicação específica de monitoramento climático que exemplifica os 3 módulos básicos da automação: uma Central de Medição Eletrônica (CME), um supervisório SCADA e uma Interface Homem-Máquina (IHM). Os diagramas produzidos são flexíveis e independem da linguagem ou plataforma que o sistema será implementado, abordando as funcionalidades da aplicação de um ponto de vista menos técnico que foca as necessidades reais do usuário.

O SIAPE apresentou resultados satisfatórios que atendiam aos requisitos da aplicação especificada com um custo de projeto bastante reduzido, viabilizando a utilização de seu framework na criação de produtos competitivos no mercado nos quesitos de qualidade e tempo de desenvolvimento. Como trabalhos futuros sugere-se o desenvolvimento do modelo UML proposto para atender aplicações mais complexas de automação industrial, que envolvam uma quantidade maior de processos e possam agregar mais artefatos UML para enriquecimento do modelo.

56 REFERÊNCIAS BIBLIOGRÁFICAS

ABINEE. Desempenho Setorial - DECON - ABINEE. Abinee - Associação Brasileira da Indústria Elétrica e Eletrônica, 2012. Disponivel em: <http://www.abinee.org.br/abinee/decon/decon15.htm>. Acesso em: 16 fev. 2013.

CHANGE VISION. Astah Professional. Astah Community, UML, Professional, Share and Ipad, 2013. Disponivel em: <http://astah.net/editions/professional>. Acesso em: 18 jun. 2013.

EMPRESA BRASIL DE COMUNICAÇÃO. Monitoramento Climático. Agência Brasil - Empresa Brasil de Comunicação, 2013. Disponivel em: <http://agenciabrasil.ebc.com.br/noticia/2013-02-25/monitoramento-climatico-reduz-em-42-uso-de-agrotoxicos-em-lavouras-de-tomate-no-rio>. Acesso em: 26 fev. 2013.

FERNANDES, J. M.; MACHADO, R. J.; SANTOS, H. D. Modeling Industrial Embedded Systems with UML. Universidade do Minho Guimarães, Portugal, 2001. p. 1-5.

FOWLER, M. UML distilled. 3ª ed. Chicago: Bookman, 2004. 160 p.

IEC1131-3. Standardized format for programming programmable controllers. International standard IEC1131-3, 1993.

MARRANGHELLO, N. Redes de Petri: Conceitos e Aplicações. UNESP, 2005. Disponivel em: <http://www.dcce.ibilce.unesp.br/~norian/cursos/mds/ApostilaRdP-CA.pdf>. Acesso em: 24 set. 2012.

MOURA, R. S.; COUTO, F. C. A.; GUEDES, L. A. Modelagem e Avaliação de Controladores Industriais Usando UML/Statecharts. UFRN Natal, Rio Grande do Norte, Brasil, 2009. p. 1-8.

NUNES, M.; O'NEILL, H. Fundamental de UML. 3ª ed. Lisboa: FCA, 2003. 246 p.

PATARICZA, A. et al. UML Based Control of Industrial Processes. Budapeste University of Technology and Economics, Hungary, 2001. p. 1-3.

RIBEIRO, A. F.; SILVESTRE, R. Interfaces Homem Máquina (IHM). Centro universitário Uniradial Estácio, São Paulo, SP, 2010. p. 1-3.

RIBEIRO, M. A. Fundamentos da Automação. 1ª ed. Salvador: TEK, 2003. 221 p.

SEBRAE. Automação Comercial - SEBRAE. Serviço Brasileiro de Apoio às Micro e Pequenas Empresas, 2009. Disponivel em: <http://www.sebrae.com.br/setor/comercio-varejista/o-setor/inovacao-etecnologia->. Acesso em: 24 set. 2012.

STADZISZ, P. C. Projeto de Software Usando a UML. Departamento Acadêmico de Informática - CEFET-PR, 2002. Disponivel em:

57 <http://www.etelg.com.br/paginaete/downloads/informatica/apostila2uml.pdf>. Acesso em: 24 set. 2012.

THRAMBOULIDIS, K. C. Using UML in Control and Automation: A Model Driven Approach. University of Patras, Patras, Greece, 2004. p. 1-8.

VOGEL-HEUSER, B. et al. Implementation and evaluation of UML as modeling notation in object oriented software engineering for machine and plant automation. Proc. of the 18th IFAC World Congress, Mailand, Italien, 2011. p. 1-7.

YOUNIS, M. B.; FREY, G. UML-Based Approach for the Re-Engineering of PLC Programs. 32nd Annual Conference of the IEEE Industrial Electronics Society (IECON'06), Paris, France, 2006. p. 1-6.

ZANCAN, M. D. Controladores Lógico Programáveis. Colégio Técnico Industrial de Santa Maria, Rio Grande do Sul, 2011. p. 1-62.

Monografia - SIAPE - R07

Documents

Transcript of Monografia - SIAPE - R07