UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR CURSO DE ENGENHARIA DE COMPUTAÇÃO

Transcrição

1 UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR CURSO DE ENGENHARIA DE COMPUTAÇÃO APLICATIVO BASE PADRÃO DE SISTEMA SUPERVISÓRIO PARA PROCESSOS DE AUTOMAÇÃO INDUSTRIAL Adelson Alves Júnior Raimundo Celeste Ghizoni Teive, Dr. Eng. Orientador São José, novembro / 2014

2 UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR CURSO DE ENGENHARIA DE COMPUTAÇÃO APLICATIVO BASE PADRÃO DE SISTEMA SUPERVISÓRIO PARA PROCESSOS DE AUTOMAÇÃO INDUSTRIAL Adelson Alves Júnior São José, novembro / 2014 Orientador: Raimundo Celeste Ghizoni Teive, D. Eng. Área de Concentração: Automação de Sistemas. Linha de Pesquisa: Desenvolvimento de Sistemas Computacionais. Palavras-chave: Sistema supervisório, Controlador lógico programável, Banco de dados, Protocolo de comunicação, Controle e Automação. Número de páginas: 107 RESUMO O presente trabalho trata de uma solução baseada em um software aplicativo padrão básico de um sistema supervisório para operação e supervisão. O foco é o estudo e desenvolvimento do aplicativo para atender as funcionalidades básicas dos sistemas de automação, tais como supervisão de eventos e de variáveis analógicas e armazenamento em banco de dados e relatórios. Cada processo industrial apresenta características particulares que devem ser customizadas no aplicativo, de forma a representar corretamente o que está sendo supervisionado, isso aumenta a complexidade de desenvolvimento do produto final. Entretanto, para todos os tipos de sistema supervisório voltados à automação de processos, existem características comuns, principalmente nos equipamentos de campo que serão supervisionados. Este trabalho descreve o projeto de um software aplicativo para sistema supervisório, criado para facilitar a customização e ainda fornecer um produto de boa qualidade. A metodologia adotada no desenvolvimento deste software foi o modelo cascata, por representar claramente as etapas a serem seguidas no decorrer deste trabalho. A arquitetura da solução e toda estrutura do aplicativo, bem como as funcionalidades e componentes desenvolvidos serão descritos e justificados, assim como serão abordadas as ferramentas de software que foram utilizadas para tornar possível o desenvolvimento da solução proposta, uma delas adquirida pela empresa e outra fornecida pela instituição de ensino. A validação do software aplicativo como um todo, ocorreu por meio da utilização do mesmo na supervisão e operação em um sistema de automação real, apresentando resultados satisfatórios.

3 ABSTRACT The present work concerns a solution based on a basic standard application software of a supervisory system for operation and supervision. The focus is the study and development of the application to meet the basic features of automation systems, such as supervision of events and of analog variables and storage in database and reports. Each industrial process presents particular characteristics that must be customized in the application in order to correctly represent what is being monitored, this increases the complexity in developing the final product. However, for all types of supervisory system aimed at process automation, there are common characteristics, mainly in the field devices that will be supervised. This work describes the design of an application software for supervisory system, designed to facilitate customization and to offer a good quality product. The methodology adopted in developing this solution was the waterfall model, since it clearly represents the steps to come in this monograph. The solution architecture and all application structure, also the features and developed components, will be described and justified, as well as the software tools that were used to make possible the development of the proposed solution will be addressed, one of them acquired by the company and the other provided by the educational institution. The validation of the application software occurred by the use of the software in the supervision of a real automation system and showed satisfactory results.

4 LISTA DE FIGURAS Figura 1 Divisão hierárquica de um processo de automação industrial Figura 2 Exemplos de antigos sistemas telemétricos Figura 3 Diagrama genérico do sistema SCADA Figura 4 Resultado final proposto pelo trabalho Figura 5 Metodologia a ser seguida através do modelo cascata Figura 6 Esquema do software compilador com o programa do usuário Figura 7 Rede local de supervisão e de campo Figura 8 Sequência de frames na leitura, CLP Mitsubishi da linha Melsec Figura 9 Sequência de frames na escrita, CLP Mitsubishi da linha Melsec Figura 10 Formato básico de transmissão de dados, CLP Mitsubishi da linha Melsec Figura 11 Conceitos do modelo relacional Figura 12 Componentes físicos de um sistema SCADA Figura 13 Arquitetura simplificada do SSC Figura 14 Estrutura e localização dos recursos no E3 Studio Figura 15 Seções de um objeto Relatório Figura 16 Exemplo de um objeto XControl Figura 17 Exemplo de um objeto XObject Figura 18 Imagem do programa SSMS Figura 19 Exemplo de uma consulta e resultado no SSMS Figura 20 Diagrama dos casos de uso Figura 21 Diagrama do banco de dados Figura 22 Hierarquia de navegação entre telas Figura 23 Lista de arquivos no domínio Figura 24 Objetos dentro de cada arquivo de biblioteca Figura 25 Objetos dentro de cada arquivo de aplicação Figura 26 Tela inicial com sistema de login para o usuário Figura 27 Tela de informações do fornecedor do sistema Figura 28 Tela cabeçalho da aplicação Figura 29 Tela roda pé da aplicação Figura 30 Drivers de comunicação do protótipo Figura 31 Modelo de tags para o driver Modbus Figura 32 Modelo de tags para o driver Mitsubishi Figura 33 Associação de uma tag em um objeto de tela Figura 34 Carregamento automático de áreas para tela de eventos online Figura 35 Tela de visualização de alarmes e eventos online Figura 36 Consulta aplicada ao componente E3Browser na tela de eventos históricos Figura 37 Tela de visualização de alarmes e eventos históricos Figura 38 - Tela de visualização do gráfico de tendências Figura 39 Relacionamento entre tabelas da biblioteca PenGroup Figura 40 Janela do tipo popup para impressão do relatório Figura 41 Componente do usuário para abrir tela tipo modal Figura 42 Componente relatório criado para os eventos do sistema Figura 43 Script criado no relatório para a biblioteca PenGroup Figura 44 Planilha de informações dos pacotes Figura 45 Esteira transportadora de pacotes e separação das docas... 93

5 Figura 46 Mapa de endereços lógicos do CLP Figura 47 Trecho de código customizado para importar planilha Figura 48 Relatório que exporta o arquivo em formato txt Figura 49 Tela utilizada para importar o arquivo csv Figura 50 Tela de sinótico do sistema Figura 51 Arquivo txt exportado para uso na base de dados da Via Log Figura 52 Tela de monitoração das docas

6 LISTA DE TABELAS Tabela 1 Padrões de interface serial Tabela 2 Padrões de interface Ethernet Tabela 3 Classificação do CLP Tabela 4 Comparação das edições do SQL Server Tabela 5 Telas acessadas conforme o grupo de usuários Tabela 6 Campos para ordenação e filtro na tela de alarmes e eventos online Tabela 7 Quantidade de horas de customização por componente

7 LISTA DE ABREVIATURAS E SIGLAS ASCII BD CLP COM CRC DLL E/S EIA FBD IEC IEEE ISV LAN LD LRC MDB NEMA ODBC OLAP OPC PC RTU SCADA SFC SQL SSMS SSC TCC TCP/IP VBScript XML American Standard Code for Information Interchange Banco de Dados Controlador Lógico Programável Component Object Model Cyclical Redundancy Checking Dynamics Link Library Entrada/Saída Eletronic Industries Association Function Block Diagram International Electrotecnical Commission Institute of Electrical and Electronic Engineers Independent Software Vendor Local Area Network Ladder Diagram Longitudinal Redundancy Checking Microsoft Access National Electrical Manufactures Association Open Database Connectivity Online Analytical Processing OLE Process Control Personal Computer Remote Terminal Unit Supervisory Control and Data Acquisition Sequential Function Chart Structured Query Language SQL Server Management Studio Sistema de Supervisão e Controle Trabalho de Conclusão de Curso Transmission Control Protocol / Internet Protocol Visual Basic Script extensible Markup Language

8 SUMÁRIO INTRODUÇÃO PROBLEMA DE PESQUISA Solução Proposta Delimitação de Escopo Justificativa OBJETIVOS Objetivo Geral Objetivos Específicos METODOLOGIA ESTRUTURA DO TRABALHO FUNDAMENTAÇÃO TEÓRICA CONTROLADOR LÓGICO PROGRAMÁVEL Sensores Linguagem de Programação Interface de Comunicação Classificação REDE E PROTOCOLO DE COMUNICAÇÃO Aquisição de Dados Modos de Comunicação Protocolo de Comunicação Modbus Protocolo de Comunicação Melsec-FX BANCO DE DADOS Modelo Relacional SISTEMA DE CONTROLE E SUPERVISÃO ELIPSE E Módulos Componentes Relatório Bibliotecas de Usuários SQL SERVER Componentes do SQL Server Bancos de Dados Integrados do SQL Server SQL Server Management Studio ESPECIFICAÇÃO DOS REQUISITOS ETAPAS DE PLANEJAMENTO CONSIDERAÇÕES FINAIS DESENVOLVIMENTO VISÃO GERAL DO SISTEMA... 68

9 3.2 ANÁLISE DE REQUISITOS MODELAGEM DO SISTEMA DETALHAMENTO DO DESENVOLVIMENTO Segurança e Suporte Hierarquia de Navegação Driver de Comunicação Alarmes e Eventos Gráfico de Tendência Objetos do Usuário Relatórios DESCRIÇÃO DOS EXPERIMENTOS RESULTADOS CONSIDERAÇÕES FINAIS CONCLUSÕES TRABALHOS FUTUROS REFERÊNCIAS BIBLIOGRÁFICAS

10 10 INTRODUÇÃO Os processos industriais, que eram acompanhados pelos operadores em grandes painéis contendo gráficos, instrumentos, botões acionadores e lâmpadas, passaram a ser monitorados através de telas de microcomputadores. Num segundo momento, os operadores passaram a operar as plantas através do teclado dos microcomputadores. Os antigos instrumentos começaram então a ser substituídos por outros contendo microprocessadores, que têm a mesma base dos microcomputadores, capazes de realizar tarefas e tomar decisões de forma automática, nascendo assim o conceito de automação industrial (ALVES, 2005). A utilização de todas estas ferramentas e métodos torna possível desenvolver sistemas de automação compostos por uma série de sensores, atuadores, controladores e outros dispositivos conectados entre si por uma rede, os quais cooperam para realização de tarefas. Isso traz uma série de vantagens quanto à confiabilidade, modularidade, facilidade de compreensão e custo em comparação com sistemas centralizados anteriormente utilizados (LUGLI; SANTOS, 2010). A automação pode ser definida como sendo, qualquer sistema, apoiado em computadores, que substitui o trabalho humano, em favor da segurança das pessoas, da qualidade dos produtos, rapidez da produção ou da redução de custos, assim aperfeiçoando os complexos objetivos das indústrias, dos serviços ou bem estar (MORAES; CASTRUCCI, 2007). Na automação industrial estão reunidas três grandes áreas da engenharia (WEG, 2006): Mecânica: máquinas que possibilitam transformar matérias primas em produtos acabados. Elétrica: geradores, motores, acionamentos e circuitos eletrônicos que são indispensáveis para as malhas de produção. Computação: redes, bases de dados, hardwares e softwares que permitem disponibilizar as informações a todos os níveis de uma empresa. Os sistemas automatizados podem ser extremamente complexos, porém observando as partes que o compõem percebe-se que o nível de complexidade diminui, porque os subsistemas

11 11 possuem características similares, simples e de fácil entendimento. Os componentes básicos de um sistema de automação são (WEG, 2006): Processo físico: representado pela mecânica das máquinas, esteiras, etc., são os objetos monitorados e de onde é coletada a informação para o controle do processo. Sensor: dispositivo eletroeletrônico que responde a um estímulo físico/químico e que tem a capacidade de transformar em sinal elétrico as grandezas físicas como nível, temperatura, pressão, etc., para que sejam mensuradas. Atuador: elemento que produz movimento para executar tarefas ordenadas pelo controlador através de acionamento manual, elétrico ou mecânico. Controlador: equipamento digital que possui memória de armazenamento não volátil, onde ficam contidas as instruções lógicas e aritméticas, executando através de rotinas cíclicas o controle do processo ou parte dele. Rede de comunicação: está na possibilidade dos dispositivos digitais com processamento próprio conseguirem comunicar-se juntamente com o PC (Personal Computer) e entre todos os elementos da estrutura da automação, através de um meio físico (rede) para transmissão de dados. Supervisão: sistema que utiliza um software que permite supervisionar variáveis e operar todo um processo ou partes dele, conectado através drivers de comunicação. Gerência: responsável pela coordenação, planejamento do processo e das vendas de uma empresa, através das informações coletadas pelos sensores e processados por um sistema de supervisão. Na Figura 1, está apresentada uma estrutura hierárquica em termos de níveis funcionais de um processo de automação industrial, ao qual este trabalho está baseado para representar dentro dos níveis da pirâmide da automação a posição ocupada pelo SSC (Sistema de Supervisão e Controle).

12 12 Figura 1 Divisão hierárquica de um processo de automação industrial Fonte: Adaptado de Moraes e Castrucci (2007). Na Figura 1 estão presentes cinco níveis em que um processo de automação industrial pode ser particionado. Cada nível é responsável pela seguinte função (MORAES; CASTRUCCI, 2007): Nível 01: onde se encontram as máquinas, atuadores, bombas, válvulas, sensores entre outros componentes da planta. Nível de onde são transferidas as informações dos equipamentos em direção ao nível superior que é o de controle. Neste nível, comumente referenciado como chão de fábrica encontram-se as redes industriais que estão em constante evolução. Nível 02: equipamentos digitais, dinâmicos e lógicos que executam o controle automático do processo, podendo ser centralizado ou distribuído. Concentra as informações sobre o nível 01. Nível 03: supervisão e operação do processo que está associado ao controle da planta. Recebe as informações dos controladores para apresentar e armazenar de forma organizada estes dados ao operador do sistema. Nível 04: gerenciamento da planta onde é feita a programação e planejamento da produção, fazendo a logística de suprimentos. Constituído por banco de dados, fornece índices de qualidade, relatórios e estatística do processo.

13 13 Nível 05: planejamento estratégico, onde são administrados os recursos da empresa objetivando vendas e custos em geral. Nível gerenciado através de um computador central por softwares corporativos. O SSC é parte fundamental de praticamente qualquer sistema de automação de processos, sendo popularmente conhecido como sistema SCADA (Supervisory Control and Data Acquisition). Os primeiros sistemas, basicamente telemétricos, apresentavam informações do processo através de um painel com lâmpadas e indicadores analógicos, apresentando algumas dificuldades básicas (MELENDEZ; LUIS, 2001): A supervisão normalmente era feita em mesas ou portas de painéis com lâmpadas, chaves e indicadores analógicos, ocupavam grande espaço. Estando em um ponto de controle o operador não tinha a visão rápida do restante da planta; Os sistemas dependiam de relacionamento entre outros sistemas para melhor eficiência no controle do processo, como normalmente a planta industrial possui grande área construída, seria comum que máquinas e equipamentos ficassem distantes um do outro dificultando a integração, e; Deslocamento constante dos operadores até a área dos controladores, pois não existia uma sala de operação onde pudessem ajustar e comandar o processo. Na Figura 2 aparecem três imagens que representam os antigos sistemas telemétricos, com grandes mesas e painéis luminosos, sendo que uma delas aparece um operador manipulando os botões para determinado equipamento, evidenciando que nesse momento ele não tem visão dos demais indicadores.

14 14 Figura 2 Exemplos de antigos sistemas telemétricos Fonte: Google imagens (2014). Um sistema SCADA é composto não somente pelo SSC, mas também pela instrumentação, CLP (Controlador Lógico Programável), RTU (Remote Terminal Unit) e toda infraestrutura de comunicação utilizada no sistema de automação e controle (SOUZA, 2005). Isto pode ser visto na Figura 3. Figura 3 Diagrama genérico do sistema SCADA Fonte: Adaptado de Souza (2005).

15 15 Os sistemas SCADA de processos industriais automatizados desempenham três atividades básicas (SOUZA, 2005): Supervisão: funções de monitoramento de variáveis analógicas ou digitais através de gráficos, relatórios, displays em tela, browsers, frames, quadros, etc. Operação: substituição das mesas de controle por comandos executados através de botões em janelas e telas. Controle: as ações de controle ficam nas RTUs ou CLPs e toda a lógica é executada através destes, sendo assim o SSC é responsável somente por ajustes de parâmetros e monitoramento. Segundo Alvez (2005), os sistemas SCADA são destinados ao controle de processos onde predominam grupos de poucas variáveis contínuas e discretas, dispersos em uma grande área geográfica. Para executar essas tarefas o sistema supervisório deve utilizar algum sistema computacional, ou software de supervisão, que seja capaz de se comunicar com o processo indiretamente através do hardware de controle (CLP). Os sistemas automatizados de monitoração e controle modernos são constituídos por redes de comunicação, dispositivos de campo, diversos tipos de equipamentos e computadores. Com a evolução da tecnologia, os computadores passaram a ter um papel importante na supervisão dos sistemas, coletando através dos CLPs e RTUs, e tornando disponíveis os dados já formatados do processo. O SSC permite coletar dados do processo, além de monitorá-lo e atuar sobre ele com algum controle em nível de supervisão. O software de supervisão geralmente está localizado em uma sala de controle onde ficam presentes os operadores do sistema. Nesta sala estão às estações de operação com um ou mais terminais de vídeo, teclados, impressoras e dentre outros dispositivos que se façam necessários. Na estação de operação é instalado o software de supervisão que tem se mostrado de fundamental importância na estrutura de gestão da empresa, pois passou a ser visto como uma relevante fonte de informação (FRANCA, 2011). O SSC surgiu com a função básica de fornecer uma interface amigável e normalmente gráfica com os equipamentos do processo, informando-o em tempo real de todos os eventos de importância da planta através da integração dos sistemas lógicos e de automação, como os CLPs, através da troca de dados entre as estruturas físicas de comando em um ambiente de rede local, disponibilizando informações ao operador em uma estação de trabalho, para que o mesmo consiga

