Emulador de Equipamentos de Campo H1

César Cassiolato - Engenheiro de Desenvolvimento e Gerente de Produtos
Daniel Teixeira de Andrade - Engenheiro de Desenvolvimento
Smar Equipamentos Industriais Ltda.

Introdução

Com a Revolução Industrial, muitos processos, tais como químicos, petroquímicos, de tratamento de água, de mineração e outros, apareceram e muitas empresas começaram a desenvolver equipamentos de campo e controladores dedicados para medir e controlar processos, como resultado de uma tecnologia emergente.

Um equipamento de campo é tipicamente parte de um controle realimentado e se localiza no campo para medir e transmitir variáveis de processo, tais como pressão, temperatura, fluxo, condutividade e outras.

Logo após o final da década de 60 surgiram os controladores programáveis, revolucionando o controle de manufaturas e o controle discreto. Um controlador (um computador dedicado ou um PC) pode rodar um controle lógico para acionar válvulas de posição, motores, solenóides, etc, que são elementos finais em um controle realimentado. Até hoje os controladores programáveis se mostram como uma solução eficaz em aplicações exigindo alta velocidade, intertravamento, sequenciamento e atendem as necessidades do controle regulatório.

Na metade da década de 70, com a evolução dos componentes eletrônicos, surgiu o primeiro SDCD, Sistema de Controle Distribuído, mas mesmo sendo uma tentativa pela eficiência e pela performance se mostrou deficiente com o surgimento dos equipamentos microprocessados, pois não estavam preparados para processar informações a mais do que as de controle. Tudo isto sem contar com a permanente necessidade dos controladores programáveis em determinadas aplicações.

Com o crescimento da tecnologia baseada em microprocessadores, começamos a ver, no começo dos anos 80, o lançamento de sistemas de controle distribuído com algumas particularidades, tais como: sinais de 4-20mA, com 2 ou 4 fios, superposição de sinais digitais, comunicação em 1.2kbits/s, aplicações em áreas de alto risco, medições analógicas e operações digitais. No final dos anos 80, apareceu a tecnologia fieldbus (barramento de campo) que durante os anos 90 se tornou um protocolo de comunicação aberto, onde podemos ver sinais digitais explícitos, conexões de 2 ou 4 fios, taxa de transmissão de 31.25 kbits/s para equipamentos de campo, aplicações em áreas de alto risco, operação e medição digital, etc. Várias vantagens para o usuário foram obtidas, principalmente considerando a redução de tecnologias proprietárias.

Fieldbus significa protocolo de comunicação aberto e alguns exemplos são: HART, Foundation Fieldbus (FF), Profibus, Asi, DeviceNet, CAN, SeriPlex, ControlNet, WorldFip, Interbus, Sensorbus, etc. Neste sentido, alguns fabricantes, dominantes dos sistemas SDCD e controladores buscaram acomodar seus sistemas dando suporte também a estes vários protocolos, isto é, passaram a tratar sinais convencionais, discretos e também passaram a ter comunicação digital em fieldbus.

Hoje em várias aplicações vemos um emaranhado de equipamentos, tais como, equipamentos de campos, PLCs, inversores, bombas, sensores, solenóides, botoeiras, etc, com várias características, ou seja, com sinais 4-20mA, HART, Modbus, Foundation Fieldbus, Profibus, Asi, etc, convivendo todos com suas peculiaridades. Alguns fabricantes possuem fieldbuses integrados em seus sistemas mas cada um trabalha com suas particularidades e os usuários precisam saber cada modo de configuração em detalhes e isso exige mais especialistas e treinamentos. Também existe a necessidade de diferentes ferramentas de configuração, tudo isto envolvendo custos adicionais.

Considerando que equipamentos de campo H1 e rede H1 são termos usados na tecnologia Foundation Fieldbus (FF), este artigo nos mostra que qualquer protocolo de comunicação industrial poderia ser visto como o protocolo FF exigindo menos detalhamentos, treinamentos e custos em geral. Através da idéia da emulação de equipamentos de campo H1, seria possível emular funcionalidades básicas de equipamentos de campo H1 conectados em uma rede H1, provendo parâmetros contidos e de entrada e saída (E/S) de equipamentos de campo não H1 via blocos funcionais FF.

