A coleta automática de dados industriais é o processo de se enviar dados dos sistemas de automação para os sistemas de informação. As peças de dados dos sistemas de automação, chamadas de 'tags', são lidas, transformadas e enviadas aos bancos de dados dos sistemas de informação. Esse processo aumenta a confiabilidade destes dados e evita o trabalho de digitação dos mesmos nos sistemas que os recebem. Desde 1996 participei do desenvolvimento de 6 soluções de coleta automática com arquiteturas distintas. Essa linha do tempo é mostrada na figura a seguir, e cada solução será detalhada nos próximos tópicos. Gostaria de ressaltar que essas soluções não são minhas, mas de dezenas de consultores e profissionais especializados dos clientes, que participaram destes projetos.
1996-Blocos SQL
Em 1996 não havia tantas ferramentas para a coleta automática como hoje, e esse processo era de certa forma uma novidade. O primeiro projeto no qual participei foi o envio de informações do processo para um sistema de controle de qualidade, a partir de tags de uma base de dados de um sistema supervisório. Tratava-se de um Fix Dmacs, produto que hoje é da GE, e na época já despontava com um dos líderes no segmento. A lógica do supervisório era toda implementada através de blocos, cada um com uma função específica. E um destes blocos, o 'Bloco SQL', permitia que enviássemos informações para um banco de dados através de comandos SQL. Então foram criadas stored procedures , que são programas que executam dentro do servidor de banco dados e são escritos em linguagem SQL (Structured Query Language). Foi criada uma stored procedure para cada tipo de informação a ser enviada, e foram incluídos no supervisório um bloco sql para cada informação. A stored procedure recebia como parâmetros valores de tags do supervisório e tratava de gravá-los nas tabelas respectivas. Cada bloco tinha opções de configurações que permitiam a definição do evento que iria disparar cada um deles, podendo ser por tempo ou pela condição de ocorrência de valores dos tags. Desta forma o banco ia sendo povoado com os dados de automação.
Essa solução tinha como vantagem a simplicidade da infraestrutura, bastando uma conexão de rede com o servidor de banco de dados. Mas como desvantagem, havia a sobrecarga de memória do supervisório, e a carga de um novo programa toda vez que se fizesse uma alteração nas coletas. Essa desvantagem acarretava um risco de interferência na principal função do supervisório, que era controlar o processo.
1997-C++ c/Supervisório
O segundo desafio foi o de enviar os dados para um sistema MES, que incluía controle qualidade do processo, controle de operações e rastreabilidade. Como o número de dados enviados seria bem maior que o anterior, não poderíamos continuar com os riscos da solução de blocos SQL. Então a estratégia foi o desenvolvimento de um programa em C++ que fizesse a leitura dos tags do supervisório e os enviasse para o sistema MES. Foi usada uma interface VBA que era disponibilizada pelo Fix, e permitia a leitura de tags por um outro programa. Mas ainda havia o requisito de performance desse programa, que deveria ser capaz de fazer toda a varredura de condições de disparo em tempo hábil. Para resolver isso usamos um software de inteligência artificial de regras de produção tipo IF-THEN, chamado Ilog-Rules. O Ilog-Rules foi desenvolvido por uma empresa francesa e era o componente inteligente de uma linha de produção para construir supervisórios. A ideia foi colocar cada coleta como uma regra de produção, e a ação seria o envio do dado para o banco de dados do MES, usando a mesma estratégia do projeto anterior, ou seja, stored procedures. O coletor foi desenvolvido em dois módulos: um configurador onde todas as coletas eram definidas, e um executor, ou o coletor em si, que iria realizar a coleta. Este software foi integrado à base dados do MES, fazendo com que todos os códigos necessários para o envio das coletas fossem obtidos de lá. Por exemplo, códigos de equipamentos, de itens de coletas, de unidades de medida, etc. Os dados da configuração iriam povoar a rede de regras de produção do Ilog, e uma varredura periódica leria os tags do supervisório e atualizaria os valores da parte IF das regras. O engenho do Ilog disparava cada coleta sempre que a condição fosse satisfeita. O resultado foi uma coleta com performance muito boa, mesmo com um grande volume de dados.
A vantagem desta solução foi o desenvolvimento de um programa de coleta independente do supervisório, sem sobrecarregá-lo, e eliminando o risco de mudança em função de alterações nas coletas. A desvantagem, é que cada coleta tinha que ser cadastrada separadamente no módulo de configuração, dando assim um trabalho considerável para tal, visto que era normal se ter alguns milhares de coletas. A outra desvantagem não era inerente ao coletor em si, mas era o fato de que muitas coletas não possuíam tags com os valores requeridos. Então solicitava-se aos desenvolvedores dos supervisórios que acrescentassem lógicas para gerar novos tags com as informações necessárias.
2003-.net c/Historiador
No ano de 2003, os historiadores, também chamados de PIMS (Plant Information Management Systems), começavam a aumentar a sua participação no mercado, com vários líderes de automação lançando seus produtos. E também se firmavam como a melhor opção para se registrar dados de automação, que eram carentes de históricos. Então surgiu o desafio de um novo coletor, agora lendo tags registrados em historiadores. Como o preço do Ilog havia aumentado muito, pelo fato do produto ter se deslocado para a área de seguros, a estratégia foi a construção de um programa em .net, com os mesmos requisitos de performance, e soluções para resolver as desvantagens anteriores de se cadastrar as coletas uma a uma, e também a questão da complexidade de coletas. Para resolver a performance foi projetado um banco de dados por objetos, que ficaria sempre residente na memória com toda a configuração das coletas. A solução, assim como a anterior, continuava integrada ao banco de dados do MES para a obtenção dos códigos necessários. Assim, cada coleta configurada era carregada em uma instância de um objeto que possuía métodos para enviar os dados para o banco de dados do MES. Foi construído um engenho de varredura por tempo que disparava as coletas de acordo com os dados dos historiadores. Desta forma a coleta podia ser feita retroativamente mudando-se o período de tempo. A desvantagem da solução anterior de cadastramento excessivo foi resolvida com a criação de uma classe de coletas. Uma vez definida uma classe, havia uma geração de coletas daquela classe para os vários equipamentos do mesmo tipo. Isso reduziu enormemente o esforço de configuração. Em relação a facilidades para a complexidade de coletas, era possível definir-se disparos de coletas a partir de expressões envolvendo vários tags, o que atenuou a dificuldade de se definir coletas mais complexas.
As vantagens dessa solução foram a independência do Ilog, a interface com os historiadores que facilitava a depuração das coletas, e a diminuição do esforço de configuração. Os dados eram lidos do iHistorian, hoje Proficy Historian da GE, através de consultas SQL. A desvantagem continuava sendo em relação as coletas muito complexas e que não podiam ser resolvidas pelo recurso da expressão de tags.
2009-.net c/Historiador+PLC
Em 2009, em função do aumento do número de itens coletados para o MES, e também da sua complexidade, optou-se pela incorporação de um PLC, chamado de PLC Concentrador, à infraestrutura das coletas. Esse PLC seria capaz de ler todos os tags dos PLCs do processo, e executar a lógica necessária para as coletas. Desta forma, mesmo coletas de maior complexidade poderiam ser coletadas. Isso aumentou sobremaneira o número de itens coletados. Agora, passava a existir nos historiadores um grupo de tags exclusivos para a coleta de dados. Esses tags eram povoados pelo PLC Concentrador e monitorados para o disparo de coletas pelo coletor .net. Neste ano também se viu que era importantíssimo ter a documentação dessas coletas. Era comum os engenheiros e especialistas de processo perguntarem como era obtida uma coleta, e não terem resposta antes de uma análise sobre lógica do programa de PLC. Então decidimos criar um 'Book de Coletas Automáticas' para cada área do processo. Esse documento era impresso em um arquivo pdf, e continha toda a lógica de formação de cada coleta, inclusive os tags originais dos PLCs do processo que eram utilizados na lógica. E este documento servia de especificação para que os programadores de PLCs pudessem construir os programas necessários.
Essa solução trouxe como vantagem uma maior robustez para enfrentar a complexidade das coletas, e uma documentação que era essencial para o processo de coleta automática. Como desvantagens houve o aumento dos requisitos de infraestrutura, e a inclusão de uma nova especialidade funcional, que era o conhecimento de programação de PLCs.
2021-Node-Red
Com o aumento e a consolidação de ferramentas de middleware e IOT disponíveis para a indústria 4.0, vimos a oportunidade de desenhar uma solução de menor complexidade e custos de infraestrutura que a anterior. Essa solução viria com a adoção de um software livre chamado Node-Red. O Node-RED é uma plataforma de código aberto para conectar dispositivos, APIs e serviços online de forma visual e intuitiva através de fluxos de dados. Toda a sua lógica é construída através de nós (nodes) que se conectam através de fluxos. Os nós podem ser executados concorrentemente. Além disso, há uma biblioteca de contribuição aberta com milhares de nós oferecidos, incluindo acessos a leituras de tags de PLCs, de servidores OPC, de envio de dados por APIs ou para bancos de dados através de linguagem SQL. Era a ferramenta ideal para construirmos um novo coletor sem a necessidade do Historiador e do PLC Concentrador, pois toda a lógica necessária poderia ser programada em seus nós. Então trabalhamos na construção de uma biblioteca de subfluxos, que são nós compostos por uma lógica de outros nós de nível subordinado. Para cada tipo de equipamento construímos um subfluxo com todos os itens que deveriam ser coletados para aquele tipo de equipamento. Essa lógica acessava tags diretamente dos PLCs ou de servidores OPC que disponibilizavam os tags dos PLCs. Os dados eram enviados para o MES através do uso de APIs. Desta forma, a coleta de uma fábrica seria um programa Node-Red com um subfluxo para cada equipamento existente no chão de fábrica, reutilizando o subfluxo daquele tipo que foi disponibilizado na biblioteca, com as devidas parametrizações. O 'Book de Coleta Automática' continuava, e agora era emitido de acordo com os dados dos equipamentos da biblioteca e sua respectiva parametrização em uma planta. Essa solução fica aberta para o uso dos atuais bancos de dados temporais, que substituem em alguns aspectos os historiadores, e são oferecidos a um baixo custo no mercado. Por exemplo, o InfluxDb. Nesse caso os tags serão armazenados nesses bancos, e o programa Node-Red lerá dos mesmos e não mais dos PLCs. Isso facilita muito a depuração das coletas.
A vantagem desta solução foi a diminuição da complexidade e custos de infraestrutura, bastando um servidor Node-Red que pode ser instalado em Windows ou Linux. A desvantagem em relação às outras soluções, é que como ela não era integrada com o banco de dados do MES, era necessário informar na parametrização dos subfluxos todos os códigos necessários, como códigos de tipos de lotes, de produtos, de itens coletados, etc.
2022-Coletor Embutido
A empresa da qual sou fundador desenvolveu um sistema MES para processos por bateladas, que é comercializado com o nome de EasyBatch. Então surgiu um novo desafio que era implementar a coleta automática de dados no produto. Como ele é orientado para indústrias de pequeno e médio porte, o grande requisito é que a coleta fosse a mais descomplicada possível. Então comecei a notar uma característica interessante da maioria das soluções de coletas, que é o fato de que mesmo usando bancos integrados, o MES não sabe da existência do coletor, e o coletor também não sabe da existência do MES. E se nós embutíssemos o coletor dentro do MES? Foi com esse pensamento que enfrentamos esse desafio. O processo no EasyBatch é modelado de acordo com a norma ISA-88, ou seja, através da definição de receitas. Então, ao definir-se algum elemento de uma receita dentro do EasyBatch, como um procedimento, uma operação, um parâmetro ou um material, há a possibilidade de se especificar a coleta daquele elemento através de uma lógica de tags. Esses tags serão enviados a uma tabela na nuvem do EasyBatch, usando-se subfluxos Node-Red oferecidos ao cliente e reutilizados em um programa Node-Red. Então, quando o operador entrar em uma ordem no EasyBatch, as coletas serão dinamizadas de acordo com a lógica definida, lendo os tags que já foram enviados para a nuvem. Isso diminui a complexidade em relação às outras soluções, porque na realidade implementa a coleta sem um coletor. O coletor é na realidade uma função das telas de ordens de produção e cip, que acessa os tags recebidos na nuvem e realiza a coleta de acordo com a especificação. Naturalmente, coletas de maior complexidade terão lógicas adicionais programadas no Node-Red. O Node-Red será colocado em um servidor, mas poderá ser de baixo custo, usando-se por exemplo uma placa Raspberry.
A vantagem desta solução é a simplificação e o baixo custo da infraestrutura necessária. A desvantagem, é que como o coletor está embutido nas telas de ordens, a coleta só é realizada quando as mesmas forem abertas pelos operadores. Isso requer o uso do MES de forma aplicada.
Conclusões
Com a oferta no mercado de excelentes ferramentas de middleware e IOT, a coleta automática de dados industriais ficou muito mais simples e popular hoje, do que em 1996. Mas ainda não arrisco dizer que é uma tarefa fácil de se fazer. Em primeiro lugar, os softwares que irão receber estes dados têm que estar preparados para tal. Hoje em dia isso vem sendo muito facilitado com a oferta de APIs pelos softwares de gestão e que podem ser utilizados para o envio de dados. Mas no meu ponto de vista, o maior problema está na camada de automação. Dependendo da forma como o programa de PLC ou Supervisório está estruturado, pode ser muito difícil conseguir tags para a coleta. E deve-se ter em mente que os requisitos dos sistemas de informação nem sempre são os mesmos dos sistemas de automação. Mas quanto melhor estiverem estruturados estes últimos, mais facilidade haverá para a coleta. Por exemplo, se o sistema de automação estiver subordinado a um processador de bateladas modelado com a norma ISA-88, já é um grande passo para a obtenção de uma coleta com maior qualidade.
Comments