Alexandre Baratella Lugli, Antônio Augusto Rodrigues de Camargo
e João Pedro Magalhães de Paula Paiva
Instituto Nacional de Telecomunicações (INATEL)
PICC/PITC (Centro de Competências) PROFIBUS Brasil
e João Pedro Magalhães de Paula Paiva
Instituto Nacional de Telecomunicações (INATEL)
PICC/PITC (Centro de Competências) PROFIBUS Brasil
Resumo: Neste artigo, foi abordado um estudo da técnica de identificação de falhas em um escravo de forma automática, através do desenvolvimento de uma plataforma de supervisório dentro do protocolo industrial PROFIBUS. O objetivo é criar um sistema que gere ganhos consideráveis no gerenciamento da planta e no tempo de identificação e resolução dos possíveis problemas encontrados dentro dos processos industriais.
V. APLICAÇÃO PRÁTICA
O experimento prático tem como objetivo o desenvolvimento de um sistema supervisório para a identificação de falhas, gerado pelo canal de diagnóstico do dispositivo, em um ou mais escravos na rede PROFIBUS DP, conforme o diagrama de blocos mostrado na figura 5.
Diagrama de blocos do sistema.
A rede PROFIBUS DP é formada por um CLP Siemens S7-1516-3 atuando como mestre e três escravos Sense PSH5 – M32 – DP, mostrado na figura 6, que operam como monitoradores de válvulas; este dispositivo possui duas entradas digitais e uma saída também digital. A comunicação entre o CLP e o sistema supervisório Elipse E3 é realizada através de um cabo padrão Ethernet.
Escravo monitorador de válvulas Sense PSH5.
A programação, que segue o fluxograma mostrado na Figura 7, foi realizada na linguagem Ladder, por meio da ferramenta computacional TIA Portal, onde os blocos utilizados, DeviceStates e DPNRM_DG, possuem parâmetros e configurações específicos do fabricante Siemens. A configuração do sistema e uma fração do código são mostradas, respectivamente, nas figuras 8 e 9.
Fluxograma do código.
Configuração da rede no TIA Portal.
Aplicação na linguagem Ladder.
O programa se inicia ao chamar o bloco de função DeviceStates. Este bloco de função faz verificação do status de cada dispositivo conectado na rede PROFIBUS. O bloco possui duas entradas e duas saídas e estão representadas nas Tabelas IV e V a seguir.
Tabela IV – Entradas do bloco de função DeviceStates.
Entrada | Descrição |
LADDR | Número de identificação do mestre DP |
MODE | Tipo de status a ser lido: • 1 – IOs dos escravos estão configuradas Tabela IV – Entradas do bloco de função DeviceStates.. • 2 – IOs dos escravos com defeito. • 3 – IOs dos escravos desabilitadas. • 4 – IOs dos escravos existem. • 5 – IOs dos escravos para um problema ocorrido. Por exemplo: – Manutenção demandada ou recomendada. – Não acessível. – Não disponível. – Erro ocorrido. |
Tabela V – Saídas do bloco de função DeviceStates.
Saída | Descrição |
RET_VAL | Status da instrução |
STATE | Buffer do status das IOs dos dispositivos ou dos escravos DPs. |
No caso do presente trabalho, o campo MODE foi configurado como 2, pois o objetivo é identificar um escravo com defeito.
Com as informações do DeviceStates, o programa MAIN chama a função DIAG_READ, que é responsável pela leitura do diagnóstico, caso necessário. Dentro desta função, existem os blocos DPNRM_DG (um para cada escravo conectado na rede), que são responsáveis pela leitura dos diagnósticos, onde cada um deles é configurado da mesma maneira. As entradas e saídas destes blocos estão representadas nas Tabelas VI e VII seguintes.
Tabela VI – Entradas do bloco DPNRM_DG.
Entrada | Descrição |
LADDR | Número de identificação do escravo DP |
REQ | Requisição de leitura (REQ=1) |
Tabela VII – Saídas do bloco DPNRM_DG.
Saída | Descrição |
RET_VAL | Se houver um erro enquanto as instruções estão sendo executadas, o valor de retorno contém um código do erro. Se não, mostra o comprimento da informação transferida |
RECORD | Área de destino do diagnóstico lido |
BUSY | Flag que indica se o bloco está ocupado (se BUSY=1, o processo está ocupado) |
As informações do campo RECORD são armazenadas em um data block, onde a informação pode ser retirada para possíveis aplicações.
Para a transferência das informações para o supervisório, é necessário utilizar um driver de comunicação, chamado M-Prot, que é fornecido pelo Elipse. [13] Para configurar este driver, foi preciso realizar os seguintes passos no TIA Portal:
- Habilitar a função Full access (no protection) e Permit access with PUT/GET communication from remote partner;
- Desabilitar a opção Optimized Block Access nas configurações do data block, pois, no modo otimizado, os endereços das variáveis são dinâmicos e, por isso, o driver não os identifica. [13]
As Figuras 10, 11 e 12 mostram a configuração.
Habilitando a função Full access (no protection).
Habilitando a função Permit access with PUT/GET communication from remote partner.
Desabilitando a função Optimized Block Access.
Assim, deve-se criar um tag de comunicação e associá-lo à informação desejada de transmissão pelo mestre PROFIBUS através de quatro parâmetros, apresentados na Tabela VIII.
Tabela VIII – Parâmetros de associação do tag no CLP. [14]
Parâmetro | Descrição |
N1/B1 |
Endereço do CLP. Se igual a 0 e protocolo diferente de
ISOTCP ou ISOTCP243, é substituído pelo
Default Slave Adress. Se o protocolo é ISOTCP ou
ISOTCP243, este valor deve ser deixado em 0
|
N2/B2 | Tipo de dados e área de dados. O valor deve ser composto pelo tipo de dados multiplicado por 100 mais a área de dados (a fórmula é N2/B2 = TipoDados x 100 + Área) |
N3/B3 | Se a área de dados selecionada é V (DB), preencha com o número do bloco DB. Caso contrário, deixe em 0. Caso a memória contenha um bloco DB único ou não especificado, preencha com valor 1 |
N4/B4 | Endereço na área de dados ou offset do bloco DB. Para usar tipos de dados que ocupam mais de um byte, devem ser colocados endereços múltiplos de dois para tipos de dados de dois bytes (16 bits com e sem sinal) e múltiplos de quatro para tipos de dados de quatro bytes (32 bits com e sem sinal e ponto flutuante de 32 bits) |
Depois disso, as informações de erro serão mostradas na tela de aplicação do Elispse E3, criada para a visualização e o monitoramento, onde serão mostrados os status dos três escravos em tempo real.
VI. RESULTADOS
Após a realização de todas as configurações anteriores, o sistema mostra toda a monitoração através da tela de aplicação no supervisório, criada no Elipse E3 e representada no exemplo da Figura 13, onde o escravo 1 apresenta uma falha na solenoide.
Tela da aplicação mostrando uma falha na solenoide no escravo 1.
Na parte superior da tela de visualização, têm-se:
- Indicador de falha – Mostra o status do sistema geral;
- Escravo 1 – Mostra o status da operação no escravo PSH5 de número 1, cujo endereço da aplicação é 74;
- Escravo 2 – Mostra o status da operação no escravo PSH5 de número 2, cujo endereço da aplicação é 52;
- Escravo 3 – Mostra o status da operação no escravo PSH5 de número 3, cujo endereço da aplicação é 36.
A parte inferior (indicador de falhas) mostra o ID number, o código de erro e a mensagem de status (informações retiradas do GSD do escravo) de cada um dos três escravos da aplicação.
As Figuras 14 e 15 mostram exemplos do sistema detectando falha na alimentação e erros múltiplos.
Escravo 2 com falha na alimentação.
Escravo 2 com erros múltiplos.
VII. CONCLUSÃO
Ao término da elaboração do projeto e dos testes propostos, conclui-se que a aplicação da identificação de falhas em escravos, através do desenvolvimento de um sistema supervisório para rede PROFIBUS, é completamente viável e auxilia um processo industrial, pois a automação deste procedimento diminui o tempo gasto na percepção de erros, se comparado com a forma manual.
Em uma aplicação real, muitas vezes, quando uma falha é gerada, o responsável pela manutenção do mesmo, não tem um recurso automático de identificação de erros em mãos, como um analisador de protocolos, e isso, por sua vez, causa um atraso na correção e prevenção, pois primeiramente é necessário identificar que há um problema e posteriormente descobrir com exatidão, qual é este erro.
O desenvolvimento do sistema prático em questão exemplifica a ideia de monitoramento e identificação de falhas em escravos da rede PROFIBUS, porém o objetivo maior é apresentar a ideia da aplicação num contexto geral, onde há um ganho considerável da facilidade de gerenciamento da planta e do tempo de identificação e resolução de problemas nos processos industriais. Possíveis sugestões para futuros trabalhos seriam: a ampliação para os demais e variados tipos de escravos existentes no mercado e a criação de um sistema de alarmes.
REFERÊNCIAS
[1] CASSIOLATO, C. Smar – Redes Industriais, 2018. Disponível em: . Acessado em 3 de julho de 2018.
[2] FELSER, M.; SAUTER, T. The Fieldbus War: History or Short Break Between Battles? 4th IEEE International Workshop on Factory Communication System, Sweden, 2002
[3] LUGLI, A. B.; SANTOS, M. M. D. Redes Industriais para Automação Industrial: AS-i, PROFIBUS e PROFINET, São Paulo/SP, Editora Érica, 1ªEdição, 2010, 176p.
[4] LUGLI, A. B.; SANTOS, M. M. D. Sistemas Fieldbus para Automação Industrial DeviceNet, CANopen, SDS e Ethernet, São Paulo/SP, Editora Érica, 1ªEdição, 2009, 156p.
[5] DMC. Siemens S7 PLC Programming. Disponível em: . Acessado em 03 de julho de 2018.
[6] DLG AUTOMAÇÃO. XM-210 DP – Remota Universal PROFIBUS DP. Disponível em: . Acessado em 14 de julho de 2018.
[7] TIA PORTAL. TIA Portal How To Read Analog Inputs: non-standard rang. Disponível em: . Acessado em 30 de junho de 2018.
[8] CASSIOLATO, C.; PADOVAN, M. A.; TORRES L.; PROFIBUS – Descrição Técnica, 2012. Disponível em: . Acessado em 14 de julho de 2018.
[9] SILVA, W. L.; MOTA, C. H. Métodos para diagnóstico em redes PROFIBUS DP. Disponível em: . Acessado em 30 de junho de 2018.
[10] SIEMENS. Reading Diagnostics Data from a DP slave with SIMATIC S7-1200, 2012. Service & Support Siemens.
[11] JUNQUEIRA, G. S. Análise das Possibilidades de Utilização de Sistemas Supervisórios no Planejamento e Controle de Produção. Dissertação de Mestrado. São Carlos, 2003, 143p.
[12] ELIPSE. Elipse E3, 2018. Disponível em: . Acessado em 3 de julho de 2018.