Sistema SCADA Open Source

UNIVERSIDADE FEDERAL DO RIO GRANDE CURSO SUPERIOR DE TECNOLOGIA EM ANÁLISE E DESENVOLVIMENTO DE SISTEMAS

MARCOS VINICIUS SCHOLL

Sistema SCADA Open Source

Trabalho de Conclusão apresentado como requisito parcial para a obtenção do grau de Tecnólogo em Análise e Desenvolvimento de Sistemas

Prof. Dr.Eng. Carlos Rodrigues Rocha Orientador

Rio Grande, Julho de 2015

CIP – CATALOGAÇÃO NA PUBLICAÇÃO Scholl, Marcos Vinicius Sistema SCADA Open Source / Marcos Vinicius Scholl. – Rio Grande: TADS/FURG, 2015. 75 f.: il. Trabalho de Conclusão de Curso (tecnólogo) – Universidade Federal do Rio Grande. Curso Superior de Tecnologia em Análise e Desenvolvimento de Sistemas, Rio Grande, BR–RS, 2015. Orientador: Carlos Rodrigues Rocha. 1. SCADA, Sistemas supervisórios, Automação, Open Source. I. Rocha, Carlos Rodrigues. II. Título.

UNIVERSIDADE FEDERAL DO RIO GRANDE Reitor: Prof. Cleuza Maria Sobral Dias Pró-Reitor de Graduação: Prof. Denise Varella Martinez Coordenador do curso: Prof. Rafael Betito

FOLHA DE APROVAÇÃO

Monografia sob o título Sistema SCADA Open Source, defendida por MARCOS VINICIUS SCHOLL e aprovada em 15 de maio de 2015, em Rio Grande, estado do Rio Grande do Sul, pela banca examinadora constituída pelos professores:

Prof. Carlos Rodrigues Rocha Orientador

Prof. Rafael Betito IFRS - Campus Rio Grande

Prof. Rogério Malta Branco IFRS - Campus Rio Grande

"Deus nos fez perfeitos e não escolhe os capacitados, capacita os escolhidos. Fazer ou não fazer algo, só depende de nossa vontade e perseverança." — A LBERT E INSTEIN

AGRADECIMENTOS

Gostaria de deixar o meu profundo agradecimento a todos os que me auxiliaram na realização deste trabalho, pela disponibilidade, dedicação, paciência e compreensão, fundamentais para os resultados que aqui apresento. Ainda um reconhecimento especial a todos aqueles que me acompanharam ao longo destes últimos anos de formação acadêmica. Ao Professor Doutor Eng. Carlos Rodrigues Rocha, pela orientação do projeto de iniciação científica e orientação deste trabalho, por sua compreensão, preocupação, confiança, força, companhia, alegria, amizade, apoio, paciência, e por todos conhecimentos transmitidos e conselhos que contribuíram para o meu crescimento científico e intelectual. És uma pessoa pela qual tenho profunda admiração. Levo como exemplo para a minha nova etapa A todos os meus amigos, que de alguma forma contribuíram para que estes últimos anos, tenham sido marcantes e inesquecíveis. A todos vocês, um muito obrigado! Por fim aos meus pais Elemar Alfredo Scholl e Rosane Inês Hackenhaar Scholl e irmãos Felipe Elemar Scholl e Marco Antonio Scholl(meu clone), a quem dedico este trabalho pela compreensão, suporte, estímulo acadêmico, sempre me apoiaram e impulsionaram a continuar seguindo em frente, e pelo carinho incondicional nesta e em tantas outras etapas de minha vida.

SUMÁRIO

LISTA DE ABREVIATURAS E SIGLAS . . . . . . . . . . . . . . . . . . . .

8

LISTA DE FIGURAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

9

RESUMO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

11

1 INTRODUÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Organização do texto . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

12 13 13

2 AUTOMAÇÃO . . . . . . . . . . . . . 2.1 Automação Industrial . . . . . . . . 2.2 Estrutura da automação industrial . 2.3 Dispositivos de Campo . . . . . . . . 2.3.1 Sensores . . . . . . . . . . . . . . . 2.3.2 Atuadores . . . . . . . . . . . . . . 2.4 Dispositivos de Controle . . . . . . . 2.4.1 Controladores Lógico Programáveis 2.4.2 Microcontroladores . . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

14 14 15 16 16 17 17 17 19

3 SISTEMAS SUPERVISÓRIOS . . . . . . . 3.1 Funcionamento dos Sistemas SCADA . . 3.2 Componentes de um SCADA . . . . . . . 3.2.1 Variáveis . . . . . . . . . . . . . . . . . . 3.2.2 Alarmes . . . . . . . . . . . . . . . . . . 3.2.3 Registros . . . . . . . . . . . . . . . . . . 3.2.4 Scripts . . . . . . . . . . . . . . . . . . . 3.2.5 Comunicação . . . . . . . . . . . . . . . 3.2.6 IHM . . . . . . . . . . . . . . . . . . . . 3.3 Planejamento do Software de Supervisão 3.4 Sistemas existentes . . . . . . . . . . . . . 3.4.1 Elipse . . . . . . . . . . . . . . . . . . . 3.4.2 SIMATIC WinCC - Siemens . . . . . . . 3.4.3 InduSoft Web Studio . . . . . . . . . . . 3.4.4 ScadaBR . . . . . . . . . . . . . . . . . . 3.4.5 Mango . . . . . . . . . . . . . . . . . . . 3.4.6 OpenSCADA . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

20 20 24 24 24 25 25 25 27 28 28 29 29 29 30 31 31

4 DESENVOLVIMENTO DO SISTEMA 4.1 Requisitos do Sistema . . . . . . . . 4.2 Projeto Conceitual . . . . . . . . . . 4.3 Escolhas de Desenvolvimento . . . . 4.4 Implementação do Software . . . . . 4.4.1 runtime . . . . . . . . . . . . . . . 4.4.2 data . . . . . . . . . . . . . . . . . 4.4.3 communication . . . . . . . . . . . 4.4.4 hmi . . . . . . . . . . . . . . . . . 4.4.5 aware . . . . . . . . . . . . . . . . 4.5 Descrevendo uma aplicação ESSA .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

33 33 34 36 38 38 38 42 43 44 47

5 TESTES E RESULTADOS . . 5.1 Arduino . . . . . . . . . . . . 5.2 Raspberry Pi . . . . . . . . . 5.3 Casos de execução . . . . . . 5.3.1 Caso 01 . . . . . . . . . . . 5.3.2 Caso 02 . . . . . . . . . . . 5.3.3 Caso 03 . . . . . . . . . . . 5.3.4 Caso 04 . . . . . . . . . . . 5.3.5 Caso 05: Completa execução

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

49 49 50 51 51 53 54 58 60

CONCLUSÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

66

REFERÊNCIAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

67

APÊNDICE A

71

6

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

LISTA DE ABREVIATURAS E SIGLAS

API

Interface de Programação de Aplicações (Application Programming Interface)

CLP

Controlador Lógico Programável

DOM

Modelo de objetos de documento (Document Object Model)

ERP

Enterprise Resources Planning

ESSA

Embeddable SCADA for Small Applications

FINEP Financiadora de Estudos e Projetos FSF

Free Software Foundation

GPL

General Public License

IHM

Interface Homem-Máquina (Human Machine Interface)

M2M

Máquina para máquina (Machine to Machine)

MTU

Unidade Terminal Mestre

OSI

Open Source Iniciative

PWM

Modulação por Largura de Pulso (Pulse-Width Modulation)

RTU

Unidade Terminal Remota (Remote Terminal Unit)

SCADA Controle e Aquisição de Dados Supervisionado (Supervisory Control And Data Acquisition) SEBRAEServiço Brasileiro de Apoio as Micro e Pequenas Empresas XML

eXtensible Markup Language

LISTA DE FIGURAS

Figura 2.1: Figura 2.2: Figura 2.3: Figura 2.4:

Pirâmide da Automação Industrial . . . . . . . . . . . . Princípio do sistema de automatização (ROSáRIO, 2005) Estrutura de um CLP . . . . . . . . . . . . . . . . . . . Princípio de funcionamento de CLP (ROSáRIO, 2005) .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

15 16 18 19

Sala de Controle Central da Itaipu (ITAIPU ELETRôNICO JIE, 2010) Visualização de um sistema Scada (ROSáRIO, 2005) . . . . . . . . . Relacionamento entre o sistema SCADA e os demais componentes da planta(CONSTAIN, 2011) . . . . . . . . . . . . . . . . . . . . . Figura 3.4: Módulos de operação de um SCADA e seus relacionamentos(ROCHA; SCHOLL, 2015) . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figura 3.5: Supervisão Web (ROSáRIO, 2005) . . . . . . . . . . . . . . . . . . . Figura 3.6: CLP com IHM integrado (NOVUS, 2014) . . . . . . . . . . . . . . . Figura 3.7: Tela sinótica no Elipse E3(Elipse Software, 2010) . . . . . . . . . . . Figura 3.8: Tela do WinCC (SIEMENS, 2010) . . . . . . . . . . . . . . . . . . . Figura 3.9: Tela do Indusoft(INDUSOFT, 2014) . . . . . . . . . . . . . . . . . . Figura 3.10: Supervisório ScadaBr (SCADABR, 2014) . . . . . . . . . . . . . . .

21 21

Figura 4.1: Figura 4.2: Figura 4.3: Figura 4.4: Figura 4.5: Figura 4.6: Figura 4.7: Figura 4.8: Figura 4.9: Figura 4.10: Figura 4.11:

Diagrama de classe do software SCADA . . . . . . . . . . Pacotes ihm e aware . . . . . . . . . . . . . . . . . . . . . Diagrama de classes revisado para o ESSA . . . . . . . . . Geradores simulados . . . . . . . . . . . . . . . . . . . . . Widgets utilizados no ESSA baseados em Qt e Qwt . . . . . Template do ESSA no Qt Designer . . . . . . . . . . . . . Widgets do ESSA usados na criação de telas de supervisório Alerta de alarme . . . . . . . . . . . . . . . . . . . . . . . Log de alarme . . . . . . . . . . . . . . . . . . . . . . . . Log de alarme, Text Logger . . . . . . . . . . . . . . . . . Arquivo de configuração do ESSA. . . . . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

35 36 39 40 44 44 45 46 46 46 48

Figura 5.1: Figura 5.2: Figura 5.3: Figura 5.4: Figura 5.5: Figura 5.6: Figura 5.7: Figura 5.8:

Arduino Uno R3 (ARDUINO, 2014) . . . . . . . . . Raspberry Pi B+ (FILIPEFLOP, 2014) . . . . . . . Esquema Arduino para o Caso 01 . . . . . . . . . . Desenho de IHM pelo QtDesigner . . . . . . . . . . Configuração do ESSA para o Caso 01 . . . . . . . Criação do ESSA. . . . . . . . . . . . . . . . . . . ESSA em execução, com seus dois estados possíveis Configuração do ESSA para Modbus . . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

50 51 51 52 52 53 53 54

Figura 3.1: Figura 3.2: Figura 3.3:

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

22 23 26 27 29 30 30 31

Figura 5.9: Figura 5.10: Figura 5.11: Figura 5.12: Figura 5.13: Figura 5.14: Figura 5.15: Figura 5.16: Figura 5.17: Figura 5.18: Figura 5.19: Figura 5.20: Figura 5.21: Figura 5.22: Figura 5.23: Figura 5.24: Figura 5.25: Figura 5.26: Figura 5.27:

Criação do ESSA. . . . . . . . . . . . . . . . . . . . . . ESSA em execução, com protocolo Modbus . . . . . . . . Esquema Arduino. Caso 03 . . . . . . . . . . . . . . . . Tela criada para Supervisão. Caso 03 . . . . . . . . . . . Configuração ESSA. Caso 03 . . . . . . . . . . . . . . . SCADA à partir do ESSA . . . . . . . . . . . . . . . . . Primeiros instantes de execução . . . . . . . . . . . . . . Resultados da movimentação do potenciômetro e do botão Esquema Arduino como CLP Modbus. Caso 04 . . . . . . IHM de Supervisão. Caso 04 . . . . . . . . . . . . . . . . Configuração ESSA. Caso 04 . . . . . . . . . . . . . . . Definição do sistema para o ESSA no Caso 04 . . . . . . ESSA em execução. Caso 04 . . . . . . . . . . . . . . . . IHM proposta para Caso 05 . . . . . . . . . . . . . . . . ESSA, definição de execução para o Caso 05 . . . . . . . Scada ESSA em execução . . . . . . . . . . . . . . . . . Alerta da aplicação para a presença de um aviso . . . . . . Visualização de Alarmes disparados . . . . . . . . . . . . Logs constantes na aplicação para cada novo valor . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

54 55 55 56 57 57 57 58 59 59 60 60 61 62 63 63 64 64 65

RESUMO

Os sistemas de automação industrial utilizam tecnologias de computação e comunicação buscando o controle e monitoramento de processos automatizado, de forma a efetuar a coleta de dados da planta e a respectiva interação do processo de modo intuitivo para o operador através de uma IHM. Essa é a finalidade dos sistemas SCADA (Supervisory Control And Data Acquisition, ou Controle e Aquisição de Dados Supervisionado em português). Esse tipo de sistema também é empregado em outras aplicações da automação, como a predial e na automação de experimentos científicos. Esse sistema coleta informações através de equipamentos de aquisição de dados, armazenando-os e disponibilizando recursos para sua recuperação e até mesmo análise, eventualmente, por parte dos usuários. Este trabalho consiste no estudo desses sistemas, visando o projeto e implementação de um sistema SCADA Open Source para sistemas embarcáveis e de relativo baixo custo, como o Raspberry Pi, de forma que possa ser empregado em aplicações abertas e que utilizem tal tipo de hardware.

Palavras-chave: SCADA, Sistemas supervisórios, Automação, Open Source.

12

1

INTRODUÇÃO

A automação industrial é uma área de pesquisa e desenvolvimento muito ativa, em função da necessidade de constantes aprimoramentos nos processos produtivos visando aumento de eficiência, redução de custos, confiabilidade e segurança. As modernas tecnologias, baseadas em sistemas digitais, começaram a ser empregadas na indústria automobilística na década de 1960, espalhando-se para outras atividades em seguida. O aumento da complexidade das instalações industriais, usualmente conhecidas por plantas, faz com que grandes volumes de dados tenham de ser monitorados e analisados em curto espaço de tempo, o que é cada vez mais complexo de se fazer manualmente, o que impacta no grau de qualidade e confiabilidade do processo produtivo (CONSTAIN, 2011). Essa acaba sendo a função primordial de um sistema supervisório ou SCADA (do inglês Supervisory Control And Data Acquisition, ou Controle e Aquisição de Dados Supervisionado), que é uma ferramenta computacional que supervisiona e monitora processos executados em uma planta industrial, através da visualização de variáveis do ambiente que está sendo automatizado, e das ações tomadas pelo sistema de automação. Atualmente, os supervisórios são muito empregados em plantas industriais, acompanhando a sua evolução e complexidade. Isso, porém, faz com que os sistemas supervisórios demandem cada vez mais recursos computacionais, e se tornem complexos, o que restringe a sua aplicação em plantas de pequenas dimensões, como no acompanhamento de pesquisas experimentais e em aplicações de pequeno porte comercial ou residencial. Além da complexidade, o elevado custo de aquisição é um limitante da adoção dos sistemas SCADA mais modernos, inviabilizando seu uso para situações em que a automação está ganhando espaço, como nos projetos open source do tipo DIY (Do It Yourself, ou Faça Você Mesmo), que são parte importante da chamada Internet das Coisas. A partir dessas constatações, definiu-se a motivação para o presente trabalho, que pretende contribuir com as comunidades supracitadas através do desenvolvimento de um software que atenda às demandas identificadas de um sistema SCADA que ao mesmo tempo suporte características presentes nos equivalentes modernos e seja passível de executar em plataformas de baixo poder de processamento/custo comuns em sistemas embarcáveis. Além disso, visando a facilidade de adaptação e extensão do sistema para diferentes usos, pretende ser um projeto open source, de forma que outros desenvolvedores possam ampliar o potencial de uso do software.

