EDDL - Electronic Device Description Language & FDT/DTM – Field Device Tool/ Device Type Management & FDI - Field Device Integration

Introdução

Quando falamos em protocolos digitais abertos, um dos tópicos mais importantes para o sucesso do interfaceamento entre os equipamentos de campo e os sistemas são os arquivos que irão traduzir as características dos dispositivos e facilitar a visualização, configuração, operação e manutenção para os usuários.

Em 2004 a EDDL, Electronic Device Description Language, que inicialmente vinha sendo o padrão adotado pelo Profibus, foi determinada pela IEC como o padrão internacional para descrição de dispositivos, a chamada IEC 61408-2. Com isto a EDDL pode ser usada para descrever equipamentos HART, Foundation Fieldbus e Profibus.

A tecnologia FDT/DTM surgiu de um grupo de fornecedores de sistemas que se uniram para criar uma arquitetura aberta em relação a equipamentos de campo. Ela é orientada ao sistema de software, e baseada em componentes de software.

Basicamente, a arquitetura divide o sistema em três domínios: o domínio da ferramenta de engenharia, o domínio da Field Device Tool (FDT) e o domínio dos equipamentos de campo suportados por Device Type Managers (DTM).

A FDI, Field Device Integration, é a convergência dos conceitos da EDDL e do FDT/DTM. É a proposta de alcançar a máxima interoperabilidade entre sistemas, equipamentos e protocolos de comunicação a partir da integração de padrões abertos existentes.

E quem ganhou foi o usuário, com maior liberdade de escolha, onde no mercado existirá à sua disposição uma vasta gama de equipamentos e soluções de diversos fabricantes interoperáveis e intercambiáveis.
Os fornecedores de sistemas e equipamentos também são beneficiados pela concorrência mais justa, uma vez que seus sistemas podem suportar equipamentos da concorrência e por outro lado, seus equipamentos de campo podem ser  utilizados em sistemas de diferentes fabricantes, ampliando assim a aplicabilidade e, portanto, o seu mercado de forma geral.

 

Mas afinal, o que é a EDDL?

A EDDL é uma linguagem baseada em texto, muito parecida com a linguagem C em termos de estruturação, que descreve as características de comunicação digital dos parâmetros dos equipamentos e dispositivos de campo. É utilizada para facilitar a informação e condições de status, diagnósticos e configuração.Sua base é a DDL (Device Description Language utilizada pela HART desde 1992) onde foram acrescidos comandos visuais, principalmente relativos a parte gráfica e imagens e que visam uma melhor interface aos usuários em termos de configuração, calibração e manutenção. Alguns equipamentos, como por exemplo, os posicionadores possuem várias informações que podem ser gráficas, tais como curvas de tendências, assinaturas de válvulas,etc, que agora poderão ser desenvolvidas com mais facilmente e com mais recursividades.

Além disso, a EDDL permite que os fabricantes de Sistemas possam criar um ambiente único e integrado, suportando qualquer equipamento, de qualquer fornecedor e de diferentes protocolos, sem a necessidade de drivers ou arquivos customizados e, aqui está a grande vantagem para o usuário que poderá trabalhar em um ambiente simples, sem a necessidade de treinamentos específicos para cada tipo de protocolo ou ferramenta.

 



Figura 1 - Integração da EDDL em um sistema Fieldbus

Uma visão geral da  EDDL

A EDDL possui algumas construções básicas onde podemos citar: arrays, blocks, collections, commands, domains, item arrays, menus, methods, programs, records, refresh relations, response codes, unit relations, variable lists, variables, write as one relations.
Vamos a seguir dar alguns exemplos.

  • Variable

    VARIABLE trd1_self_calibration_cmd
    {
                                   LABEL                    [trans_act_self_calibration_cmd];
                                   HELP                      [trans_act_self_calibration_cmd_help];
                                   CLASS                    CONTAINED;
                                   TYPE                      ENUMERATED (1)
                                   {
                                                   DEFAULT_VALUE 0;
                                                   { 0,          "No reaction of the field device"         },
                                                   { 2,          "Start self calibration / Initialization"},
                                                   { 7,          "Reset total valve travel"},
                                                   {255,         "Abort current calibration-procedure"}
                                   }
                                   HANDLING            READ & WRITE;
    }

