Parametrização remota: FDT + eEDDL = FDI?

Grupo de trabalho estuda unificação das tecnologias

Em abril de 2007, o grupo de trabalho conjunto EDDL e FDT anunciou que estudaria uma solução unificada das duas tecnologias, o chamado FDI, o que seria um alívio para os usuários. A solução unificada também é boa os fabricantes que não precisarão mais investir em desenvolvimento de produtos para duas tecnologias. O FDI também deve ser compatível com a Namur NE 105.

A nova arquitetura está sendo desenvolvida voltada para a tecnologia cliente/servidor; plataforma independente do sistema operacional; host independente do sistema; compatível com o que já existe de EDDL e FDT de descrições de dispositivo; aplicável para quaisquer tecnologias de comunicação de dispositivo do campo; aplicável para topologias de rede hierárquica e heterogêneas; tecnologia aberta que deve se tornar uma norma internacional. Estratégias de migração também serão desenvolvidas. O grupo de trabalho tinha o final de 2008 como primeira data para o lançamento do FDI, o que não se confirmou. A mais nova previsão é que a especificação final esteja disponível em meados de 2010.

O FDT Group é uma organização composta por 57 empresas que buscaram uma interface não proprietária para integração de instrumentos e sistemas. Só que o não proprietário estava – e ainda está – amarrado ao ambiente Windows.

O time de cooperação EDDL surgiu em 2003 da união Fieldbus Foundation, Hart Foundation e a Organização Profibus para desenvolver uma interface gráfica e históricos permanentes. As três tecnologias (FF, Hart e Profibus) utilizam EDDL para parametrização e descrição de seus instrumentos.

O interessante é que, ao se traçar uma linha do tempo, verifica-se que a unificação, assim como as disputas para estabelecer normas em geral, enfrenta muitas variáveis... Em fevereiro deste ano, o FDT Group lançou o FDT 2.0, para incluir melhorias à tecnologia e garantir a migração. E o FDI ainda não saiu.

FDT e EDDL não são protocolos, são como drivers ou softwares não executáveis que sozinhos não fazem nada; é preciso de uma infra-estrutura para que a comunicação aconteça. Eles interpretam e disponibilizam dados e, no geral, hoje, usar um ou outro não influi no comportamento do sistema como um todo. Só vão acontecer problemas se, ao se utilizarem versões mais antigas, na hora de uma substituição ou manutenção, não se tiver arquivados os parâmetros necessários.

Os dois surgiram da necessidade de parametrizar e configurar remotamente os instrumentos de campo e as grandes discussões começaram com a necessidade de armazenamento permanente dos dados e do obrigatório uso do Windows.

Já a partir de 2006 o EDDL Enhanced era uma norma IEC. Mas o mercado, a utilização de fato de uma tecnologia é que dita o que “norma”. Voltando no tempo: ter uma linguagem padrão única para dispositivos portáteis como os handhelds na década de 1990 já era um grande passo para quem precisava configurar instrumentos no campo. Porque antes disso, cada instrumento tinha seu próprio configurador. E era voltado para Hart que, de fato, foi o primeiro protocolo aberto multi-fornecedor. O Hart foi criado pela Emerson que, a exemplo da IBM, abriu a tecnologia para criar mercado. O padrão de comunicação do Hart era aberto, mas precisava definir o padrão de parametrização, de como ter folhas de dados eletrônicas que podem ser lidas por qualquer fornecedor. Antes do Hart só havia o 4-20 mA, e não era possível fazer endereçamentos via rede pois o 4-20 mA só transmite o valor medido: era preciso ir até cada instrumento e fazer a configuração. O Hart foi um caminho aberto e a linguagem era o DD. Quando surgiu o primeiro instrumento Profibus PA, ele utilizou o DD.

Mas, em paralelo, os acionamentos – que possuem muito mais parâmetros que um instrumento de campo – demandavam a visualização gráfica devido às curvas e rampas do seu trabalho. E cada fornecedor criava um software de parametrização para os acionamentos, com muita riqueza gráfica já que o PC permitia – os handhelds tinham um display muito limitado. O FDT/DTM foi uma resposta a demanda de representar visualmente melhor os dados num ambiente Windows, com arquivamento. O DTM é semelhante ao DDL, um objeto de software compilado, com grande riqueza de recursos, e o FDT é onde o DTM roda. E aí surgiram as dúvidas quanto a compatibilidade das versões – seria necessário atualizar todos os instrumentos a cada atualização do Windows. É um efeito colateral. Mas o pensamento deve ser: uma aplicação DOS roda no Windows? Pode rodar, desde que o sistema operacional tenha um mecanismo de suporte a softwares legados. Se existir um emulador para aquele software não há problema. Os componentes não podem, então, estar amarrados a versões de sistemas operacionais. No mundo do PC, o hardware que rodava um Windows 3.1 já virou sucata no decorrer das versões, enquanto um instrumento não. Uma DLL de Excel, que tem milhões de usuários vale a pena ser atualizada rapidamente no caso de uma mudança de versão do Windows – no mundo industrial o número de usuários é menor, e a atualização dos DTMs provavelmente não acontece com tanta frequência.