13

1.1

Objetivos

Este trabalho visa contribuir com a criação de um Sistema SCADA open source para aplicações de pequena escala que precisam de sistemas de aquisição e supervisão de dados com recursos disponíveis em sistemas supervisórios modernos, porém de elevado custo e demanda de recursos computacionais. Visa equipamentos de relativo baixo custo e poder de processamento, para aplicações em experimentos científicos e em projetos open source. Assim, o objetivo geral deste trabalho é projetar e desenvolver um sistema de aquisição de dados e controle supervisionado voltado para aplicações de pequeno porte e embarcáveis, que atenda as necessidades de um típico sistema SCADA com recursos disponíveis em sistemas comerciais modernos. Contudo, o sistema deve prover facilidades para a sua extensão e contribuições por parte de terceiros, o que implica em ser disponibilizado como open source. Como objetivos específicos para atender a esse fim, tem-se: • Estudar aspectos da automação industrial e o uso das tecnologias da informação para esse fim • Analisar as características e funcionalidades de sistemas SCADA • Projetar um sistema SCADA multiplataforma, com foco em sistemas de baixo custo/poder de processamento • Desenvolver o software com base no projeto definido • Realizar testes de funcionamento do SCADA em diferentes hardwares realizando a supervisão de processos

1.2

Organização do texto

Este texto é organizado em mais 5 capítulos. O Capitulo 2 faz uma revisão bibliográfica sobre a automação industrial. A seguir, são analisados os sistemas SCADA e suas aplicações, com base em uma revisão da literatura e de produtos disponíveis no mercado. O desenvolvimento do objeto deste trabalho é detalhado no capítulo seguinte, onde o projeto conceitual, as escolhas de projeto e detalhes de implementação são tratados. Segue-se o capítulo onde os testes são descritos e os seus resultados são analisados. Por fim, são feitas as conclusões e recomendações de trabalhos futuros.

14

2

AUTOMAÇÃO

Desde o surgimento da sociedade, o homem buscou formas de mecanizar atividades manuais. A necessidade de minimizar o esforço humano levaram a invenções como a roda, a roda d’água e o moinho de vento, na busca por minimizar a participação humana nos processos produtivos. Este é o objetivo máximo da automação, termo que deriva do latim Automatus, que significa mover-se por si só. Assim, o objetivo principal de um sistema automatizado é que este realize suas tarefas da forma mais autônoma possível, com a mínima intervenção do homem. Mais do que isso, a automação é capaz de aperfeiçoar os processos produtivos e reduz os seus custos (SANTOS, 2012). A automação teve seu grande destaque na sociedade a partir da segunda metade do século XVIII, quando o sistema de produção agrário e artesanal se transformou com a Revolução Industrial, inicialmente na Inglaterra, e depois no resto do mundo. A máquina a vapor propiciou uma forma barata e confiável de geração e transformação de energia mecânica, possibilitando a movimentação automática de máquinas sem necessidade de esforço humano ou animal. As demandas dos processos produtivos geraram uma série de inovações tecnológicas que buscaram aumentar a produção e a produtividade, capazes de produzir com mais rapidez e precisão em relação ao trabalho manual (SANTOS, 2012). Segundo MORAES; CASTRUCCI (2007), a automação atual é um sistema apoiado em computadores, que substitui o trabalho humano favorecendo a segurança das pessoas, da qualidade dos produtos e tornam eficiente e ágil os processos de fabricação, assim aperfeiçoando os complexos objetivos das indústrias e dos serviços.

2.1

Automação Industrial

Pode-se dizer que um sistema de automação industrial é um conjunto de equipamentos e tecnologias capazes de fazer com que uma máquina ou processo industrial trabalhe automaticamente, ou seja, com a mínima intervenção humana. Aos humanos cabe o papel de programar, parametrizar ou supervisionar o sistema para que este trabalhe de acordo com os padrões desejados. A automação da indústria não tem como único objetivo redução de custos, matérias e energia, mas também busca trazer melhorias na qualidade de produtos/serviços e na segurança dos processos e dos trabalhadores humanos. Assim, seu grande benefício situa-se na agilidade dos processos e da produção, com maior qualidade nas informações de processos e um melhor controle e planejamento da produção (LOPES, 2007). Para MORAES; CASTRUCCI (2007), a automação envolve a implementação de sistemas interligados e assistidos por rede de comunicação, o que compreende um sistema supervisório e IHMs (Interfaces Homem-Máquina) que auxiliem os operadores no exercício da supervisão e análise dos problemas eventuais que possam ocorrer.

15

2.2

Estrutura da automação industrial

A automação integra varias áreas do conhecimento e campos dos setores produtivos, correlacionando estruturas e processos para realizar diversas funções. Uma visão estrutural da automação é baseada no conceito da pirâmide da automação, organizada em níveis com diferentes responsabilidades eque se comunicam entre si, como ilustrado na Figura 2.1 (MORAES; CASTRUCCI, 2007).

Figura 2.1: Pirâmide da Automação Industrial Os níveis tem as seguintes atribuições dentro do contexto industrial: Nível 1 É o nível dos equipamentos de campo como sensores e atuadores. É o chão de fábrica, onde os componentes da planta industrial possuem o primeiro controle distribuído, a rede de comunicação; Nível 2 É onde se situam os controladores dos equipamentos do Nível 1, como os Controladores Lógicos Programáveis (CLP) e as Unidades Terminais Remotas (RTUs, do inglês Remote Terminal Units). São equipamentos responsáveis por repassar comandos dos níveis superiores para as máquinas da planta. Também pode-se dizer que é neste nível que se realiza o controle das ações da planta industrial; Nível 3 É o nível dos sistemas de supervisão, conhecidos como sistemas SCADA, ou Controle e Aquisição de Dados Supervisionado), permitindo a supervisão e otimização e controle do processo produtivo da planta. Além de supervisão, este nível agrega, armazena e produz análises dos dados históricos de operação da planta industrial, produzindo informações que auxiliam os níveis superiores na tomada de decisão; Nível 4 O planejamento e programação da produção é realizado neste nível, através do gerenciamento de suprimentos, planejamento de tarefas a serem passadas para o nível da supervisão. Além disso, neste nível também se verificam as necessidades de manutenção dos equipamentos da planta, de acordo com as informações armazenadas pelos SCADA do nível inferior;

16

Nível 5 No nível mais alto tem-se a administração dos recursos da empresa, em que se encontram os softwares ERP (Enterprise Resources Planning) integrando os diferentes dados e processos da empresa. O presente trabalho situa-se no nível 3 da pirâmide da automação, de forma a integrar os dados provenientes dos níveis mais físicos da pirâmide, armazenando-os e gerando insumos para os níveis mais altos utilizarem para basearem suas ações e decisões a respeito do processo produtivo.

2.3

Dispositivos de Campo

Os dispositivos de campo compreendem sensores e atuadores, que servem como ferramentas para os controladores adquirirem dados e acionarem os equipamentos/processos da planta de produção. O uso de sensores tornou mais confiável a medição de variáveis de interesse de um processo produtivo independente de sua natureza, constituindo a atividade de instrumentação. Atuadores que possam ser automaticamente comandados complementam os instrumentos de aquisição de dados. A interação entre esses dispositivos de campo e os equipamentos de processamento digital dá-se conforme a Figura 2.2.

Figura 2.2: Princípio do sistema de automatização (ROSáRIO, 2005)

2.3.1

Sensores

Segundo MORAES; CASTRUCCI (2007), sensores são dispositivos amplamente utilizados na automação industrial, transformando variáveis físicas como posição, velocidade, temperatura, nível, pressão, pH em sinais que podem ser adquiridos e interpretados pelo sistema de automação. Em geral, os sinais gerados pelos sensores são elétricos, que podem ser convertidos para informações digitais (discretizados) para subsequente processamento (BORGES; CARVALHO DORES, 2010). Em outras palavras, sensores são componentes que permitem que um equipamento eletrônico possa interagir com o mundo. As características mais relevantes sobre os sensores são: Sensibilidade Grau de facilidade com que se obtém o valor de uma grandeza física; Resolução Relação entre o menor estímulo possível e a mudança que este provoca no sinal emitido pelo sensor; Precisão/Exatidão Concebido como uma forma de se ter processos com qualidade, são as projeções de erros que podem ocorrer;

17

Linearidade Comparação entre a curva de funcionamento do sensor e a curva ideal de funcionamento; Velocidade de resposta velocidade com que a medida do sensor chega a um controlador e este provoca o acionamento dos atuadores; Faixa Também conhecido como range, é definido pelos limites mínimo e máximo de valores em que o sensor atua dentro da precisão; Alcance São os valores máximos e mínimos que podem ser medidos pelos sensores. 2.3.2

Atuadores

Um atuador transforma um sinal (usualmente elétrico) em uma grandeza física, como, movimento, magnetismo ou calor. Sobre os atuadores, diz-se: [...] atendem a comandos que podem ser manuais ou automáticos, ou seja, qualquer elemento que realize um comando recebido de outro dispositivo, com base em uma entrada ou critério a ser seguido [...] (BRUGNARI; MAESTRELII, 2010)

Os principais atuadores são motores elétricos de diferentes modos de operação, válvulas hidráulicas e pneumáticas, bombas, resistências elétricas e compressores. Além desses, ainda podem-se citar os relés. Estes podem comandar o acionamento de circuitos externos de elevada potência a partir de sinais de baixa intensidade de corrente.

2.4

Dispositivos de Controle

Existem diferentes dispositivos de controle automático digital de processos e equipamentos, que são utilizados de acordo com as características do processo e do meio de operação. Além dos controladores específicos para determinadas variáveis, como os controladores de temperatura, os Controladores Lógico Programáveis (CLP) são muito usados na indústria. Em aplicações onde a responsabilidade não seja tão crítica e o meio não seja muito agressivo, microcontroladores também são bastante empregados. 2.4.1

Controladores Lógico Programáveis

O controlador lógico programável surgiu na década de 1960, nascido dentro da indústria automobilística americana. A General Motors foi a primeira empresa a utilizar esse tipo de tecnologia para agilizar as mudanças rápidas e constantes nas linhas de produção de veículos, o que causava gastos de tempo e dinheiro. Assim nasceu um equipamento versátil, de fácil utilização e que sofreu inúmeras mudanças desde a sua concepção. Os controladores lógicos, como o mostrado na Figura 2.3, possui uma variedade de entradas e saídas controláveis por software, velocidade de processamento, blocos lógicos complexos para controle das entradas e saídas e uma eventual interface com o usuário (PETRUZELLA, 2014). Em termos de hardware, um CLP é um computador especializado, com memórias que são utilizadas para armazenamento de dados que provêm do hardware de aquisição de dados e outros tipos de geração de dados, como temporizadores e contadores, bem como programas que definem como este equipamento deve executar uma tarefa específica. A finalidade dos módulos de entrada e de saída do CLP é prover uma forma do software

18

Figura 2.3: Estrutura de um CLP interagir com o mundo físico. Os tipos de dados básicos destas entradas e saídas são discretos (booleanos) ou analógicos (valores inteiros ou reais). Uma entrada discreta pode ser um botão, ou um sensor de final de curso em uma impressora, por exemplo. Já uma saída discreta é como uma chave que pode ligar/desligar equipamentos. As entradas analógicas são capazes de processar sinais elétricos gerados por transdutores, que convertem as grandezas físicas nesses sinais. Este, por sua vez, são usualmente discretizados por conversores analógico-digitais para gerar valores inteiros de acordo com a resolução do conversor (MCCRADY, July 2013) Algumas das vantagens de utilização do CLP são o menor espaço ocupado (em relação a outros sistemas de aquisição e controle de processos); o menor consumo de energia elétrica; a possibilidade de serem reaproveitáveis através de novas programações; flexibilidade na modificação de parâmetros de operação; flexibilidade e agilidade no desenvolvimento do sistema. Segundo MORAES; CASTRUCCI (2007), os CLP podem ser programados através de linguagens de alto nível, possuem elevada confiabilidade operacional e robustez, simplificam a construção de quadros e paineis de comando, comunicam-se em rede com outros equipamentos e podem possuir funções predefinidas que reduzam a complexidade de desenvolvimento de aplicações. Por ter essas características, os CLPs são equipamentos modernos que são utilizados em sistemas flexíveis. Por não ter teclado, mouse e monitor como um computador convencional, os CLPs são programados por interfaces específicas, como terminais de programação. Outras opções são software para computadores que façam as vezes desses terminais, reduzindo custos com a aquisição de equipamentos dedicados e possibilitando outras facilidades, como a simulação e depuração online, sem necessidade do equipamento físico, o que acaba minimizando paradas na produção. A lógica de funcionamento de um CLP é cíclica, onde as seguintes fases são executadas em um contínuo laço, como mostrado na Figura 2.4. Resumidamente, são essas as fases (MORAES; CASTRUCCI, 2007): Leitura Atualização das variáveis de entrada a partir da aquisição de dados; Processamento Execução do programa, com o processamento das instruções pré-determinadas em relação aos dados de entrada e o estado de operação;

19

Atuação Atualização das saídas, ativando ou desativando equipamentos ou mesmo modificando seus valores de operação.

Figura 2.4: Princípio de funcionamento de CLP (ROSáRIO, 2005) O tempo de um ciclo de varredura é denominado scan, e este é função tanto da velocidade do hardware quanto da complexidade do programa a ser executado a cada ciclo. Por trabalhar com diversas tarefas de aquisição ao mesmo tempo, um CLP necessita que seu tempo de scan seja calibrado, para que os tempos de execução das pequenas tarefas de uma atividade complexa sejam minimizados. 2.4.2

Microcontroladores

Os microcontroladores são microcomputadores do tipo SoC (System on a Chip, ou Sistema em um circuito integrado), onde um único circuito integrado reúne microprocessador, memória e entradas/saídas programáveis. Estas podem ser usadas para gerar sinais que acionem equipamentos ou detectar sinais digitais ou analógicos, de acordo com a capacidade do microcontrolador. Embora não sejam tão robustos quanto os CLP, o fato de terem dimensão reduzida e relativo baixo custo fez com que fossem adotados para uma grande variedade de sistemas eletrônicos, como em automóveis, aviões e até mesmo em equipamentos médicos e implantes. Essa característica de embarcabilidade incrementa o interesse de seu uso em sistemas tão diferentes quanto cafeteiras e SmartTVs. Mais recentemente, as iniciativas de desenvolvimento de sistemas embarcados por parte de pessoas não especializadas e a Internet das Coisas, aumentaram a notoriedade desses sistemas, com placas de prototipação de baixo custo e computadores de dimensões reduzidas, como o Arduino (ARDUINO, 2014) e o Raspberry Pi (Raspberry Pi Foundation, 2013), respectivamente. Além do equipamento de automação, é importante que este seja supervisionado. O próximo capítulo tratará desse assunto, apresentando os sistemas supervisórios.

20

3

SISTEMAS SUPERVISÓRIOS