16 16 acompanhar, gerenciar ou manipular variáveis do processo automatizado (ROSÁRIO, 2005), algumas funções estão listadas a seguir: Monitoramento de variáveis analógicas em tempo real; Sinalizações de falhas ou condições indevidas através de eventos (alarmes); Ajustes de parâmetros tais como setpoints de malhas de controle e eventos; Envio de comandos; Armazenamento e consultas; Gráficos históricos, e; Emissão de relatórios. Dentre as funções de um SSC, tem-se que destacar na aquisição de dados a característica de vínculo bidirecional, onde os dados são recebidos e enviados para os equipamentos do chão de fábrica. Uma característica importante é a capacidade de integração com equipamentos de vários fabricantes diferentes, conseguido através de pacotes de software denominados drivers de comunicação (PENIN, 2012). Com um SSC instalado em um processo automatizado é possível adquirir vantagens tais como (LAURINDO, 2003): Qualidade: Através do monitoramento das variáveis do processo produtivo é possível determinar níveis ótimos de trabalho. Caso estes níveis saiam de uma faixa considerada aceitável o SSC pode gerar alarmes em telas, e então o operador tomará as devidas providências para um eventual problema. Redução de custos operacionais: Um processo produtivo possui inúmeros instrumentos de medição. O tempo e a quantidade de funcionários especializados necessários para percorrer todo o processo de produção são reduzidos. Planilhas manuais não seriam mais necessárias evitando assim a probabilidade de erros humanos. O SSC centraliza todas as leituras dos instrumentos de campo, com isso será gerado gráficos de tendência e gráficos históricos das variáveis do processo.

17 17 Maior desempenho de produção: Através das leituras dos instrumentos de campo as intervenções são feitas rapidamente, garantindo uma uniformidade sobre o controle do processo. Problemas de parada de máquina por defeitos podem ser diagnosticados pontualmente assim como ajustes de parametrização serão mais fáceis. Base para outros sistemas: O SSC pode coletar os dados do processo produtivo e armazená-los em banco de dados. Estes dados podem ser utilizados para gerar informações importantes, sendo integrados com demais sistemas onde esta informação poderá ser útil. Existem muitos fabricantes de softwares para sistemas supervisórios hoje no mercado, cada um com seus recursos e custos envolvidos. A seguir estão listados alguns softwares destinados ao desenvolvimento de sistemas supervisórios, são eles: Fix (Intellution) Wizcon Operate it (ABB) Gênesis Cte Factory Link RSView (Rockwell Allen Bradley) Unisoft Elipse (nacional) WinnCC Citect Intouch (Wonderware) Alguns critérios para a escolha e especificação do SSC devem ser adotados. Alguns dos fatores que devem ser considerados são (PENIN, 2012): Conectividade: O sistema deve prever a integração com diversos elementos de diferentes fabricantes, oferecendo interfaces tais como OPC (OLE Process Control), ODBC (Open Database Connectivity), XML (extensible Markup Language), TCP/IP (Transmission Control Protocol / Internet Protocol) para viabilizar essa integração. A escolha deve visar também softwares desenvolvidos por ISV (Independent Software Vendor), pois estes procuram compatibilidade com maior número possível de fabricantes. Arquitetura aberta: É desejável que o sistema de supervisão ofereça meios para acesso direto a base de dados (tags) ou para desenvolvimento de novas interfaces de comunicação.

18 18 Facilidades de uso: A ferramenta deve ser de fácil assimilação, manutenção e expansão durante as fases de desenvolvimento e implantação do sistema. Escalabilidade: Deve ser compatível com diferentes SO. Adequação ao processo: Oferecer tipos de licença para o mesmo produto, com diferentes limitações a fim de proporcionar custos compatíveis com o porte de cada projeto. Diferentes linhas de processos e equipamentos utilizados na automação industrial, como esteiras, motores, medidores, disjuntores, etc., implicam em diferentes soluções de software aplicativo do SSC, ou seja, com características particulares. Outro fator que afeta na variabilidade da solução para cada projeto é o custo, onde sistemas menos automatizados e com mais intervenção operacional, possuem um menor valor agregado no desenvolvimento da solução. Enfim, para cada projeto de automação que visa operar com um SSC, apresentará necessidades diferentes e uma vasta gama de soluções possíveis, aumentando o custo do desenvolvimento deste software aplicativo. 1.1 PROBLEMA DE PESQUISA O cenário em que as empresas do ramo industrial atuam nos dias de hoje se faz necessária à modernização e automatização dos processos industriais. Sendo a vantagem competitiva um dos fatores de maior impacto. As metas são cada vez mais desafiadoras e para que a qualidade e a eficiência sejam atingidas, faz-se necessário um apoio crescente do uso da automação. Para a construção do aplicativo de um sistema supervisório existem vários desenvolvedores de softwares como já citados anteriormente. Cada ferramenta de software desenvolvida pelos diferentes fabricantes possui características próprias, podendo oferecer facilidades ou dificuldades dependendo do uso a que será aplicada. Quando se adquiri uma licença de software para um determinado programa, está se obtendo a ferramenta para construir o aplicativo de um sistema de supervisão. A construção deste aplicativo se for começado do ponto zero vai demorar mais tempo, conforme o que se deseja fazer em termos de qualidade, escalabilidade, usabilidade, padronização, aspectos gráficos dentre outras características. Para uma empresa que visa fornecer serviços e produtos para automação industrial essas características são de extrema relevância, pois os processos industriais apesar de serem

19 19 diferentes e terem o produto final diferente, ainda assim compartilham tecnologias de supervisão e controle em máquinas instaladas nas plantas de produção. Para cada projeto de automação sendo ele industrial, de infraestrutura ou de facilidade, existe a necessidade de mão-de-obra capacitada para desenvolvimento de um aplicativo do SSC. Os processos automatizados são uns diferentes dos outros, exigindo uma customização de interfaces e funcionalidades para cada projeto, o que envolve várias horas de engenharia. Assim, há a necessidade de desenvolver um aplicativo que facilite a configuração dos sistemas de operação e supervisão, de modo a reduzir o tempo de projeto Solução Proposta O programa aplicativo de um sistema supervisório é reutilizável dependendo da forma como foi concebido no início de seu desenvolvimento, sendo elaborado de uma forma organizada e estruturada é possível diminuir o esforço de desenvolvimento, ganhando qualidade e agilidade, além de manter padronizadas as funcionalidades entre os diversos sistemas fornecidos. A solução proposta é o desenvolvimento de um aplicativo base padrão para sistemas supervisórios, que será instalado em um sistema computacional. Para o desenvolvimento da solução foi utilizada a ferramenta de software Elipse E3. O aplicativo será constituído de uma estrutura pré-programada, contendo recursos de uso básico para atender sistemas de automação industrial. Este aplicativo será a interface do operador com o processo, denominada como sistema supervisório ou SSC, que tem a premissa básica de propiciar uma interface de alto nível do operador com o processo, informando-o em tempo real de todos os eventos de importância da planta. Todo serviço de automação que necessitar de um SSC, deverá partir sempre do aplicativo base padrão, o qual contempla uma estrutura pré-programada, para minimizar tempo de customização e assim padronizar funcionalidades dentre os SSC já fornecidos. O projetista que utilizar este aplicativo precisará customizar dentro da estrutura pré-programada os recursos já disponibilizados, como telas, logos, objetos gráficos, conteúdo de relatórios, variáveis não previstas, etc., para que não sejam mostradas informações não pertinentes ao processo de automação a ser fornecido.

20 20 Toda a interface apresentada para o operador através do SSC deve estar de forma clara e objetiva, no que diz respeito à monitoração e operação do sistema como um todo. A supervisão de alarmes e eventos deve ser apresentada de maneira clara e concisa, auxiliando inclusive na resolução de possíveis problemas. Toda a parametrização deve ser disponibilizada de forma organizada e seletiva, sendo protegida por nível de acesso conforme cada usuário cadastrado Delimitação de Escopo O aplicativo do SSC será desenvolvido para ambiente Windows e receberá em tempo real usualmente as medidas, por exemplo: tensão, corrente, pressão, nível, temperatura, vazão, velocidade, etc. Tais medidas são coletadas através de CLPs e RTUs, provenientes de equipamentos como motores, tanques, esteiras, elevadores, barramentos e demais equipamentos do processo, bem como os estados de elementos de manobra, tais como: disjuntores, chaves seletoras, seccionadoras, etc. Estas informações são recebidas no aplicativo através de protocolos de comunicação, os quais serão utilizados o Modbus (MODBUS, 2012) e Mitsubishi (MELSEC, 2003). Internamente, estará dividindo suas principais tarefas em blocos ou módulos, que vão permitir maior ou menor flexibilidade e robustez, de acordo com a solução adotada. Os seguintes componentes serão foco deste trabalho: Servidor de alarmes: Objeto necessário para estabelecer conexão com o BD (Banco de Dados) e armazenamento de todos os eventos da aplicação. Também é responsável por reportar os eventos de alarmes para todos os Viewers conectados. Sua presença é obrigatória para que a verificação de alarmes ocorra. Configurador de alarmes: Local onde as Áreas são inseridas e organizadas. Banco de dados: Utilizado para armazenar as informações referentes a históricos, fórmulas, alarmes e storage. Será utilizado o banco de dados da Microsoft SQL Server. Drivers de comunicação: Permite a integração com equipamentos de aquisição de dados e controladores lógicos. Relatórios: Componente ActiveX chamado de Active Report, que permite a visualização e impressão de valores instantâneos de variáveis do sistema e dados armazenados em banco de dados.

21 21 Bibliotecas: Permite transformar qualquer objeto ou conjunto de objetos da aplicação em uma biblioteca do usuário. É formada por componentes XControl (gráfico) e XObjects (dados). Gráficos: Componente ActiveX que permite exibir gráficos mostrando medidas variando em tempo real, bem como dados históricos gravados em um banco de dados. Telas: Utilizadas para monitoramento de processos, são a interface entre o operador e o processo como um todo. Quadros: Utilizado para organizar e estruturar a interface do aplicativo, criando visualizações compostas para o usuário dentro da janela principal do Viewer ou navegador. A partir daí, o usuário pode navegar por outras telas, que ocuparão o lugar da primeira, formando uma única visualização do processo. Ao final do desenvolvimento do aplicativo, este irá possuir um conjunto de funcionalidades que atenderá aos requisitos mais comuns de um sistema de automatizado. A Figura 4 ilustra as funcionalidades disponibilizadas após a configuração e elaboração dos componentes acima citados. Figura 4 Resultado final proposto pelo trabalho Fonte: Do Autor (2014).

22 Justificativa A implantação de sistemas que englobam monitoração de variáveis e tomadas de decisão podem propiciar inúmeras vantagens, seja em processos produtivos ou instalações físicas (residência, comércio, etc.). Em um cenário produtivo cada vez mais globalizado, a atualização tecnológica é imprescindível para a manutenção de uma empresa e, neste contexto, a adoção de sistemas de automação é um elemento chave de sucesso. As empresas, cada vez mais, estão promovendo a ligação de suas máquinas e equipamentos com softwares aplicativos, com a finalidade de aprimorar o processo produtivo (COSTA, 2010). O SSC é voltado para apoiar o processo industrial. Segundo Laurindo (2003) o SSC acrescenta vantagens tais como qualidade, redução de custos operacionais, desempenho na produção e base para outros sistemas. O desenvolvimento do aplicativo para um SSC como assunto deste trabalho de conclusão de curso é um incentivo da Safe Automação. A empresa não possui em seus serviços ofertados nada relativo a sistemas supervisórios, por isso o incentivo. Entretanto, pode-se dizer que o produto deste trabalho certamente pode ser utilizado por outra empresa do ramo de automação industrial. A empresa Safe Automação atua em projetos de automação de máquinas e processos, buscando soluções para aplicar o que há de mais moderno em seus serviços. Trabalha com grandes marcas de renome mundial tais como Mitsubishi, Allen Bradley, Weg e entre outras, procura fornecer confiabilidade, robustez, facilidade, custo reduzido e assistência técnica garantida para os processos automatizados (SAFE, 2014). Estamos ao longo do tempo fornecendo serviços e soluções para os mais variados segmentos industriais, desde os mais simples até os mais complexos. Atuamos nos setores elétrico e eletrônico, possuindo uma estrutura ágil e flexível, oferecendo soluções rápidas, criativas e de baixo custo para o segmento industrial, ainda assim preservando a qualidade (SAFE, 2014). A ferramenta de desenvolvimento Elipse E3 da empresa Elipse Software, é líder nacional em soluções de software para o gerenciamento de processos e que hoje possui uma gama de 450 drivers de comunicação contemplando diversos fabricantes de CLPs (ELIPSE, 2014). Sendo uma empresa nacional e possuindo uma filial localizada em Curitiba/PR, facilita suporte de desenvolvimento, utilização e treinamento na ferramenta Elipse E3. O aplicativo gerado

23 23 por essa ferramenta roda em ambiente Windows, que é um sistema operacional bastante comum e difundido nos computadores comercializados atualmente. O ambiente de programação Elipse E3 possui recursos já inclusos para desenvolvimento de bibliotecas de usuário, animações gráficas, banco de dados, relatórios, receitas, dentre outros. Inclui uma ferramenta de scripts baseada no VBScript (Visual Basic Script) da Microsoft que é orientada a eventos e objetos, permitindo operações matemáticas, lógicas e manipulação de estruturas, além de fontes modificáveis e cores diferentes para palavras-chave (ELIPSE, 2014). 1.2 OBJETIVOS Esta seção formaliza os objetivos do trabalho, conforme descrito a seguir Objetivo Geral Desenvolver um aplicativo base padrão e customizável para sistemas supervisórios em projetos da área de automação industrial Objetivos Específicos 1. Gerar bibliotecas de objetos de componentes gráficos para padronizar funcionalidades e animações em telas. 2. Projetar uma estrutura de tags/dados para os drivers de comunicação. 3. Projetar uma estrutura de relatórios para a exportação dos dados. 4. Projetar gráficos para monitoramento de medidas em tempo real e consultas de medidas históricas. 5. Projetar estrutura de configuração de alarmes e eventos para monitoramento em tempo real e com armazenamento histórico. 6. Realizar testes em aplicação real para validação e verificação da solução proposta.

24 METODOLOGIA Um projeto de desenvolvimento de software passa por fases identificáveis antes que surja uma aplicação que possa ser usada. Há diversas maneiras de progredir por essas fases, e cada maneira é chamada de processo de software (WORDPRESS, 2013). Um processo de software é uma forma de ocupar-se da criação e da manutenção de um produto de software. Uma das maneiras de se construir um processo de software, é através do modelo incremental que é classificado como evolutivo dentro da engenharia de software, que consiste na execução de tarefas de forma gradativa, obedecendo a ordem apresentada na Figura 5. Figura 5 Metodologia a ser seguida através do modelo cascata Fonte: Wordpress (2013). O modelo incremental é baseado no modelo cascata com diversas iterações, ou seja, várias cascatas são percorridas durante o desenvolvimento do aplicativo. Na Figura 5 é apresentado um modelo teórico geral, onde existe a etapa de implantação e manutenção, entretanto, devido ao curto espaço de tempo para o desenvolvimento deste trabalho estas etapas não serão aplicadas. Para a realização deste trabalho será feito inicialmente um estudo bibliográfico sobre os conceitos de um SSC e analisados trabalhos empregados na indústria para melhor especificar os requisitos de funcionalidade a serem atendidas. A etapa de implantação é executada após o término de codificação e testes do aplicativo base padrão. Está ligada aos projetos futuros que serão comercializados pela empresa que está apoiando a pesquisa e desenvolvimento do aplicativo. O ideal para esta etapa é possuir um projeto onde se possa aplicar o aplicativo desenvolvido, mas que no momento ainda não existe.

25 25 A metodologia de trabalho para elaboração e execução deste TCC (Trabalho de Conclusão de Curso) está segregada em quatro etapas principais, visando um desenvolvimento sequencial. Estas etapas estão descritas a seguir: 1ª Etapa (requisitos): A etapa de análise dos requisitos é o processo de entender e colocar no papel, uma declaração do que uma aplicação destina-se a fazer depois de construída, pois esta aplicação pode realizar suas funcionalidades de várias maneiras. Esta etapa possui as seguintes atividades: 1. Estudo dos conceitos de um SSC. 2. Especificação dos requisitos. 2ª Etapa (projeto): A etapa de projeto explica como será construída a aplicação e descreve as partes que a compõem e como elas devem ser montadas. Esta etapa possui as seguintes atividades:etapa (codificação): A etapa de codificação nada mais é do que a digitação do código fonte detalhado e comentado. Nesta etapa também é feita a interpretação completa da aplicação para assegurar que ela faz o que foi concebida para fazer. Para dar início da fase de codificação, o ideal seria completar totalmente a fase de projeto, mas nem sempre é possível. O final da 2ª etapa e o início da 3ª etapa será executado simultaneamente. Esta etapa possui as seguintes atividades: 1. Codificação dos requisitos no software Elipse E3. 2. Codificação da estrutura no software. 4ª Etapa (teste): A fase de testes consiste em fornecer uma entrada à aplicação e comparar a saída com aquela determinada pela especificação de requisitos de software. Esta etapa possui as seguintes atividades: 1. Validação individual de cada funcionalidade programada. 2. Validação da estrutura do driver de comunicação. 3. Validação e verificação da aplicação. 1.4 ESTRUTURA DO TRABALHO

26 26 Este documento está organizado em quatro capítulos. O presente capítulo apresenta a introdução ao tema, com uma breve descrição do problema e visão introdutória dos aspectos relevantes para a obtenção da solução, apontando os objetivos a serem alcançados. No Capítulo 2 está apresentada a fundamentação teórica, onde são descritos os dois protocolos utilizados (Modbus e MelsecFX) de comunicação industrial, conceito e estrutura de um CLP, descrição e fundamentação para especificação dos requisitos de funcionalidades e estrutura da aplicação. No Capítulo 3 estão descritos os requisitos de funcionalidades e organização do aplicativo, bem como navegação, layout de telas, configuração de drivers, área de alarmes e eventos, gráficos de tendência, relatórios para exportação dos dados e bibliotecas do usuário. Os softwares Elipse E3 e Microsoft SQL Express também serão abordados, apresentando a descrição dos componentes e os recursos disponibilizados por cada ferramenta. No Capítulo 4 está apresentado o desenvolvimento do aplicativo, ou seja, a codificação dos requisitos apresentados no capítulo anterior, bem como a análise de cada requisito e uma visão geral do sistema. A descrição dos experimentos e os resultados obtidos serão abordados ao final deste capítulo. No quinto e último Capítulo são apresentadas as considerações finais, que com base nos experimentos feitos e análise dos resultados, efetuar a conclusão deste trabalho com relação ao aplicativo desenvolvido.