Portanto, se o usuário conhece a tecnologia FF não deveria ser um grande esforço trabalhar com outras tecnologias. Isto é o que o cliente normalmente busca, redução de custos de projeto, uma mesma plataforma, fácil integração, instalação e manutenção, tudo em um mesmo ambiente integrado, com as mesmas ferramentas de configuração, de forma eficiente e segura. Ou seja, a idéia principal deste artigo é mostrar que as informações requeridas pelos vários protocolos/sistemas, de uma forma ou de outra, são praticamente as mesmas.

Detalhamento do Emulador

Baseado na idéia de que qualquer protocolo de comunicação industrial pode ser visto como o protocolo de campo (fieldbus) da FF através da emulação de equipamentos de campo H1, este artigo apresenta o detalhamento de como um equipamento de ligação HSE (HSE Linking Device, onde o termo HSE é definido mais abaixo) certificado pela FF poderia emular esses equipamentos dentro do mesmo hardware e de modo paralelo.

A seguir serão apresentados alguns conceitos básicos da arquitetura FF para facilitar o entendimento da idéia principal deste artigo.

A arquitetura de um sistema FF deve ser capaz de endereçar aplicações e interfaces de comunicação para ser possível prover o gerenciamento da rede (network) e do processo que se pretende controlar.  Os componentes genéricos desta arquitetura são apresentados na Figura 1.

Figura 1: FF Arquitetura Genérica do Sistema.

Nessa arquitetura genérica deve haver o núcleo de gerenciamento do sistema (System Management Kernel) e suas funcionalidades (AP1... APk), o módulo de aplicação com a descrição de objetos e dicionários (DD e OD) e com os objetos e aplicações do blocos funcionais (Function Block Objects e Function Block Aps), o módulo do agente de gereciamento de rede (Network Management Agent) e seus objetos (SMIB e NMIB), e o módulo de comunicação com suas camadas (FMS, Connectionless and Connection-Oriented Services e MAC and PHY).

A Figura 2 mostra como os componentes genéricos da arquitetura FF podem ser adaptados para o ambiente da ethernet de alta velocidade (HSE – High Speed Ethernet) e como deve ser a arquitetura de um equipamento de ligação HSE.

Figura 2: Arquitetura de um Equipamento de Ligação HSE da FF.

O módulo de comunicação da arquitetura mostrada pela Figura 2 é formada pelos componentes: IEEE 802.3 MAC and PHY Layer (que é conectado fisicamente a uma rede ethernet comum de10/100 Mbits/seg), IP, TCP e UDP, ou seja, esse módulo utiliza o protocolo padrão TCP/IP como protocolo de transporte para o protocolo industrial HSE definido pela FF.

Um equipamento de ligação HSE, opcionalmente, pode conter uma ou mais aplicações de blocos funcionais (FBAPs) representada na Figura 2 por “FBAP VFD 1...FBAP VFDn”, porém ele necessita, adicionalmente, de uma ou mais interfaces H1, representada pelo módulo H1 (H1 Inferface 1... Bridge...H1 Interface N).

Cada interface H1 incluída no equipamento de ligação HSE requer os seguintes componentes H1: FMS, FAS, DLL, Physical layer, NMA e SMK, e é conectada fisicamente a uma rede H1 (H1 Network), onde também estão conectados equipamentos de campo H1 que trocam informações através do protocolo industrial H1 definido pela FF.

A Figura 4 apresenta um exemplo de como podem estar conectados equipamentos em um sistema FF. Nota-se que o configurador de sistemas FF, mesmo conectado na rede HSE, pode configurar os equipamentos de campo H1 na rede H1 através do equipamento de ligação HSE.

Figura 3: Exemplo de um Sistema FF.

A Figura 4 mostra como os componentes genéricos da arquitetura FF (Figura 1) também podem ser adaptados para o ambiente H1.

Figura 4: Arquitetura H1 definido pela FF.

A referência 7 pode ser consultada para um melhor entendimento das siglas e abreviaçõs das Figuras 1,2 e 4. Para maiores informações sobre as especificações da FF, deve-se consultar a referência 8.

Baseado nas Figuras 2 e 4, numa representação simples, a arquitetura de sistema de um equipamento de ligação HSE pode ser representado pela Figura 5.

Figura 5: Exemplo de Arquitetura de um Equipamento de Ligação HSE FF.

O módulo HSE Stack, na Figura 5, poderia ser implementado a partir das 2 partes principais da arquitetura de um equipamento de ligação HSE (representada pela Figura 2): a parte FF, representada pelos blocos em cinza claro, que seria responsável pelo gerenciamento do protocolo HSE (FDA Agent, NMA, SMK, etc), e a parte padrão TCP/IP, representada pelos blocos em cinza escuro, que seria responsável pela comunicação com a rede ethernet (MAC and PHY layers, IP, TCP and UDP).