Sistema supervisórios são usados para o monitoramento e operaçao de plantas industriais através do gerenciamento de variáveis de processos, que podem ser acessadas em tempo real, armazenadas para fins de registro histórico e modificadas de forma a controlar a execução do processo. Esse tipo de sistema é relativamente antigo em seu uso. Porém, a versão digital começou a ser usada no final do século XX, graças à disseminação dos computadores em todas as áreas do conhecimento de da produção (MORAES; CASTRUCCI, 2007). À medida em que os computadores tinham sua capacidade de processamento aumentada e a comunicação em redes de dados evoluia, os sistemas supervisórios baseados em software, usualmente denominados SCADA ampliavam a sua capacidade em termos de recursos oferecidos e de integração com outros sistemas importantes nas indústrias. A evolução dos equipamentos industriais, com inclusão de processamento digital em sensores e atuadores, aumento de eficiência e necessidades de minimização do consumo de energia também contribuiu para que os supervisórios digitais sofressem evoluções para acompanhar os novos equipamentos. A função principal de um SCADA é visualizar e operar uma planta de forma integrada, muitas vezes remotamente. Assim, instalações de grande porte podem ser completamente supervisionadas por um grupo reduzido de operadores em um local central, permitindo uma melhor visão do processo. Isso não dispensa, porém, a operação local, nas unidades da planta. Ao contrário, a complementa. Um exemplo de sistema de supervisão em uma instalação de grande porte é apresentado na Figura 3.1, que mostra a sala de operações da Usina Hidrelétrica de Itaipu. Ao fundo pode-se ver o sistema analógico originalmente utilizado para a supervisão, enquanto no quadro principal aparecem os monitores com o sistema SCADA usado para a supervisão. Segundo DUTRA; ALMEIDA (2011), Os sistemas supervisórios evoluíram muito nos últimos vinte e cinco anos, tornando-se mais poderosos e mais integrados com a TI e outros componentes dos negócios. Hoje eles vão muito além de atender somente as necessidades do chão de fábrica, que era a intenção inicial quando eles foram criados.

3.1

Funcionamento dos Sistemas SCADA

A terminologia dos SCADA estabelece claramente a sua função. A aquisição de dados e o controle são as atividades essenciais do sistema, que depende de elementos físicos de níveis inferiores da pirâmide da automação, como os controladores lógico programáveis

21

Figura 3.1: Sala de Controle Central da Itaipu (ITAIPU ELETRôNICO JIE, 2010) (CLP) e as unidades terminais remotas (RTU). Estes, por sua vez, fazem uso da instrumentação para adquirir dados (sensores) e de atuadores para agir sobre a planta (MORAES; CASTRUCCI, 2007; Seixas Filho, 2002). A supervisão, por sua vez, é um aspecto amplo do sistema, podendo ocorrer de várias formas, indo desde o acompanhamento em tempo real por operadores através de uma IHM ao armazenamento histórico dos dados para posteriores análises do comportamento da planta, podendo ainda haver supervisão automática com intervenção no caso de eventos específicos que façam com que o SCADA tenha uma resposta automática no caso de ausência de operadores, como em uma emergência. A Figura 3.2 sintetiza graficamente essas atribuições.

Figura 3.2: Visualização de um sistema Scada (ROSáRIO, 2005) Para que possa realizar essas tarefas, a comunicação entre o equipamento hospedeiro de um sistema SCADA e os controladores da planta é um elemento essencial. Esta pode utilizar diferentes meios físicos para ocorrer, bem como empregar diferentes protocolos para a troca de dados. A diversidade de aplicações, modelos e fabricantes dos equipamentos industriais implica em diversidade desses protocolos e meios de transmissão de dados, por mais que existam esforços de padronização por parte da indústria e dos governos. Isso faz com que os SCADA tenham de ter uma grande base de componentes de software para lidar com esses diferentes equipamentos, muitas vezes utilizando o conceito de drivers para agregar apenas as funcionalidades pertinentes a determinados

22

dispositivos de controle em determinadas aplicações. Some-se a tal variedade os sensores/atuadores inteligentes, que podem dispensar controladores por terem capacidade de processamento própria e se comunicam diretamente com o supervisório. Assim, é natural que um SCADA supervisione e controle quantidades elevadas de variáveis de entrada e saída digitais e analógicas distribuídas (MORAES; CASTRUCCI, 2007). Uma visão do relacionamento dos sistemas SCADA com os demais elementos de uma planta é apresentada na Figura 3.3.

Figura 3.3: Relacionamento entre o sistema SCADA e os demais componentes da planta(CONSTAIN, 2011) Os componentes básicos nela presentes são (CONSTAIN, 2011): Operador O operador humano monitora e interage com o sistema SCADA e executa remotamente as funções de controle supervisório; IHM Interface constituída de hardware e software que permite ao operador acompanhar e intervir em um processo, em geral através de apresentação gráfica de informações e de componentes que permitam a modificações de parâmetros de execução do processo; Estação Central/UTM É onde os dados adquiridos pelos dispositivos remotos são agregados e armazenados. Dependendo da escala da planta e das necessidades de processamento crítico (sem falhas ou interrupções), é possível que essa função seja

23

distribuída entre vários computadores, que agem como servidores de informações para IHM e outros software que fazem uso das informações adquiridas para outros fins, como o planejamento de recursos, por exemplo (ERP); Rede de Comunicação Meio pelo qual as informações do sistema SCADA são transferidas, fazendo a troca de dados entre o sistema SCADA com os equipamentos de controle de processos, como CLPs e RTUs. Essa comunicação se dá por protocolos específicos, como o MODBUS, por exemplo (Modbus Organization, 2014); Estações Remotas São os elementos afastados da estação central, dedicados ao controle e aquisição de dados provenientes dos dispositivos de campo; Dispositivos de Campo São os sensores e atuadores que estão diretamente conectados os equipamentos, fazendo a aquisição dos dados e atuação; Processo Físico Elemento que se deseja monitorar/controlar. De acordo com MORAES; CASTRUCCI (2007), um software SCADA deve ser capaz de fornecer ao sistema: • Capacidade de criar painéis de alarme, que solicitem a presença do operador para reconhecer o incidente, onde pode haver uma parada de tarefa ou processo; • Gerar dados históricos; • A execução de programas que modificam ou até cancelam o processo ou tarefa, de forma autônoma, sob certas condições; • Possibilidade de executar cálculos matemáticos. Em relação ao uso dos SCADA, observa-se que este pode ser organizado em três módulos, com um relacionamento entre eles como mostrado na Figura 3.4. O módulo runtime é o responsável pela aquisição de dados e controle, comunicando-se com os equipamentos de controle. O módulo cliente fornece a IHM para os operadores, podento ser em nível local (para a central de monitoramento da planta) ou remoto (para clientes externos, podendo inclusive ser por dispositivos móveis/portáteis como smartphones e tablets). Para o desenvolvimento e configuração das aplicações SCADA, o módulo design é utilizado, sendo que normalmente ele não é necessário na operação do sistema (ROCHA; SCHOLL, 2015).

SCADA modules Interage com

Runtime Co

n

nfi

gu re

Cliente

Design

sig De

Figura 3.4: Módulos de operação de um SCADA e seus relacionamentos(ROCHA; SCHOLL, 2015)

24

Esses módulos podem estar integrados em um único software ou existirem independentemente. O runtime, por exemplo, é possível de rodar em vários servidores, que são acessados por clientes em estações de trabalho conectados à mesma rede da supervisão. O design, muitas vezes, é utilizado apenas pelo integrador do sistema SCADA à planta, no desenvolvimento da aplicação e sua configuração. Em alguns SCADA de pequeno porte, todos os módulos podem compor um único software, cuja funcionalidade é definida de acordo com o que se deseja fazer (executar o sistema ou configurá-lo).

3.2

Componentes de um SCADA

Ao se analisar os componentes comuns de softwares SCADA, observa-se que apesar de haverem terminologias diferentes entre produtos, é possível enquadrar os seus componentes nas mesmas categorias. Assim, uma aplicação SCADA típica é formada pelos componentes descritos a seguir. 3.2.1

Variáveis

Segundo Elipse Software (2010) a supervisão de um processo ocorre através da leitura das variáveis dos processos. Essas são muitas vezes denominadas tags, em função de sua associação com as variáveis monitoradas por instrumentos, que são identificadas por etiquetas únicas. É comum que mesmo as variáveis não instrumentadas (por exemplo, auxiliares em memória) também recebam esse nome. As variáveis instrumentadas são continuamente atualizadas durante o ciclo de varredura da aplicação SCADA, que deve consultar os dispositivos remotos para sincronizar valores entre as variáveis da aplicação e os dados no dispositivo, que por sua vez são obtidos pelos sensores. O controle do SCADA sobre a planta também é exercido através dessas variáveis, através da modificação dos seus valores pela aplicação. Assim, uma variável booleana pode ter seu valor alterado de falso para verdadeiro através do apertar de um botão na IHM, resultando em atualização do valor da variável do CLP supervisionado e, consequentemente, ativar uma saída deste, que acionará um motor, por exemplo. Outro exemplo é a definição de um valor desejado para uma variável de processo (setpoint), como temperatura, a partir de um campo da IHM, que definirá o ponto desejado de operação para o controlador, que executará alguma ação de controle digital sobre os atuadores da planta. Os tipos de dados usuais em CLPs e RTU são booleanos, correspondentes à entradas e saídas digitais do equipamento. Outro tipo usual é o inteiro, que é usado para representar dados adquiridos por sensores e convertidos para sinais digitais através de conversores analógico/digitais (ADC, de Analog-Digital Converters). Porém, hardwares mais recentes já trabalham com dados reais e textuais. As variáveis costumam estar associadas à componentes visuais da IHM para sua apresentação aos operadores do sistema. Além disso, elas podem ser constantemente armazenadas em arquivos texto ou em bancos de dados para manter seu registro histórico através de loggers. 3.2.2

Alarmes

Esses componentes estão diretamente associados às variáveis monitoradas, de forma a automatizar o processo de verificação de condições normais de operação da planta. Alarmes podem ter condições predefinidas, como limites mínimo e máximo de valores admissíveis para operação. Eles também podem ser definidos por expressões lógicas que

25

relacionem as variáveis monitoradas com outros dados, como o histórico da operação, estado da planta e outros fatores externos. Quando um alarme está associado a uma variável monitorada, a cada ciclo de varredura, após a atualização do dado, ele é verificado. Em situação em que a expressão lógica do alarme resulte verdadeira, pode-se notificar o operador através da IHM ou mesmo disparar eventos que levem à execução de algum código (muitas vezes denominado script) que execute alguma ação corretiva ou de proteção da planta, como o seu desligamento. 3.2.3

Registros

Os dados adquiridos em um ciclo de varredura são fundamentais para a avaliação em tempo real das condições operacionais do processo monitorado. Porém, também é importante avaliar o histórico de operação da planta, tanto para fins da própria operação, identificando problemas que ocorreram anteriormente quando para os níveis superiores da pirâmide da automação, onde a análise de dados históricos e de ocorrências podem fornecer subsídios para a tomada de decisões e o planejamento estratégico da empresa. O registro (ou log) pode ser feito em arquivos texto ou binários mantidos pelo próprio SCADA ou através de Sistemas Gerenciadores de Bancos de Dados (SGBDs), que assumem a responsabilidade da organização e acesso aos dados armazenados. Em geral, os registros das variáveis monitoradas é feito separadamente do registro de ocorrências de operação. Assim, diferentes usuários podem analisar os dados de acordo com seus interesses, sem ter acesso indevido à dados quenão lhes dizem respeito. 3.2.4

Scripts

Embora a ideia dos software SCADA seja facilitar o desenvolvimento de aplicações de supervisão de processos, as ações predefinidas de seus componentes podem não ser suficientes para situações mais complexas, como definir o processo de desligamento correto de uma planta. Nessas situações, muitos sistemas fornecem um sistema de scripting, que permite ao usuário descrever lógicas que devem ser executadas em determinadas situações, como no disparo de alarme ou na ocorrência de um evento temporizado. As linguagens variam de acordo com o produto, mas em geral seguem o paradigma estruturado ou orientado a objetos. Em alguns casos, para facilitar o trabalho de usuários pouco experientes em programação, o módulo de design pode fornecer assistentes gráficos para reduzir o esforço. 3.2.5

Comunicação

A comunicação entre aplicações SCADA e os dispositivos de controle e aquisição de dados baseia-se na troca de dados apropriada entre eles. Em geral, esses dispositivos adotam algum protocolo de comunicação para padronizar essa troca de dados. Esses protocolos podem ser proprietários (ou exclusivos de um determinado modelo/fabricante) ou abertos, normatizados por algum órgão oficial ou associação de fabricantes, como é o caso do Modbus (Modbus Organization, 2014), Fieldbus (PETRUZELLA, 2014) e Profibus (MORAES; CASTRUCCI, 2007), entre outros empregados amplamente na indústria, cada qual com suas características, vantagens e desvantagens. Os modos de comunicação variam de acordo com o protocolo, podendo se dar por consulta (ou polling) ou por interrupção (ou report by exception). O primeiro caso é típico de arquitetura mestre/escravo, onde a estação central (mestre) tem controle absoluto das comunicações, efetuando sequencialmente o polling aos dados de leitura de cada estação

26

remota (escravo), que apenas responde à estação central após a recepção de um pedido (MORAES; CASTRUCCI, 2007; RAYSARO, 2012). Já na comunicação por interrupção, os equipamentos da rede de supervisão se comunicam entre si quando algum dado que estão monitorando sofre modificações significativas ou algum evento ocorre. Embora não se baseie no conceito mestre-escravo, em geral os dispositivos controladores é que enviam ao supervisório as informações relativas às variáveis que estão sendo monitoradas (MORAES; CASTRUCCI, 2007). A variedade de protocolos de comunicação pode ser um problema para sistemas SCADA, que devem ser capazes de trocar dados com os dispositivos remotos da planta a supervisionar. O conceito de driver de comunicação é útil nesse caso. Um driver consiste em um módulo que pode ser carregado em tempo de execução, responsável por gerenciar a comunicação utilizando um protocolo/equipamento específico. Assim, ao invés do SCADA ser sobrecarregado com uma grande variedade de suporte a protocolos que não serão necessariamente usados em uma determinada situação, apenas os protocolos relevantes a esta serão usados, com economia de memória e evitando desperdício de recursos computacionais. Além dos protocolos industriais, os SCADA cada vez mais tem de lidar com protocolos de comunicação comuns nos demais sistemas de informação, particularmente os utilizados pela Internet. Clientes web e para dispositivos móveis são cada vez mais comuns, utilizando tecnologias consagradas como TCP/IP para rede e HTTP para aplicação, como exemplificado na Figura 3.5. As IHM então são baseadas em tecnologias como HTML, CSS e Javascript. Quando os dados fluem facilmente do processo de produção para os desktops, as decisões de negocio podem ser feitas de forma mais rápida e inteligente, independentemente do tamanho do processo a ser controlado. Nos dias atuais o sucesso comercial depende da qualidade e da acessibilidade dos dados da produção. (MORAES; CASTRUCCI, 2007)

Figura 3.5: Supervisão Web (ROSáRIO, 2005) Isso demanda o desenvolvimento de recursos de gerenciamento de clientes remotos, por vezes integrados a servidores web, capazes de forneces IHMs e/ou dados.

27

3.2.6

IHM