27 27 2 FUNDAMENTAÇÃO TEÓRICA Neste capítulo são apresentados os conceitos necessários ao desenvolvimento deste trabalho, os quais são: conceito de CLP e SSC, abordagem sobre a ferramenta de desenvolvimento Elipse E3 e banco de dados Microsoft SQL Express, protocolos de transmissão de dados e especificação dos requisitos e estrutura da aplicação. 2.1 CONTROLADOR LÓGICO PROGRAMÁVEL O CLP e o RTU são unidades computacionais específicas, utilizadas nas instalações fabris para a funcionalidade de ler entradas, realizar cálculos ou controles e atualizar saídas. A diferença entre os dois é que o primeiro possui mais flexibilidade na linguagem de programação e controle das entradas e saídas, enquanto que o segundo possui uma arquitetura mais distribuída entre sua unidade de processamento central e os cartões de entradas e saídas. Definição de CLP segundo a NEMA (National Electrical Manufactures Association): Aparelho eletrônico digital que utiliza uma memória programável para armazenamento interno de instruções para desenvolvimento específico, como lógica, sequenciamento, temporização, contagem e aritmética, para controlar, através de módulos de entradas e saídas, vários tipos de máquinas ou processos. O CLP é um equipamento de controle micro processado, criado inicialmente para efetuar controle lógico de variáveis discretas ou analógicas, e atualmente é usado para praticamente todos os tipos de controle. Utilizados também para controle de tráfegos de informações do chão de fábrica para disponibilizar dados de produção através de interfaces de comunicação com os sistemas de supervisão (FRANCA, 2011). Para Natale (2001) o CLP É um computador com as mesmas características conhecidas do computador pessoal, porém, utilizado em uma aplicação dedicada dentro da automação de processos em geral [...]. Com base nas definições de CLP acima citadas, podemos entender este equipamento como o cérebro do processo, porém é necessário que ele comande e receba informações de outros equipamentos, e com base nelas tomar as devidas ações. Os equipamentos que o CLP possui maior interligação são os sensores e atuadores, que são dispositivos de interface final com o processo de

28 28 um sistema automatizado, ou seja, dispositivos de aquisição de dados e atuação instalados no campo Sensores Os sensores são dispositivos que mudam seu comportamento sob a ação de uma grandeza física, podendo fornecer diretamente ou indiretamente um sinal que indica esta grandeza. O sinal gerado por um sensor pode ser usado para informar ao CLP que houve uma mudança de estado em uma variável que esteja sendo monitorada (ALVES, 2005). Segundo Alves (2005) um sinal é qualquer quantidade que pode ser representada como uma função no tempo, classificando os tipos de sinais que um sensor pode gerar da seguinte forma: Tempo contínuo: quando o tempo é uma variável contínua; Tempo discreto: quando o tempo é uma variável discreta, normalmente assumindo valores periódicos; Analógicos: sinais cuja amplitude não é restrita, podendo assumir qualquer valor, e; Digitais: sinais cuja amplitude é restrita a uma classe de valor. Alves (2005) afirma que a maioria dos elementos provedores de informações para os sistemas de supervisão consistem de sensores, sendo os tipos mais utilizados: Sensor capacitivo: utiliza o ar como dielétrico, cuja constante é igual a um. Quando algum objeto com constante dielétrica maior que um é aproximado do sensor, o circuito de controle detecta através do aumento da capacitância; Sensor indutivo: possui o núcleo aberto e denomina-se entreferro. O campo magnético deve passar pelo e que com tem sua intensidade menor. Quando uma peça metálica se aproxima do núcleo do indutor, o campo magnético passa por ela e sua intensidade aumenta, e assim o circuito de controle faz a detecção desta peça; Sensor óptico: formado por um emissor e um receptor de luz. Um oscilador gera uma onda que é convertida em luz pelo emissor. Quando um objeto é aproximado deste

29 29 sensor a onda de luz é refletida e captada pelo receptor, e então o circuito de controle faz a detecção; Sensor magnético: composto por duas peças, uma chave feita de material ferro magnético e outra de material com campo magnético (ímã permanente). Quando o ímã se aproxima da chave atrai as chapas de metal fechando um contato elétrico, e; Sensor resistivo: a resistência elétrica de um material é resultado da relação entre três fatores: resistividade elétrica do material, comprimento e secção transversal do condutor. A resistência de um material pode ocorrer, dentre outras formas, através de variações na sua geometria ou na temperatura, podendo mensurar grandezas como: deslocamento, pressão, nível, temperatura ou radiação eletromagnética. No Quadro 1 são apresentados alguns tipos de sensores, segundo seu princípio físico de funcionamento, associados a medição de diferentes tipos de variáveis. Princípio físico Temperatura Intensidade luminosa Pressão Força/peso Nível Volume Deslocamento Deformação Velocidade Aceleração Composição Concentração iônica Umidade Resistivo Capacitivo Indutivo Piezo resistivo Fotovoltaico Eletromagnético Termoelétrico Piezo elétrico Eletroquímico Piro elétrico Quadro 1 Tipos de sensores X Variáveis medidas Fonte: Adaptado de Alves (2005) Linguagem de Programação A programação traduz funções a serem executadas. Para isso, ela deve ser o mais simples possível. A linguagem de programação é baseada na mnemotécnica, e através de uma linguagem específica, que usa abreviações, figuras e números, se torna acessível a todos os níveis tecnológicos,

30 30 principalmente aos técnicos e engenheiros (lógica de relés). Esta linguagem de programação é padronizada segundo a norma IEC (International Electrotecnical Commission) estabelecida em 1993, que visa atender tanto os conhecimentos da época do relé, ditos comandos elétricos, onde os sistemas eram automatizados fazendo-se uso destes, como os conhecimentos da era digital, onde os sistemas são automatizados usando-se CLP. No primeiro caso, adequa-se a representação da linguagem pelos diagramas de contatos, e no segundo, a representação pelos diagramas lógicos de tecnologia digital, ou ainda a representação matemática (NATALE, 2001). Quando na criação do CLP pensou-se que seria conveniente que a maneira de programa fosse semelhante com a lógica de relés, e assim desde sua criação a programação em Ladder é a linguagem mais difundida no mundo. Existem diversas linguagens de programação para CLP, que com a grande difusão deste equipamento e avanço da tecnologia percebeu-se logo, a necessidade de padronização, que foi onde entrou a norma IEC (NATALE, 2001). De maneira geral o programa do CLP é um conjunto de expressões, que são avaliadas uma a uma sequencialmente a cada ciclo de varredura. Normalmente existe um software que permite o usuário utilizar uma linguagem de mais alto nível, este software é um compilador ou interpretador que traduz o programa escrito pelo usuário para a linguagem de máquina, como demonstrado na Figura 6. Figura 6 Esquema do software compilador com o programa do usuário Fonte: Adaptado de Moraes e Castrucci (2007). Segundo a norma IEC (2013) as linguagens gráficas para uso em CLP devem seguir um dos seguintes diagramas: Diagrama de funções sequenciais (SFC Sequential Function Chart): evolução do graphcet francês.

31 31 Diagrama de contatos (LD Ladder Diagram): programação como esquemas de relés. Diagrama de blocos (FBD Function Block Diagram): blocos representando portas lógicas. A linguagem mais difundida é o diagrama de contatos (LD), devido à semelhança com os esquemas de projetos elétricos com relés. O software se apresenta de forma linear, onde o programa é varrido a partir da primeira linha até a última, não se importando com a necessidade de ser executada somente uma parte do programa (IEC, 2013). Ainda segundo a norma IEC (2013) podem-se utilizar linguagens textuais em CLP seguindo os seguintes modelos: Lista de instruções (IL): semelhante ao código assembly com comandos load e store. Texto estruturado (ST): linguagem para substituir as linguagens declarativas tais como linguagem de instrução. Na programação estruturada, um programa principal é lido e conforme a sequência de eventos, os blocos de programa e funções são executados. Uma grande vantagem está na eficiência do software, que oferece a possibilidade de utilização de sub-rotinas e subprogramas (IEC, 2013) Interface de Comunicação A interface de comunicação permite a conexão entre CLPs e demais dispositivos que possuem a mesma interface, como relés inteligentes ou PCs. Normalmente instalada junto a CPU em uma parte específica do rack. O tipo de interface e o cabo utilizado irão definir o padrão físico e o protocolo de rede, ex.: RS485 e Modbus RTU, respectivamente. A comunicação serial é a mais comumente utilizada e o cabo utilizado é simples de ser fabricado, normalmente com cabo manga de par trançado. Na Tabela 1 estão apresentados alguns padrões de interface serial:

32 32 Tabela 1 Padrões de interface serial Padrão Tipo de Codificação Níveis elétricos (V) Taxa de transmissão de linha BIT 0 BIT 1 transmissão Rs-232C EIA Desbalanceada NRZ bipolar 3<V<15-15<V<-3 Até 20 kbps RS-423 EIA Desbalanceada NRZ bipolar 0,3<V<6-6<V<-0,3 Até 100 kbps RS-422 EIA Balanceada NRZ bipolar 0,3<V<6-6<V<-0,3 Até Mbps Nota: O padrão RS-485 EIA equivale ao RS-422 com drivers em tri-state. Fonte: Adaptado de Lugli (2010). A comunicação Ethernet TCP/IP ganhou popularidade, desempenho e baixo custo, tornando-se atrativa para aplicações industriais já que era possível a conexão com o PC. A Ethernet Industrial é semelhante à Ethernet comum utilizando também o modelo OSI, porém mais robusta em termos de componentes e testes, já que o ambiente industrial requer índices de imunidade a ruído e proteção mecânica. Os principais fabricantes de CLP suportam sistemas de fieldbus específicos, mas todos suportam Ethernet, tecnologia que foi adotada pela IEEE (Institute of Electrical and Electronic Engineers) como padrão 802.1p/Q, onde acrescentou-se campos de prioridade e de quality of servisse (QoS) ao frame Ethernet tradicional. Outros fatores que contribuíram para a utilização da Ethernet no meio industrial foi o uso de switchs, canais dedicados de 10 Mbps a 100 Mbps e comunicação full duplex para eliminar colisões. Na Tabela 2 estão apresentados dois padrões de interface Ethernet: Tabela 2 Padrões de interface Ethernet Itens Ethernet comercial Ethernet industrial Temperatura de operação 5ºC a 40ºC 0ºC a 60ºC Multi layer (imunidade ruído) Não Sim Conectores RJ-45 Parafuso, DB9, RJ-45, Fibra Redundância Não Sim Encapsulamento industrial Não Sim Alimentação 110 Vca 24 Vcc Compatibilidade até 10 anos Não Sim Fonte: Adaptado de Lugli (2010). Os fatores que contribuíram para a construção da rede Ethernet Industrial foram o uso de switchs para evitar a arbitragem de barramento, canais dedicados de 10 Mbps a 100 Mbps e full duplex para eliminar colisões.

33 Classificação A especificação do CLP deve ser feita em função do número de sensores e atuadores necessários, assim como conhecer o nível elétrico dos sinais envolvidos, tanto na entrada como na saída e também as interfaces e protocolos de comunicação. Segundo Moraes e Castrucci (2007) uma classificação de CLP deve levar em conta a combinação de vários aspectos tais como número de pontos de E/S (Entrada e Saída), capacidade de memória, comunicação, recursos de software e programação, etc. Para propósitos práticos, pode-se considerar a classificação da Tabela 3. Tabela 3 Classificação do CLP Porte Nº de pontos (E/S) Micro +/- 20 Mini +/- 180 Pequeno +/- 400 Médio Até 3000 Grande Acima de 3000 Fonte: Moraes e Castrucci (2007). 2.2 REDE E PROTOCOLO DE COMUNICAÇÃO A necessidade de transporte das informações do nível de planejamento para o nível de controle em um processo industrial é evidente. As redes de comunicação de dados se tornaram importantes no ambiente industrial, com todas suas formas, protocolos e topologias. Uma rede é um conjunto de dispositivos (nós) conectados por links de comunicação, onde um nó pode ser um PC, CLP, RTU etc., capaz de enviar/receber dados que estejam conectados a outros nós da rede. As redes tornaram possível a integração do processo com os sistemas de controle e entre estes o sistema de supervisão, sendo executado em um computador (LOPEZ, 2000). O protocolo é um conjunto de regras que controla a comunicação de dados, ou seja, um acordo entre dispositivos de comunicação. Sem um protocolo, dois dispositivos podem estar conectados, mas, sem se comunicar. O protocolo utilizado dependerá do equipamento que se está trabalhando, tendo um grau de complexidade maior ou menor. A topologia da rede adotada e o suporte de transmissão também influenciam. O protocolo para atender tais necessidades inclui funções básicas como estabelecer e terminar conexões lógicas entre dois ou mais dispositivos,

34 34 identificar o transmissor e o receptor das mensagens, assegurar que as mensagens sejam transferidas corretamente, supervisionando esta transferência e na ocorrência de erro iniciar procedimentos de recuperação (SALVADOR; SILVA, 2005). Uma das vantagens de utilizar CLP e outros dispositivos digitais com capacidade de processamento autônomo está na possibilidade de integração com o PC. Assim, é possível conseguir a troca de informações entre todos os elementos da estrutura da automação através de um meio físico adequado definido para a transmissão de dados, criando um sistema de comunicação em rede onde os elementos podem trocar informações. Ao estabelecer a integração dos dados digitalmente por meio de uma rede de comunicação entre os mais diferentes níveis hierárquicos dentro da indústria, melhora-se o custo de fabricação e produtividade, pela eficiência da manipulação do produto, ou seja, estabelece-se a integrabilidade de seus componentes nos mais diferentes níveis (LOPEZ, 2000). Uma rede de comunicação constitui-se geralmente de duas sub-redes (SALVADOR; SILVA, 2005): Rede de campo: responsável pela aquisição dos dados do processo, a fim de adquirir uma comunicação determinística. Estas redes normalmente utilizam uma arquitetura mestre/escravo, onde o dispositivo escravo responde somente às solicitações feitas pelo equipamento mestre, sendo assim a estação escrava nunca inicia a comunicação. Rede local: responsável por disponibilizar e compartilhar os dados do processo em uma LAN (Local Area Network). Geralmente os sistemas de supervisão utilizam arquiteturas do tipo cliente/servidor para acessar as informações do processo. No ambiente industrial é comum nas redes utilizar o modelo cliente/servidor e o mestre/escravo. No modelo cliente/servidor o processamento da informação é dividido em módulos ou processos distintos, ou seja, um processo é responsável pela manutenção da informação (servidor), enquanto o outro é responsável pela obtenção dos dados (cliente) (NATALE, 2001). Na Figura 7 é possível observar a divisão entre a rede de campo (mestre/escravo) e a local (cliente/servidor).

35 35 Figura 7 Rede local de supervisão e de campo Fonte: Adaptado de Salvador e Silva (2005) Aquisição de Dados Aquisição de dados é um procedimento que envolve a coleta e transmissão de informações das instalações industriais, eventualmente remotas, até a estação central de monitoramento (ex.: SSC), que inicia com a solicitação de dados do processo. A requisição de informações, quando feita pelo controlador do processo, é uma solicitação local, ou se feita por uma estação da rede local de supervisão, é uma solicitação remota. A ocorrência de uma requisição faz com que a unidade de processamento autônoma (CLP, RTU, etc.) leia os dados do processo, através dos sensores de campo. Na solicitação local, ou seja, requisição de dados através da rede de campo, estas informações são utilizadas no controle do processo pelo CLP. Na solicitação remota, ou seja, através da rede local de supervisão, estas informações são armazenadas em base de dados e disponibilizadas ao usuário para consulta e monitoramento do processo (SALVADOR; SILVA, 2005).

36 Modos de Comunicação Conforme Salvador e Silva (2005), a principal funcionalidade de qualquer SSC está ligada na troca de informações, que podem ser basicamente com estações remotas, outras estações de supervisão e entre outros sistemas. A comunicação com os equipamentos de campo, realizada através de um protocolo em comum, geralmente ocorre por polling ou interrupção. Polling (master/slave): a estação central tem controle absoluto das comunicações, efetuando sequencialmente o polling aos dados de cada estação remota (slave), que apenas respondem à estação central após a recepção de um pedido, ou seja, em half duplex (SALVADOR; SILVA, 2005). Interrupção: a estação remota (slave) monitora os seus valores de entrada e ao detectar alterações significativas que ultrapassem os limites definidos, envia as informações para a estação central (master) (SALVADOR; SILVA, 2005) Protocolo de Comunicação Modbus O Modbus é um protocolo bastante utilizado em ambiente industrial, automação predial, controle de energia, transporte e outros. Segundo Lopez (2000) Modbus é um protocolo de comunicação criado na década de 1970 pela Modicom (atualmente parte do grupo Schneider Electric), para atuar em redes industriais entre os controladores lógicos e equipamentos como: PC, IHM, inversores de frequência, sensores, CLP, etc. Trata-se de um protocolo aberto e atualmente o mais usado em automação industrial. O Modbus usa o modelo de comunicação mestre/escravo. A simplicidade e a possibilidade de transmissão entre diferentes meios físicos fazem que este protocolo não se limite somente ao uso industrial (LOPEZ, 2000). A transmissão do protocolo Modbus pode ser feita de duas maneiras, sendo RTU ou ASCII (American Standard Code for Information Interchange). Os dois modos de transmissão definem a forma da mensagem, especificam cada um dos bits, como são encapsulados, formato de empacotamento dos dados e como a mensagem é transmitida pela rede (MODBUS, 2012). Os dispositivos podem ser configurados para transmitir sobre o meio físico Ethernet ou serial (RS232, RS485 ou RS522). Estando definido o modo de transmissão e o meio físico,

37 37 configura-se a taxa de transmissão (baud rate), bits de parada (stop bits) e bits de paridade para o caso de uma conexão serial, ou para uma conexão Ethernet, configuram-se o endereço IP e porta (MODBUS, 2012). A comunicação Modbus pelo modo RTU possui uma palavra onde cada byte (8 bits) é enviado por 2 caracteres hexadecimal. Quadro 2 Palavra Modbus RTU Fonte: Adaptado de Modbus (2012). Conforme o Quadro 2, uma palavra RTU tem o acréscimo de (um) bit de início (start), (um) bit de paridade e (um) bit de fim (stop). A palavra RTU é formada da seguinte forma: start (1 bit) + dados (8 bits) + paridade (1 bit) + stop (1 bit). Com isso cada palavra tem o tamanho de 11 bits e cada mensagem transmitida terá uma sequencia de palavras. O frame Modbus RTU é constituído da seguinte forma: Quadro 3 Frame Modbus RTU Fonte: Adaptado de Modbus (2012). Conforme o Quadro 3, para identificar o endereço é utilizada uma palavra, podendo definir valores entre 0 e 247, onde o zero é usado para broadcast e os demais para endereçar os escravos. O código de função também utiliza uma palavra, que é usada para definir uma ação a ser efetuada, onde os números utilizados para especificar essa ação variam de 0 a 127. Os números de 128 a 255 são utilizados para informe de erros na transmissão. Os dados carregam as