Note que na estrutura da variável existem algumas informações que não serão vistas pelo usuário e sim serão interpretadas pela ferramenta de configuração.Toda variável possui os campos de LABEL e HELP que trarão informações sobre o parâmetro, possui uma CLASSE, onde o parâmetro pode ser de uso geral, de entrada, saída, diagnóstico, etc; possui um TYPE, que pode ser inteiro, float, enumerated, string, etc; e a forma de acesso permitida, escrita ou leitura ou ambos(HANDLING).
           

  • Métodos

    METHOD method_lower
    {
                    LABEL [smar_cal_point_lo];
                    HELP        " Testing.. ";
                    DEFINITION
                    {
                                   char            flagtest1;
                                   int              CalControl;
                                   float           trim_point, var_feedback;
                                   int              rc,result;

                               flagtest1 = 0;
                               trim_point = 0.0;
                               /* display a message that requires user acknowledgment */
                               rc = ACKNOWLEDGE("WARNING: Control loop should be in manual !");
                               if (rc==0)
                               {
                                               fassign(trd1_cal_point_lo,trim_point);
                                               WriteCommand(write_trd1_cal_point_lo);
                               }
                               else
                                               flagtest1 = 1;
                               while (flagtest1 == 0)
                               {
                                               ACKNOWLEDGE("Wait the valve stabilize in the position!");
                                               rc=GET_LOCAL_VAR_VALUE("Please, enter the valve's position:",var_feedback);
                                               if(rc==0)
                                               {
                                                               fassign(trd1_feedback_cal,var_feedback);
                                                               WriteCommand(write_trd1_feedback_cal);
                                                               result = SELECT_FROM_LIST("Proceed it again ?","Yes;No");
                                                               if (result == 0)
                                                                              flagtest1 = 0;
                                                               else
                                                               {
                                                                              CalControl = 0;
                                                                              iassign(trd1_cal_control,CalControl);
                                                                               WriteCommand(write_trd1_cal_control);

ACKNOWLEDGE("WARNING: Loop may be returned to last operation mode !");
                                                                              flagtest1 = 1;
                                                               }
                                               }
                                               else
                                               {
                                                               CalControl = 0;
                                                               iassign(trd1_cal_control,CalControl);
                                                               WriteCommand(write_trd1_cal_control);
ACKNOWLEDGE("WARNING: Loop may be returned to last operation mode !");
                                                               flagtest1 = 1;
                                               }
                               }
                }
}

O exemplo acima mostra um método de calibração de um posicionador de válvula. O Método é a rotina que passo a passo permite a interface entre o equipamento e o usuário.

  • Menus

MENU Page_trd_set_diag
{
                LABEL "Settings";
                ITEMS
                {
                               Group_setpoint_ao,
                               Group_travel_fy303,
                               trd1_diagnoses_status,
                               method_set,
                               BarVal_display_trd,       
                               BarVal_display_readback   
                }
}

Os menus são agrupamentos de outros elementos e até mesmo outros menus, normalmente relacionados para uma determinada tarefa especifica, onde o usuário pode navegar.

  • Elementos Gráficos
    • Bargraph

MENU BarVal_display_trd_FY303
{
       LABEL                    [trans_act_positioning_value];
       ITEMS
       {
                       trd1_positioning_value                                       (READ_ONLY),
                       func3_AO_out_lower_range_value                    (READ_ONLY),
                       func3_AO_out_upper_range_value                   (READ_ONLY)
      
       }
}

O Bargraph permite que se crie barras de progresso associadas às variáveis, como no exemplo, para facilitar a visualização da posição real da válvula no FY303, posicionador SMAR.

    • Gráficos

MENU Page_yt1
{
               LABEL     "Settings and Diagram";
               ITEMS
               {
                               Group_setpoint,
                               Val_yt,
                               OCX_out_display_1,
                               Val_temp,
                               OCX_out_display_temp  
               }
}

Os gráficos permitem através de componentes OCX as telas de tendências, os gráficos X/Y, etc..No exemplo, tem-se um gráfico do FY303, onde pode-se acompanhar o valor de setpoint versus a posição real da válvula.

Facilitando a visualização, configuração e manutenção

A figura 2 mostra uma tela de configuração, bem simples onde o usuário facilmente pode ter acessos a vários parâmetros.


Figura 2 - Variáveis e Menus

 

A figura 3 dá um exemplo da utilização dos status.

 


Figura 3 - Fácil visualização de status

 

Na figura 4 podemos ver  o comportamento da posição real de uma válvula em função do SP.


Figura 4 - Recursos de gráficos na EDDL do FY303-SMAR

 

O que é a FDT/DTM?

A tecnologia FDT/DTM nasceu de um grupo de fornecedores de sistemas que se uniram para criar uma arquitetura aberta em relação aos equipamentos de campo. Ela é orientada ao sistema de software e baseada em componentes de software.

Basicamente, a arquitetura divide o sistema em três domínios: o domínio da ferramenta de engenharia, o domínio da Field Device Tool (FDT) e o domínio dos equipamentos de campo suportados por Device Type Managers (DTM).

O centro da tecnologia é o DTM, um componente de software desenvolvido pelo fabricante do equipamento capaz de provê, além do acesso a informações do equipamento de campo, as interfaces gráficas de usuário e toda a funcionalidade de configuração, diagnóstico e manutenção do equipamento de campo.