A IHM de uma aplicação SCADA consiste de telas que contém widgets, que podem estar vinculados às variáveis monitoradas para que seus dados sejam apresentados ou modificados pelos widgets. As telas e widgets também podem ser usadas para a apresentação de alertas e análise de dados históricos. A interface gráfica pode apresentar os dados de forma intuitiva para o operador familiarizado com instrumentação industrial, simulando mostradores e indicadores normalmente encontrados na indústria e estendendo as suas funcionalidades. Da mesma forma, o controle pode ser feito com componentes análogos aos industriais como botões, dials e sliders, permitindo ligar e desligar, alterar modos de funcionamento e modificar parâmetros de operação (RAYSARO, 2012). Isso é feito em tempo real, no qual o sistema detecta um evento e responde com a ação os dados de todos os eventos da planta industrial (PRESSMAN, 2006). As IHM podem ser apresentadas em hardware comuns, como monitores, no caso de salas de controle e monitoramento, ou em equipamentos que possam ser usados em ambientes agressivos (MORAES; CASTRUCCI, 2007). Um exemplo deste tipo de equipamento é mostrado na Figura 3.6, onde a IHM é integrada a CLPs.

Figura 3.6: CLP com IHM integrado (NOVUS, 2014) O projeto e desenho de telas deve incluir os widgets que reflitam as condições de operação da planta de forma intuitiva ao operador, e que permitam a rápida localização das variáveis na planta. Por isso, é comum o uso de figuras que contenham a representação esquemática da planta, previamente desenhada com algum software de projeto utilizando a simbologia padronizada da área do processo. Acima dessa representação, os widgets apresentam textual ou graficamente os dados. Por exemplo, o nível de tanques pode ser representado por barras coloridas cuja altura são função do valor da variável monitorada correspondente. Temperaturas podem ser mostradas em representações de termômetros. Pressão, por manômetros virtuais, com indicações por cores de faixas de operação. Equipamentos mecânicos podem ser mostrados em operação por símbolos coloridos de acordo com seu estado ou mesmo por animações que simulem o movimento que está sendo realmente feito. A interação do operador, da mesma forma, pode ser feita através de widgets que são acionados por ele, como botões e barras deslizantes. Quando há necessidade de fornecer um valor exato, caixas de edição podem ser usadas. O projeto da IHM, em

28

geral, é o que demanda mais preocupações com o profissional que irá utilizá-la, desde a facilidade de compreensão desta até questões como ergonomia da operação.

3.3

Planejamento do Software de Supervisão

Ao se planejar um sistema SCADA, é necessário um entendimento geral sobre o processo a ser supervisionado. Segundo MORAES; CASTRUCCI (2007), o desenvolvimento do sistema compreende nove etapas: Entendimento do processo Para um entendimento do processo a ser automatizado todos os recursos disponíveis devem ser levados em consideração. Uma grande quantidade de informações deve ser levantada, com contribuição essencial dos operadores para isso; Variáveis do processo Identificar as variáveis realmente necessárias a serem monitoradas, sem excessos, porém que permitam a completa supervisão do processo; Planejamento da base de dados Um sistema conciso e robusto deve fornecer uma base de dados que contém as informações necessárias ao sistema, mas de maneira essencial. O tamanho do banco de dados deve ser considerado, um aumento de tráfego de rede pode causar a indisponibilidade e demora de um dado o que pode levar a uma falha de processo. Taxas de atualização e relevância para o processo são características que devem ser observadas; Planejamento de alarmes O alarme tem a função de chamar a atenção do operador para uma modificação do estado do processo. Alarmes visuais e sonoros devem sinalizar adequadamente o objeto atingido e a severidade do evento, fornecer indicação global sobre o estado do processo e uma providencia de ação; Planejamento da navegação entre telas Telas que fornecem progressivamente detalhes das plantas e seus constituintes à medida que se navega através do sistema; Desenho de telas Ser projetado de maneira consistente no uso de símbolos, cores, nomes de botões, com clareza de entendimento e padronização para garantir a consistência. Telas de visão geral, de grupo, de detalhe, de malha, de tendência e de manutenção trazem maior facilidade e clareza ao operador; Gráfico de tendências Uma importante ferramenta para se estudar variação, analisar tendências de processo, monitorar a eficiência da produção, arquivar variáveis de processo para garantir a conformidade com leis federais ou outras regulamentações; Planejamento de segurança Sistema mantém a restrição de acesso a pessoas com nível para cada operação ou visualização; Padrão industrial de desenvolvimento Leva em consideração a familiaridade do operador, reduzindo o tempo de aprendizado.

3.4

Sistemas existentes

São apresentados aqui alguns sistemas SCADA existentes no mercado, representativos das características típicas desse tipo de software. Os sistemas aqui relacionados variam

29

em porte, tecnologias empregadas/plataformas, preço e disponibilidade de código, o que consiste numa boa amostra das opções existentes. 3.4.1

Elipse

O Elipse SCADA é um software brasileiro, desenvolvido pela Elipse Software, empresa gaúcha fundada em 1986 (Elipse Software, 2010). A empresa é especializada em soluções voltadas ao gerenciamento de processos. Os softwares Elipse não estão vinculados a nenhum hardware específico. O Elipse SCADA é baseado em uma arquitetura monolítica, onde os módulos de design, runtime e cliente são integrados e acionados de acordo com a utilização deste. Além do SCADA, a versão de supervisório mais recente é o Elipse E3. Uma tela sinótica em execução neste supervisório é ilustrada na Figura 3.7.

Figura 3.7: Tela sinótica no Elipse E3(Elipse Software, 2010)

3.4.2

SIMATIC WinCC - Siemens

SIMATIC WinCC é uma SCADA da Siemens que é voltado para sistemas operacionais Microsoft Windows Server. Por esse motivo, usa a interface gráfica do sistema operacional, e se comunica com SGBDs utilizando drivers existentes para os principais produtos do gênero. Apesar de ser proprietário, o software permite expansão através do uso de uma API para desenvolvimento de bibliotecas dinâmica de componentes de terceiros. Apesar de ser de uma fabricante de equipamentos industriais de grande porte no mercado, o SIMATIC WinCC foi projetado de modo a não ser específico para os equipamentos Siemens, podendo ser utilizado com outros equipamentos e para diferentes fins (SIEMENS, 2010). A Figura 3.8 apresenta um exemplo de supervisório desse produto. 3.4.3

InduSoft Web Studio

A InduSoft foi fundada em 1997 nos Estados Unidos, desenvolvendo ferramentas industriais utilizando a plataforma Microsoft. O InduSoft Web Studio é um software

30

Figura 3.8: Tela do WinCC (SIEMENS, 2010) de desenvolvimento e runtime integrado que incorpora todas as ferramentas necessárias para criar aplicações SCADA com painéis e interfaces. Desde 1997 a InduSoft vendeu mais de 300.000 licenças pelo mundo inteiro (INDUSOFT, 2014). A Figura 3.9 contém uma tela do Indusoft.

Figura 3.9: Tela do Indusoft(INDUSOFT, 2014)

3.4.4

ScadaBR

O ScadaBR mostrado na Figura 3.10, é uma iniciativa nacional no desenvolvimento de um software SCADA no modelo de Software Livre. Ele se baseia no projeto mango, que é um sistema SCADA open source canadense, possuindo todas as funcionalidade do mango, mais as características adicionadas no projeto brasileiro. Alem de aberto, já é distribuído e funciona através de servidores web, possibilitando de maneira simples integrar com outros sistemas e controlar plantas remotamente (SCADABR, 2010). O software é multiplataforma, baseado em Java, ou seja, PCs rodando o Windows, Linux e outros sistemas operacionais podem executar o software a partir de um servidor de aplicações. A IHM é gerada como página web, podendo ser acessada a partir de

31

um navegador de Internet. A interface principal do ScadaBR oferece visualização das variáveis, gráficos, estatísticas, configuração dos protocolos, alarmes, construção de telas tipo IHM e uma série de opções de configuração. Também possibilita criar aplicativos personalizados, em qualquer linguagem de programação, a partir do código-fonte disponibilizado ou de sua API web-services.

Figura 3.10: Supervisório ScadaBr (SCADABR, 2014)

3.4.5

Mango

Mango possui muitas ferramentas importantes em sistemas SCADA, desde diversos barramentos ou protocolos de comunicação, passando por sensores variados, até a construção de telas interativas. Segundo GROUP (2014), Mango é o software SCADA de código aberto mais utilizado e conhecido no mundo. Entre os protocolos suportados, tem-se Modbus, BACnet, OPC DA, Dallas 1-Wire, SNMP, SQL, HTTP, POP3, NMEA 0183, MBus, DNP3, OpenV, vmstat, e muitos outros protocolos proprietários desenvolvidos por ou para fornecedores de hardware. 3.4.6

OpenSCADA

O OpenSCADA é um sistema alemão que possui alguns aspectos inovadores importantes, por exemplo, inclui a primeira implementação 100% Open Source e multiplataforma do OPC, o que até então era reservado exclusivamente à plataforma Microsoft Windows ou versões proprietárias da DCOM. É um software que presta bastante atenção a conceitos de flexibilidade e segurança em sua implementação, porém não é muito fácil de utilizar, por parte de usuários finais que não sejam programadores e conhecedores de automação, já que é uma solução em que o usuário necessita realizar toda integração do sistema e a sua configuração (ROCHA, 2011). Segundo OPENSCADA (2012), ele é independente de plataforma e baseado em um projeto de sistema moderno que oferece segurança e flexibilidade ao mesmo tempo. Esta ferramenta não é uma solução fora da caixa, é um conjunto de ferramentas que podem ser combinados de muitas maneiras diferentes.

32

Ele fornece bibliotecas de desenvolvimento, aplicações de interface, ferramentas de configuração de massa, front-end e back-end de aplicações. O estudo desses produtos e suas características permitiram identificar os elementos importantes de um sistema SCADA e sua utilização. Com base nisso, foram identificadas as características desejadas e os requisitos para o desenvolvimento do objeto deste trabalho, o que será discutido no próximo capítulo.

33

4

DESENVOLVIMENTO DO SISTEMA

Na revisão bibliográfica, foram identificados os features característicos dos sistemas SCADA, bem como as aplicações empregadas. A partir dessas informações e da definição do foco de aplicação do software, foram definidos os requisitos do sistema. Seguiu-se a modelagem do software e, em função do modelo e dos requisitos, definida a plataforma de desenvolvimento a ser empregada. A implementação do software foi realizada, com testes parciais de componentes. Todos esses tópicos são apresentados a seguir.

4.1

Requisitos do Sistema

Os requisitos do sistema foram definidos em função do estudo das características de sistemas SCADA existentes no mercado e dos requisitos de usuário, definidos a partir do contexto desejado de aplicação do software a ser criado, qual seja, aplicações de pequena escala, sejam científicas, ou da comunidade open source. Nestas, a aquisição e controle poderá ser função de hardware de baixa capacidade/custo (por exemplo, Arduinos) ou controladores lógicos programáveis que se comuniquem através de protocolos abertos. Assim, foram listados os seguintes requisitos, que guiaram as etapas subsequentes de escolhas e subsequente implementação do sistema: Multiplataforma O software deve poder executar em diferentes sistemas operacionais, inclusive em diferentes hardware. Visa-se não apenas aplicações executando em microcomputadores convencionais, mas também em sistemas embarcáveis; Pouca demanda por recursos computacionais Para executar no hardware típico de sistemas embarcáveis, que muitas vezes tem pouca capacidade de processamento/memória/gráficos, o software deve procurar minimizar a exigência de recursos; Apresentar os features essenciais em SCADA A despeito da necessidade de minimizar a demanda por recursos computacionais, o software deve prover um conjunto básico de recursos existentes em sistemas SCADA, como a aquisição de dados, armazenamento em históricos, interface humano-máquina e alarmes; Extensibilidade/adaptabilidade Ao contrário de muitos SCADA pesquisados, o software deve prover capacidade de criação de novos recursos por parte de seus usuários, se assim estes desejarem, estendendo seus componentes existentes e adaptandoos de acordo com as necessidades. Assim, o escopo de aplicações pode ser ampliado para atender a supervisão de novos hardwares e a interação com outros softwares, bem como a definição de novas formas de fazer interface com o usuário;

34

Suporte a protocolos de comunicação Pelo menos um protocolo de comunicação industrial amplamente adotado pela indústria deve ser suportado pelo software, como o Modbus. Em relação a dados, deve ser possível comunicar dados numéricos, string e timestamps; Open source Embora não seja uma característica inerente ao funcionamento do software, este é um requisito definido pelo foco da aplicação, que pretende ser uma contribuição à comunidade open source e científica.

4.2

Projeto Conceitual

Com base nos requisitos do sistema e das características típicas de sistemas SCADA identificadas na revisão bibliográfica, foram elaboradas diferentes concepções para o software. A análise dessas diferentes concepções permitiu extrair os pontos positivos de cada solução, e a combinação destes em um processo de síntese resultou no modelo conceitual que foi adotado para o desenvolvimento do software. O paradigma da orientação a objetos foi naturalmente adotado em função da modularidade desejada para o software e dos requisitos de extensibilidade e adaptabilidade, que podem ser uniformizados através de uma correta definição de interfaces e módulos na modelagem do sistema. O modelo conceitual do software se concentrou nos dois módulos essenciais para a execução de aplicações SCADA, que seriam o runtime e o cliente. Enquanto o primeiro realiza o controle e aquisição de dados, função primária do SCADA, o segundo é o que estabelece a interface com o usuário, permitindo a supervisão e a interação com o sistema. Apesar de ser parte importante na criação de aplicações, o módulo de desenvolvimento (ou design) normalmente não tem utilização durante a execução de aplicações. Dependendo da forma como uma aplicação é descrita, pode-se prescindir do módulo, podendo se empregar editores de código para criar as suas configurações. Não se diminui a importância desse módulo, porém, já que ele é necessário para os usuários que tem pouca ou nenhuma familiaridade com programação de aplicações. O diagrama de classes da Figura 4.1 representa como o software foi estruturado conceitualmente. As classes que compõe o software foram organizadas em pacotes de acordo com suas atribuições. Estes são: runtime Contém as classes essenciais para a execução de uma aplicação SCADA, como as classes ESSA e Tag. ESSA é um container dos componentes da aplicação, havendo apenas uma instância dela por aplicação. Essa instância é que contém o método de execução do ciclo de varredura que faz a comunicação com os dispositivos remotos supervisionados, processa os dados adquiridos e atualiza a interface com o usuário. Instâncias da classe Tag (e suas derivadas) representam os dados de interesse do supervisório, originários dos dispositivos remotos, ou através de simulações (controladas por instâncias da classe DataGen e suas derivadas); comm Contém classes responsáveis pela comunicação com dispositivos remotos, baseadas na classe Link, a partir da qual são implementados drivers de comunicação utilizando diferentes protocolos, para diferentes dispositivos remotos. hmi Neste pacote estão as classes usadas para criar a interface com o usuário da aplicação. Telas da aplicação são representadas por instâncias da classe Screen, que é

35