38 38 informações adicionais necessárias, como endereços de memória, quantidade de registros transmitidos e quantidade de bytes do campo. O CRC (Cyclical Redundancy Checking) é o último campo do frame e realiza a verificação de erros, não possui start e stop bits e nem paridade, portanto tem o tamanho de 16 bits (MODBUS, 2012). A comunicação Modbus pelo modo ASCII possui uma palavra onde cada byte (8 bits) é enviado por 2 caracteres ASCII, quando em linha série. Este modo é menos eficiente do que o RTU, pois utiliza duas palavras para cada byte de mensagem, mas tem a vantagem de conseguir um melhor detalhamento das informações. Quadro 4 Palavra Modbus ASCII Fonte: Adaptado de Modbus (2012). Conforme o Quadro 4, a palavra em ASCII é formada por 10 bits, sendo (um) bit de início (start), (sete) bits de dados, (um) bit de paridade e (um) bit de fim (stop). Assim como no modo RTU cada mensagem transmitida terá uma sequência de palavras. A mensagem (frame) é enviada por sequência de caracteres sem interrupção, onde o início é identificado pelo caractere ASCII 3A (:) e o final identificado pelos caracteres ASCII 0D e 0A (CR e LF). Todos os caracteres são enviados em hexadecimais sendo codificados pela tabela ASCII. Além da detecção de erro ao nível do caractere, também é realizada ao nível do frame através do método LRC (Longitudinal Redundancy Checking) (MODBUS, 2012). Quadro 5 Frame Modbus ASCII Fonte: Adaptado de Modbus (2012).

39 39 Conforme o Quadro 5, um frame montado ficaria: Início (start) com (um) caractere (10 bits); Endereço com (dois) caracteres (20 bits); Função com 2 caracteres (20 bits); Dados de 0 a 2x252 caracteres; LRC com 2 caracteres (16 bits); Fim (end) com 2 caracteres, CR + LF (20 bits). O Modbus TCP desenvolvido no ano de 1999 foi o primeiro protocolo aberto a utilizar o TCP/IP sobre Ethernet. Nesta versão os dados são encapsulados no formato binário em frames TCP, utilizando o meio físico Ethernet (IEEE 802.3), cujo o meio de acesso é o CSMA-CD. No Quadro 6 está representado o frame do Modbus TCP (MODBUS, 2012). Quadro 6 Frame Modbus TCP Fonte: Adaptado de Modbus (2012). Quando se utiliza o Modbus TCP, qualquer nó com uma porta TCP pode acessar qualquer outro nó, pois não existe a distinção entre mestre e escravo, possibilitando a comunicação ponto a ponto entre os dispositivos. A mensagem original não é modificada, porém existem diferenças na interpretação do endereço e na verificação de erros. O endereço agora é um identificador único, que usa o endereço IP para integrar vários dispositivos, e na verificação de erros são usados os mecanismos existentes no TCP/IP, não utilizando mais o CRC Protocolo de Comunicação Melsec-FX Este é um protocolo proprietário, diferente do Modbus que é aberto. Por ser um protocolo proprietário, no manual do fabricante são poucas as informações que detalham seu comportamento, a não ser pela forma de configuração na lógica do CLP e os frames de transmissão de dados. A linha Melsec-FX do CLP da Mitsubishi possui dois formatos do protocolo de comunicação. Os parâmetros de comunicação (data length, parity, and baud rate, etc.), são ajustados através de um registro especial D8120 de acordo com o Quadro 7. Neste mesmo registro, é feita a seleção do formato do protocolo dedicado, sendo que a diferença entre eles é

40 40 basicamente se os comandos CR + LF são adicionados em cada bloco ou não. No quadro abaixo está a descrição dos parâmetros do registro D8120 (MELSEC, 2003). Quando o computador faz a leitura de um dado no CLP são seguidos os seguintes passos, conforme a Figura 8. Figura 8 Sequência de frames na leitura, CLP Mitsubishi da linha Melsec Fonte: Melsec (2003) Quadro 7 Registro D8120, CLP Mitsubishi da linha Melsec Fonte: Melsec (2003).

41 41 Com base na Figura 8, as áreas A e C indicam a transmissão do PC para o CLP e a área B indica a transmissão do CLP para o PC. O programa do computador é criado de modo que os dados de leitura sejam transmitidos da esquerda para a direita, e o protocolo determina que os dados sejam enviados na sequência A, B, C. Na área A, ENQ é transmitido seguido por todos os outros dados, iniciando pela direita, depois do ENQ (MELSEC, 2003). Quando o computador faz uma escrita de um dado no CLP são seguidos os seguintes passos, conforme a Figura 9. Figura 9 Sequência de frames na escrita, CLP Mitsubishi da linha Melsec Fonte: Melsec (2003). Com base na Figura 9, a área A indica a transmissão do PC para o CLP e a área B indica a transmissão do CLP para o PC. O programa do computador é criado de modo que os dados de leitura sejam transmitidos da esquerda para a direita, e o protocolo determina que os dados sejam enviados na sequência A, B. Na área A, ENQ é transmitido seguido por todos os outros dados, iniciando pela direita, depois do ENQ. Segundo o formato básico de transmissão de dados apresentado na Figura 10, a função Sum check code *1 pode ser ou não adicionada através da seleção do parâmetro no registro especial D8120. Outra função que pode ser ou não adicionada é Control code CR/LF também através do registro D8120, responsável por definir o formato do protocolo selecionado (MELSEC, 2003).

42 42 Figura 10 Formato básico de transmissão de dados, CLP Mitsubishi da linha Melsec Fonte: Melsec (2003). 2.3 BANCO DE DADOS Uma função frequente do SSC é manter informações sobre a produção ou estado do processo ao longo do tempo, usando para isso algum tipo de BD. O uso de bases de dados proprietárias ainda é comum, a maioria deles se comunica através de conexões ODBC (dependente do Windows para troca de informações) ou ADO (um tipo de ActiveX). Para softwares que utilizam ODBC não existe restrição quanto ao uso de BD como MySQL ou PostgresSQL, já para os que não utilizam precisam ser operados através de scripts. Os bancos de dados armazenam informações com eficiência quando minimizam a quantidade de espaço necessária para mantê-los. Quando se trata de consultas complexas que exigem cálculos, é possível acelerar de forma considerável armazenando resultados previamente calculados, no entanto, requer espaço adicional, ou seja, não existe uma resposta única para as decisões de planejamento, é preciso analisar as necessidades de armazenamento e desempenho. (ELMASRI; NAVATHE, 2005). Uma forma produtiva de armazenamento de informações é considerada quando oferecidas maneiras de inserir, recuperar e modificar esses dados com facilidade, fazendo isso de forma intuitiva. Por exemplo, o usuário de um BD em uma loja de varejo pode encontrar informações sobre funcionários em uma tabela, clientes em outra e produtos em uma terceira tabela (ELMASRI; NAVATHE, 2005). O software de um BD é executado normalmente em servidores, com avançado hardware desenvolvido para melhorar o desempenho do sistema de armazenamento de informações, cálculos

43 43 e comunicação na rede. O servidor pode conter um ou mais BD de diferentes, por exemplo, pode ser usado para armazenar uma base de dados contendo informações de clientes e outra base contendo informações de gerenciamento de projetos (ELMASRI; NAVATHE, 2005) Modelo Relacional Um banco de dados relacional possui uma arquitetura que pode ser descrita de maneira formal ou informal, onde a primeira trata de aspectos práticos de utilização usando os termos tabela e a segunda trata da semântica formal do modelo usando termos como relação (tabela), tupla (linhas) e atributos (coluna), segundo Elmasri e Navathe (2005): Tabela: possui uma estrutura de linhas e colunas, sendo utilizada para armazenar informações, onde cada linha possui um mesmo conjunto de colunas. As regras de relacionamento são utilizadas para associar duas ou mais tabelas, ligando um ou mais atributos de uma tabela com um ou mais atributos de outra tabela. Um modelo teórico idealizado por Edgar Codd na década de 70 é baseado em uma estrutura de dados simples chamada relação, que é o mais utilizado em aplicações convencionais de BD. Linha: formada por uma lista ordenada de colunas (registro/tupla) onde cada coluna não precisa necessariamente conter informações, assumindo assim valores nulos. Um registro é uma instância de uma tabela (entidade), onde esta representa um conjunto de informações. A entidade possui atributos (colunas), ou seja, informações que referenciam a entidade. Chave: através desta é que as tabelas se relacionam, sendo formada por um conjunto de um ou mais atributos de forma a determinar uma unicidade de cada registro. Existem dois tipos de chaves: chave primária: nunca se repetirá; chave estrangeira: define o relacionamento entre tabelas, podendo ocorrer repetidas vezes, sendo formada por um relacionamento com a chave primária de outra tabela. A chave primária pode ser do tipo simples ou composta, sendo que a primeira é formada por apenas um campo da tabela, e a segunda é formada pela combinação de dois ou mais campos da tabela, pois podem existir casos em que um único campo não seja capaz de atuar como chave primária. O modelo relacional revelou-se ser flexível e adequado para solucionar problemas de concepção e desenvolvimento de um BD. A estrutura principal do modelo relacional é a relação,

44 44 sendo constituída por um ou mais atributos (colunas) e cada instância do esquema (linha) designa-se por uma tupla (registro), na Figura 11 está representada esta estrutura. Para trabalhar com esse modelo de tabelas foram criadas restrições para evitar aspectos indesejáveis, tais como, repetição de informação, incapacidade de representar parte da informação e perda de informação. Essas restrições são: integridade referencial, chaves, integridade de junções de relações. Figura 11 Conceitos do modelo relacional Fonte: Adaptado de Elmasri e Navathe (2005). 2.4 SISTEMA DE CONTROLE E SUPERVISÃO A necessidade de tornar os sistemas automatizados mais eficientes e com melhores recursos, faz o SSC tornar-se cada vez mais comum em indústrias de diversos setores. Dotados de telas gráficas coloridas, dispositivo de interface como teclado, mouse, etc., proporcionam ao sistema maior clareza e melhores condições de operação em uma determinada planta ou processo (SALVADOR; SILVA, 2005). O SSC é utilizado para monitorar e operar, em tempo real, um sistema já implantado, permitindo ao usuário a visualização ou até mesmo a mudança de parâmetros de controle, visando facilitar o acompanhamento dos mais variados processos, através da leitura de dados obtidos dos sensores, sendo disponibilizados ao usuário através de interfaces gráficas (ARAÚJO, 2000). Segundo Alves (2005) o SSC, também conhecido como programa para interface homem-máquina ou por programa para controle supervisório, é um sistema de monitoração e operação da planta que gerencia as variáveis de processo.

45 45 No SSC também é possível programar a gravação de registros em bancos de dados, ativação de som, mensagens, mudança de cores, correio eletrônico, etc., podendo também verificar condições de alarmes, identificadas quando o valor de uma tag ultrapassa uma faixa ou condição pré-estabelecida (SALVADOR; SILVA, 2005). Estas são atualizadas continuamente e podem ser guardadas em bancos de dados locais ou remotos para fins de registro histórico. No sistema SCADA os algoritmos de controle são executados em uma unidade de processamento autônoma, por exemplo, o CLP. Sendo assim, o SSC é responsável por ajustar os setpoints do mecanismo de controle dinâmico, de acordo com o comportamento global do processo. A arquitetura de um processo (Figura 12) em relação aos componentes físicos pode ser resumida em: atuadores, sensores, rede de comunicação, CLP e o SSC que opera em um sistema computacional (PC). O sistema SCADA trabalha com os seguintes elementos (FRANCA, 2011): CLP, responsável pela coleta dos dados do campo e controle do processo; Estação de operação, PC de uso industrial executando um software aplicativo de supervisão, e; Software aplicativo, programa aplicativo do SSC que depois de configurado funciona em modo de operação que permite a supervisão principalmente do processo, bem como comandar equipamentos, estabelecer pontos de ajuste e parametrização do controlador. Quando em modo edição permite alterar telas, colocar ou retirar instrumentos, configurar níveis de acesso, dentre outros ajustes e customizações. Figura 12 Componentes físicos de um sistema SCADA Fonte: Adaptado de Salvador e Silva (2005).

46 46 A regra geral para o funcionamento correto do SSC parte dos processos de comunicação com os equipamentos de campo, cujas informações são enviadas para o núcleo principal do software. O núcleo é responsável por distribuir e coordenar o fluxo dessas informações para os demais módulos, até chegar de forma esperada para o usuário, através da interface gráfica ou console de operação com o processo, geralmente acompanhadas de gráficos, animações e relatórios, de modo a exibir a evolução do estado dos dispositivos e do processo controlado, permitindo informar anomalias ou sugerir medidas a serem tomadas (SALVADOR; SILVA, 2005). Na Figura 13 está apresentada uma arquitetura simplificada do núcleo do programa, bem como o fluxo da informação. A sua base de dados é composta por tags, ou seja, nomes que associam um endereço ou registro de um dispositivo ao sistema de supervisão, como fonte de informação. O SSC trata as variáveis do processo oriundas de CLP, RTU, relés inteligentes, etc., e desta maneira, estratégias de operação, relatórios, tendências, receitas, históricos, manipulação de escalas são possíveis com as variáveis do processo, gerando uma grande flexibilidade de configuração para o usuário. O acesso das variáveis de um dispositivo de campo se dá através dos drivers, onde cada protocolo de comunicação possui um driver em específico. Figura 13 Arquitetura simplificada do SSC Fonte: Adaptado de Salvador e Silva (2005).

47 47 A seguir serão tratadas as ferramentas de software utilizadas para o desenvolvimento deste trabalho, bem como a especificação dos requisitos funcionais e não funcionais do aplicativo. 2.5 ELIPSE E3 O aplicativo do sistema supervisório foi desenvolvido utilizando o Elipse E3, sendo um dos softwares mais populares utilizados no ramo de automação industrial. Uma das vantagens na utilização deste software é a flexibilidade frente às novas tecnologias de controladores, que hoje, qualquer driver de comunicação pode ser disponibilizado pela própria Elipse Software, mediante um cadastro e processo prévio de aprovação. O Elipse E3 não é um software gratuito, é necessária a compra de uma licença de desenvolvimento que vem no formato de uma hardkey. Esta licença libera todos os recursos da ferramenta para que se possa desenvolver o aplicativo, entretanto ela não permite a execução continua em modo runtime, como no ambiente de produção, seu tempo é limitado em 120min. O valor de uma licença para o modo runtime está intimamente ligado ao número de tags que se deseja monitorar no processo. A Elipse Software permite gratuitamente para aprendizado e desenvolvimento de pequeno porte, o aplicativo que contenha até 20 tags executar em modo runtime por até 10min, após isso, é encerrado e precisa ser reinicializado (ELIPSE1, 2014) Módulos O programa Elipse E3 é composto de quatro módulos, descritos abaixo (ELIPSE2, 2014): E3 Server: é o servidor de aplicações, onde os principais processos são executados, incluindo a comunicação em tempo real com os equipamentos de controle. E3 Studio: ferramenta única de configuração e desenvolvimento, que possui um ambiente com editor gráfico e de scripts (VBScript). E3 Viewer: permite operar as aplicações residentes no servidor em qualquer PC com o Viewer instalado.

48 48 E3 Admin: módulo responsável pela interface do E3 Server e de outros módulos do E3 com o usuário, através dele é possível enviar comandos ao E3 Server Componentes O ambiente de programação E3 Studio disponibiliza diversos recursos para a criação de telas, lógicas de animação, relatórios e entre outros. Para que se desenvolva um sistema supervisório é preciso conhecer os recursos disponíveis, para ajudar na estrutura e organização do aplicativo que servirá de base para outros. A seguir estão descritos os recursos utilizados no desenvolvimento deste trabalho (ELIPSE1, 2014): Tela: objeto básico de interface com o usuário final, onde são inseridos objetos como primitivas (retas, retângulos, polígonos, etc.), ActiveX (E3Alarm, E3Chart, E3Browser), imagens e bibliotecas gráficas (XControl). Quadro: organiza a interface melhorando a estrutura, através de visualizações compostas, ou seja, de duas ou mais telas ao mesmo tempo dentro frame principal do Viewer. O Quadro trabalha com divisores, que podem ser criados uns dentro dos outros, tanto na vertical como na horizontal. Viewer: configura o modo como o E3 Viewer será visualizado, podendo rodar a partir de qualquer ponto da rede, desde que tenha acesso ao E3 Server. O aplicativo não precisa estar na máquina de onde será executado o E3 Viewer, pois as telas serão carregadas em tempo de execução. É no Viewer que a tela ou quadro principal será especificado como inicial. Objetos de tela: objetos gráficos ActiveX criados pela Microsoft onde são baseados na tecnologia COM (Component Object Model). O Elipse E3 instala e disponibiliza estes objetos para o desenvolvedor utilizar nas telas da aplicação, podendo realizar diversas tarefas afim de criar a interface visual com o processo. Todo objeto possui propriedades (atributos) que guardam informações a respeito de suas características. Associações: ligações feitas entre propriedades e objetos ou entre outras propriedades, trazendo facilidade na criação de animações e lógicas comuns, minimizando o uso de scripts. Por exemplo, é possível alterar a cor de um objeto, como o de um retângulo, a partir do valor de uma tag fazendo-se uma associação entre a propriedade BackgroundColor e a propriedade Value da tag.

49 49 Comunicação: utilizado para aquisição de informações fornecidas pelos controladores (CLP, RTU) do processo. No Elipse E3 podem ser utilizados os drivers de comunicação (DLL) ou servidores OPC. As informações recebidas do processo ficam mapeadas em tags que podem ser de vários tipos. O driver de comunicação composto pelo arquivo DLL e um manual de configuração, é fornecido pela própria Elipse Software conforme o tipo de equipamento que se deseja trocar informações. Scripts: programação utilizada para criar procedimentos em eventos específicos, sendo que todo script está associado a um evento de algum objeto e que todo objeto possui uma lista de eventos previamente definidos, sendo possível também definir um novo evento de usuário. Os eventos são ocorrências relacionadas a um objeto que disparam ações programadas, sendo basicamente de dois tipos, eventos físicos que são ocasionados pelo teclado ou mouse, eventos internos que são ocasionados pelas tags. A programação utiliza conceitos de orientação a objetos, onde as propriedades definem atributos de um objeto. A linguagem usada é o VBScript, um subconjunto do Visual Basic, que possui um interpretador rápido, leve e portátil. Métodos: procedimentos encapsulados dentro dos objetos, que podem ser executados e que na chamada deve constar a qual objeto está se referindo. A maioria dos métodos pré-definidos possuem parâmetros que podem ou devem ser passados na chamada, para isso o VBScript possui uma regra que se o método for utilizado em uma atribuição, seus parâmetros devem estar entre parênteses. Segurança: o aplicativo desenvolvido pode ou deve ser protegido desde o código fonte até o acesso das telas do aplicativo pelo usuário final. O Elipse E3 possui uma lista onde são inseridos os nomes de usuários do aplicativo, sendo que para cada nome é atribuída uma senha e um login. No cadastro de cada usuário ainda serão inseridos os dados e políticas de segurança. É possível formar grupos com características que serão comuns para todos os membros (usuários). As permissões são configuradas para acesso as Telas, Alarmes, Domínio e Viewer, sendo individualmente para cada usuário ou grupo. Para a proteção do projeto (código fonte) é disponibilizado dois tipos, proteção de edição e proteção de execução. Através deles é possível proteger contra edição, visualização ou execução não autorizada.