O módulo H1 Stack poderia ser implementado a partir da arquitetura de um sistema H1, representada pelos blocos em cinza claro da Figura 4, e seria responsável pelo gerenciamento (SMK, NMA, etc) e pela comunicação (PHY, DLL, FAS and FMS) com a rede H1.

O módulo IDShell poderia ser implementado para faciliar a interface do módulo HSE Stack com o módulo H1 Stack. Por exemplo, o módulo IDShell seria responsável pela troca de dados em uma ligação HSE-H1, que poderia ser uma ligação direta de configuração entre o configurador (conectado numa rede HSE) e um equipamento de campo H1 (conectado numa rede H1), como mostrado na Figura 3.

O módulo FB Application seria implementado para prover uma interface do Módulo HSE Stack e do módulo H1 Stack com os módulos OD e FB. O módulo OD armazena as informações locais do equipamento, como o tipo de estrutura de dados usados nos blocos funcionais locais, etc. E seria no módulo FB que se encontrariam todos os mecanismos para executar as aplicações dos blocos funcionais.

Assim, a idéia de emular equipamentos de campo H1 seria remover os blocos de comunicação (com a rede H1) do módulo H1 Stack, como os blocos FAS, DLL e PHY da Figura 4, e incluir um novo módulo chamado H1  Field Devices Emulator (emulador de equipamentos de campo H1). A Figura 6 apresenta uma possível arquitetura de um equipamento de ligação HSE com o módulo H1 Field Devices Emulator.

Figura 6: Exemplo de Arquitetura de um Equipamento de Ligação HSE com o Módulo H1 Field Devices Emulator.

Para um melhor entendimento do módulo H1 Field Devices Emulator, ele pode ser melhor representado pela Figura 7.

Figura 7: Outra Representação do Módulo H1 Field Devices Emulator.

Portanto, quando um equipamento de campo que não é H1 fosse conectado na rede não H1 (onde também está conectado o módulo Non H1 Stack), um equipamento de campo H1 seria automaticamente instanciado dentro do módulo H1 Field Devices Emulator. Esse equipamento de campo H1 instanciado passa a emular todas as funcionalidades básicas de um equipamento de campo H1 real quando conectado em uma rede H1 e passaria a trocar dados com o equipamento de campo não H1 (que foi conectado) por meio de blocos funcionais dedicados que seriam executados no módulo FB dentro do módulo H1 Field Devices Emulator.

Equipamentos de campo não H1 poderiam ser, poe exemplo, equipamentos que usam o protocolo Modbus e equipamentos que usam o protocolo Profibus. Por meio de blocos funcionais projetados para trocar dados com os protocolos Modbus e Profibus, poderíamos implementar, de uma maneira simples, o sistema representado pela Figura 8.

Figura 8: Exemplo de um Sistema FF com Equipamentos de Campo Não H1 (Modbus e Profibus).

Do ponto de vista do usuário ou do configurador de sistemas FF, todos os equipamentos de campo da Figura 8 poderiam ser vistos apenas como equipamentos de campo H1, podendo assim serem feitas configurações que permitiriam a troca de dados entre os equipamentos de campo de diferentes protocolos via equipamentos de ligação HSE e rede HSE.

Conclusão

Este artigo apresenta a idéia de um sistema híbrido que poderia ser a solução da convivência entra várias tecnologias, que ofereceria uma melhor solução custo/benefício para os clientes e além disso, permitiria um enorme tratamento de informações. Ou seja, com a idéia da emulação H1, a solução poderia se tornar mais atrativa pela simplificação de conceitos, pelo ambiente integrado, pela fácil instalação e pela configuração e manutenção sendo feita de uma forma mais segura e eficiente.

Referências

1. BERGE, JONAS, Fieldbus for Process Control:Engineering, Operation, and Maintenance, ISA;
2. BERGE, JONAS, Using Foundation Fieldbus in Hybrid and Batch Applications, Foundation Fieldbus End User Council Australia Inc., 2002;
3. Manuais Smar Foundation Fieldbus;
4. Manuais Smar Profibus;
5. www.smar.com.br;
6. Fieldbus FOUNDATION TM Specification System Architecture;
7. Fieldbus FOUNDATION TM Specifications.