Figura 4.1: Diagrama de classe do software SCADA container de instâncias de classes derivadas de Widget, que define a interface comum dos componentes visuais da interface. A maioria dos widgets são associadas à instâncias de Tag, de forma a refletir visualmente o estado (valores) destes. Essa associação é provida por instâncias de Adapter e suas derivadas, que definem as regras de associação dos valores das Tags com o que é mostrado na interface com o usuário. Um detalhamento desse pacote é mostrado na Figura 4.2, onde algumas classes derivadas de Widget disponíveis em sistemas SCADA são relacionadas. logger Este pacote é composto por classes que gerenciam o armazenamento de dados adquiridos e registro de eventos ocorridos ao longo da supervisão. Isso torna possível o registro histórico de operação, permitindo análises do comportamento do sistema supervisionado, muito importante em situações onde a planta fica operando sem um operador constantemente monitorando a operação, como no caso de experimentos científicos de longa duração. Além da opção por registro em arquivos texto (comuns para pequenos volumes de dados e conveniente para o pós-processamento em planilha eletrônica), o registro em sistemas gerenciadores de bancos de dados (SGBDs) é interessante para integração com outros sistemas de informações. Assim, classes especializadas gerenciam o armazenamento em cada meio (Logger para arquivos texto e DBLogger para SGBDs). aware Este pacote reune classes de objetos acessórios ao sistema, ou cuja função não

36

se enquadra nos demais pacotes. Em particular, o padrão de projeto observer é implementado através de classes como Event (e suas derivadas), Listener e Subject. Além disso, parsers de arquivos de descrição de aplicações SCADA também são contidos neste pacote (ESSAParser, CfgParser e ProcessUI), cuja responsabilidade é a de permitir que uma aplicação possa ser descrita, ao invés de programada, o que poderia ser feito por intermédio de um módulo interativo e assistivo de design. Uma das possibilidades mais consideradas para a descrição das aplicações seria o uso de XML (eXtensible Markup Language).

Figura 4.2: Pacotes ihm e aware

4.3

Escolhas de Desenvolvimento

A partir da modelagem, foram identificadas diferentes demandas de recursos, como comunicação, interface gráfica com o usuário, processamento numérico, armazenamento de dados, que se possível deveriam ser providos por bibliotecas/APIs da plataforma de desenvolvimento de software a ser utilizada. Os requisitos do sistema também definiram algumas características que a plataforma deveria ter, como extensibilidade, possibilitar aplicações multiplataforma e possibilitar que o software desenvolvido seja fornecido como open source. Em função dos pontos identificados, da disponibilidade de recursos e de base de conhecimento e da experiência de desenvolvimento, optou-se pela adoção da linguagem Python como base para o código do software (Python.org, 2014a). Entre as características que a tornam interessante para a implementação do software, tem-se: Multiplataforma Aplicações em Python rodam sem necessitar de modificações (ou com poucas modificações) em diferentes sistemas operacionais, sobre diferentes hardwares. Isso também garante grande independência de recursos específicos dos sistemas operacionais; Orientada a Objetos Uma vez que a modelagem baseou-se neste paradigma, nada mais adequado que a linguagem adotada também fosse orientada a objetos. Isso permite

37

uma melhor definição de interfaces para futuras extensões/adaptações do software, que é um dos requisitos dele; Interfaces Gráficas Existem diferentes bindings com bibliotecas dinâmicas que gerenciam interfaces gráficas com usuário independentes de sistema operacional, como wxWindows, GTK, Qt, OpenGL e FLTK, e mesmo para casos dependendes de sistemas operacionais como o MFC/Windows (Python.org, 2014b); Disponibilidade de recursos Além de interfaces gráficas, existem inúmeros bindings de bibliotecas que provêem suporte a diferentes recursos, como comunicações, suporte a protocolos industriais, bancos de dados, processamento científico, gráficos e estruturas de dados diversas. Isso deve-se à relativa facilidade de criar bindings com bibliotecas existentes (muitas vezes binárias) criadas em linguagens como C/C++, por exemplo. Claro, também existem diversas APIs nativas em Python que ampliam o escopo já existente; Velocidade de execução Apesar de interpretada, Python tem um runtime eficiente em execução, com pouca perda de velocidade em relação à aplicações compiladas e transformadas em executáveis puros em muitos casos. Além disso, existem compiladores que permitem a geração de executáveis para vários sistemas operacionais, às custas da perda da execução multiplaforma; Interface com aplicações externas Muitas aplicações permitem criação de extensões de suas funcionalidades através de Python, fornecendo uma API que dá acesso à seus componentes. Em alguns casos, Python é a linguagem que é usada para fazer a interface com o usuário ou outras aplicações, como é o caso do ROS (Robot Operating System) (ros.org, 2014), o OpenRave (simulador de robôs) (DIANKOV, 2010), e o FreeCAD (RIEGEL, 2015). Dinâmica Isso implica em flexibilidade de codificação em função dos dados definirem os tipos de seus containeres, ao contrário de linguagens com tipificação estática. Apesar disso, Python trabalha com tipagem forte, não deixando que tipos de dados incompatíveis com operações gerem resultados anormais/não esperados. Isso também se estende à questão de código, com métodos dinamicamente definidos e extensões de classes em tempo de execução; Licença e custos As versões correntes de Python são open source, compatíveis com a GPL (GNU Public License). Além disso, várias ferramentas de desenvolvimento e distribuições (que empacotam as ferramentas e bibliotecas) são também abertas. Em relação a interface gráfica, foi adotado o Qt, por ser independente de sistema operacional, possuir grande variedade de widgets, outros recursos de apoio à aplicações desktop gráficas e ter dois bons bindings para Python, o PyQt (Riverbank Computing, 2013) e o PySide (TECHTONIK, 2014). Além disso, complementos como o QWT (Qt Widgets for Technical applications) (RATHMAN; WILGEN, 2014) e MatplotLib (HUNTER, 2007) proveem vários widgtes que emulam instrumentação industrial e que são usados em supervisórios, bem como na geração de gráficos científicos. Por fim, uma ferramenta de desenvolvimento visual de interfaces para Qt, chamada Qt Designer, também é disponível livremente, com grandes facilidades para o desenho de telas, e customização para uso de novos componentes visuais.

38

Embora Python e os pacotes mencionados pudessem ser instalados individualmente, foi utilizada a distribução Python(x,y) (RAYBAUT; NYO, 2013), projeto que visa facilitar o uso de Python pela comunidade científica, incorporando a maioria os pacotes de interesse junto com o intepretador Python e diferentes interfaces de uso e desenvolvimento com a linguagem. Dessas interfaces, o Spyder foi adotado como ambiente integrado de desenvolvimento.

4.4

Implementação do Software

No início do processo de implementação, surgiu um possível nome para o software, formado por um acrônimo de uma sentença que define claramente seu foco de aplicação. Assim, o termo SCADA Embarcável para Pequenas Aplicações deu origem ao nome ESSA (de Embeddable SCADA for Small Applications em inglês). Assim, futuras referências ao software neste texto utilizarão o nome ESSA. Uma revisão do modelo conceitual foi feita após terem sido definidas as ferramentas para a implementação do ESSA, principalmente em função da questão de aproveitamento de componentes já existentes em módulos do Python, particulamente em relação à interface gráfica. O diagrama de classes mostrado na Figura 4.3 representa a estrutura que foi implementada. No diagrama estão representados os componentes necessários para que o módulo runtime e o módulo cliente gráfico local sejam viabilizados, de forma que o supervisório execute e tenha a interface com o usuário no mesmo hardware. Como foi anteriormente exposto, um módulo para design de aplicações não foi tratado neste trabalho por não ser essencial à execução de aplicações, apesar de ser reconhecida a sua importância. Outro motivo para isso é a delimitação do escopo em função do tempo disponível. O mesmo motivo se aplica para a criação de um cliente gráfico remoto, que exigiria provedores de dados e de interface rodando como um servidor junto ao módulo runtime, recurso disponível em muitos SCADA atuais em função do aumento de dispositivos móveis e da comunicação em rede. Os componentes do sistema e seus interrelacionamentos são tratados a seguir, organizados por pacotes. 4.4.1

runtime

O pacote runtime contém a classe ESSA. Ela funciona como container dos demais componentes de uma aplicação e através dela que a aplicação SCADA é executada. Uma thread é criada para gerenciar os ciclos de varredura (scan cycle) de atualização dos dados (armazenados em instâncias da classe Tag) através de comunicação com o hardware remoto ou com provedores que simulam dados a partir de funções geradoras. A thread principal gerencia a interface com o usuário, atualizando os widgets de acordo com a atualização dos tags aos quais estão vinculados. O construtor da classe recebe o nome de um arquivo de configuração de aplicação, que é analisado por uma instância da classe ESSAParser e a partir desta, os componentes necessários para a aplicação são criados. 4.4.2

data

Diferentes classes relacionadas à representação e ao armazenamento dos dados estão agrupadas neste pacote. A classe Tag é a principal delas, que representa os dados adquiridos em um dado momento. Outra classe relevante é a Adapter (e suas derivadas), que vincula propriedades dos Tags (especialmente o valor do dado nele armazenado) aos wid-

39

Figura 4.3: Diagrama de classes revisado para o ESSA gets da IHM. A classe Log é a que faz o armazenamento dos dados ao longo do tempo, criando históricos de dados e eventos. E a classe Generator (e suas derivadas) permitem simular a aquisição de dados, o que é útil durante o processo de desenvolvimento de uma aplicação e não se tem sempre à disposição o hardware remoto a ser supervisionado. 4.4.2.1

Tag

Os tags podem ser considerados como as variáveis da aplicação SCADA. O termo Tag se deve às aplicações da área de instrumentação industrial, onde os instrumentos são unicamente identificados por etiquetas (ou tags, em inglês). Esses dados são usados para atualizar a interface com o usuário, bem como para comunicar ao hardware remoto as interações do usuário com o supervisório, uma vez que, a princípio, as Tags estão em

40

sincronismo com o hardware remoto de aquisição/controle. Assim, tags são vinculados à instâncias da Link, que fazem a comunicação com os dispositivos remotos e sincronizam os dados entre a aplicação e estes. Os tipos de dados usuais nos dispositivos remotos, como RTUs e CLPs, são discretos (booleanos) ou inteiros. Os primeiros representam sinais puramente digitais, como contatos de botões ou detecção de objetos, enquanto os inteiros resultam de contadores, temporizadores ou são gerados por conversores analógicos/digitais que discretizam os dados contínuos. Dados reais e textuais (strings) são mais comuns em dispositivos mais recentes, como as placas de prototipação com microcontroladores e CLPs que usam protocolos de comunicação atuais. Esses são os tipos que Tags devem armazenar. Sendo as variáveis da aplicação, eventualmente pode haver necessidade de armazenamento de dados temporários ou que não estejam associados à aquisição remota. Assim, Tags também podem apenas armazenar valores gerados na aplicação SCADA, desde que não estejam vinculados a um objeto de comunicação remota. Da mesma forma, pode-se simular a aquisição de dados através dos geradores (instâncias de Generator). Alguns dos sinais simulados são comuns na automação, como ondas dente de serra, degraus e senoides, e na Figura 4.4 são apresentadas graficamente essas formas de variação de valores.

Figura 4.4: Geradores simulados

4.4.2.2

Adapter

Os adaptadores são objetos que associam tags (ou suas propriedades) aos componentes da interface com o usuário. Além de desacoplar totalmente a IHM dos elementos de dados, os adaptadores são úteis na transformação dos dados provenientes das propriedades das tags para a sua apresentação em widgets/telas. Um caso comum dessa ocorrência deve-se à conversão analógica/digital efetuada por RTUs na leitura de sensores. Nela, um sinal analógico é discretizado dentro de uma faixa de valores (ou range) em um valor inteiro de acordo com a resolução do conversor. Por exemplo, no Arduino, sinais entre 0V e 5V são convertidos para valores numéricos de 10 bits (faixa de 0 a 1023). Para mostrar um valor de temperatura em graus Celsius em um widget do tipo mostrador (gauge), torna-se necessário aplicar uma conversão de escala do valor inteiro adquirido/transmitido ao tag para a correspondente temperatura. Essa conversão é feita pelo adaptador. Em outros casos, sinais binários (ligado/desligado) de um tag podem equivaler a valores reais ou inteiros para um widget. Da mesma forma, o estado binário de um widget botão pode corresponder a valores inteiros diferentes para um tag. O fato desses adaptadores fazerem essas conversões diminuem a necessidade de criação de scripts no software, o que não é pouco, visto a quantidade de conversões típicas em uma aplicação SCADA.

41

Além disso, a relação entre adaptador e tag baseia-se no padrão de projeto Observer (METSKER, 2004). Tags são observados pelos adaptadores, e mudanças em suas propriedades são notificadas aos adaptadores, fazendo com que estes ajam e atualizem os widgets correspondentes. De forma similar, a relação entre widget e adaptador se dá pelo sistema signal/slot existente no Qt (Riverbank Computing, 2015). Assim, a comunicação entre widget e tag pode ser bidirecional, de acordo com a propriedade Direction do objeto Adapter, cujos valores podem ser: 1 Comunicação de dados no sentido Tag → Widget. Mudanças de valor Tag causam atualizações no Widget; 2 Comunicação de dados no sentido Widget → Tag. Modificações de estado Widget causam mudanças nas propriedades da Tag; 3 Comunicação de dados bidirecional, Tag ↔ Widget. Ambos os componentes causam modificações; 4 Comunicação de dados Tag ↔ Tag. Faz com que duas tags possam monitorar uma a outra. Um adaptador pode se associar às propriedades provider (estado de prover dados simulados para a tag - booleana), state (se a tag está habilitada ou não - booleana) e value (dado armazenado na tag - variável). Em relação aos widgets, as propriedades associáveis são state (se o widget está habilitado ou não - booleana), text (texto inerente ao widget cujo efeito depende do tipo de widget) e value (que é refletido na apresentação do widget de acordo com o seu tipo). A classe Adapter é a base de um conjunto de classes que especializam as regras de conversão de valores entre tag e widget. Estão disponíveis as classes AdapterContinuous (que faz a conversão em escala de valores numéricos tanto no tag quanto no widget), AdapterRange (que define estados discretos para o widget de acordo com valores numéricos da tag) e AdapterDiscret (que define valores para o tag de acordo com estados booleanos do widget). 4.4.2.3

Log

A implementação de registro do histórico dos dados adquiridos e dos eventos ocorridos no sistema durante a supervisão são gerenciados por instâncias dessa classe. Ela, por sua vez, aproveita os recursos do pacote logging do Python para realizar esse registro em arquivos. Durante o ciclo de varredura da aplicação, tags que são definidas como registráveis tem seu valor armazenado em histórico utilizando uma instância de Log. No caso de eventos, como alarmes, outra intância de Log armazena o registro do ocorrido em outro arquivo. Com isso, tem-se um conjunto de dados cuja análise não apenas possibilita reconstruir a evolução de um processo quanto também avaliar o estado do sistema, o que é de extrema importância para os níveis superiores da chamada pirâmide da automação. Para lidar com os diferentes tipos de registros, três classes derivadas de Log foram criadas. São elas: LogCreate Gera um log contendo a configuração de todos os Tags e Adaptadores; LogAlarm Log fixo de Alarme, registrando toda ocorrência de alarme e notificações de ciência por parte do operador do sistema;

42

LogAlarmWarning Registro do alarme corrente, disponível na IHM do ESSA. Quando ocorre um alarme, esse componente dispara um evento na IHM que altera a propriedade do Led de status. O usuário clica no Led para verificar qual evento desencadou esse alerta. 4.4.2.4

Scan

O ciclo de varredura da aplicação é função de uma instância da classe Scan. Ele é executado como uma thread, paralela à IHM, de forma que esta não pare de interagir com o usuário em função de atrasos no ciclo causados por problemas de comunicação com os dispositivos remotos. Pode-se afirmar que essa classe é que mantém a parte de controle e aquisição de dados do sistema, que é a finalidade essencial de qualquer aplicação SCADA. A cada ciclo, scan verifica o tempo transcorrido entre atualizações das tags. Cada vez que o intervalo entre atualizações das tags é ultrapassado, é feita a atualização de seu valor. Se a tag está vinculada a um dado de um dispositivo remoto, Scan utiliza o driver para se comunicar e sincronizar os valores entre o tag e o disposivito. Se a tag tiver um provedor de dados simulado, este é consultado para atualizar o valor da tag. 4.4.3