50 50 Armazenamento de dados: é feito através de Históricos, Fórmulas e Alarmes a fim de guardar as informações do projeto. O Elipse E3 possui suporte para MDB (Microsoft Access), Oracle e SQL Server. Alarme: consiste basicamente em duas unidades sendo uma o servidor de alarmes e outra o configurador de alarmes, cujo funcionamento é interligado logicamente. O servidor de alarmes concentra todos os alarmes do projeto, responsável por reportar os eventos para todos os Viewers conectados e banco de dados (se desejável), sendo a sua presença obrigatória para a verificação dos alarmes. No configurador de alarmes são criadas as áreas e fontes de alarmes. Uma área pode conter um conjunto de alarmes bem como de áreas, facilitando o gerenciamento e organização, pois podem ser aplicados filtros de consulta e visualização. Os alarmes podem ser de vários tipos, dentre eles analógico, digital, banda morta (faixa) e taxa de variação (delta). Para o monitoramento dos alarmes e eventos é utilizado o objeto E3Alarm, este objeto é adicionado em uma tela permitindo assim verificar o estado dos alarmes do sistema. Histórico: módulo responsável por permitir o armazenamento de informações em um banco de dados, para análises futuras no próprio aplicativo ou em outra ferramenta qualquer. É possível criar ou utilizar uma tabela independente dentro do banco de dados, o qual pode ser escolhido entre os demais para armazenamento dos dados. Podem existir dentro do aplicativo tantos arquivos de históricos quanto necessário, cada um contendo tags ou expressões. Consulta: objeto que auxilia no processo da definição de consultas (Query) no BD da aplicação, sempre que necessita buscar dados. Toda vez que a aplicação precisa consultar ou gravar informações no BD, serão enviados comandos no formato SQL, sendo que este objeto de consulta apresenta uma interface gráfica para edição e acompanhamento na construção da consulta SQL. Os objetos E3Browser e E3Chart são componentes ActiveX que trabalham com dados históricos gravados em banco de dados, utilizando consultas para aplicar filtros de vários tipos nos dados. A Figura 14 mostra uma visão geral e detalhada da ferramenta com os recursos acima apontados.

51 51 Figura 14 Estrutura e localização dos recursos no E3 Studio Fonte: Do Autor (2014) Relatório O Relatório é um componente ActiveX chamado de ActiveReport utilizado para visualização e impressão dos dados armazenados em BD (alarmes, históricos, consultas e fórmulas). O objeto Consulta em um relatório especifica a origem dos dados no BD, que será visualizado na impressão do relatório. O Relatório é dividido em seções, onde cada seção possui um grupo de controles que são processados e impressos ao mesmo tempo, como uma simples unidade (ELIPSE1, 2014). Os componentes que formam as seções em um relatório estão representados na Figura 15.

52 52 Figura 15 Seções de um objeto Relatório Fonte: Elipse2 (2014). Report Header: utilizado para informações que precisam aparecer somente uma vez no início do relatório, como títulos, gráficos, tabelas e entre outras. Report Footer: utilizado para informações que precisam aparecer somente uma vez no final do relatório, como totais gerais, somas e entre outras. Page Header: utilizado para informações que precisam aparecer uma vez no topo de cada página do relatório, exceto quando esta página contém a seção report header. Usada para imprimir totais de páginas, números de páginas, títulos de páginas e entre outras. Page Footer: utilizado para informações que precisam aparecer uma vez no topo de cada página do relatório. Usada para imprimir totais de páginas, números de páginas e entre outras. Group Header e Group Footer: cada grupo possui duas seções header e footer. A seção detail é impressa entre as seções footer e header, ou seja, uma é impressa antes (header) e outra é impressa depois (footer). O relatório pode conter vários grupos aninhados, sendo que o número de vezes que uma seção de grupo pode imprimir depende de como os dados são agrupados. Detail: corpo do relatório onde serão inseridas as informações, que imprime uma vez para cada registro da fonte de dados Bibliotecas de Usuários A biblioteca de usuário chamada de ElipseX é formada por qualquer objeto ou conjunto de objetos, afim de ser compartilhada entre projetos sem que seja necessário desenvolver novamente

53 53 cada um dos objetos. A ideia dessa biblioteca vem das linguagens de programação orientadas a objetos, devido ao ganho de produtividade que elas trazem, como reutilização de código, minimização de testes durante desenvolvimento, criação de interfaces padrão e proteção do conteúdo. Na biblioteca ElipseX podem ser inseridos dois tipos de objetos, sendo um deles gráfico (XControl) e outro de dados (XObject). Nesses objetos podem conter desenhos, variáveis internas, lógicas de programação (scripts) que estarão sempre presentes em todas as instâncias criadas desse objeto, diminuindo a repetição de código. Para a manutenção a biblioteca se torna mais prática, pois toda alteração nela será atualizada para o restante do projeto nos lugares onde esteja sendo utilizado tal objeto. Os dois objetos estão descritos a seguir (ELIPSE2, 2014): XControl: estão disponíveis todos os itens de telas para serem inseridos neste objeto, dentre os itens estão as primitivas de desenho, gráficos vetoriais e não vetoriais, ActiveX (E3Chart, E3Browser, E3Alarm), dentre outros. Este objeto define uma interface gráfica, com o propósito de ser reutilizada em diversas partes do aplicativo. A edição gráfica possui os mesmos recursos e opções da edição de telas, sendo possível ser inserido em qualquer tela ou até mesmo dentro de outro XControl, que a partir desse momento terá um nome dentro da tela e será entendido como uma cópia da definição original. A Figura 16 representa o exemplo de um objeto criado na biblioteca de usuário utilizando o XControl. Figura 16 Exemplo de um objeto XControl Fonte: Do Autor (2014).

54 54 XObject: pode conter qualquer objeto não gráfico que seja executado no E3 Server, dentre eles está o driver de comunicação, servidor de dados e alarmes, banco de dados, fórmulas, configurador de alarmes, dentre outros. É possível definir uma estrutura de dados contendo cálculos, associações, comunicações, verificação de alarmes, registro histórico, etc., a ser executada no servidor e que independa de qualquer interface gráfica (Viewer) aberta ou em execução. Este objeto pode ser inserido em qualquer servidor de dados dentro do aplicativo conforme mostra a Figura 17, que possui dentro da pasta objetodados um XObject nomeado como PenStorage. Figura 17 Exemplo de um objeto XObject Fonte: Do Autor (2014). Alguns critérios que indicam a necessidade do uso de uma biblioteca de usuário: Repetição no uso; Procedimentos de conhecimento do usuário, e; Uso de controladores. 2.6 SQL SERVER O banco de dados utilizado para o desenvolvimento deste projeto foi o Microsoft SQL Server 2008 R2 Express. Esta ferramenta é de edição gratuita, porém com muitos recursos do SQL Server, ideal para desenvolver e capacitar aplicativos em desktops e servidores de pequeno porte.

55 55 Os limites para a versão gratuita são suporte a 1 núcleo por CPU, 1GB RAM e 10GB de capacidade de armazenamento. O gerenciamento do BD é feito com a ferramenta SQL Server Management Studio Express. Este software não faz armazenamento dos dados, apenas faz a gerência das instâncias do SQL Server. O SQL Server é o servidor de BD de classe empresarial da Microsoft, desenvolvido para competir com produtos como Oracle e DB2, da IBM. O SQL Server permite armazenar, reter e controlar dados para atender aos objetivos comerciais de uma empresa. A plataforma oferece ferramentas e tecnologias para gerenciar e controlar os dados, como (CHAPPLE, 2011): Importar e exportar dados a partir de vários formatos de arquivos; Conectar-se a outros BD do SQL Server ou de outros fabricantes; Controlar dados a partir do Microsoft Excel e Access; Gerar relatórios profissionais dinâmicos com base nos dados do SQL Server, e; Criar tarefas automáticas que são ativadas quando os dados cumprem determinadas condições. O SQL Server é um produto complexo com grande variedade de serviços. A maioria das aplicações requer apenas uma fração das funcionalidades disponibilizadas. Esse software está dividido em edições, ao invés de possuir um tamanho único com valor único. As edições começam a partir da Express Edition, com funcionalidades básicas, porém gratuita, até a mais completa nomeada como Enterprise Edition, com todas as funcionalidades e de valor mais alto.

56 56 Tabela 4 Comparação das edições do SQL Server Recurso Express Workgroup Standard Enterprise Máx. processadores Sem limite Máx. de RAM 1GB 3GB Sem limite Sem limite Armazenamento 10GB Sem limite Sem limite Sem limite Espelhamento de dados Não Não Sim Sim Envio de registros Não Sim Sim Sim Unificação assinatura Sim Sim Sim Sim Unificação de edição Não Não Não Sim Duplicação do Oracle Não Não Sim Sim Agente SQL Não Sim Sim Sim Gerador de perfil SQL Não Não Sim Sim Serviços de análise Não Não Sim Sim Análise avançada Não Não Sim Sim Particionamento Não Não Não Sim Compressão de dados Não Não Não Sim Gerenciador de recursos Não Não Não Sim Custo (por processador) Gratuito U$3.899 U$6.000 U$ Fonte: Adaptado de Chapple (2011). Os valores citados na Tabela 4 são referentes à data inicial de lançamento do SQL Server 2008, sendo também uma visão resumida de algumas diferenças comuns entre as edições. Existe a edição adicional para desenvolvedor de aplicativos, onde oferece exatamente a mesma funcionalidade da Enterprise Edition ao custo aproximado de U$50 por desenvolvedor, não sendo possível usá-la em ambiente de produção (CHAPPLE, 2011) Componentes do SQL Server O SQL Server possui ferramentas para facilitar a interação com BD, onde cada uma é desenvolvida para um conjunto específico de tarefas. O SQL é uma linguagem usada para qualquer interação entre usuário, programa ou servidor e um BD. Todos os principais BD da atualidade (SQL Server, Oracle, Access, IBM DB2 e outros) utilizam os mesmos comandos básicos do SQL, permitindo uma migração fácil entre plataformas e a criação de conexões entre BD distintos (JOBSTRAIBIZER, 2009).

57 57 Os fabricantes de software de BD adicionam em suas plataformas funcionalidades personalizadas para oferecer um suporte exclusivo. A Microsoft usa o nome Transact-SQL para referir sua versão estendida do SQL (JOBSTRAIBIZER, 2009). O gerenciador de configuração é a ferramenta SQL Server Configuration Manager, que permite a execução de tarefas administrativas básicas que afetam a configuração de instalação do SQL Server. Essa ferramenta permite as seguintes funções (JOBSTRAIBIZER, 2009): Iniciar, parar, interromper e reiniciar serviços do SQL Server; Configurar o uso de protocolos de rede para acessar o SQL Server, e; Configurar a conectividade do SQL Server Native Client. A interface para administrar o BD é o SQL Server Management Studio (SSMS), que oferece uma interface de gerenciamento totalmente funcional a partir de um único console, podendo interagir e configurar o BD. O serviço de relatório é feito pelo SQL Server Reporting, que é uma plataforma que permite criar e publicar relatórios dinâmicos com base nos dados armazenados no banco. Os serviços de análise são feitos com o SQL Server Analysis Services, oferecendo técnicas avançadas como OLAP (Online Analytical Processing), centros de armazenamento de dados e mineração de dados. Existem muitos outros componentes do SQL Server, como por exemplo, SQL Profiler e Database Engine Tuning. A Microsoft inclui documentação online detalhada para o SQL Server 2008, na forma de manuais. Essa documentação contém informações sobre funcionalidades para administradores e desenvolvedores, sendo uma excelente fonte de consulta para comandos de sintaxe e recursos avançados (JOBSTRAIBIZER, 2009) Bancos de Dados Integrados do SQL Server Na instalação de uma nova instância do software são criados quatro BD locais no SQL Server, servindo para armazenamento de informações de configuração e dados temporários, bem como modelo para BD recém-criados (CHAPPLE, 2011). Os bancos de dados criados são:

58 58 Mestre: usado para armazenar informações de configuração que se aplicam à instância inteira, incluindo: dados de configuração, informações de servidores conectados, login de usuário e informações de alto nível sobre outros BD. Esta base é o conector fundamental que une todos os BD separados armazenados no servidor. Msdb: usado para armazenar informações dos componentes de programação e histórico. Este BD contém informações sobre qualquer tarefa regular do SQL Server Agent e também de histórico de backup/restauração da instância do software. Modelo: é a base para todos os bancos recém-criados no servidor, ou seja, sempre que for criado um novo BD do usuário, o SQL Server cria uma cópia do modelo para fornecer a configuração inicial do novo BD. Para aplicar um padrão de BD sempre que uma nova base for criada basta fazer as alterações no modelo. Tempdb: local de armazenamento temporário para dados de trabalho, como resultados de consultas intermediárias. O usuário pode utilizar este BD para criar tabelas temporárias, procedimentos armazenados ou outros objetos SQL Server Management Studio A Microsoft desenvolveu o SSMS para ser uma substituição única às ferramentas de fragmentação como Query Analyzer e Enterprise Manager, utilizadas em versões anteriores do SQL Server. A função principal desta ferramenta é permitir gerenciar várias instâncias do SQL Server em servidores locais ou remotos, a partir de uma única plataforma. Para acessar o BD através do SSMS é preciso fazer um login que aparece em uma caixa de diálogo logo na abertura do programa. Após a autenticação do usuário, o programa acessa diretamente a instância do SQL Server, na Figura 18 a interface de acesso pode ser observada já conectada ao banco de dados.

59 59 Figura 18 Imagem do programa SSMS Fonte: Do autor (2014). A estrutura de navegação é baseada em pastas, chamada de Object Explorer (CHAPPLE, 2011). São utilizadas cinco pastas para organizar as opções, divididas nas categorias de Banco de dados, Segurança, Objetos do servidor, Replicação e Gerenciamento, conforme representada na Figura 18. Uma das tarefas importantes que pode ser executa no SSMS é a realização de consultas Transact-SQL nos BD do SQL Server. O painel principal se transforma em uma janela com fundo em branco onde é possível digitar os comandos do Transact-SQL. Após executar a consulta o painel fica dividido em duas seções, onde a metade superior mostra a consulta realizada e metade inferior exibe os resultados da consulta (CHAPPLE, 2011). A Figura 19 demonstra o exemplo de uma consulta ao BD DadosDigitais, onde o resultado com os registros aparecem na parte inferior da imagem e o código SQL na parte superior.

60 60 Figura 19 Exemplo de uma consulta e resultado no SSMS Fonte: Do Autor (2014). 2.7 ESPECIFICAÇÃO DOS REQUISITOS O projeto de um SSC é baseado em uma série de critérios de forma a melhorar a ergonomia do sistema, tendo como base relatos de problemas de operação em outros sistemas. Normalmente as dificuldades enfrentadas pelo operador são: Ações baseadas em uma abstração da planta real, tendo que transformar a interpretação dos dados em ações corretas; Conhecer especificamente uma área do processo é inviável, é preciso conhecer todas que estão sob seu controle; Pressão psicológica ocasionada pela responsabilidade sob seus erros e omissões, e; Fadiga produzida pelo nível maior de concentração exigido no trabalho de operar e supervisionar o processo. Para diminuir as chances de erro do operador são tomadas algumas medidas preventivas, tentando não conduzir operações incorretas do sistema, por exemplo, as entidades do processo devem estar representadas de forma única e consistente, para não ocasionar dúvidas entre a

61 61 representação abstrata e o real. As telas do SSC devem ser organizadas e estruturadas para atingir o nível adequado de informações e coerência com cada parte do processo que será supervisionada. Para isso alguns critérios podem ser adotados durante o desenvolvimento, são eles: Telas de sinópticos que não representam adequadamente o processo e sem animações levam ao desinteresse por não contribuir com a supervisão e operação; O excesso de informações tais como displays, animações e tabelas fazem com que o operador não foque em pontos específicos do processo para o qual a tela foi criada; Elementos que piscam através da alteração de cores e sinalização sonora podem contribuir para chamar a atenção de pontos importantes do processo, porém aplicar em situações que necessitarem de uma real atenção, tais como falhas e alarmes, e; Avalanches de alarmes ou alarmes crônicos fazem o operador perder o foco por causa da repetição ou quantidade de eventos gerados. Alguns conceitos ergonômicos podem ser seguidos para a construção de telas em um SSC, segundo Petterson (1989) os olhos tendem a se mover de: Uma imagem grande para uma menor; Uma cor saturada para uma não saturada; Uma cor brilhante para uma cor pastel; Uma imagem colorida para outra monocromática; Formas simétricas para formas assimétricas, e; Imagem em movimento para uma estática. Para Petterson (1989) a criação de uma tela, por exemplo, a de um sinóptico deve ser bem balanceada, onde a quantidade de informação fornecida para o operador deve estar condizente com a capacidade de interpretá-la, diminuindo o congestionamento de elementos gráficos ou também evitando deixa-la muito vazia. A representação gráfica dos equipamentos com excesso de detalhes pode prejudicar a visualização ao invés de objetivar a sua função no processo. Utilizar sempre que

62 62 possível mensagem clara e explícita, por exemplo, as que são acionadas por popups ou banner de alarmes. Os objetos grandes ou que piscam devem ser evitados ao máximo, sempre procurando uma segunda alternativa. A representação gráfica de uma informação é mais indicada de uma forma natural, por exemplo, uma medida de nível dentro de um tanque, pode-se utilizar um desenho do tanque e um objeto que indique o nível através de uma barra posicionada ao lado da figura do tanque (PETTERSON, 1989). Em uma sequência de comandos, por exemplo, para acionamento de um equipamento deve ser simples e intuitiva, de forma a não gerar dúvida durante a ação. O meio de sinalizar que tal equipamento possui comandos deve estar visível e próximo à representação gráfica do equipamento, que também deve estar clara a sua função no processo (PETTERSON, 1989). Os requisitos funcionais (RF) e requisitos não funcionais (RNF) para o projeto estão citados logo abaixo e serão abordados na sessão 3.2 mais adiante. (RF) aquisição dos dados enviados pelos sensores e controladores; (RF) possibilidade de consulta das informações coletadas; (RF) definição de parâmetros nos controladores; (RF) visualização em tela das informações contidas na base de dados (tags); (RNF) utilizar monitor de vídeo com mínimo de 19 ; (RNF) persistência das informações em uma base de dados; (RNF) segurança para acesso nas telas, comandos e parâmetros; (RNF) uso de um padrão de rede de comunicação entre controladores e SSC; (RNF) uso de um protocolo de comunicação entre controladores e SSC, e; (RNF) uso das bibliotecas de usuários nas telas de supervisão do SSC.