Como ter o melhor dos dois mundos? Daí a analogia com a web. O formato em que são descritas as páginas da web é independente de plataforma porque é uma linguagem de markup. O HTML descende do SGML, o pai de todas as linguagens de markup. O EDDL também uma forma de linguagem de markup que permite que em texto se descreva toda a funcionalidade necessária para criar recursos gráficos. Mas faltava desenvolver alguns aspectos que só apareceram no Enhanced EDDL, com a mesma riqueza de recursos gráficos, que foi homologado como IEC.

O OPC precisava de uma linguagem descritiva de estruturas de parâmetros e nisso o EDDL caiu como uma luva: ao invés do OPC criar outra forma de escrever estruturas, ele adotou o Enhanced, para o novo padrão OPC UA, que congrega os métodos de comunicação baseados na tecnologia HTTP da Web, o DA – para acesso em tempo real, Alarmes e Eventos, HDA – para acessar dados históricos armazenados em disco -, e as outras modalidades, antes separadas e amarradas ao mecanismo de  comunicação DCOM do Windows.

Mas tanto o EDDL quanto o DTM são formas de escrever os parâmetros dentro do instrumento, mas os parâmetros do instrumento são um só, tanto que um mesmo instrumento pode ser configurado por uma ferramenta EDDL ou DTM. São formas diferentes de ler a mesma coisa. Quando se compra um instrumento ele não muda o firmware se o leitor de parâmetro vai ser baseado em DTM ou EDDL. O que tem que estar claro é a funcionalidade de comunicação acíclica – no caso do Profibus PA, por exemplo, DPV1. O instrumento tem que permitir upload e download on line e o fabricante deve disponibilizar o arquivo EDDL para ser lido pelo software de parametrização.

Siemens e Emerson – que possuem duas ferramentas de gerenciamento de ativos bem desenvolvidas – concentraram-se em utilizar apenas o eEDDL/IEC 61804-3, ao contrário dos outros fornecedores que disponibilizam mais frequentemente ferramentas baseadas no FDT do que no eEDDL. O que parece limitado na verdade não o é porque a tecnologia eEDDL em conjunto com OPC UA torna a abordagem mais simples porque qualquer software tem acesso à parametrização armazenada numa ferramenta de gerenciamento de ativos. Porque nem DTM nem EDDL sozinhos acessam a estrutura de dados. Algumas das ferramentas de gerenciamento de ativos existentes têm interface SQL e OPC, o que torna muito mais fácil acessar os dados via TI do que ir direto ao instrumento.

Os grandes usuários focam essas tecnologias amarradas aos sistemas/DCS que utilizam. E uma mesma planta pode ter instrumentos que possuem arquivos de descrição eletrônica em uma ou outra linguagem. Saber esses detalhes é importante para quem configura. E quem configura? Quem comissiona – o usuário, o fabricante, um integrador... O instrumento pode ser o melhor disponível no mercado mas sem o acesso à parametrização, sem o arquivo na plataforma adequada, podem surgir problemas. O FDI vai suportar todas essas nuances e ainda permitir a migração do que está hoje no campo. E quem precisa saber disso tudo no usuário? O pessoal da engenharia na hora de especificar e o pessoal da manutenção.

O mais importante de se debater e divulgar uma tecnologia ou outra é a fixação de uma cultura de gerenciamento de ativos e parametrização remota. Porque ainda existem muitas plantas onde essa cultura não existe, onde os projetos não prepararam a estrutura para receber novas tecnologias. É preciso ter em mente que o hardware deve permitir parametrização remota baseada em roteamento/datapasstrough da Ethernet. Os sistemas mais novos já têm essa função embutida mas é sempre bom especificar. Sem controladores que permitam o fluxo de dados, é necessário incluir um gateway para cada mestre de rede de campo.

Isso tudo deve ficar mais tranquilo quando sair o FDI, que vai unificar essas linguagens. Até lá, é não deixar a guerra mercadológica impedir boas escolhas técnicas.

Comparando

Para comparar FDT e eEDDL, uma iniciativa da WIB com a Shell Global Solutions promoveu um teste das duas linguagens numa rede Fieldbus Foundation. Apenas o FDT Group tomou parte no experimento – que focou mais intensamente o acesso aos dados, comissionamento e manutenção. Em 2007, quando os testes foram aplicados, o eEDDL acabara de ser lançado e o FDT para FF era novidade. A Shell testou a interação das tecnologias com o FF no seu Centro de Pesquisa e Tecnologia, em Amsterdam, na Holanda, usando três DCS – Emerson, Yokogawa e Invensys – e três ferramentas de gerenciamento – Pactware, Metso e Yokogawa. Segundo os testes, apenas o DCS da Invensys trabalhou bem com as duas. Foram utilizados quatro instrumentos de campo mas apenas o da Metso, à época, suportava DDs, eDDL e DTMs.