communication

Neste pacote estão classes que gerenciam a comunicação de uma aplicação SCADA com os dispositivos remotos que estão sendo supervisionados. As classes, derivadas de Link, implementam o suporte a diferentes protocolos de comunicação, possibilitando assim tratar com diferentes tipos de dispositivos. Essa abstração, muitas vezes denominada driver, permite desacoplar as particularidades de conexão e troca de mensagems de cada tipo de equipamento, sejam físicas ou lógicas, facilitando a utilização do SCADA em diferentes aplicações. Dois protocolos foram considerados para a implementação inicial do ESSA, ambos abertos. A classe ArduinoLink implementa o protocolo Firmata, utilizado para microcontroladores, em particular nas placas de prototipação Arduino (HOEFS, 2015). A classe ModbusLink implementa o protocolo Modbus, que é muito conhecido e empregado no meio industrial desde a década de 1980 e que ainda tem uma grande base de equipamentos instalada (Modbus Organization, 2014). 4.4.3.1

ArduinoLink

No desenvolvimento dessa classe, foi utilizado o módulo pyFirmata(BRUIJN, 2014) que é uma interface Python para esse protocolo (FIRMATA, 2014). Firmata é um protocolo genérico para se comunicar com microcontroladores cuja finalidade é trabalhar com qualquer pacote de software em um computador hospedeiro, por meio de comunicação serial. A definição de um objeto ArduinoLink é feita atribuindo-se os parâmetros básicos de comunicação, a saber: name, port e baudrate, que correpondem à identificação do dispositivo, à porta serial de comunicação empregada e à velocidade de transmissão. A associação de tags a um dado do dispositivo remoto a partir do ArduinoLink deve especificar o pino a ser monitorado, o modo de operação dele (se entrada ou saída) e o tipo de dado (analógico ou digital). Isso define um link como um provedor de dados para o Tag (Provider).

43

4.4.3.2

ModbusLink

Existem algumas bibliotecas Python que dão suporte ao protocolo Modbus. Devido à sua facilidade de uso e tamanho, foi adotada a MinimalModbus (BERG, 2015). Ela suporta as variantes Modbus RTU e Modbus ASCII, o que é adequado para o escopo de uso do ESSA. A limitação é a falta de suporte ao protocolo Modbus-TCP, que permite a comunicação entre CLP e supervisório através de redes TCP/IP. Não obstante, é uma limitação aceitável para o ESSA, já que para pequenas aplicações é usual a conexão serial com o computador Host (seja USB, RS-232 ou RS-485), mesmo para equipamentos industriais. O protocolo Modbus baseia-se no modelo mestre-escravo, onde o computador com o sistema SCADA faz o papel do mestre e os dispositivos remotos são os escravos. A princípio, até 127 escravos podem estar ligados ao mestre em uma rede de comunicação industrial (mesmo serialmente, como no caso do RS-485), cada qual com seu endereço numérico único. Um escravo só se comunica com o mestre respondendo à comandos que este envia a ele. As mensagens que encapsulam comandos e respostas são padronizadas, e usualmente trafegam bits (dados booleanos) ou números inteiros (dados discretizados). Valores textuais e reais são tratados como extensões do Modbus original, e são suportadas pelo MinimalModbus. A definição de um objeto ModbusLink é feita atribuindo-se os parâmetros básicos de comunicação, a saber: name, board, register e type. O primeiro é o nome dado para identificar o dado textualmente, se necessário. O segundo é a porta de comunicação onde o dispositivo remoto está conectado. O parâmetro register é o endereço Modbus do dado no dispositivo remoto (número inteiro que é mapeado de acordo com o dispositivo). Por fim, type indica se o dado é um register (inteiro) ou um bit (booleano). Outros tipos de dados não definidos no Modbus são suportados, como floats (reais) e strings (texto). 4.4.4

hmi

O pacote hmi reúne os componentes utilizados pela IHM que foram criados ou especializados para o ESSA. O fato de se utilizar o Qt como gerenciador gráfico simplificou o desenvolvimento, pelo fato das janelas poderem ser representadas diretamente por instâncias de classes da própria Qt, como Widget ou MainWindow, o que dispensou a criação de uma classe específica para esse tipo de gerenciamento. Nos widgets, porém, houveram alguns problemas inerentes à falta de padrão para definição dos valores, o que levou à necessidade de especializações onde a propriedade que define o valor fosse a mesma para todos os componentes. Alguns componentes também foram criados especificamente para o ESSA, como é o caso do Thermometer, do CounterLabel e dos dials. A Figura 4.5 contém alguns componentes baseados em Qt e Qwt. A atualização dos widgets é feita através dos adaptadores, que os associam às tags que são continuamente atualizadas pelo ciclo de varredura da aplicação. Isso simplifica bastante a criação de telas de supervisão. Componentes como botões, sliders e dials, usados para interação com o usuário, usam os adaptadores também para refletir as mudanças feitas neles. O uso do Qt como base da IHM também trouxe um benefício adicional. O Qt Designer, software utilizado para o desenho das janelas de aplicativos baseados em Qt, pode ser adaptado para agilizar o processo de desenvolvimento, suprindo parte das necessidades de um módulo de projeto/design. Um template foi criado para incluir os componentes particulares do ESSA no menu do aplicativo, possibilitando criar telas do supervisório

44

Figura 4.5: Widgets utilizados no ESSA baseados em Qt e Qwt com simples ações de arrastar e soltar, com subsequente definição das propriedades num painel de configuração, como é mostrado na Figura 4.6.

Figura 4.6: Template do ESSA no Qt Designer Com isso, as telas podem utilizar todos os componentes já disponíveis no Qt, os componentes do Qwt e mais os componentes específicos do ESSA, como o Thermo, o Thermometer, os dials, leds e alarmes, alguns dos quais mostrados na Figura 4.7. Outros componentes podem ser facilmente adicionados ao template, na medida em que os usuários estenderem o rol de componentes do ESSA. As telas geradas no Qt Designer são descritas em arquivos XML quando salvas, e podem ser tratadas pelo parser de aplicações do ESSA para criar as telas quando uma aplicação que as usa é executada. Para isso, basta dar o nome do arquivo de tela no arquivo de descrição da aplicação. 4.4.5

aware

Nesse pacote estão classes de apoio ao ESSA, como os parsers e a implementação do padrão observer base. Além dessas classes, encontra-se também um elemento importante

45

Figura 4.7: Widgets do ESSA usados na criação de telas de supervisório

em aplicações SCADA, que são os alarmes. 4.4.5.1

Alarm

Essa classe gerencia o monitoramento automático de condições anormais de funcionamento do sistema. Os alarmes estão associados às tags, verificando os seus valores de acordo com condições predefinidas, como limites mínimos e máximos admissíveis ou expressões lógicas que indicam que a condição de operação do sistema supervisionado está normal em função de uma ou mais tags. Os alarmes podem disparar eventos, indicar condições de operação anormal na IHM e gerar registros em um log próprio de operação. Entre as diversas propriedades de um alarme, estão a relação de tags a supervisionar, o tipo de alarme, os limites válidos para um valor de tag e o tempo de vida de um sinal de alarme na IHM após seu disparo. O disparo de um evento de alarme pode levar à execução de scripts para que ações de minimização de problemas possam ser automatizadas, como o desligamento emergencial do sistema, caso o operador não esteja próximo para intervir. Quando ativo, o alarme executa um aviso sonoro, que somente é desativado quando o usuário indicar que está ciente deste alarme a partir do botão que o alerta do alarme exibe, como mostrado na Figura 4.8. Ao ser pressionado, a janela de alarme e o aviso sonoro são desativados, e um registro de que o usuário respondeu ao alarme é adicionado ao log de alarme. No registro de um alarme, são informadas a tag que originou o alarme, o tipo de alarme, os momentos em que ele foi disparado, que a situação foi normalizada (valores da tag voltaram ao normal) e que o usuário respondeu ao alarme. Um exemplo desse registro é mostrado na Figura 4.9. Caso o alarme esteja ativo e o usuário ausente, após o tempo definido pela propriedade lifeGui, a tela de alerta do alarme se encerra, e o sistema registra no log que o usuário não visualizou o alarme. O alarme sonoro continua até que o alarme seja normalizado. Assim, as informações necessárias para uma revisão e posterior identificação dos acontecimentos ocorridos desde que o alarme foi ativado estarão disponíveis, como é exemplificado na Figura 4.10.

46

Figura 4.8: Alerta de alarme

Figura 4.9: Log de alarme

Figura 4.10: Log de alarme, Text Logger 4.4.5.2

ESSAParser

Essa classe é a responsável por analisar a descrição de uma aplicação SCADA e gerar os seus componentes. Para isso, a classe utiliza a biblioteca ElementTree, que é um

47

processador de DOM de documentos hierárquicos, em especial XML, que é a base do arquivo de descrição de aplicações do ESSA (effbot.org, 2007). Uma instância do ESSAParser é utilizada quando o programa SCADA é invocado com o nome do arquivo da aplicação, analisando cada ramo da árvore criada por ElementTree, criando os componentes correspondentes e definido suas propriedades conforme os valores contidos nela. Telas, em particular, são definidas em um arquivo xml a parte criado pelo QtDesigner. Esse arquivo é referenciado no arquivo da aplicação SCADA.

4.5

Descrevendo uma aplicação ESSA

A descrição de uma aplicação é feita em um arquivo texto no formato XML, especializado para o software em questão. Assim, ele pode ser trabalhado em qualquer editor de textos, e futuramente pode ser facilmente mantido por uma aplicação gráfica interativa. São duas as partes de aplicação que devem ser criadas. A IHM é criada através do QtDesigner, e salva em um arquivo próprio. A parte correspondente ao módulo runtime, por sua vez, é criada diretamente em XML, e nela também deve ser incluída a tela. Este arquivo deve conter as seguintes definições: 1. Caminho de instalação do software; 2. Caminho onde os logs devem ser armazenados; 3. Nome e caminho da IHM, armazenado em um arquivo com extensão .ui; 4. Intervalo do ciclo de varredura global da aplicação; 5. Descrição dos objetos de comunicação; 6. Descrição das tags da aplicação; 7. Descrição dos adaptadores; 8. Descrição dos alarmes. Um exemplo de arquivo de configuração é mostrado na Figura 4.11. Uma descrição mais clara poderá ser encontrada nos Apêndices. No próximo capítulo serão apresentados testes de utilização do ESSA em diferentes aplicacões com sistemas diversos a serem monitorados e controlados. Além de poder observar mais detalhadamente como as aplicações são descritas, resultados serão discutidos.

48

49

5

TESTES E RESULTADOS

Um sistema SCADA consiste de um número de RTUs que recebe os dados de campo e os envia de volta para uma estação mestre, via um sistema de comunicação. A estação mestre exibe os dados adquiridos por IHM e permite que o usuário/operador possa executar tarefas de controle remoto. O RTU fornece uma interface para o campo e sensores digitais situados em cada local remoto. O sistema de comunicações fornece a via para a comunicação entre a estação mestre e os locais remotos. A estação mestre reune dados dos vários RTUs e fornece uma interface de operador para exibição de informações e controle dos locais remotos. Um SCADA tem seu funcionamento a partir dessa integração, que realiza a monitoração através de do uso de equipamentos de aquisição de dado, como CLPs, estes sendo equipamentos proprietários e de relativo custo de aquisição. Como o trabalho destina o desenvolvimento de uma ferramenta aberta, o mesmo requisito é obtido ao hardware. Satisfazendo essa necessidade, como possíveis alvos de uso do software, existem plataformas abertas de hardware, como Arduino, podendo ser utilizado como dispositivo de aquisição de dados e atuador, e o Raspberry Pi como unidade de processamento, ou RTU. O ESSA é compatível com as opções de hardware abertas e também fechadas, como CLPs habituais, e para fins de validação uma plataforma Open Source e de baixa exigência foi utilizada. Essa plataforma está descrita em Conceptual Design of an Open Source SCADA System(ROCHA; SCHOLL, 2015, Cap 6)

5.1

Arduino

O Arduino, Figura 5.1, é uma plataforma de prototipagem eletrônica Open source que se baseia em hardware e software flexíveis e fáceis de usar. Segundo MCROBERTS (2011), o Arduino é uma plataforma de computação física ou embarcada, que pode interagir com seu ambiente por meio de hardware e software. Permite programar para processar entradas e saídas entre o dispositivo e os componentes externos conectados a ele e ainda pode enviar um conjunto de dados recebidos de alguns sensores, para outro dispositivo, a ele conectado. É baseado numa simples placa microcontroladora e um ambiente de desenvolvimento para escrever o código para a placa. Segundo ARDUINO (2014), o Arduino Uno é uma placa de microcontrolador baseado no ATmega328. Dispõe de 14 pinos digitais de entrada/saída, dos quais 6 podem ser

50

utilizados como saídas PWM e também possui 6 entradas analógicas, uma conexão USB, um conector de energia, um cabeçalho ICSP, e um botão de reset. O hardware e o software do Arduino são ambos de fonte aberta, o que significa que o código, os esquemas, o projeto etc. podem ser utilizados livremente por qualquer pessoa e com qualquer propósito.

Figura 5.1: Arduino Uno R3 (ARDUINO, 2014) Ele foi utilizado em conjunto com sensores e Leds como um dispositivo de aquisição.

5.2

Raspberry Pi

A Raspberry Pi, Figura 5.2, é um computador completo, com considerável poder de processamento, em uma placa de circuito impresso menor do que um cartão de crédito. Todo o hardware é integrado numa única placa. Segundo HEIN (2013), em 2006 o engenheiro britânico Eben Upton e sua equipe desenvolveram os primeiros conceitos para o Raspberry Pi, baseados no microcontrolador Atmel ATmega328. A ideia de atrair jovens interessados no minicomputador já fazia parte do programa. Em 2009, os membros oficialmente estabeleceram a Raspberry Pi Foundation. Em agosto de 2011, a série alpha de aproximadamente 50 placas deixou a produção, inicialmente produzidas para testes e depuração. A partir desse momento estava sendo disponibilizado um dos menores computadores do mundo a preço realmente acessível e que um ano após a produção não dava conta dos pedidos, tamanha aceitação do produto. O RPi permite, assim como o Arduino, a integração de sensores, displays e outros componentes utilizando o conector GPIO de 40 pinos. GPIO significa General Purpose Input/Output, ou Entrada e saída de uso geral, em tradução livre. Não possui HD, mas pode-se utilizar um HD externo ligado à uma das portas USB, ou o slot para cartão microSD, localizado na parte de trás da placa que é o método nativo de armazenamento do RPi. Esse slot para cartão microSD, é uma parte importante do Raspberry, pois é através de um cartão que é instalado o Raspbian, um sistema operacional baseado em Linux e otimizado para uso com o Raspberry. O RPi foi projetado para trabalhar nativamente com a linguagem Python. É possível conectar ao RPi teclado, mouse, áudio, dongle wifi, dispositivos USB padrões, integrar uma tela pela sua conectividade HDMI, câmera, e mais uma infinidade de possibilidades. Para o seu funcionamento é necessário fornecer alimentação a partir de um conector Micro USB (5 volts, 700mA). Sua usabilidade é extensa, ele provê inúmeras possibilidades de utilização, é muito fomentado devido ao seu baixo custo de aquisição, tonando-se um ótimo dispositivo embarcado para aplicações de automação.