63 ETAPAS DE PLANEJAMENTO Segundo Moraes e Castrucci (2007) as etapas que compõem o planejamento de um SSC são: Entendimento do processo: esta etapa teve por finalidade compreender as principais funções do SSC e codificá-las no aplicativo, de forma padronizada, aumentando a reutilização de códigos. Faz-se necessária a coleta de uma grande quantidade de informações, vindas de diversas fontes, tais como: Verificar com a empresa que apoia o projeto os principais setores (serviços) que podem ter um SSC aplicado, e assim incluir funcionalidades voltadas para estes setores; Encontros para esclarecimentos de quais informações são necessárias para o suporte de decisões do operador e registrá-las; Separar o processo em subsistemas para facilitar o entendimento individual de cada parte e nomeá-las precisamente, e; Definir quais variáveis precisam de monitoramento e identificá-las com nomes precisos. Dados de comunicação: na apresentação da informação manter somente as necessárias, de maneira que o SSC se torne conciso. Quando os sistemas envolvem redes (maioria dos casos) é preciso ficar atento no tráfego do canal de comunicação e estipular um limite se for o caso, pois pode prejudicar o desempenho e a integridade da informação. Drivers de comunicação: os sistemas SSC utilizam como meio de acesso a informação dos dispositivos de campo os drivers de comunicação, onde cada ponto (variável) é definido com uma tag que será utilizada em diversas partes do aplicativo. Para a correta utilização e endereçamento destas tags no aplicativo são necessárias as seguintes informações: Lista de instrumentos/equipamentos da planta que serão monitorados; Mapeamento dos endereços/registradores lógicos do CLP e/ou RTU; Identificação e descrição de cada ponto dentro do mapeamento lógico. Com os itens acima citados é possível construir dentro do aplicativo a estrutura de tags do driver de comunicação, e que para isso devem-se seguir alguns critérios tais como:

64 64 Tempo de varredura (scan), ou seja, período de leitura dos pontos, e; Planejar um esquema de nomes para cada tag e se possível organizar em grupos através de pastas, seguindo uma lógica, de forma que represente o seu significado físico no CLP ou processo. Alarmes e eventos: os alarmes têm por função chamar a atenção do operador para uma modificação do estado do processo ou sinalização de algum dispositivo, que podem ou não implicar no aparecimento de uma situação indesejada, mas que para saber é preciso uma análise do seu contexto. Os meios possíveis de intervir em um alarme através do SSC são: Reconhecimento do evento pelo operador, silenciando o sinal sonoro (se existir), e; Intervir no dispositivo relacionado ao evento, através de uma tela do SSC e reconhecimento do alarme por parte do operador. A análise de um relatório de alarmes e eventos é bastante importante para diagnóstico de causa e frequência com que este ocorre. Os campos data/hora e descrição são fundamentais para contextualizar eventos ocorridos determinando causas e efeitos, e assim tomar as devidas precauções. Estas informações podem ser armazenadas em base de dados para consultas e impressão de relatórios, ficando disponível para o operador a todo o momento que precisar. Hierarquia de navegação: a hierarquia é montada através da árvore de navegação entre telas, onde a disposição e organização podem tornar o sistema claro e condizente com a realidade. A tela principal é a de apresentação do aplicativo, contendo informações, logos e login, para depois permitir acesso às telas do processo a ser monitorado e operado. É importante existir a separação e descrição entre conjuntos de telas pelas características que cada uma irá apresentar, pois fornecem progressivamente os detalhes e configurações tanto da planta como do aplicativo. Desenhos de telas: uma tela pode conter vários objetos gráficos que devem ser cuidadosamente organizados e posicionados, de forma a facilitar o entendimento e contextualização da informação apresentada. Alguns critérios são levados em conta para a melhor eficiência de uma tela:

65 65 Consistência: o uso de símbolos e cores deve representar a informação de forma adequada, conforme o objetivo para que foram criados. Nomes nos botões também precisam indicar a real funcionalidade, sendo o mais claro possível o seu texto; Entendimento: utilizar elementos que podem ser facilmente reconhecidos, evitar a sobrecarga de objetos gráficos, adotar um padrão de terminologia para evitar abreviações de difícil compreensão, fazer uso de cores com significado conhecido, e; Padronização: o uso de bibliotecas do usuário pode facilitar não só o desenvolvimento, mas também formar um padrão de telas dentro do projeto. Consegue-se estruturar as informações seguindo um mesmo layout, sendo assim, cada nova tela pode partir de uma biblioteca existente e ser moldada. Gráfico de tendências: valores de variáveis representadas por curvas ao longo do tempo através de um gráfico. Neste gráfico é possível conter diversas penas, onde cada uma representa uma variável e com isso compará-las a outras. Os valores contidos em cada variável podem ser obtidos em tempo real através de uma comunicação online com o dispositivo de campo, ou de um histórico armazenado em base dados. Os dados plotados pelo gráfico podem ser utilizados para análise de tendência do processo e eficiência da produção. Segurança: o sistema precisa conter restrição de acesso dos usuários de acordo com a posição hierárquica de cada um na empresa. O aplicativo pode conter sistema de cadastro de usuários ou grupos para permitir maior ou menor acessibilidade dos recursos disponíveis, e também permitir registros dos usuários em base de dados a cada login executado. Sistema operacional: o que atualmente predomina no mercado é o padrão Windows desenvolvido pela Microsoft, possibilitando a redução do tempo de aprendizagem caso o operador esteja familiarizado no seu ambiente de trabalho. Muitas das ferramentas de desenvolvimento de sistemas supervisórios são feitas para o ambiente Windows, por ser um sistema operacional amplamente difundido no mundo da tecnologia da informação.

66 CONSIDERAÇÕES FINAIS O objetivo da leitura e análise da fundamentação teórica é definir a arquitetura e funcionalidades do software aplicativo para um SSC. O conhecimento das áreas que envolvem a concepção do SSC se faz necessária, de modo a conhecer os equipamentos de controle do processo como o CLP, bem como a informação é repassada do campo para o sistema de supervisão. O CLP é responsável por fazer o controle do processo, seguindo uma rotina lógica programada, ou seja, um controlador dedicado a esta função. Este equipamento possui memória volátil e não volátil, onde uma armazena informações temporárias e outra é a memória de programa o qual não pode ser perdido no desligamento, respectivamente. O CLP é programado em até cinco linguagens, que ao menos uma deve ser adotada pelo fabricante, seguindo a norma IEC A informação é passada do CLP para o nível de supervisão utilizando-se as redes de comunicação e protocolos. A aquisição de dados é um procedimento que envolve a coleta e transmissão de informações das instalações industriais, eventualmente remotas, até a estação central de monitoramento (ex.: SSC). A comunicação com os equipamentos de campo, realizada através de um protocolo em comum, geralmente ocorre por polling ou interrupção. Como padrão para o este aplicativo base, foram definidos dois protocolos de comunicação, o Modbus por ser um protocolo aberto e amplamente difundido na indústria, e o Melsec-FX que é proprietário da Mitsubishi, sendo utilizado com CLP do próprio fabricante. As ferramentas de software Elipse E3 (Elipse Software) e SQL Server (Microsoft) utilizadas para a codificação dos requisitos foram adquiridas, uma pela SAFE Automação e outra pelo site da Univali (Software Legal). A licença para utilização do Elipse E3 é comprada, e dá suporte ao desenvolvimento de um aplicativo para SSC, já o SQL Server possui uma versão gratuita, denominada como SQL Server Express, que fornece suporte ao armazenamento em banco de dados. A especificação de requisitos para o SSC parte do conhecimento das ferramentas de desenvolvimento e equipamentos envolvidos, tendo também como base relatos de problemas de operação em outros sistemas. Algumas dificuldades encontradas pelo operador é a abstração da planta real e conhecimento de apenas uma área do processo. Para minimizar as chances de erro foram adotados critérios para o desenvolvimento do aplicativo, conforme indica Petterson (1989).

67 67 O Elipse E3 é um programa bastante difundido no ambiente industrial, sua ferramenta E3 Studio utilizada para edição e desenvolvimento, permite a codificação dos requisitos funcionais e não funcionais, que ao adotar padrões na concepção do aplicativo permite a colaboração e expansibilidade da solução.

68 68 3 DESENVOLVIMENTO A seguir é apresentado o desenvolvimento do trabalho, mostrando as técnicas e estruturas utilizadas dentro do aplicativo, como telas, bibliotecas do usuário, driver de comunicação, configuração do banco de dados, gráfico de tendência histórico e tempo real, relatórios e hierarquia de navegação entre telas. 3.1 VISÃO GERAL DO SISTEMA O aplicativo protótipo deste sistema supervisório foi desenvolvido para padronizar e facilitar a customização de um SSC. Na sessão 2.7 estão levantados os requisitos mais comuns utilizados para suprir a necessidade dos processos automatizados. Com base nos requisitos o aplicativo foi codificado para atender os projetos de automação que utilizam SSC como ferramenta de supervisão e operação. Este protótipo possui funcionalidades customizáveis, usando-se da estrutura de objetos projetada justamente para esta finalidade, tendo também como foco a reutilização de código através das práticas de programação orientada a objetos. O desenvolvimento do conteúdo de telas e popups foram feitos em bibliotecas de usuários para que seja possível instanciar tantos objetos quanto forem necessários dentro do aplicativo, sem a necessidade de aumentar a quantidade de códigos e objetos primitivos (retângulos, displays, botões, etc.). Visando este conceito, é possível diminuir muito a taxa de erros no desenvolvimento de um aplicativo se comparado a outro que parte do zero, sendo que algumas vezes não se sabe a procedência ou bugs contidos no código que não foram resolvidos ou até mesmo desconhecidos. Os projetos de automação na maioria dos casos estão inseridos em processos que podem ser nada parecidos, porém com características de operação e controle semelhantes, ou seja, requisitos como relatórios, consulta na base de dados para recuperação de informações através de históricos, gráficos de tendência com monitoração em tempo real ou histórica, objetos montados para animar estados de equipamentos como disjuntores, contatores, chaves seccionadoras, fusíveis, etc., podem ser padronizados e incluídos neste aplicativo base, estando disponível para o próximo projeto a ser desenvolvido. Para que isso acontece, a estrutura da aplicação precisa estar projetada e utilizar conceitos adquiridos durante o curso de engenharia de computação, pois se deseja montar um

69 69 template de um sistema que seja confiável e desejável pelas empresas que estão dispostas a investir em tecnologia. 3.2 ANÁLISE DE REQUISITOS Na sessão 2.7 foram levantados alguns pontos que influenciam na usabilidade do SSC olhando pelo ponto de vista do usuário final. No desenvolvimento foi pensado em fazer com que o aplicativo fosse atrativo e ao mesmo tempo funcional, tendo que apresentar estabilidade e robustez na execução das tarefas solicitadas pelo operador. Para um operador do sistema que antes estava acostumado a fazer manualmente determinadas tarefas do processo, por exemplo, acionamento de equipamentos através de botoeiras em painéis, preenchimento e acompanhamento de planilhas com dados do processo, foi então preciso analisar com base em outros projetos e livros as dificuldades enfrentadas por ele, quando passa a substituir o prático (manual) pelo automático. Um operador que por muito tempo operou o seu processo manualmente ou boa parte dele, deve ser capaz de operar também através de um SSC, mas existem algumas dificuldades a serem vencidas, por exemplo, alguns operadores não possuem afinidade com equipamentos informatizados como os computadores, isso dificulta o desenvolvimento do aplicativo, pois precisa de uma quantidade maior de intertravamentos e ainda ser intuitivo o suficiente para que o usuário saiba o que está fazendo e onde ou como fazer. No aplicativo desenvolvido além dos requisitos funcionais e não funcionais, foi preciso fazer um estudo bibliográfico no que diz respeito à apresentação e organização da informação, preocupando-se no modo em como seriam elaboradas as telas. Critérios ergonômicos como cores, quantidade de objetos em tela, títulos de botões e descrições de campos, foram levados em conta para que traduzissem e representassem suas devidas funções. Os requisitos a serem atendidos pelo aplicativo estão citados e numerados logo abaixo, estando divididos em RF e RNF, são eles: [1 RF] Aquisição dos dados enviados pelos sensores e controladores: Um SSC que não recebe ou envia informações para com os equipamentos de campo acaba por não atender a principal finalidade, que é a monitoração e operação do processo. Por isso é

70 70 importante esta troca de informações entre os níveis na pirâmide da automação como mostra a Figura 1, utilizando-se dos meios de comunicação disponibilizados pelos equipamentos envolvidos. [2 RF] Possibilidade de consulta das informações coletadas: Os dados que são recebidos do campo através de equipamentos instalados no chão de fábrica precisam ser visualizados nas telas do SSC. Estas informações estão contidas dentro da base de dados (tags) do aplicativo, sendo necessária a consulta nesta base para que as informações sejam mostradas ao operador através da elaboração de telas, para que de forma amigável estes dados sejam contextualizados ao usuário do sistema. [3 RF] Definição de parâmetros nos controladores: O processo que antes tinha os seus ajustes feitos manualmente por meio de relés temporizadores, chaves seletoras, válvulas para controle de vazão, pressão, nível, etc., são agora feitos através do SSC por meio de setpoints e botões, que são alterados pelo teclado e mouse de um computador. A definição destes parâmetros influencia diretamente no comportamento do processo, determinando níveis satisfatórios de controle e operação. [4 RF] Visualização em tela das informações contidas nas tags: Um dos recursos importantes dentro do SSC é o objeto tela, o qual é apresentado para o operador do sistema, e que o conteúdo deste é preenchido com informações inerentes ao processo, permitindo o acompanhamento e controle. Um objeto tela que esteja vazio, não é capaz de apresentar a informação coletada de campo, é preciso ter outros objetos dentro da tela, de forma a contextualizar essa informação recebida, para que fique claro o que realmente ela representa no processo. A conexão destas tags nestes objetos é importante para que isso seja possível de ser cumprido, ou seja, a visualização das informações em tela. [1 RNF] Utilizar monitor de vídeo com mínimo de 19 : O espaço útil em uma tela do SSC é importante para que a informação apresentada não fique uma sobre a outra ou comprimida, de forma a disputar espaço e fazer fronteira sem espaçamento adequado. É recomendado não utilizar um monitor menor que 19, justamente para evitar a falta de espaço, que pode ocasionar na criação de mais telas ou misturar informações. Um monitor de vídeo

71 71 com tela de 19 ou maior, é bastante comum hoje em dia, principalmente no formato widescreen e em full HD. [2 RNF] Persistência das informações em uma base de dados: A informação recebida dos equipamentos de campo pode ser armazenada em um banco de dados para consultas posteriores. Estes dados históricos se tornam referência no tempo, de modo a conseguir traçar uma linha de tendência ao longo de um período de apuração. Esse recurso quando utilizado traz benefícios como, melhorar a eficiência do processo, executar ações preventivas de situações já ocorridas, possibilidade de exportar a informação armazenada para o envio e conhecimento das partes interessadas. A persistência das informações é indicada até mesmo para a integração entre outros sistemas, de modo que eles também tenham esta informação disponível para uma consulta em sua base de dados. [3 RNF] Segurança para acesso nas telas, comandos e parâmetros: Um programa de software como é o caso do aplicativo de um SSC, é recomendado formas de restringir o acesso em determinadas telas e comandos do sistema. É importante existir níveis de acesso conforme a função que o usuário desempenha dentro do processo, por exemplo, um operador de produção não necessariamente vai precisar ajustar parâmetros e configurações de equipamentos, como falhas e malhas de controle, porém um operador de manutenção já deveria ter o acesso, pois é ele quem faz o ajuste de equipamentos e os deixa operacionais. A segurança então poderá ser feita conforme o grau de envolvimento que um operador tem com o processo, separando em grupos e determinando até onde cada grupo permitirá acesso dentro do aplicativo. [4 RNF] Uso de um padrão de rede de comunicação entre controladores e SSC: Usar um padrão de rede conhecido e já aplicado na indústria é uma forma de conseguir o funcionamento e compatibilidade entre os vários tipos de equipamentos instalados. Muitos fabricantes desenvolvem em seus equipamentos interfaces de comunicação com padrões já conhecidos no mercado, dentre as mais encontradas é a de comunicação serial e ethernet nos padrões RS232, RS485 e IEEE O aplicativo do SSC funciona em computador com arquitetura industrial ou convencional, sendo que a maioria destes possuem comumente a interface ethernet e alguns ainda a interface serial RS232 para uso mais específico.

72 72 [5 RNF] Uso de um protocolo de comunicação entre controladores e SSC: A comunicação entre equipamentos se faz utilizando um tipo de rede e um protocolo que define como a troca de mensagens será feita. O protocolo que trafega na rede entre os controladores pode ser qualquer um, porém os dois equipamentos devem se entender, ou seja, falar a mesma língua. Para que o SSC desempenhe a função básica é necessário que exista um protocolo de comunicação configurado no aplicativo, sendo ele proprietário ou aberto. Existem muitos protocolos de comunicação já desenvolvidos para uso industrial, que podem ser aplicados no SSC e assim atender a sua função básica. [6 RNF] Uso das bibliotecas de usuários nas telas de supervisão do SSC: As ferramentas para desenvolvimento do aplicativo de um SSC incluem recursos que podem facilitar a criação de bibliotecas de objetos. A vantagem de utilizar objetos criados em bibliotecas é poder instanciar inúmeras vezes um mesmo componente, por exemplo, uma chave seccionadora que possui animação gráfica de cores e posição dos contatos pode ser criada dentro de uma biblioteca, que quando for utilizar basta inserir na tela este componente a buscando a partir da biblioteca já criada. É altamente recomendável o uso deste tipo de programação, pois os componentes ficam disponíveis para até mesmo para projeto futuros, criando-se um dicionário de objetos do usuário. 3.3 MODELAGEM DO SISTEMA O diagrama dos casos de uso apresentado na Figura 20 representa os três tipos possíveis de usuários que terão acesso ao sistema, bem como os recursos que estarão disponibilizados a cada um. No processo de autenticação do usuário na tela de login, será verificado o grupo ao qual pertence, estando em um dos três grupos previstos, sendo mantenedor, administrador ou operador. Na hierarquia o nível de acesso mais completo é o de administrador, que terá privilégio para configurar o sistema e editar os cadastros dos usuários. O usuário mantenedor faz ajustes para o correto funcionamento do processo, por isso ele terá privilégio de acesso para configuração do sistema. O operador é o que tem um nível de acesso mais baixo na hierarquia, possuindo apenas o que diz respeito ao monitoramento e operação do processo. Todos os usuários do tipo mantenedor e administrador possuem acesso para monitorar e operar o processo, bem como exportar relatórios para o nível de gerência.

73 73 Figura 20 Diagrama dos casos de uso Fonte: Do Autor (2014). O sistema de armazenamento em banco de dados será simples e objetivo, possuindo as tabelas correspondentes aos recursos que trabalham com base de dados histórica, como históricos, servidor de alarmes e consultas. No aplicativo poderá existir mais de um banco de dados configurado, sendo que a representação será idêntica ao da Figura 21. Figura 21 Diagrama do banco de dados Fonte: Do Autor (2014).