O FDT especifica interfaces padronizadas que garantem a conectividade e interoperabilidade entre uma ferramenta de engenharia e os equipamentos de campo, através dos seus DTMs. Então, uma ferramenta de engenharia que implemente as especificações FDT pode integrar equipamentos de qualquer fabricante para o qual se tenha um DTM disponível, tornando o sistema largamente extensível pela simples incorporação de novos DTM’s.

A ferramenta de engenharia pode ser voltada à configuração, diagnóstico, serviços ou gerenciamento de ativos. Além disso, ela é responsável pelo gerenciamento das comunicações e da persistência das informações em base de dados para todo o sistema, inclusive para os DTM’s.

Tanto o FDT quanto o DTM são baseados na tecnologia COM/DCOM da Microsoft®, uma tecnologia largamente utilizada e para a qual  se encontra disponível uma ampla variedade de ferramentas para diversas linguagens de desenvolvimento.

 

Mas afinal, o que é a FDI?

A FDI, Field Device Integration, é a convergência dos conceitos da EDDL e do FDT/DTM. É a proposta de alcançar a máxima interoperabilidade entre sistemas, equipamentos e protocolos de comunicação a partir da integração de padrões abertos existentes.

Foi inicialmente anunciado em 2006 e a liberação da Especificação Funcional final está prevista para 2010.

A tecnologia FDI foi concebida levando em consideração as inovações na área de interfaces de software e apresenta características que generalizam a integração dos equipamentos de campo a ponto de permitir a integração de outros componentes ao sistema de controle.

O FDI se apresenta como uma alternativa para a padronização de mais algumas interfaces, por exemplo, a interface para  integração de configuradores de lógica ladder de um equipamento de controle discreto de um fornecedor A ao sistema de um fornecedor B.

A arquitetura de um sistema baseado na tecnologia FDI segue um modelo cliente-servidor baseado na tecnologia OPC UA (IEC 62541). Os equipamentos são integrados aos sistemas através do Device Package. O Device Package contém Device Definition, Business Logic, User Interface Description (UID) e User Interface Plug-In (UIP) e Anexos.



Figura 5 - Arquitetura do Sistema usando FDI

A integração de dispositivos de campo é realizado por uma “embalagem do dispositivo” (Device Package) fornecidas pelo fornecedor do dispositivo contendo componentes EDDL(baseada na IEC 61804-3) e um componente opcional programado para interfaces de usuário programado. O User Interface Plug-in (UIP) é um componente criado em linguagem procedural como um DTM e baseado na IEC 62453 (FDT).


Figura 6 - Exemplos de UID e UIP num cliente FDI

Seguem alguns requisitos básicos da FDI:

  • Ser indedepende do sistema Host
  •  Ser independente da plataforma e sistema operacional
  •  Fornecer acesso a plena capacidade dos dispositivos de campo
  •  Suportar FOUNDATION™, HART, PROFIBUS & PROFINET
  •  Aceitar outras tecnologias de comunicação fieldbus
  •  Basear-se nas especificações OPC UA de cliente / servidor e do modelo de informação
  •  Especificações validadas pela ECT
  • Oferecer compatibilidade com a EDD's e DTM's
  • Etc.

Conclusão

A tendência natural tecnológica é o aperfeiçoamento e a coexistência de vários protocolos, cada um buscando explorar ao máximo seus pontos positivos e a EDDL, o FDT/DTM  e a FDI vêm para facilitar isto, colocando à disposição dos desenvolvedores de equipamentos e sistemas um maior poder expressivo para descrição e interpretação dos recursos e interfaces, sem abrir mão das suas características de simplicidade em relação à plataforma e, quem ganha com tudo isto é o usuário.

 

Referências

  • Specification for PROFIBUS Device Description and Device Integration, Volume 2: EDDL Specification".
  • Material de treinamento Profibus – SMAR, César Cassiolato
  • DONAIRES, Omar Sacilotto, FF DD x FDT/DTM: Origens, Características e Tendências., Revista Controle & Instrumentação, Edição nº 99, 2004
  • CARRIJO, Renato Santos, DONAIRES, Omar Sacilotto, SOUZA, Libânio Carlos, FDI – Tecnologia Habilitadora.
  • www.profibus.com
  • www.profi-bus.co.uk/
  • www.fieldbus.org
  • www.smar.com.br  (faça o download gratuitamente  das EDDLs e DTMs da SMAR)

 

Links Relacionados:

 

Siga-nos:

Últimas notícias

Soluções Confiáveis

"Utilizamos cookies essenciais e tecnologias semelhantes de acordo com a nossa Política de Privacidade e, ao continuar navegando, você concorda com estas condições." Ler mais