51

Figura 5.2: Raspberry Pi B+ (FILIPEFLOP, 2014) RPi pode tanto ser utilizado com um RTU, e também como unidade mestre do ESSA, e é um alvo de validação do ESSA.

5.3

Casos de execução

Após o desenvolvimento do software, foram realizados testes do sistema, onde à partir dos erros e inconsistências encontrados foram efetuadas algumas correções, gerando novas versões, até a atual versão do sistema. A seguir são apresentados alguns estudos de casos de execução do sistema onde são aplicadas as caracteristicas que apresentam o ESSA. 5.3.1

Caso 01

Foi desenvolvido um exemplo simples de supervisão para o ESSA, onde o alvo do caso é a plataforma Arduino. Os requisitos deste caso são, uma tela IHM contendo um botão e um Arduido que possui um Led conectado ao seu pino digital de numero 9. O botão representa o estado do Led conectado ao Arduino, e o botão serve como uma interface para ligar e desligar este Led. Este é o esquema no Arduino, Figura 5.3.

Figura 5.3: Esquema Arduino para o Caso 01 Após, foi criado a seguinte Tela no QtDesigner, Figura 5.4. E então foi definido a configuração, pelo arquivo que descrição, para que ocorra a supervisão do botão presente na IHM, e a correspondente alteração do Led conectado ao

52

Figura 5.4: Desenho de IHM pelo QtDesigner Arduino na Figura 5.5:

Figura 5.5: Configuração do ESSA para o Caso 01 Após definida a configuração, uma instância do objeto ESSA foi criado, onde o arquivo de configuração a ser interpretado, foi o anteriormente definido. Essa é a visão da definição do ESSA, que quando executado, inicia o SCADA, Figura 5.6. O resultado obtido é apresentado na Figura 5.7, e posteriormente discutido. Pode se perceber que a supervisão provê na IHM imediatamente o valor de estado do botão conectado com o Arduino. Isso ocorre pois a comunicação é do tipo 3, que é bidirecional. A alteração da Tag reflete no botão, e a alteração do botão reflete na Tag. Ao clicar no botão o Led é desligado. O que ocorre é que a Tag está possuindo o valor do botão da IHM, e a Tag é uma comunicação de saida com o pino do Led. Toda vez que há alguma alteração no botão, este valor é refletido à comunicação da Tag, que por ser

53

Figura 5.6: Criação do ESSA.

Figura 5.7: ESSA em execução, com seus dois estados possíveis uma saida, será repassada ao arduino que desliga o Led. É provado aqui o conceito de supervisão e atuação. 5.3.2

Caso 02

Esse caso tem por objetivo validar a anterior, mas agora utilizando o protocolo Modbus. Os requisitos propostos são os mesmos do Caso 01, porém a configuração dos dados é de acordo com as especificações do Modbus. Para o caso, está sendo utilizado o Arduino, contendo um programa de simulação Modbus, já que no presente momento, um CLP não estava disponível. A configuração deste caso utiliza o Modbus como objeto de comunicação e Link, e foi definido a configuração como Teste02.xml. O comportamento deve ser idêntico ao anterior, onde o click do botão atua como alteração do Led conectado ao Arduino, que está simulando um CLP com Modbus na Figura 5.8. A instância do objeto ESSA criado leva em consideração o arquivo de configuração Teste02.xml definido na Figura 5.8. Essa é a visão da definição do ESSA, que quando executado, inicia o SCADA, na Figura 5.9. O resultado obtido é apresentado na Figura 5.10, e então discutido. O comportamento é idêntico ao do Caso 01, pois o ESSA foi definido com as mesmas

54

Figura 5.8: Configuração do ESSA para Modbus

Figura 5.9: Criação do ESSA. caracteríticas, mas com propriedades diferentes. Percebe-se que a configuração de conexão foi totalmente diferente, e o software manteve o seu comportamento. Ao clicar no botão o Led é desligado. Indepentente da comunicação o fluxo de dados é reconhecido da mesma forma pelo ESSA, pois ele encapsula essa abstração provendo uma maneira simplificada para esses diferentes protocolos. Este exemplo prova a atuação e supervisão com Modbus. 5.3.3

Caso 03

Foi definido um configuração para Arduino em que pudesse ser demonstrado mais de uma caracteristica do ESSA, portanto a Caso 03 possui uma visão de uma supervisão que capta uma entrada de um sensor mecânico, no caso sendo utilizado um potenciômetro para simular um valor de tensão, e através do ESSA, esse valor é repassado para um Led. O valor do potenciômetro é supervionado por um componente Dial. Também possui um botão na IHM que desliga esse Led. É demostrado como dois componentes distintos podem ser utilizados para inferir em um único componente. Como a plataforma desse caso é o Arduino, a Figura 5.11 mostra o esquema que nele foi montado. O Arduino está rodando com o protocolo Firmata. O Potenciômetro é um componente eletrônico usada para variar a resistência, quando ele é movimentado, o valor de resistencia diminui ou aumenta. Após a criação do esquema, é criado a IHM de supervisão pelo QtDesigner, apresentado na Figura 5.12. Ela contém um Display, que mostra uma situação, e como é uma

55

Figura 5.10: ESSA em execução, com protocolo Modbus

Figura 5.11: Esquema Arduino. Caso 03 simulação, pode-se imaginar que esse componente pode estar aberto ou fechado, e o botão que o liga e desliga. Então foi definido a sua configuração, que necessita de uma Tag para o potenciômetro, que recebe o seu valor e o conecta por um adaptador ao Dial para prover uma supervisão visual, uma Tag Led que conecta o Led presente no arduino ao sistema e uma Tag para o botão da IHM. Então foi definido as interfaces que conectam as Tags com os componentes

56

Figura 5.12: Tela criada para Supervisão. Caso 03 da IHM e que vinculam as ações mecânicas com o software e vice-versa. Necessitou de quatro AdapterContinuous, um para conectar o Dial a Tag do potenciômetro, um para Conectar a Tag do potenciômetro ao Led para que o Led possa receber o valor da variação mecânica efetuada, um para conectar o botão da IHM ao valor da sua Tag, e outro para conectar o valor da Tag do botão ao valor da Tag Led para que quando clicado no botão, o Led se desligue. Também foi necessário definir um AdapterDiscret que de acordo com o botão, apresenta no display uma resposta diferente do que o valor que o botão representa. A Figura 5.13, mostra o arquivo de configuração que foi definido para este caso. Criado a IHM e a sua configuração, agora é necessário especificar o ESSA para criar um SCADA correspondente, visto na Figura 5.14. Assim que ele entra em execução, a tela apresentada é idêntica à criada pelo QtDesigner, Figura 5.15. Neste ponto, o sistema ainda não está executando a supervisão, ele foi configurado para aguardar 3 segundos para que todos os módulos sejam carregados e configurados, para então entrar em execução. Assim que a supervisão é iniciada foi possível atuar mecanicamente sobre o sistema utilizando o potenciômetro. Isto occore pois a sua movimentação reflete na Tag que é vinculada ao potenciômetro, que recebe o valor dessa variação, que então é repassada ao componente Dial e também ao Led. Esse comportamento ocorre pois foi configurado um adaptador que faz com que a atualização da Tag do potenciômetro seja repassada a Tag do Led. Ao movimentá-lo, o Dial e o Led se alteram. Já o botão presente na IHM está conectado ao Led, então quando ele é pressionado, o led liga ou desliga. Independente se o potenciômetro é movimentado, se o Led foi desligado, ele não sofre atualização, somente após ser ligado. E o Display mostra na supervisão um correspondente para o botão, que é "Aberto"ou "Fechado", dependendo do seu estado. Quando desligado o Led pelo botão, pode-se perceber que o Dial continua a apresentar o valor proveniente do potenciômetro, pois a atuação somente está ocorrendo no Led.

57

Figura 5.13: Configuração ESSA. Caso 03

Figura 5.14: SCADA à partir do ESSA

Figura 5.15: Primeiros instantes de execução A Figura 5.16 mostra como ações no potenciômetro e botão afetam o sistema, pode ser visto que na imagem superior o potênciometro foi pouco movido, então o Led apresenta um baixo brilho. Ao centro houve uma maior movimentação que corresponde a um valor mais elevado, que representa um alto brilho no Led. Por ultimo, o inferior da imagem apresenta uma ação no botão, que desliga o Led e também altera a mensagem do estado desse botão. Essa é uma simulação, mas em um ambiente real poderia corresponder a um equipamento como uma caldeira, em que o potenciômetro corresponde a sua temperatura e o Led ao seu estado de ligada ou desligada. Como neste exemplo, poderia ser controlada

58

Figura 5.16: Resultados da movimentação do potenciômetro e do botão a sua temperatura e o seu desligamento. Poderia inclusive ser definido um script, para que assim que a temperatura chegar a um determinado valor de limite, a caldeira seja desligada automaticamente. 5.3.4

Caso 04

A ideia é a mesma do Caso 03, com algumas modificações visando algumas caracteristicas diferentes do ESSA, como o uso do Modbus e do botão físico. Aqui é efetuado uma simulação de CLP com o Arduino. A característica que o difere é a presença de um botão físico que trabalha em conjunto com um botão na IHM. O botão presente na tela possui agora uma imagem vinculada aos seus dois possiveis valores, que neste exemplo são imagens de uma porta aberta e fechada. O Led também representa este estado, se o botão estiver em modo aberto, o led ficará ligado, caso contrário ele se desliga, assim como o botão muda de valor. Outra característica é a presença do Slider na

59

IHM, em que ao ser movimentado, o seu correspondente valor atualiza o Led e também é plotado graficamente. A Figura 5.17 apresenta o esquema montado no Arduino.

Figura 5.17: Esquema Arduino como CLP Modbus. Caso 04 A tela na Figura 5.18 foi gerada à partir do QtDesigner, e contém os componentes Plot, Slider e Botão. O botão tem a sua propriedade PathImage definida de acordo com as imagens para o seu estado.

Figura 5.18: IHM de Supervisão. Caso 04 As características que compreendem esse sistema são definidas para posterior criação da configuração, apresentada na Figura 5.19. Ao pressionar o botão físico, o Led muda seu status de acordo com o correspondente da ação, se estava ligado então ele desliga. Como existe também um botão visual, que deve ter correspondencia com o botão físico, o seu valor deve sempre refletir o estado atual da aplicação. Existe uma hierarquia definida no sistema em que sempre um componente físico tem superioridade ao componente de

60

software. Que nada interfere na aplicação. Um exemplo seria alguém alterar um componente de tela e ao mesmo tempo o seu correspondente físico ser alterado. Nessa situação o software vai assumir a alteração do componente físico.

Figura 5.19: Configuração ESSA. Caso 04 Foi definido a existência de quatro Tags, uma para o Slider, Tag do Led, Tag para componente gráfico, e para o Botão. As adaptações para a IHM correspondem a quatro adaptadores do tipo AdapterContinuous, que correspondem a: adaptador do Slider para a Tag; Tag Slider para a Tag Led, para que o Led receba o valor variável do Slider; adaptação da Tag Gráfico para o componente de tela; e um adaptador do botão da IHM para a sua Tag. Essas características fazem com que ocorra uma supervisão do Slider, botão físico e o botão na IHM, e a atuação no Led e também no botão presente na IHM. Com a finalização da configuração, foi descrito o código para o ESSA criar um SCADA correspondente às configurações, Figura 5.20.

Figura 5.20: Definição do sistema para o ESSA no Caso 04 A Figura 5.21, mostra a o sistema em execução, com o Slider movimentado a um valor baixo, depois a um valor limite e posteriormente após pressionado o botão físico. Uma modificação de Slider, reflete na alteração do brilho do Led e ao mesmo tempo no valor atual apresentado pelo componente gráfico. Uma alteração de botão, tanto o físico quanto o widget visual, corresponde ao estado de ligado e desligado do Led, e também no seu respectivo valor do botão Widget, no caso da alteração física. 5.3.5

Caso 05: Completa execução

Com os casos de uso anteriores têm-se uma visão do funcionamendo do ESSA com algumas de suas diferentes características, mas nenhum exemplo apresentado contemplou

61

Figura 5.21: ESSA em execução. Caso 04 alguns dos recursos mais importantes providos pelo sistema, como Log e Alarme. Para isso, foi preparado um exemplo completo e funcional, que contempla aquisição de dados, dados simulados, interferência por hardware e software, e ainda Alarme e registros gerados pela supervisão. Foi criado uma IHM, Figura 5.22, que corresponde a essas características. Ela contém

62

um plotador gráfico, um componente termômetro, dois Dials, um Slider, um botão e um display do tipo LCD.

Figura 5.22: IHM proposta para Caso 05 Esse sistema foi criado utilizando o Arduino, a Figura 5.11 apresenta o esquema necessário. O funcionamento ocorre da seguinte forma, um potenciômetro corresponde a temperatura que será visível pelo termômetro, o Slider controla o brilho de um Led, o plotador apresenta um sinal simulado que é uma senoide, um dial mostra um sinal contínuo simulado e o outro dial é axiliar ao valor do Slider. Para isso foi necessário a criação de sete Tags: tagPotenciometro adquire sinal proveniente do potenciômetro. tagGrafico contendo um gerador simulado do tipo onda dente de serra. tagRPM com dado simulado contínuo. tagSlider representa no ESSA o valor do componente Widget Slider. tagLed conectada ao Led no Arduino. tagBotao que supervisiona o Widget botão. tagAux utilizada para mapear o valor do potenciômetro a uma nova escala. Após foram definidos os adaptadores necessários, sendo todos do tipo AdapterContinuous, que servem de integração entre as Tags e a IHM. Os mais importantes foram os responsáveis por conectar a tagPotenciometro, tagGrafico, tagSlider, e tagRPM com seu respectivo Widget. As tagPotenciometro, tagAuxiliar e tagSlider possuem uma escala de

63

valor, já que o potenciômetro e Led trabalham com sinais de 0 até 1, tendo seu valor variável nessa faixa. Isso foi necessário para que quando o Slider fosse movimentado, o valor refletido no Led fosse correspondente. Essa é uma propriedade existente para as instâncias de Adapter dentro do ESSA. A definição dessa aplicação está presente no Apêndice A[1-4]. Após configurado foi necessário criar a instância dessa aplicação, Figura 5.23.

Figura 5.23: ESSA, definição de execução para o Caso 05 Quando em execução, Figura 5.24, pode-se perceber como o movimento do Slider refletiu no Led, e também é apresentado a ocorrência de um alarme.

Figura 5.24: Scada ESSA em execução Havia sido definido um Alarme para a TagSlider. Uma vez que seu valor ultrapasse a faixa de 200, o alarme seria ativado. Isso ocorre e pode ser visto na segunda parte da figura 5.24. Como ouve a ocorrência de um alarme, o compoente Led presente na IHM de supervisão altera sua cor para vermelho, o que indica um aviso presente. Para visualizar esse aviso, Figura 5.25, é necessário clicar no Led para que seja apresentado uma janela com a ocorrencia que disparou um aviso, e assim que a janela é aberta o sistema volta a seu status normal, que corresponde a cor verde. Um registro constante de Alarmes pode ser visto na Figura 5.26, ele é acessado pelo menu da aplicação a qualquer momento, assim como os registros de Log, Figura 5.27,

64

Figura 5.25: Alerta da aplicação para a presença de um aviso também podem ser visualizado da mesma forma. Esses registros em modo texto, não são eliminados da aplicação até que seu prazo rotação seja atingido.