Estrutura modular formadas pelos commDTM possibilita FDT trabalhar com protocolos

O FDT é uma ferramenta que surgiu para a padronização da forma de acesso a dispositivos de campo, oferecendo liberdade ao fabricante de equipamentos para integrar todas suas funções disponíveis ao usuário final, em uma interface universal – desde uma interface gráfica para a disponibilização de dados até uma complexa rotina de gerenciamento de ativos, ou monitoramento da continuo do estado do equipamento. Com isso o usuário ganha uma interface única para acessar qualquer tipo de dispositivo de campo, desde um complexo inversor de frequência a uma simples chave de nível, reduzindo a necessidade de treinamento e especialistas em infinitos softwares.

A forma como é construída a tecnologia FDT/DTM permite a criação de infinitas soluções, e a integração das mais diversas tecnologias a partir do desenvolvimento de novos drivers de comunicação (commDTM) e drives de gerenciamento de dispositivos (DTM). Hoje já é possível acessar um equipamento a milhares de quilômetros de distância através de um commDTM criado para um gateway com transmissão de sinal via celular. Ou seja, um dos assuntos mais discutidos no momento - Wireless - está longe de ser um grande problema para o padrão FDT/DTM.

O FDT já está pronto para trabalhar com Hart, Profibus, FF, Modbus, Asi, DeviceNet etc. Toda essa integração de protocolo é possível graças a estrutura modular formadas pelos commDTM, que permite que dispositivos de comunicação sejam diretamente conectados a um Frame FDT como o FieldCare ou PACTware. Além dos protocolos de campo já conhecidos e utilizados dentro do FDT já temos interfaces prontas para protocolos como o GSM/GPRS (sinal de celular), o próprio Ethernet TCP/IP e o WirelessHart que já surge pronto para trabalhar com o FDT/DTM.

O FDT Group é uma organização com sede na Bélgica que se reúne desde 1998, para discutir os padrões e limites da tecnologia, certificar novos DTMs, Frames FDT e sistemas de certificação, mostrar a interoperabilidade entre equipamentos, protocolos e fabricantes que colaboram com a tecnologia além de divulgá-la ao redor do mundo. Durante os últimos anos diversos testes, seminários e roadshows foram realizados pelo mundo - em agosto de 2007 foi realizado um ciclo de palestras itinerantes pelo Brasil, que visitou cinco capitais (São Paulo, Rio de Janeiro, Porto Alegre, Salvador e Belo Horizonte) realizando a divulgação da tecnologia FDT, para diferentes indústrias. O FDT Group continua com suas atividades no Brasil basicamente conta com as empresas Endress+Hauser, Smar, Invensys, Sensor do Brasil, ABB, Yokogawa,  Rockwell e Metso. Para dar continuidade a esse trabalho, o grupo, expõe e faz palestras durante o ISA Show deste ano. André Nadais, Flow Business Driver da Endress+Hauser, ressalta que o FDI é o fim de uma pequena batalha de tecnologias nas quais o prejudicado era o usuário final. Anunciado na Hannover Fair de 2007, o FDI será o resultado de um trabalho em conjunto do FDT-Group com a ECT (EDDL coopertation Team) para uma junção do FDT com o EDDL. Em nenhum momento foi intuito do FDT substituir a tecnologia EDDL que sempre fez o seu papel na integração de sistemas com suas vantagens evidentes, porém seu uso é limitado na representação e exploração de recursos do equipamento.

“O que o FDI se propõe a fazer e unir o melhor de dois mundos e trazer isso para o usuário final. Como qualquer grande junção isso demanda um certo tempo para o desenvolvimento e testes, sem que prejudique nenhuma das partes envolvidas. Mas, independente de como será o padrão a caminho e de qual nome ele terá, isso será compatível com a tecnologia atual aceita pelo FDT e pela ECT, ou seja, o usuário que decidir por FDT hoje está pronto para padrão que virá em breve”.

A Endress+Hauser em conjunto com a CodeWrights lançou um software para trabalhar com EDDL e FDT em FF, baseado em mais um padrão do FDT Group - o iDTM (interpreter DTM) para a integração daqueles equipamentos que não possuem DTMs. Esse pacote de iDTMs está disponível no site da Endress+Hauser para download sem custos para o usuário. O próximo passo é o desenvolvimento de iDTMs para
Fieldbus Foundation e Profibus.