INTEROPERABILIDADE EM UM AMBIENTE PRODUTIVO AUTOMATIZADO

Segundo Gomes (2007), nos últimos anos, centenas de fabricantes de hardware e software produziram uma infinidade de sistemas fechados e proprietários que passaram a compor o “chão de fábrica” das indústrias. A dependência tecnológica decorrente dessa política de automação passou a ser um problema, pois a partir do momento que se escolhia e implementava uma determinada tecnologia de monitoramento e controle, as mudanças de arquitetura se tornavam inviáveis devido ao seu alto custo e impacto. Outro problema das arquiteturas proprietárias é a dificuldade de integração com os sistemas corporativos de uma empresa.

Por outro lado, informações atualizadas, cujas fontes são as mais variadas possíveis, passaram a serem essenciais ao suporte de tomada de decisão de uma empresa. A necessidade de um planejamento estratégico mais preciso, apoiado sobre informações de limitações operacionais e capacidade produtiva, passaram a ser vitais para a formação de estratégias e procedimentos táticos de uma companhia, propiciando o desenvolvimento de novas técnicas de controle operacional e administrativo (SILVEIRA & SANTOS, 1998).

Sendo assim, de acordo com Gomes (2007), o conceito de Automação Integrada tem sido muito evidenciado nos últimos tempos. A integração da planta de produção com os sistemas corporativos permitiu a obtenção das informações do processo industrial em tempo real. Antes, essas informações levavam horas ou até mesmo dias para serem coletadas, o que poderia acarretar uma defasagem em relação aos estímulos que as geravam. De acordo com Silveira e Santos (1998), nesse cenário, entre os diversos fabricantes de produtos para automação industrial, iniciou-se uma tendência para o desenvolvimento de padrões que possibilitassem aos projetistas de redes de automação dispor de tecnologias abertas, que permitissem a interoperabilidade entre dispositivos de fabricantes diversos.

3.2.1. OLE para Controle de Processo/ OLE for Process Control (OPC)

O OPC é um padrão de interoperabilidade entre sistemas industriais, baseado na tecnologia Object Linking Embedding (OLE) da Microsoft e mantido pela OPC Foundation,

57 uma organização sem fins lucrativos, formada por centenas de empresas, cujo interesse é a manutenção da interoperabilidade entre as diversas fontes de dados existentes em plantas de processos industriais (SÁ BARRETTO & GAMA, 2007; MATRIKON, 2007).

Matrikon (2007), afirma que em uma rede de automação industrial existem diferentes fontes de dados, tais como: Controladores Lógicos Programáveis (CLP), IHC, bases de dados, dentre outras. A interconexão entre estas fontes implica na necessidade da aquisição de interfaces proprietárias fornecidas por seus fabricantes. Estas interfaces podem implementar conexões do tipo serial, ethernet, rádio enlace, entre outras, e trabalham com diferentes sistemas operacionais, tais como, Windows, DOS, VMS, Unix, dentre outros. Este formato proprietário obriga aos usuários retornarem aos respectivos fabricantes de cada fonte sempre que houver necessidade de manutenção, ou mudanças no sistema.

O padrão OPC, ao contrário destas estruturas proprietárias, é uma arquitetura aberta que implementa um grupo de especificações OPC, das quais citam-se duas:

• OPC Data Access (DA) – provê o acesso aos dados de processo em tempo real;

• OPC Historical Data Access (HDA) – utilizado para recuperar dados previamente armazenados.

Na Figura 10, tem-se uma arquitetura de automação onde se dispõem as aplicações A e B, desenvolvidas em ambientes distintos, e três fontes de dados, de fabricantes diversos, sejam elas: CLP, unidades de campo, bases temporais ou IHC. Nesse ambiente heterogêneo, se for implementada a conexão de cada uma das aplicações com cada uma das fontes, utilizando soluções proprietárias desenvolvidas pelos fornecedores das fontes, será necessária a instalação, em cada aplicação, de dois drivers distintos, para cada fonte de dados do processo.

Neste contexto, verifica-se que cada uma das fontes possui duas conexões, ou seja, o mesmo dado é gerado duas vezes: uma vez para cada aplicação e para cada driver associado. O número de conexões pode aumentar à medida que surjam mais ambientes de desenvolvimento e mais drivers de conexão. E isso faz com que ocorra uma queda de desempenho nas fontes de dados devido ao número excessivo de solicitações a que são submetidas (SÁ BARRETTO & GAMA, 2007; MATRIKON, 2007).

No modelo arquitetural OPC, disposto na Figura 11, observam-se três servidores OPC, cada um conectado a cada fonte de dados. Estes servidores disponibilizam em arquitetura Distributed Component Object Model (DCOM), em tempo real, dados de processo

58 e dados históricos, respectivamente através da implementação das especificações OPC DA e HDA. A partir do momento em que os dados são disponibilizados para os servidores OPC, estes podem ser adquiridos através de interfaces remotas, os clientes OPC, que podem estar integrados a aplicações desenvolvidas em ambientes distintos. Segundo Matrikon (2007), se um servidor OPC receber duas solicitações simultâneas das aplicações A e B, ele enviará somente uma conexão para a respectiva fonte de dados, promovendo um aumento de desempenho no sistema. Observa-se também que esta arquitetura apresenta uma escalabilidade maior que a do modelo proprietário, a partir do momento em que se podem conectar mais ambientes de desenvolvimento apenas adquirindo as interfaces cliente OPC, certificadas pela OPC Foundation, específicas para cada ambiente.

Figura 10 – Arquitetura Proprietária Figura 11 – Arquitetura OPC

A arquitetura OPC vem ganhando cada vez mais ênfase no que se refere à integração das áreas de processos industriais e negócios. No processo de aquisição de dados, ela é muito utilizada para integrar fontes de dados heterogêneas a um mesmo PIMS.

Na arquitetura de aquisição de dados de processos industriais, disposta na Figura 12, as interfaces clientes OPC, em geral, ficam hospedadas nos nós de aquisição de dados, remetendo os dados para um PIMS que pode ser instalado atrás de um firewall, que o isola do acesso indiscriminado a partir da rede corporativa. Nesta mesma figura, também se verifica a implementação de defesas em profundidade, a partir do momento em que também há um firewall protegendo a rede corporativa da internet (SÁ BARRETTO & GAMA, 2007; DANG, 2007).

Nessa pesquisa, o padrão de interoperabilidade OPC foi utilizado para implementação da comunicação entre a camada de supervisão da UTE-Piloto e o repositório PIMS, utilizado para o armazenamento das séries temporais da planta. Essa comunicação também foi realizada com a interposição de um firewall que realiza a proteção da rede

59 corporativa. Maiores detalhes desta arquitetura são apresentados no item 6.3. O desenvolvimento desta pesquisa está fundamentado nos princípios da modelagem empírica, realizada com base nas séries temporais coletadas a partir do processo produtivo da UTE-Piloto.

Também é objeto desta pesquisa a proposição de uma arquitetura multi-agentes para construção de um SAD. Essa arquitetura contemplou agentes, portadores de schemas que implementem o método de atualização de parâmetros de modelos decisórios, aqui definido, e também se baseou nas técnicas de modelagem empírica realizadas sobre os dados coletados.

Figura 12 – Arquitetura simplificada PIMS Fonte: Modificada de Dang (2007)

60

4. A IDENTIFICAÇÃO DE SISTEMAS E A ATUALIZAÇÃO DE MODELOS