74 74 Figura 22 Hierarquia de navegação entre telas Fonte: Do Autor (2014). Com base nos recursos disponibilizados pelo software Elipse E3 foi modelado conforme Figura 22 uma hierarquia de navegação entre as telas do SSC. A modelagem usa os recursos de quadros para atender a solução proposta e facilitar o desenvolvimento. 3.4 DETALHAMENTO DO DESENVOLVIMENTO O software Elipse E3 utilizado para o desenvolvimento do aplicativo de um SSC separa os arquivos de projeto em até três tipos diferentes de extensões, sendo elas: LIB extensão de arquivo que armazena as bibliotecas de objetos criados pelo usuário de desenvolvimento, estas bibliotecas podem ser reutilizadas em diferentes projetos, é possível conter mais de um arquivo deste tipo no mesmo projeto, conforme o desenvolvedor montar a estrutura interna do aplicativo; PRJ extensão para arquivo de aplicação onde contêm definições de objetos, telas e outros componentes do aplicativo, é possível no mesmo projeto conter mais de um arquivo deste tipo, conforme o desenvolvedor montar a estrutura interna do aplicativo, e;

75 75 DOM extensão do arquivo de domínio onde armazena quatro tipos de informação: opções de configuração do domínio, lista de arquivos prj e lib, configurações dos servidores que executam o domínio e configurações de segurança (usuários e permissões). Este arquivo é único no projeto e sem ele não pode ser executado no E3. A estrutura interna projetada para este aplicativo foi montada em seis arquivos, sendo quatro de biblioteca e dois de aplicação, o arquivo de domínio é único e sempre vai existir, pois é nele que estão armazenadas as configurações e estrutura do aplicativo em geral. A lista de arquivos do domínio pode ser observada na Figura 23, já na Figura 24 e Figura 25 o conteúdo de cada arquivo. Figura 23 Lista de arquivos no domínio Fonte: Do Autor (2014). As bibliotecas denominadas como janelas.lib, navegação.lib, objetos.lib e pengroup.lib foram criadas com o propósito de organizar os objetos que são instanciados dentro do arquivo de aplicação denominado como aplicacao.prj, que contém as telas e os quadros. O arquivo de aplicação recursos.prj concentra os objetos de comunicação, servidores e imagens. Figura 24 Objetos dentro de cada arquivo de biblioteca Fonte: Do Autor (2014).

76 76 Figura 25 Objetos dentro de cada arquivo de aplicação Fonte: Do Autor (2014). O levantamento dos recursos disponíveis no software Elipse E3 para utilização no aplicativo está descrito na sessão 2.5, e com base nestes recursos foi feita a especificação dos requisitos e os componentes que inicialmente estão compondo a estrutura deste protótipo, criando-se as bibliotecas de objetos, servidores e a hierarquia de navegação entre telas. Como a escolha do software de desenvolvimento já estava determinada pela empresa que está apoiando o projeto, fez-se necessário fazer tal levantamento e estudo desta ferramenta, para conhecer os seus limites e assim conseguir projetar uma boa estrutura para a aplicação do SSC Segurança e Suporte A verificação de segurança está atrelada aos grupos de usuários, onde estão atribuídas as permissões, e o usuário terá determinados níveis de acesso às telas de acordo com o grupo ao qual ele pertence. Estão criados três grupos, são eles: Administradores, Mantenedores e Operadores. Na Figura 26 está mostrada a tela de boas vindas do aplicativo, que possui os campos para autenticação do usuário, que ao fazer o login o sistema identifica o grupo que ele pertence e configura as permissões para cada tela.

77 77 Figura 26 Tela inicial com sistema de login para o usuário Fonte: Do Autor (2014). O aplicativo também está protegido contra edição e cópia não autorizada através do sistema que o software Elipse E3 oferece. Quando um arquivo lib ou prj é aberto no editor, este inicializa com um ícone cinza e um cadeado, indicando que está protegido, e que para acessar o conteúdo do arquivo é preciso fornecer uma senha. O projeto foi elaborado em arquivos prj e lib separados já prevendo que o cliente poderá ter acesso aos arquivos prj para alterações simples ou até mesmo criar uma tela de seu interesse, porém serão preservadas a bibliotecas no que diz respeito a código, com o intuito de conservar o conhecimento ali aplicado, ou seja, o cliente poderá utilizar na sua nova tela objetos das bibliotecas, mas sem acesso ao código. Na Tabela 5 está o perfil de acesso para cada grupo de usuários. Tabela 5 Telas acessadas conforme o grupo de usuários - Telas Administradores acesso Mantenedores acesso Operadores acesso Cadastro usuários - boasvindaslogin1 cabecalho1 rodape1 eventosativos graficotendencia historicoeventos importaplanilha configaplicacao configbd - - configdrivers - - config - informacoes -

78 relatorioalarmes relatoriopengroup controlador1 interface1ea interface1ed interface1sa interface1sd navegacao1 Fonte: Do Autor (2014) O suporte será fornecido pelo contato da empresa que está apoiando o projeto, foi então criada uma janela com as informações necessárias para entrar em contato no caso de dúvidas ou assistência técnica. Nesta mesma janela será identificado o número da hardkey comprada para que seja possível executar o aplicativo, e também que de alguma forma o cliente possa consultar seu número de série e solicitar algum suporte para a Elipse Software. Na janela de informações (Figura 27) foi adicionado o logo da empresa e criado um código para que no click sobre o logo será aberta uma página de internet com o endereço do site da empresa, facilitando consultas para novos serviços e produtos. Esta funcionalidade só estará disponível caso o computador onde está instalado o aplicativo possuir acesso à internet. Figura 27 Tela de informações do fornecedor do sistema Fonte: Do Autor (2014) Hierarquia de Navegação A hierarquia de navegação entre telas está mapeada conforme a Figura 22. A tela inicial do sistema quando inicializado, mostrará o logo da empresa e duas caixas (Figura 26), uma para login e outra para senha, ambas para o usuário. O acesso às demais telas somente será permitido após a

79 79 autenticação do usuário no sistema, e o grau de permissão nestas telas estará conforme o grupo de usuários ao qual pertence. O nível de acessibilidade por grupo está representado na Tabela 5. A estrutura de navegação (Figura 22) só foi possível montar através do uso de objetos Quadro, onde seu objetivo é organizar e separar mais de uma janela ao mesmo tempo, permitindo apresentá-las simultaneamente no Viewer. Foram utilizados dois objetos do tipo Quadro, identificados como principal e secundário. O cabeçalho e o roda pé são únicos para os dois quadros, o que estará mudando é a divisão central, onde serão apresentadas as telas. Praticamente toda a navegação parte da tela do cabeçalho (Figura 28), que a partir dela, serão alcançadas todas as telas do sistema e o roda pé (Figura 29) fornece acesso para a tela inicial após executar o logout. Figura 28 Tela cabeçalho da aplicação Fonte: Do Autor (2014). Figura 29 Tela roda pé da aplicação Fonte: Do Autor (2014) Driver de Comunicação Estão disponíveis inicialmente dois drivers de comunicação, um Modbus e outro Mitsubishi. Estes dois componentes estão utilizando arquivos DLL (Dynamics Link Library) fornecidos pela própria Elipse, com versões (Mitsubishi MX Component v1.03 build 5 (Dec :04:03)) e (Elipse Driver Modicon Modbus v2.08 Build 17 (Oct :29:21)).

80 80 Figura 30 Drivers de comunicação do protótipo Fonte: Do Autor (2014). A Figura 30 indica onde estão inseridos os dois drivers de comunicação, e que quando abertos (através do duplo click) é possível fazer a configuração individual de cada um, desde que, o caminho do arquivo DLL esteja corretamente cadastrado. Nesta mesma figura pode-se observar um terceiro driver, porém para envios de , que está sendo desenvolvido como trabalho futuro, onde sua função será enviar notificações e até mesmo relatórios para endereços de s cadastrados através de uma tela de configuração ou no momento do envio, ainda está sendo projetado. As tags que compõem a base de dados da comunicação com os equipamentos de campo são configuradas a partir de um documento fornecido pela Elipse. Quando é feito o download do arquivo DLL, também está junto o manual de configuração e descrição do protocolo de comunicação ao qual o arquivo baixado se refere. Os dois drivers de comunicação já possuem exemplos de tags configuradas com o tipo de dado ao qual normalmente cada protocolo é utilizado, caso seja necessário configurar uma tag com um novo tipo de dado será preciso fazer a consulta no respectivo manual de configuração do driver. Figura 31 Modelo de tags para o driver Modbus Fonte: Do Autor (2014).

81 81 Figura 32 Modelo de tags para o driver Mitsubishi Fonte: Do Autor (2014). Os equipamentos de campo quando utilizam o protocolo Modbus, normalmente são utilizados dados do tipo inteiro com 16bits. Conforme o manual do driver foi configurado uma tag com o nome OR para ser copiada e colada quantas vezes necessária. Na Figura 31 na tag OR nas colunas N1/B1, N2/B2 e N4/B4 são ajustados os parâmetros de endereço do escravo, função e endereço do registro, respectivamente. Nesta mesma figura pode-se observar que existem outras tags com o prefixo IO, que são criadas a partir do browser IOKit acessado como indica a Figura 30, este kit auxilia na criação de tags para parametrização e monitoração do driver. A possibilidade de utilizar o protocolo proprietário da Mitsubishi também é grande, pois a empresa costuma fazer uso deste CLP em seus serviços de automação. Por isso, está configurado um driver deste tipo para uso se necessário. Conforme o manual de configuração deste driver foi preciso se reunir com a empresa para levantar os tipos de dados que mais estava sendo utilizado no software do CLP, para que fossem criadas as tags exemplos conforme mostra a Figura 32. As colunas N1/B1, N2/B2, N3/B3 e N4/B4 representam o formato de dados, tipo dado, endereço do dado e endereço lógico da estação respectivamente, para quatro tipos de dados, sendo o M, D, X e Y. O tipo M é uma memória que representa um valor booleano, o tipo D é um registrador de 16bits e os tipos X e Y representam valores booleanos, porém especificamente da interface de entradas e saídas digitais do controlador. As tags criadas e configuradas dentro do driver de comunicação possuem as informações lidas correspondentes aos seus endereços lógicos do dispositivo de campo. Esta informação coletada pode ser apresentada em tela através de uma associação entre a tag e um objeto, sendo ele primitivo ou da biblioteca do usuário conforme apresentado sessão 2.5. Para acessar a janela de propriedades do objeto deve-se clicar com o botão direito do mouse e selecionar o item propriedades, ao abrir esta janela pode-se observar uma aba chamada associações onde o usuário deverá clicar.

82 82 Figura 33 Associação de uma tag em um objeto de tela Fonte: Do Autor (2014). Nesta aba são mostradas as propriedades do objeto que podem ser associadas, bem como os tipos de associações existentes e suas fontes. Para as propriedades comuns as conexões disponíveis são: simples, bidirecional, analógica, digital, tabela, reserva e múltipla. A fonte no caso mais simples especifica o caminho para um objeto ou outra propriedade, que em geral é uma expressão que permite aplicar operações lógicas, aritméticas e avaliações de funções à propriedades, objetos e constantes Alarmes e Eventos As telas de alarmes e eventos online e histórica estão desenvolvidas dentro da biblioteca janelas.lib de modo a facilitar a customização, apenas duplicando a original e assim editando-se a cópia, criando um novo objeto. A tela online possui indicadores separados por severidade para contabilizar o total de alarmes individualmente ativos. No componente E3Alarm foram definidas cores para identificar a severidade da falha e para que o operador possa identifica-las foi criada uma legenda de cores. As ações disponíveis nesta tela são os filtros e a ordenação aplicados aos eventos. A ordenação é feita por dois campos, onde um tem prioridade sobre o outro, ou seja, o Combo Box denominado como 1 campo tem prioridade de ordenação sobre o outro denominado como 2 campo, desta forma é possível ordenar por até dois tipos de colunas disponíveis no componente E3Alarm, com objetivo de melhorar a visualização e organização das mensagens. O filtro está disponível em três categorias,

83 83 sendo por tipo, severidade e área, permitindo fazer o reconhecimento apenas dos eventos filtrados através do botão reconhecer. Tabela 6 Campos para ordenação e filtro na tela de alarmes e eventos online Ordenação Ordenação Filtro Filtro Filtro 1 campo 2 campo Tipo Severidade Área Área Hora de entrada Alarme Alta Categoria Hora de saída Evento Media Severidade Hora de reconhecimento Alarme e evento Baixa Descrição Fonte: Do Autor (2014). Os campos do filtro de área serão criados pelo desenvolvedor conforme o mapa de comunicação do CLP, ao inserir uma nova área dentro do configurador de alarmes, automaticamente será listado dentro do Combo Box do filtro de área, pois está desenvolvida uma lógica de busca automática utilizando o evento OnStartRunning do objeto. O configurador de alarmes mencionado na sessão está localizado dentro do arquivo recursos.prj. No objeto AlarmConfig serão criadas as áreas de acordo com a organização do desenvolvedor e também inseridos os alarmes dentro destas conforme as falhas e eventos existentes programadas no CLP. Figura 34 Carregamento automático de áreas para tela de eventos online Fonte: Do Autor (2014).

84 84 Figura 35 Tela de visualização de alarmes e eventos online Fonte: Do Autor (2014). A tela de histórico faz uma busca no banco de dados da aplicação através de consultas em SQL. Os eventos são visualizados através do componente E3Browser, que pode ser manipulado pelas ações de pesquisa por período, texto ou área. Ao executar uma pesquisa utilizando o botão pesquisar será apresentado os eventos que se encaixam conforme foi configurada a consulta pelo usuário. Após obter as informações da pesquisa é possível exportar os dados retornados para os formatos disponíveis de acordo com a programação já desenvolvida, pois será aberto um popup com as opções de exportação, que será vista mais adiante neste capítulo. Figura 36 Consulta aplicada ao componente E3Browser na tela de eventos históricos Fonte: Do Autor (2014). O carregamento das áreas disponíveis para a pesquisa na base de dados segue o mesmo critério da tela online, sendo o processo automático igual está apresentado na Figura 34. Para inserir um período na consulta estão disponíveis dois objetos criados na biblioteca de usuário, que foram programados para abrir uma janela de seleção para data e hora, e também permitindo incrementar e decrementar a hora através de botões aumenta e diminui, caso o usuário queira excursionar somente alguns segundos ou minutos no final ou inicio do período da consulta.

85 85 Figura 37 Tela de visualização de alarmes e eventos históricos Fonte: Do Autor (2014) Gráfico de Tendência O desenvolvimento desta tela foi feita dentro da biblioteca de usuário pengroup.lib. É uma biblioteca fornecida pela Elipse Software como forma de demonstrar e aplicar os recursos disponíveis para o E3Chart online e histórico ao mesmo tempo, através de técnicas de programação orientadas a objeto e consultas em SQL para manipulação das penas históricas no gráfico. Esta biblioteca é composta por um objeto E3Chart e mais uma barra de ferramentas com diversas opções de manipulação do gráfico. Sua aparência e organização foram remodeladas para atender aos requisitos ergonômicos, melhorando sua usabilidade e distribuição das funcionalidades. Esta biblioteca possui muitos algoritmos e recursos complexos, ao qual apenas um desenvolvedor com experiência seria capaz de editar as funcionalidades programadas, por isso, junto com ela acompanha um manual de instruções também fornecido pela Elipse Software, que visa orientar desenvolvedores que apenas queiram incorporar esta ao seu projeto, ou aos que desejam alterar os algoritmos e recursos disponíveis com o objetivo de customização.

86 86 Figura 38 - Tela de visualização do gráfico de tendências Fonte: Do Autor (2014). Esta tela possui um sistema de segurança ao qual o usuário deve estar logado no Viewer como administrador, para que seja permitido criar a lista de tags disponíveis. A lista é armazenada em uma tabela no banco de dados chamada TagDef, obtida através da leitura de objetos históricos. Pode-se criar novos grupos ou selecionar algum já existente a partir do box Grupo de penas, quando clicar sobre o botão para criar novo grupo, uma caixa de diálogo aparecerá solicitando um nome a este grupo. Com os grupos já criados é possível a partir do box Penas adicionar ou retirar medidas históricas que correspondem ao grupo selecionado dentro do box Grupo de penas. A configuração de cada grupo é salva em uma tabela do banco de dados chamada de GroupDef, já cada uma das penas pertencentes ao grupo é salva na tabela PenDef. As configurações das tags tais como escalas, descrição, tipo de histórico, nome de tabela, etc., são armazenadas na tabela TagDef.

87 87 Figura 39 Relacionamento entre tabelas da biblioteca PenGroup Fonte: Do Autor (2014). Dentre as funcionalidades principais, é possível mudar intervalos de visualização, imprimir e exportar o gráfico através de um relatório, limpar o gráfico, mudar o eixo horizontal para fixo ou rolante, criar e apagar grupos de penas, habilitar o grid, mover o gráfico, navegar pelos pontos, enquadrar penas, zoom, exibir e destacar o eixo que está relacionado com a pena e salvar a configuração das penas para o grupo Objetos do Usuário Os objetos do usuário estão criados e organizados dentro dos arquivos de bibliotecas como podem ser vistos na Figura 24. As telas mais elaboradas com maior tempo de desenvolvimento e conhecimento agregado estão criadas no arquivo janelas.lib com o intuito de proteger o código e as soluções padronizadas, o mesmo serve para os objetos dos arquivos navegação.lib e objetos.lib. A tela denominada como importadados, é utilizada para interpretar um arquivo com extensão csv e importar determinadas colunas para dentro de uma tag interna do programa. Esta tela possui as facilidades necessárias, sendo possível customizar seu uso em um projeto que necessite tal função. A qualidade de visualização das telas do aplicativo está vinculada com a resolução da tela do monitor utilizado, atualmente o aplicativo está configurado para trabalhar com uma resolução de 1920x1080 pixels. Para facilitar o redimensionamento das telas foram inicialmente criados dois moldes como exemplo, que estão no tamanho de 1920x1080 pixels e 1280x800 pixels.

88 88 A funcionalidade para exportar relatórios foi criada em uma janela do tipo popup e também dentro do arquivo de biblioteca. O objeto possui os recursos necessários para visualização do relatório em tela, exportar o arquivo permitindo selecionar uma extensão dentre as disponíveis, seleção do caminho para salvar o arquivo e abrir uma janela do explorer apontando para a pasta de destino onde foi salvo o arquivo. No desenvolvimento deste componente e todos os demais, foram criadas propriedades para que fosse possível interagir com os outros objetos dentro de uma mesma tela, pois objeto de biblioteca que não interage com os demais acaba por não possuir muitas utilidades. Figura 40 Janela do tipo popup para impressão do relatório Fonte: Do Autor (2014). No aplicativo foram criados objetos para fazer animações e padronizar o estilo dos botões e textos de navegação entre telas. Da mesma forma como feito na janela de impressão do relatório foi preciso criar propriedades para que fosse possível interagir com o objeto criado. Estes componentes de navegação estão criados dentro do arquivo navegação.lib, atualmente os recursos disponíveis contemplam a abertura de tela modal e inteira (dentro do quadro) em três tipos de aparência, sendo eles, texto que é sublinhado quando o mouse passa por cima, ícone qualquer desenhado pelo desenvolvedor ou um retângulo animado quando o mouse passa por cima. Todos eles possuem propriedades criadas para que apenas seja necessário informa o caminho da tela e o quadro ao qual deve ser visualizada, sem necessidade de criar eventos ou scripts para tal função.

