Título: Um Sistema Automático de Coletas de Dados Industriais Autor: Roberto de Lima Campos Mestre em Informática pela Pontifícia Universidade Católica - RJ em 1981. Formado em Administração de Empresas pela Faculdade Moraes Júnior - RJ em 1976. Já trabalhou em diversos projetos de automação industrial e vem dedicando-se ao desenvolvimento de sistemas da classe MES. Atualmente exerce a função de consultor especialista de negócios industriais da CPM/SA. Sinopse: Atualmente é indiscutível a necessidade de integração entre os sistemas ERP e os sistemas industriais através da camada M.E.S (Manufacturing Execution Systems). Diversas soluções tem sido desenvolvidas nos últimos anos e uma em especial vem conquistando mercado em diversas áreas de atuação, tanto de processo como de manufatura. Trata-se dos historiadores, softwares capazes de conectar-se com a maioria dos sistemas de controle de processos (supervisórios,, SDCDs, etc), ler dados dos mesmos a velozes taxas de aquisição e armazená-los de forma histórica em arquivos de dados compactados. Estes arquivos são acessados por interfaces especiais que disponibilizam estes dados como um servidor. O objetivo deste trabalho é apresentar a arquitetura de um software para extração on-line dos dados dos historiadores, baseada em expressões de eventos e de tempos e, o envio dos mesmos diretamente para bancos de dados relacionais (SQL). Sua funcionalidade contribui para aumento da qualidade de produtos, já que faz uma integração verdadeira entre sistemas de chão de fábrica e corporativos. Em seu escopo de extração há um tratamento especial para coletas de paradas de equipamentos, visando alimentação de dados para cálculos de produtividade, que com certeza contribuem para a melhoria da lucratividade.
1. Objetivo. O objetivo deste trabalho é apresentar uma solução para desenvolvimento de um software de extração de dados industriais utilizando historiadores. Basicamente, um Historiador é um software que contém um repositório onde são concentradas todas as informações relevantes das células de produção, diretamente ligadas aos sistemas de supervisão e controle. O Historiador coleta informações dos sistemas de supervisão, CLPs, SDCDs e sistemas legados e, os armazena em uma base de dados real time. Tal base tem características não encontradas nos bancos de dados convencionais, como grande capacidade de compactação e alta velocidade de resposta a consulta em sua base histórica. Devido a isto, é capaz de armazenar um grande volume de dados com recursos mínimos, se comparado às soluções convencionais. Os historiadores também são chamados por seus fabricantes de PIMS ( Plant Information Management Systems). A primeira grande vantagem de se utilizar um historiador é que todos os pontos de coleta (ou tags), possuem seus valores armazenados de forma temporal com um dado tipo timestamp sempre informando a hora exata na qual o mesmo foi coletado. A segunda grande vantagem é que um mesmo historiador poderá manter um repositório com dados coletados das mais diversas fontes e tipos de sistemas de controle industrial. A motivação de se propor o sistema título deste trabalho é a de que apesar de todas as suas vantagens, os historiadores mantém um repositório de dados brutos. E apesar de a maioria dos softwares historiadores possuírem interfaces com sistemas da camada corporativa, não existem programas flexíveis o suficiente para conter uma inteligência que possa transformar o dado do repositório e enviá-lo aos ERPs e sistemas da classe MES de uma forma simples, segura e organizada. O objetivo do trabalho é justamente propor a arquitetura e as características de um software tipo middleware que leia dados dos repositórios de historiadores, identifique estes dados de acordo com os modelos fabris e, os envie aos sistemas corporativos que os requisitam. 2. Historiadores. O que é um historiador ou um software normalmente denominado de PIMS? A definição de um software deste tipo foi dada no item 1. A principal função de um Historiador é concentrar a massa de dados e permitir transformar dados em informação e informação em conhecimento. Para um engenheiro de processo é a ferramenta fundamental que permite tirar conclusões sobre o comportamento atual e passado da planta, que permite confrontar o comportamento atual com o de dias atrás ou com o melhor já observado no sistema. Um dos maiores benefícios de um Historiador é permitir ao engenheiro de processo entender as situações operacionais que se apresentam, e compará-las com situações padrões previamente arquivadas. Uma prática comum é se armazenar todos os dados de preparação da linha (set-up) para associá-los aos resultados obtidos. Uma das características mais importantes de sistemas historiadores é sua grande capacidade de compressão de dados históricos, o que torna possível armazenar até 3 anos da operação de uma planta em um disco rígido de capacidade típica em um PC (80 Gbytes). A figura 1 traz a arquitetura de um historiador. Figura 1. Arquitetura de um Historiador A maioria dos historiadores encontrados no mercado possuem diversos tipos de software analisadores dos dados coletados.em geral são sofisticados sistemas de controle estatístico de processo e sistemas para emissão de gráficos dos mais diversos tipos. Isto por si só já é um diferencial na decisão pelo uso de um software deste tipo.
3. Arquitetura do Sistema. O sistema integrado de coleta de dados industriais, incluindo os historiadores,será denominado neste trabalho de Sistema de Coleta Automática de Dados Industriais. A sua arquitetura é mostrada na figura 2. Corporativo Interface de Extração Regras de Coleta Envio para ERP/MES ERP, MES Historiador WAN Execução Historiador Analisadores Planta Fabril Planta Fabril LAN LAN SCADA OPC Server SDCD SCADA OPC Server SDCD Controle Figura 2. Arquitetura do Sistema de Coleta Automática de dados Industriais A figura 1 mostra a distribuição dos componentes do sistema pelas 3 camadas MES (Manufacturing Execution Systems), que são: Corporativo, Execução e Controle. Na camada de controle encontram-se os sistemas de controle de processos industriais, representados pelos tipos mais conhecidos que são os SCADAs e os SDCDs. Servidores de OPC (OLE for Process Control) já são utilizados atualmente pela maioria dos fabricantes de e outros controladores e, agem como uma interface que disponibiliza em tempo real os dados destes equipamentos para os historiadores. Na camada de execução encontra-se o historiador, que conectado através de um rede local (LAN), coleta os dados dos SCADAS, Servidores OPC e SDCDs e os armazena na sua base temporal compactada. Na camada corporativa encontra-se a Interface de Extração de Dados e os sistemas MES e ERP. A Interface de Extração tem uma característica centralizada. Supondo uma indústria que possui fábricas espalhadas por um país ou mesmo pelo mundo, a interface leria dados dos historiadores de cada uma das fábricas através de uma rede tipo WAN, os transformaria e os enviaria aos sistemas usuários. O historiador que aparece na camada corporativa é uma alternativa para armazenamento de um grupo de fábricas com pequeno volume de dados, para as quais não se justificaria em termo de custos a aquisição deste produto. Assim, os SCADAS, Servidores OPC e SDCDs destas fábricas enviariam os dados para um único historiador através da rede WAN, que residiria em local centralizado da corporação. Este historiador será normalmente lido pela interface contendo dados de várias fábricas. A arquitetura com a interface centralizada possui uma série vantagens tais como: o o o Toda a inteligência de configuração e o controle de operação da extração de dados ficam agrupadas em único ponto, facilitando a sua manutenção. O armazenamento histórico dos dados pelos historiadores dispensam a coleta instantânea. Isto é, se houver algum problema de rede, por exemplo, assim que o mesmo for resolvido, a interface continua seu trabalho de extração. A inteligência de extração pode ser re-utilizada por diversas fábricas que tenham requisitos similares. Dispensa-se o trabalho de instalação das interfaces em cada uma das fábricas e reduz-se o custo por não haver necessidade de hardware adicional para os mesmos. Naturalmente a arquitetura proposta aqui poderá ter várias outras formas em função dos requisitos de projeto e das soluções de conectividade que são utilizadas dentro de uma corporação.
4. Modelos de Processo e de Plantas Fabris. Quando fala-se em coleta de dados industriais para sistemas corporativos não se pode deixar de pensar na correlação que estes dados devem ter com os modelos adotados por estes sistemas. Por exemplo, ao coletar-se o volume de um tanque que armazena determinado produto, deve-se saber pelo menos de qual tanque é este volume, e de qual fábrica é este tanque. Isso gera então a necessidade dos conhecidos cadastros de fábricas e de tanques, com seus códigos, nomes e associações. Na realidade tais cadastros são resultados de modelagens de dados que são feitas a nível dos objetos das plantas fabris, produtos, receitas, etc. Para que se possa coletar um dado industrial, qualquer interface deverá ter o conhecimento das associações daquele dado com as representações do mundo corporativo. Por isso é indispensável que se modele e se preencha estes tipos de dados. Entre os modelos mais conhecidos e usados atualmente está o modelo preconizado pelo padrão S88 (S88 Batch Control Standard) da ANSI-ISO. Dois padrões desta norma ditam conceitos sobre modelos e terminologia (S88.01) e estruturas de dados e linguagens (S88.00.02). Esta norma é usada para padronizar os conceitos de sistemas que utilizam o processamento de bateladas. Porém, o modelo físico proposto por ela pode ser usado também por outros tipos de indústrias, que não as de processo de batelada. A figura 3 traz o modelo físico proposto pela norma S88. Enterprise Site Area Must contain Process Cell Unit Equipment Module Must contain Must contain Figura 3. Modelo Físico da norma ANSI-ISO S88 Control Module O que o modelo define é que uma corporação deve conter um ou mais sites. Cada site pode conter uma ou mais áreas. Cada área deve conter uma ou mais células de processo. Cada célula de processo deve conter uma ou mais unidades. Cada unidade pode conter um ou mais equipamentos. Cada equipamento pode conter um ou mais módulos de controle. Há uma definição conceitual para cada um destes componentes. Para se utilizar este modelo deve-se adequar de forma interpretativa os objetos da planta fabril a estas definições. Por exemplo, ao modelar-se uma indústria de bebidas pode-se definir que os sites são as fábricas, as áreas são processo (elaboração da bebida) e engarrafamento, as células de processo são as linhas de produção, e as unidades são conjuntos representativos de equipamentos, tais quais um tanque ou uma enchedora de garrafas. Utilizando-se ou não este modelo, toda interface de extração de dados irá requerer estes cadastros. Por exemplo, para se coletar o tempo de parada de uma enchedora de garrafas deve-se ter cadastrado os códigos de todas as enchedoras para informar-se ao sistema de qual delas é aquele tempo de parada. Há outras definições que transcendem os modelos fabris como por exemplo os tipos de dados coletados (p.ex dado de processo ou parada de equipamento) e o significado do item coletado. Este último acaba resultando na necessidade de um cadastro de itens a coletar, de forma a distinguir por exemplo que um valor representa a temperatura de um tanque, um volume produzido, um tempo de parada ou a data do início de uma determinada operação. O cadastramento do modelo fabril poderá ser implementado na interface ou importado dos softwares corporativos. O cadastramento das características das coletas deverá ser obrigatoriamente implementado pela interface.
5. Estrutura da Interface de Extração de Dados. Pode-se conceituar a Interface de Extração de Dados como: O componente do Sistema de Coleta Automática de Dados Industriais capaz de ler os dados dos historiadores, transformá-los de acordo com regras definidas pelo usuário e enviá-los aos sistemas corporativos em intervalos contínuos ou prédeterminados de tempo. Para desenvolver-se um software desta natureza, com requisitos de flexibilidade e confiabilidade e, alto poder de definição das regras de coletas, é requerido um projeto similar ao de um produto. Provavelmente em pouco tempo fabricantes de historiadores estarão agregando interfaces deste tipo as suas listas de produtos add-in para dispensar ou pelo menos diminuir as tarefas de integração entre os bancos de dados de historiadores e os bancos de dados padrão SQL. Os sub-itens a seguir definem os requisitos recomendados para uma interface deste tipo. 5.1 Componentes da Interface. A figura 4 mostra os módulos da interface: Modelador, Configurador, Compilador, Extrator e Documentador. Todos estes módulos gravam ou acessam informações armazenadas em um banco de dados próprio, conforme representação da figura 2, que apresenta um símbolo de disco conectado com o micro da interface. Recomenda-se utilizar um banco de dados padrão SQL. Interface Interface Modelador Modelador Configurador Configurador Compilador Compilador Extrator Extrator Documentador Documentador Figura 4. Módulos da Interface de Extração de Dados 5.1.1 Modelador. O Modelador é o módulo responsável pelo cadastramento das informações necessárias as coletas de dados. Entre elas estão o modelo fabril, conforme explicado no item 4, contendo os cadastros de todas as entidades pertinentes, os cadastros de produtos, receitas, materiais e o cadastro dos itens de coletas. O cadastro dos itens de coleta identifica cada item que será coletado,podendo ter as naturezas mais diferentes possíveis, como por exemplo: uma temperatura, uma quantidade de peças produzida, um tempo de parada de equipamento ou uma data de início de operação. Recomenda-se que este módulo possua facilidades de importação dos dados necessários destes cadastros, pois na maioria das vezes, estas codificações já fazem parte dos ERPs e dos sistemas MES. Todos os dados do Modelador são armazenados no banco de dados da Interface. 5.1.2. Configurador. O Configurador é o módulo responsável pela definição das coletas que deverão ser feitas e suas regras de extração. Mas o que vem a ser uma coleta de dados? Uma coleta poderá ser definida por : um valor obtido através de algum processamento feito sobre dados armazenados por historiadores quando acontece alguma condição de evento ou de tempo verificada sobre outros dados também armazenados pelos historiadores. Uma coleta será representada por uma regra de disparo do tipo: If <condição de disparo> = verdade then :- <processamento da coleta> A condição de disparo é uma expressão condicional envolvendo dados do historiador. Como cada dado do historiador é um ponto de coleta ou tag, o configurador deverá ter um cadastro que relacione cada um dos tags a ser usado do historiador, podendo fazer-se uma nomeação dos mesmos, ou uma espécie de apelido. Estes nomes de tags é que serão usados na condição de disparo e no processamento de uma coleta. O Configurador deverá permitir também a possibilidade de condições de coletas por tempo nas suas várias modalidades: contínuo por intervalos, em períodos determinados, por data e hora fixos,etc. O processamento da coleta também deverá receber funções especiais tais como média, máximo, mínimo, somatório, desvio padrão, tempo entre eventos e outras. Mas uma coleta não necessariamente representa somente um item de dados. Deverá haver uma tipificação das coletas de acordo com a natureza do dado que será coletado. Isso receberá influência do tipo de indústria em questão. Por exemplo, no projeto de um configurador para processos de bateladas e que também tenha recursos para coletar paradas de
equipamentos, os tipos de coletas deverão ser: batelada, rastreabilidade, item de dado e paradas de equipamentos.uma coleta de batelada informará por exemplo a data de início e fim de uma batelada e a receita utilizada. A tipificação é importante pois o envio de uma coleta é sempre acompanhado de todos os dados necessários mantidos pelo Modelador. Portanto a configuração de cada tipo de coleta varia em termos dos dados a serem informados pelo usuário. Todos os dados do Configurador são armazenados no banco de dados da Interface. 5.1.3 Compilador. O Compilador é o módulo responsável pela tabulação e compilação dos dados mantidos pelo Modelador e Configurador e, pela gravação destes em tabelas especialmente projetadas para o módulo Extrator que será descrito no próximo item. Várias transformações são feitas de acordo com os dados que são requeridos pelo engenho do Extrator, visando uma alta performance deste módulo. 5.1.4 Extrator. O módulo Extrator é o módulo responsável pela leitura dos historiadores, transformação dos dados e, envio dos mesmos ao sistemas requerentes de acordo com o modelo fabril criado pelo Modelador e pelas definições das coletas criadas pelo Configurador. O Extrator deverá possuir um engenho (engine) desenhado para suportar os seguintes requisitos: o algorítimo do engenho deve ter o conceito de varredura de tempo e de espaço, avaliando as ocorrências de todas as condições de eventos e de tempos dos disparos das coletas em um período determinado; deverá ser construído visando uma boa performance do Extrator; deverá controlar os períodos de tempo de varredura, salvando-os no banco de dados da interface, garantindo que o início de uma nova varredura será imediatamente após o final da varredura anterior; deverá controlar os estados das condições de disparo, garantindo que após o disparo de uma condição, somente após uma mudança no estado de seus tags a condição será habilitada para um novo disparo; deverá permitir extração contínua, a intervalos de tempo ou em data/hora pré-estabelecida; deverá permitir processamento paralelo das varreduras das diversas fábricas para otimizar o tempo de processamento. As saídas do Extrator constituem-se nos dados enviados aos sistemas usuários. Estas saídas deverão ser projetadas de forma o mais flexível possível, mas seguindo os requisitos destes softwares. Para enviar dados a bancos padrão SQL recomenda-se o uso de Stored Procedures através de interfaces ODBC. O Extrator envia um comando SQL ao banco com todos os dados requeridos e a procedure distribui os mesmos nas tabelas. Para conectividade com ERPs recomenda-se usar as próprias ferramentas dos softwares, como por exemplo as funções ABAP do SAP. Para uma interface off-line pode-se fazer a geração das coletas em arquivos padrão XML que serão importados posteriormente pelos ERPs e sistemas tipo MES. 5.1.5 Documentador. O módulo Documentador é responsável pela geração de uma documentação das coletas definidas, explicando as condições de disparo e cálculos efetuados, sempre relacionando as coletas com o modelo fabril associado. Com estes documentos é possível saber-se com exatidão qual a metodologia de coleta usada para cada um dos itens envolvidos. 5.1.6 Implementação Atualmente há várias soluções tecnológicas que podem ser usadas no projeto da Interface, como por exemplo as plataformas:.net, Java ou C++. Os módulos Modelador, Configurador, Compilador e Documentador possuem todas as características de um sistema tradicional de informações. Os quatro módulos poderão ser distribuídos em menus de uma única aplicação que seja executada no servidor Web através de um browser. Isso facilita o uso e dispensa instalações em micros usuários. O projeto do Extrator já requer maiores cuidados devido aos seus requisitos de performance. Recomenda-se que seja feita uma modelagem de classes dos dados necessários pelo engenho e que esta modelagem seja implementada por um banco de dados orientado a objetos, com suas instâncias de classes e suas associações entre objetos. Este banco será criado na memória através de instâncias de suas classes, carregando-se os dados dos objetos do banco de dados da interface (das tabelas geradas pelo Compilador). Com isso obtém-se uma alta performance e uma maior resistência a possíveis problemas de disco. O modelo de classes deverá prever os armazenamentos requeridos pelo algoritimo do engenho. Por exemplo, ao varrer um período de tempo de 30 minutos para uma dada condição de disparo de coleta, poderão ser encontradas várias ocorrências. Logo deverá haver uma classe de histórico de disparos que armazene os fatos para um posterior envio de comandos. A conectividade do Extrator com os historiadores é feita de forma simples, pois todos eles possuem uma interface em geral tipo OLEDB que permite o envio de comandos padrão SQL
para recuperar os dados dos historiadores. O desenho do algoritimo do engenho é influenciado pelos recursos disponíveis por estas interfaces de leitura dos historiadores. 6. Conclusão. O uso de historiadores ou PIMS em plantas industriais traz uma vantagem significativa que é o fato de manter-se um banco temporal compactado com o registro de todos os tags relevantes, podendo ser usado para extrações, auditorias, controles estatísticos e gráficos em geral. Mas apesar dos sofisticados programas add-in que acompanham os historiadores, nem sempre consegue-se fazer extrações de dados para outros tipos de sistemas sem ter que construir-se algum tipo de interface. Este artigo, além de propor o uso de historiadores como base de fornecimento de dados para sistemas corporativos, apresenta uma solução moderna, robusta e flexível para interfaces entre historiadores e sistemas corporativos. O Sistema de Coleta Automática de Dados Industriais dá a sua contribuição para a melhoria da qualidade dos processos e produtos, pois pode coletar dados que medem estas caraterísticas e enviá-los para análises corporativas. Em relação a melhoria da lucratividade, sua influência é inquestionável, pois o sistema poderá coletar informações de tempos de paradas de equipamentos que serão processadas por sistemas de gerenciamento da produtividade, perseguindo sempre o aumento da mesma. 7. Bibliografia. BUSINESS RULES GROUP. Defining Business Rules - What Are They Really. Jul 2001. Disponível em: http://www.businessrulesgroup.org/first_paper/br01c0.htm. Acesso em: 22 Out 2002. Software Historiador-Arquitetura 2004. Disponível em: http://www.historico.com.br. Acesso em: 12 Fev 2004. Kusiak, Andrew Intelligent Manufacturing Systems -. Englewood Cliffs, New Jersey : Prentice Hall International Series in Industrial and System Engineering, 1990. 237p. ISA-The Instrumentation, Systems, and Automation Society ANSI/ISA S88 Batch Standard a General Overview ISA Philadelphia Section 20 February 2002 ANSI/ISA 95.00.01-2000 Enterprise Control System Integration Part 1: Models and Terminology ANSI/ISA 88.00.02-2001 Batch Control Part 2: Data Structures and Guidelines for Languages