Figura 5.26: Visualização de Alarmes disparados Com essas caracteriticas obtém-se uma maior confiabilidade sobre os procesos supervisionados. É possivel obter informações em tempo real sobre o estado de cada componente. Caso ocorra uma falha, ela estará registrada, e poderá ser analizada posteriormente

65

Figura 5.27: Logs constantes na aplicação para cada novo valor para identificação do ocorrido. O alarme é uma ferramenta fundamental para a prevenção de incidentes, já que emite alertas para que possa se obter uma correção antes de alguma falha, além de também registrar a atividade do usuário frente ao ocorrido, pois sabe-se, se o usuário viu ou não a exibição desse alarme. Esses casos apresentam a obtenção dos objetivos propostos para o ESSA.

66

6

CONCLUSÃO

Neste trabalho foi apresentado o desenvolvimento de um Sistema SCADA Open Source voltado para hardware de baixo poder de processamento e pequenas e médias aplicações. Para a execução do projeto fez-se uma revisão do tema, consistindo em uma visão geral da automação industrial e de sistemas supervisórios, a fim de compreender o funcionamento desse tipo de sistema e, com isso, identificar os requisitos para o seu desenvolvimento. O modelo conceitual criado a partir dos requisitos identificados e do foco do trabalho procurou contemplar todas as funcionalidades presentes nos sistemas SCADA modernos, modularizando-o de forma que pudesse ser facilmente compreendido e estendido por usuários com conhecimentos de programação. A implementeção feita neste trabalho não chegou a contemplar todas as funcionalidades presentes no modelo conceitual devido ao tempo disponível para a sua conclusão. Entretando, pode-se afirmar que os objetivos do projeto foram atingidos. Os testes de funcionamento mostram um sistema funcional, que adquire dados de dispositivos remotos através de comunicação com protocolos conhecidos e consagrados na indústria. Os dados são apresentados em diferentes formas através de componentes visuais de uma IHM, são monitorados por alarmes e armazenados através de um sistema de log que ainda registra eventos ocorridos na planta. O supervisório roda satisfatoriamente em microcomputadores com sistemas operacionais Windows e Linux, bem como em plataformas SoC como o Raspberry Pi. A modularização do código permite estender o software sem comprometer o que já existe, o que é interessante para o desenvolvimento colaborativo típico de iniciativas open source. É possível considerar este um trabalho em desenvolvimento, cuja primeira versão está concluída neste trabalho de conclusão de curso. Como um possível trabalho futuro, sugere-se um software para o projeto interativo de aplicações ESSA, integrando o QtDesigner com funcionalidades de definição dos componentes não visuais do SCADA, como drivers, tags, alarmes, históricos e scripts. Além disso, novos protocolos de comunicação devem ser suportados. O suporte a clientes remotos através de provedores de dados e IHMs é um tópico de interesse, devido ao crescente uso de dispositivos móveis em tarefas industriais. E, claro, extensos testes em diferentes situações se fazem necessários, seja com hardware de prototipação, seja com hardware industrial, com CLPs e outros controladores. Por fim, reitera-se que este trabalho pretende ser uma contribuição à comunidade científica/acadêmica, no sentido de prover um software que pode auxiliar a supervisão de experimentos, mas também para o estudo desse tipo de software. E à comunidade open source, que carecia de um software para pequenas aplicações em sistemas embarcáveis. Esse projeto será disponibilizado em um repositório após defendido.

67

REFERÊNCIAS

ARDUINO. Arduino Uno. Disponivel em . Acesso em 13/12/2014. BERG, J. MinimalModbus. Disponivel em . Acesso em 29/06/2014. BORGES, L. P.; CARVALHO DORES, R. de. Automação Predial Sem Fio Utilizando BACnet/ZigBee Com Foco em Economia de Energia. 2010. Trabalho de Conclusão de Curso — Universidade de Brasília - Faculdade de Tecnologia, Brasilia-DF. BRUGNARI, A.; MAESTRELII, L. H. M. Automação Residencial via WEB. 2010. Trabalho de Conclusão de Curso — Pontifícia Universidade Católica do Paraná - Curso de Engenharia de Computação, Curitiba. BRUIJN, T. pyFirmata. Disponivel em . Acesso em 29/06/14. CONSTAIN, N. B. P. Integração de sistemas SCADA com a implementação de controle supervisório em CLP para sistemas de manufatura. 2011. Dissertação de Mestrado — Universidade Federal de Santa Catarina - Programa de Pós-Graduação em Automação e Sistemas. DIANKOV, R. Automated Construction of Robotic Manipulation Programs. 2010. Tese (Doutorado em Ciência da Computação) — Carnegie Mellon University, Robotics Institute. DUTRA, A. C. S.; ALMEIDA, R. L. A Nova Geração de Supervisórios. InTech, [S.l.], n.132, p.20–27, 2011. effbot.org. ElementTree Overview. Disponivel em . Acesso em 03/04/2015. Elipse Software. Manual do Usuário HMI/SCADA SOFTWARE. [S.l.]: Elipse Software, 2010. Disponível em . Acesso em 29/11/2014. FILIPEFLOP, B. Primeiros Passos com Raspberry Pi B+. Disponível em . Acesso em 03/12/14.

68

FIRMATA. Firmata Library. Disponível em . Acesso em 29/06/14. GROUP, L. Mango – the world’s most popular open-source M2M platform. Disponível em . Acesso em 30/11/2014. HEIN, W. Raspberry Pi aplicado a projetos do mundo real. Linux Magazine, [S.l.], n.100, Março 2013. Disponível em . Acesso em 03/12/2014. HOEFS, J. firmata/protocol. Disponivel em . Acesso em 03/04/2015. HUNTER, J. D. Matplotlib: a 2d graphics environment. Computing In Science & Engineering, [S.l.], v.9, n.3, p.90–95, 2007. INDUSOFT. InduSoft Web Studio. Disponível em . Acesso em 30/11/2014. ITAIPU ELETRôNICO JIE, J. de. Troca de turno: o ritual da ccr. Disponível em . Acesso em 03/12/2014. LOPES, K. L. G. V. Branqs Automação - Introdução à Automação Industrial. Disponível em . Acesso em 26/11/2014. MCCRADY, S. G. Designing SCADA Application Software. [S.l.]: Elsevier, July 2013. EDITORA, N. (Ed.). Arduino básico. [S.l.: s.n.], 2011. METSKER, S. J. Padrões de Projeto em Java. Porto Alegre: Bookman, 2004. 407p. Modbus Organization. The Modbus Organization. Disponível em . Acesso em 03/11/14. MORAES, C. C.; CASTRUCCI, P. L. Engenharia de automação industrial. 2.ed. Rio de Janeiro: LTC, 2007. NOVUS. Controladores programáveis com IHM incorporada - Família XL. Disponível em . Acesso em 04/12/14. OPENSCADA. OpenSCADA. Disponível em . Acesso em 30/11/2014. AMGH (Ed.). Controladores Lógicos Programáveis. 4o Edição.ed. [S.l.: s.n.], 2014. MCGRAW-HILL (Ed.). Engenharia de Software. 6o Edição.ed. [S.l.: s.n.], 2006.

69

Python.org. Python Programming Language - Official Website. Disponível em . Acesso em 01/07/15. Python.org. Graphical User Interface FAQ - Python 2.7.10 documentation. Disponível em . Acesso em 01/07/15. Raspberry Pi Foundation. Raspberry Pi - An ARM GNU/Linux box for $25. 2013. RATHMAN, U.; WILGEN, J. Qwt - Qt Widgets for Technical Applications. Disponível em . Acesso em 03/03/14. RAYBAUT, P.; NYO, G. pythonxy - Scientific-oriented Python Distribution Based on Qt and Spyder. Disponível em . Acesso em 03/08/14. RAYSARO, M. C. Sistema Open-Source de Supervisão Controle e Aquisição de Dados. Disponível em: . Acesso em 12/10/2014. RIEGEL, J. FreeCAD: an open source parametric 3d cad modeler. Disponível em: . Acesso em 13/02/2015. Riverbank Computing. Riverbank | Software | PyQt | What is PyQt? Disponível em: . Acesso em 13/08/2015. Riverbank Computing. New-style Signal and Slot Support. Disponível em: . Acesso em 14/05/2015. ROCHA, C. R.; SCHOLL, M. Conceptual Design of an Open Source SCADA System. In: INTERNATIONAL CONFERENCE ON FLEXIBLE AUTOMATION AND INTELLIGENT MANUFACTURING - FAIM 2015, 25., 2015, Wolverhampton. Proceedings. . . The Choir Press, 2015. v.2, p.182–189. ROCHA, V. Automação e Sensoreamento Remoto utilizando Software Livre "SCADA". Disponível em , Pag3. Acesso em 30/11/2014. ros.org. ROS.org - Powering the world’s robots. Disponível em: . Acesso em 05/07/2015. HALL, P. (Ed.). Princípios de Mecatrônica. [S.l.: s.n.], 2005. SANTOS, V. Automação e Redes Industriais. Disponível em . Acesso 18/11/14. SCADABR. Manual ScadaBR Sistema Open-Source Supervisão e Controle. [S.l.: s.n.], 2010. Disponível < / i n s t a l l > < l o g s p a t h = " / home / s c h o l l / Dropbox / S p y d e r / e s s a / l o g s / " >< / l o g s > < / window> 0.1< / scan> commArduino< / name> < p o r t > / dev / ttyACM0< / p o r t > < b a u d r a t e >9600 < / b a u d r a t e > < / comm> < t a g name= " t a g G r a f i c o " i d = " 1 " > < s t a r t V a l u e >0< / s t a r t V a l u e > False < / readOnly> 0.1< / scan> < p r o v i d e r E n a b l e >True< / p r o v i d e r E n a b l e > < p r o v i d e r > S i n e G e n e r a t o r ( 1 , min =−1,max =1 , s t e p = 1 0 ) < t a g name= " t a g P o t e n c i o m e t r o " i d = " 2 " > < s t a r t V a l u e >0< / s t a r t V a l u e > False < / readOnly> 0.1< / scan> < p r o v i d e r E n a b l e >True< / p r o v i d e r E n a b l e > < p r o v i d e r > A r d u i n o L i n k ( b o a r d =commArduino , p i n = " a : 0 : i " ) < t a g name= " tagRPM " i d = " 3 " > < s t a r t V a l u e >0< / s t a r t V a l u e > False < / readOnly> 0.1< / scan> < p r o v i d e r E n a b l e >True< / p r o v i d e r E n a b l e > < p r o v i d e r > S e q u e n c e G e n e r a t o r ( 1 , min =0 , max =3000 , s t e p = 1 0 ) < t a g name= " t a g S l i d e r " i d = " 4 " > < s t a r t V a l u e >0< / s t a r t V a l u e > False < / readOnly> 0.1< / scan> False < t a g name= " t a g L e d " i d = " 5 " > < s t a r t V a l u e >0< / s t a r t V a l u e > False < / readOnly> 0.1< / scan> False < p r o v i d e r > A r d u i n o L i n k ( b o a r d =commArduino , p i n = " d : 9 : p " ) < t a g name= " t a g B o t a o " i d = " 6 " > < s t a r t V a l u e >1< / s t a r t V a l u e > True< / readOnly > 0.1< / scan> False

73

Apendice A.2: Especificação de configuração no formato XML < t a g name= " tagAux " i d = " 7 " > < s t a r t V a l u e >1< / s t a r t V a l u e > True< / readOnly > 0.1< / scan> False < a d a p t e r t y p e = " A d a p t e r C o n t i n u o u s " name= " A d a p t e r 0 1 " i d = " 1 " > < s t a r t V a l u e >1< / s t a r t V a l u e > p l o t < / widget> value tagGrafico < ta gPro prier ty >value < d i r e c t i o n >1< / d i r e c t i o n > < a d a p t e r t y p e = " A d a p t e r C o n t i n u o u s " name= " A d a p t e r 0 2 " i d = " 2 " > < s t a r t V a l u e >1< / s t a r t V a l u e > thermometer< / widget> value tagPotenciometro < ta gPro prier ty >value < d i r e c t i o n >1< / d i r e c t i o n > 0 . 0 < / minimum> 1 . 0 < / maximum> 0< / newMinimum> 100< / newMaximum> < a d a p t e r t y p e = " A d a p t e r C o n t i n u o u s " name= " A d a p t e r 0 3 " i d = " 2 " > < s t a r t V a l u e >1< / s t a r t V a l u e > dial_Widget< / widget> value tagSlider < ta gPro prier ty >value < d i r e c t i o n >1< / d i r e c t i o n > < a d a p t e r t y p e = " A d a p t e r C o n t i n u o u s " name= " A d a p t e r 0 4 " i d = " 2 " > < s t a r t V a l u e >1< / s t a r t V a l u e > < widget >displayLCD< / widget > value tagPotenciometro < ta gPro prier ty >value < d i r e c t i o n >1< / d i r e c t i o n > 0 . 0 < / minimum> 1 . 0 < / maximum> 0< / newMinimum> 100< / newMaximum>

74

Apendice A.3: Especificação de configuração no formato XML < a d a p t e r t y p e = " A d a p t e r C o n t i n u o u s " name= " A d a p t e r 0 5 " i d = " 3 " > < s t a r t V a l u e >1< / s t a r t V a l u e > dial_3Widget< / widget> value < t a g >tagRPM< / t a g > < ta gPro prier ty >value < d i r e c t i o n >1< / d i r e c t i o n > < a d a p t e r t y p e = " A d a p t e r C o n t i n u o u s " name= " A d a p t e r 0 6 " i d = " 4 " > < s t a r t V a l u e >1< / s t a r t V a l u e > s l i d e r < / widget> value tagSlider < ta gPro prier ty >value < d i r e c t i o n >2< / d i r e c t i o n > < a d a p t e r t y p e = " A d a p t e r C o n t i n u o u s " name= " A d a p t e r 0 7 " i d = " 6 " > < s t a r t V a l u e >1< / s t a r t V a l u e > onOffButton< / widget> value tagBotao< / tag> < ta gPro prier ty >value < d i r e c t i o n >2< / d i r e c t i o n > < a d a p t e r t y p e = " A d a p t e r C o n t i n u o u s " name= " A d a p t e r 0 8 " i d = " 7 " > < s t a r t V a l u e >1< / s t a r t V a l u e > tagLed< / widget> state tagBotao< / tag> < ta gPro prier ty >value < d i r e c t i o n >1< / d i r e c t i o n > < a d a p t e r t y p e = " A d a p t e r C o n t i n u o u s " name= " A d a p t e r 0 9 " i d = " 2 " > < s t a r t V a l u e >1< / s t a r t V a l u e > < w i d g e t > tagAux < / w i d g e t > value tagSlider < ta gPro prier ty >value < d i r e c t i o n >1< / d i r e c t i o n > 0< / minimum> 255< / maximum> 0 . 0 < / newMinimum> 1 . 0 < / newMaximum> < a d a p t e r t y p e = " A d a p t e r C o n t i n u o u s " name= " A d a p t e r 1 0 " i d = " 5 " > < s t a r t V a l u e >1< / s t a r t V a l u e > < w i d g e t > tagAux < / w i d g e t > value < tag >tagLed< / tag > < ta gPro prier ty >value < d i r e c t i o n >3< / d i r e c t i o n >

75

Apendice A.4: Especificação de configuração no formato XML Alarme1 < / name> < i d >1< / i d > tagSlider < t y p e >maxmax< / t y p e > < v a l u e >200< / v a l u e > < l i f e G u i >15< / l i f e G u i > < / alarm> < / alarms>