89 89 Figura 41 Componente do usuário para abrir tela tipo modal Fonte: Do Autor (2014). No arquivo objetos.lib estão os componentes inicialmente criados para algumas funções básicas no SSC, como bloco de monitoração de pontos digitais utilizados para interface de entradas e saídas digitais do CLP, botões do tipo toggle e pulso para enviar comandos digitais aos equipamentos de campo, botão para abrir a janela de paleta de cores do Windows e também um outro objeto para seleção de data e hora que abre uma janela com um calendário. Na Figura 38 podem ser observados os objetos para alterar a cor de fundo do gráfico dentro do box grade e outro que altera a data inicial e final para consulta dentro dos boxes data inicial e final. Outros componentes das bibliotecas do usuário podem ser observados também nas Figura 35 e Figura 37, como botões de cor azul e textos nas cores azul marinho para navegação e chamada de telas popup. O componente bloco de monitoração para entrada ou saída digital do CLP está representado na Figura 33, este objeto é composto por mais outro, criado e denominado como circulo, ele é a bolinha na cor verde, mas que quando sua propriedade zsetaestado altera de false para true muda sua cor para vermelho Relatórios O componente utilizado para exportar as informações é o relatório, e foram desenvolvidos dois modelos para este aplicativo, um para exportar os eventos do sistema e outro para exportar o gráfico de tendência da biblioteca PenGroup. Todo componente deste tipo quando adicionado ao projeto já acompanha um objeto Consulta, porque na maioria das vezes os dados exportados são

90 90 oriundos do banco de dados. Mas para o caso do relatório do gráfico de tendência foi utilizado outro método para exportar as informações, já que nele contém um objeto do tipo E3Chart. No desenvolvimento do relatório de eventos foi criado um modelo para ficar melhor configurado quando for exportado no formato pdf, podendo também utilizar outros formatos. Foram utilizadas quatro sessões disponíveis no componente, começando com ReportHeader onde foi adicionada uma figura com o logo da SAFE e um título para o relatório, esta sessão aparecerá somente uma vez e na primeira página. Na sessão PageHeader foram adicionados os títulos de cada coluna da tabela, pois este arquivo informará a data e hora, área, mensagem, condição e se foi reconhecido, por isso é preciso informar em cada página o título da cada coluna, a fim de facilitar a leitura deste documento. A sessão Detail é onde ficam configurados os campos de informações do evento, esta sessão é impressa várias vezes até que se complete o tamanho total da página, estes campos estão ligados diretamente com a consulta no banco de dados, que inclusive aplica e mesma regra de filtragem da tela de eventos, conforme mostra a Figura 36. Por última a sessão ReportFooter utilizada para o roda pé do relatório, que tem por função apresentar o número da página atual e o total de páginas do documento, desta maneira é possível saber se está faltando alguma página. Figura 42 Componente relatório criado para os eventos do sistema Fonte: Do Autor (2014). O relatório da biblioteca PenGroup foi desenvolvido sem a necessidade de um objeto consulta e utiliza apenas a sessão PageHeader do componente. Dentro desta sessão foi adicionado

91 91 um objeto do tipo E3Chart, que tem por função plotar o gráfico sendo ele histórico ou online. Este componente está ligado diretamente com o gráfico da tela de tendência conforme Figura 38, ou seja, toda manipulação feita no gráfico desta tela como filtros e penas, será capturada toda a configuração deste objeto e repassada para o objeto do relatório que está na sessão PageHeader. Para fazer a cópia desta configuração foi elaborado um script no evento OnBeforePrint na sessão Page Header. Este script pode ser visualizado na Figura 43. Figura 43 Script criado no relatório para a biblioteca PenGroup Fonte: Do Autor (2014). 3.5 DESCRIÇÃO DOS EXPERIMENTOS A empresa SAFE Automação indicou um de seus projetos para que fosse aplicado o software do SSC. O projeto disponibilizado é para um centro de distribuição de encomendas da empresa Via Log, e se trata de uma esteira transportadora de pacotes, como televisores, rádios, cafeteiras, etc., de todos os tamanhos e tipos. A Via Log é uma empresa que oferece serviços de logística para outras empresas que necessitam de agilidade e simultaneidade para as suas encomendas, com 32 centros de distribuição divididos por toda região sul do Brasil. O centro de distribuição que receberá o SSC será em Porto Alegre, que hoje tem suas encomendas separadas manualmente na esteira, ou seja, desde o descarregamento dos pacotes recebidos até a separação e carregamento nas docas para os municípios de destino. O processo neste centro atualmente segue uma sequência de tarefas onde algumas delas são feitas manualmente, e que é iniciado quando recebe uma carreta transportando diversos produtos

92 92 encaixotados, que serão descarregados em duas esteiras pequenas especialmente para esta finalidade, que irão levar os pacotes até a esteira central e que passará por um operador portando um scanner de mão, este ficará executando a leitura dos códigos de barras dos pacotes. Outros operadores serão responsáveis por identificar e separar estes pacotes entre 12 docas disponíveis, que possuem individualmente uma rota (logística) programada pela própria Via Log. Em cada doca existe um caminhão do tipo baú para seguir com a rota planejada e fazer a distribuição das encomendas. Toda carreta carregada de produtos que chega ao centro de distribuição possui uma planilha que lista as informações de cada pacote, como código de barras, nome do destinatário, endereço e bairro do destinatário, etc., que a partir dessa lista a Via Log faz uma programação de entrega e a separação nas docas conforme o destino. Observando a Figura 44, para determinar em qual doca a encomenda será descarregada, é preciso verificar a coluna nr e setor de cada linha da planilha, com essa relação o operador saberá o código de barras do pacote e o seu destino, direcionando para a doca correta que contém este destino na rota programada. Figura 44 Planilha de informações dos pacotes Fonte: Via Log (2014). A Figura 45 representa a esteira já com os dispositivos da automação, como sensores, scanner e pusher, que serão instalados para atender aos requisitos de funcionamento. As esteiras de entrada, de saída (docas) e a principal, já existiam e foram aproveitadas, não sofrendo alterações de curso ou prolongamentos.

93 93 Figura 45 Esteira transportadora de pacotes e separação das docas Fonte: Safe (2014). O escopo deste projeto é automatizar a leitura do código de barras, separação dos pacotes nas docas e um SSC para fazer impressão de relatórios, monitoramento de alarmes do sistema, carregamento da planilha com informações dos produtos e gerar um arquivo de saída para que a Via Log possa importar na sua base de dados local os pacotes processados. O SSC não fará interface direta com o sistema da Via Log, somente o arquivo de saída em formato txt que será importado. A customização do aplicativo iniciou-se com o entendimento do processo e suas funcionalidades, para elaborar uma solução e atender o automatismo proposto pelo projeto da SAFE. Esta primeira etapa foi bastante importante no desenvolvimento do projeto e no levantamento dos dados de entrada, para isso foram feitos encontros e reuniões a fim de esclarecer dúvidas e fornecer sugestões para a integração entre CLP e o SSC. A segunda etapa da customização foi solicitar o mapa de endereços lógicos que estão programados e também o modelo do CLP, para que fossem criadas as tags dentro do driver de comunicação. O modelo de CLP utilizado para este projeto é da marca Mitsubishi série Q, sendo previsto e comentado em capítulos anteriores, este é o tipo de equipamento que a SAFE costuma utilizar em seus projetos. Com base no mapeamento de endereços lógicos é possível saber os tipos de alarmes e eventos, e assim inserir os objetos para a monitoração das variáveis na tela do sinótico e de subsistemas.

94 94 Figura 46 Mapa de endereços lógicos do CLP Fonte: Safe (2014). Após entendimento do processo e de posse dos dados de entrada é iniciada a customização do aplicativo, porque somente assim será possível definir quais telas devem existir para uso do operador e os componentes do aplicativo que serão aproveitados ou criados para atender as funcionalidades de supervisão e operação. A solução proposta por este projeto de automação é utilizar o SSC como fonte de consulta para o CLP, pois seria inviável criar lógicas de comparação e carregamento da planilha nele próprio, já que uma planilha pode conter mais que 700 códigos de produtos. A solução é passar esta função para o SSC, e para isso foram criados algoritmos utilizando scripts na linguagem VBScript suportada pelo software Elipse E3, com finalidade de atender este requisito. O driver de comunicação por protocolo modbus foi excluído do aplicativo ficando apenas o driver do CLP Mitsubishi, que a partir dos modelos de tags foram criadas pastas de forma a separálas por função, mantendo a organização para uma manutenção futura. Os objetos do tipo histórico foram criados em uma pasta prevista dentro do aplicativo, neste SSC o histórico foi utilizado para guardar os registros de códigos e setores dos pacotes que foram processados por doca, totalizando 12 objetos porque existem 12 docas. Os registros armazenados

95 95 por doca são: codigo (código de barras), setor (cidade destino), doca (1 a 12) e nomecarga. O registro nomecarga foi criado para identificar cada carreta que chegasse carregada de produtos, facilitando a busca por remessa. Como a quantidade de objetos do tipo histórico ficou em 12, foi melhor criar um BD separado somente para o armazenamento destas 12 tabelas que são correspondentes as 12 docas. No configurador de alarmes do aplicativo, foram criadas áreas conforme as funções de cada indicação digital, sendo ela um evento ou falha e criado um BD somente para estes registros. Os eventos foram cadastrados um a um com descrição diferente para a borda de subida e na de descida conforme o valor da tag. Foram separados os eventos em dois tipos, trip (parada do processo) e alarme (somente alerta), identificando para o operador qual mensagem é crítica e que merece uma atenção imediata. A parte de monitoração e operação é a que mais sofreu customização e criação de telas, pois cada processo tem seus equipamentos em particular. Neste caso foram desenvolvidas três novas telas a partir de componentes já existentes na biblioteca do usuário, bem como um relatório para exportar o arquivo txt. As telas customizadas foram: importadados2: foi originada a partir da tela importadados1 e customizada para atender ao requisito de carregamento e interpretação do arquivo csv que lista as informações dos pacotes. Foram feitas adequações no código para facilitar a seleção do arquivo, visualização dos dados carregados, parametrização para associar um setor a uma doca e campo para inserir uma descrição, a fim de identificar cada planilha importada.

96 96 Figura 47 Trecho de código customizado para importar planilha Fonte: Do Autor (2014). mondoca1: tela criada para a monitoração da doca que informa o estado do sensor e permite visualizar os pacotes processados. Este componente foi originado a partir da tela do histórico de eventos, já que possuía um objeto do tipo browser e um método de consulta desenvolvido. Foi utilizado um conceito de tela indexada para facilitar o desenvolvimento, que sugere criar um único componente associado a um objeto do tipo XObject, e assim ser instanciado 12 vezes sem a necessidade de duplicação, ou seja, utilizar uma tela e poder visualizar as 12 docas, apenas fazendo o chaveamento de parâmetros como sugere o método de tela indexada. No objeto browser foram configuradas as colunas conforme os atributos da tabela do componente histórico de cada doca. sinotico1: esta tela é chamada pelo botão home que se encontra no cabeçalho da aplicação (Figura 28), com a função de representar o processo como um todo. A partir dela é possível navegar para as demais telas do processo, como visualizar a interface de entradas e saídas digitais do CLP, monitoração individual das docas, etc. Nesta tela foram adicionadas animações para sinalização dos sensores quando estão atuados e movimentação dos pushers quando um pacote é empurrado para a doca. Para fazer a animação do pusher foi necessário criar um novo componente na biblioteca do usuário, e depois de criado foi instanciado 12 vezes, correspondente ao número de docas disponíveis. Este objeto é um agrupado de retângulos, que ao receber o sinal da tag associada em uma propriedade faz um deslocamento no eixo y no sentido de empurrar o pacote para fora da esteira principal, este objeto pode ser observado na Figura 45.

97 97 Os relatórios de evento e gráfico permaneceram inalterados, porém foi criado um novo a partir do relatório de eventos, e customizado com a finalidade de exportar os registros históricos de cada doca, que serão analisados pela gerência do centro de distribuição conforme mostra a Figura 20. Outro relatório foi criado e modelado para exportar as informações em um arquivo no formato txt, para isso foi preciso criar um relatório específico, a fim de garantir a compatibilidade entre o arquivo exportado e o sistema da Via Log que irá importar estas informações. O relatório para atender a solicitação de exportar um resumo do dia informando os pacotes que foram processados nas docas, contém as informações como código de barras, número da doca, setor de destino do pacote e identificação da carreta. O desenvolvimento do relatório ficou bem simples pelo fato de não possuir logo, numeração de página, cabeçalho e roda pé, simplesmente contém os campos da tabela onde estão armazenadas as informações. O arquivo de relatório gerado possui a extensão txt e tem os campos separados pelo caractere (;), este foi um requisito para integrar o sistema da Via Log com o resumo da produção diária do centro de distribuição. Figura 48 Relatório que exporta o arquivo em formato txt Fonte: Do Autor (2014). 3.6 RESULTADOS A validação e verificação do aplicativo foram feitas usando recursos de simulação, fornecidos na cede da empresa SAFE. A implantação do sistema não foi possível de ser executada, porque houve uma incompatibilidade na agenda da Via Log com o cronograma proposto para o desenvolvimento deste trabalho, basicamente nas datas de entrega e defesa. Os ensaios feitos em bancada utilizaram o CLP e o scanner da própria Via Log. O programa de execução das lógicas do CLP foi adequado ao novo funcionamento e assim feito a integração

98 98 com o SSC. Todos os pontos do mapa (Figura 46) de endereçamento lógico foram testados no supervisório, bem como as animações dos eventos em tela e os alarmes. Os testes se deram da seguinte forma, foi criado um arquivo similar ao da Figura 44 com códigos conhecidos, cerca de 20 pacotes. No scanner foram passados códigos de barras com valores que existiam e que não existiam dentre os 20 criados, para observar o comportamento e velocidade de resposta da comunicação entre o SSC e o CLP. Os sensores e os pushers foram substituídos por chaves digitais de contato seco e relés do tipo contatores, de modo a simular tais eventos. Uma das funções importantes do aplicativo neste projeto de automação está na tela desenvolvida para selecionar e importar o arquivo csv, contendo os códigos de barras e setores de cada pacote. Após a adequação do componente importadados2 e adaptação dos scripts existentes, percebeu-se uma redução no tempo de customização, pois já havia um algoritmo para interpretação do arquivo csv e método de seleção do arquivo, que partiram da tela original importadados1. O algoritmo que foi adaptado para interpretar o arquivo csv e carregar as informações de duas colunas em específico (Figura 47) atendeu com desempenho satisfatório o requisito inicial, fazendo o carregamento da planilha e relacionamento entre as docas e os setores. O arquivo de entrada de dados (Figura 44) que representa uma remessa de pacotes em uma carreta é carregado através da tela abaixo. Figura 49 Tela utilizada para importar o arquivo csv Fonte: Do Autor (2014). O arquivo csv criado com os 20 códigos foi carregado e relacionado os setores e docas, conforme seria feito se aplicado em um caso real. A validação do algoritmo de consulta foi

99 99 verificada quando se passava um código de barras no scanner, e em seguida o CLP recebia um retorno com a informação do número da doca onde deveria ser descartado tal pacote. Os testes foram feitos com intervalos de 2s entre um código de barras e outro, pois este é o tempo de passar um pacote pelo scanner antes da chegada de outro, caso acontece do SSC não responder a tempo, automaticamente o CLP seleciona o pacote para a doca de descarte. No desenvolvimento da tela de sinótico foram criados novos componentes para animar os pushers e os sensores, além de utilizar os componentes já existentes. Percebeu-se que com uma biblioteca de objetos do usuário completa e organizada, é possível diminuir o tempo de trabalho ainda mais. A biblioteca ainda possui poucos componentes para a criação de telas desse tipo, mas isso é uma questão de tempo até obter uma boa variedade de objetos, pois conforme saem novos projetos, mais componentes serão criados e agregados a esta biblioteca. Figura 50 Tela de sinótico do sistema Fonte: Do Autor (2014). Quando o pacote passa pelo scanner e ganha uma doca de destino, o CLP sincroniza a posição do pacote sobre a esteira até que chegue o momento certo de atuar o pusher, empurrando-o para a esteira de saída na doca correta. A tela de sinótico possibilitou acompanhar o acionamento dos sensores conforme o pacote passava na frente de cada um, e no momento que o pusher era ativado, também era possível saber, através do movimento de avanço do objeto.

100 100 O relatório que exporta o arquivo em formato txt (Figura 48) foi baseado no relatório de alarmes e eventos (Figura 42), facilitando a customização para um novo recurso do aplicativo. O sistema da Via Log terá por função importar este documento, assim como é feito pelo aplicativo com o arquivo csv, demonstrado na Figura 49. Este procedimento foi aceito pelo cliente para evitar problemas de incompatibilidade e garantir a integridade do banco de dados da própria Via Log, e porque também o escopo deste projeto é automatizar somente o centro de distribuição. O SSC visa sempre que possível integrar o controle de processo com o nível da gerência como demonstra a Figura 1, mas neste caso optou-se por fazer esta integração não automatizada, ou seja, através de um procedimento operacional de exportar o resumo da produção e disponibilizar para o nível de gerência. Figura 51 Arquivo txt exportado para uso na base de dados da Via Log Fonte: Do Autor (2014). O pacote após ser empurrado pelo pusher passa na frente de um sensor, informando ao CLP que o pacote realmente saiu na doca, pois existem casos onde o mesmo é retirado da esteira antes de chegar à doca de destino, não podendo contabilizar como pacote processado. Para cada pacote processado, o CLP informa ao SSC através de uma flag que este saiu na doca de destino, por sua vez, o SSC insere um registro no BD como pacote processado e demais informações para complemento. Estes registros posteriormente serão consultados e exportados através dos relatórios ou do arquivo txt (Figura 51). A tela de monitoração individual da doca não existia inicialmente no aplicativo protótipo do SSC, porém já se considerava a possibilidade de existirem novas telas, para esta foi utilizada como base a de alarmes e eventos históricos. Os objetos contidos inicialmente na tela já atendiam boa parte do propósito, sendo preciso fazer um ajuste na consulta SQL do browser (Figura 36) e