Desenvolvimento de um mestre classe 2 pertencente a uma ferramenta de diagnóstico em redes PROFIBUS FÁBIO L. NARDUCI, RENATO DA V. TORRES, DENNIS BRANDÃO Laboratório de Automação Industrial, Departamento de Engenharia Elétrica, Escola de Engenharia de São Carlos, Universidade de São Paulo Av. Trabalhador São Carlense, 400. São Carlos – SP. CEP 13560-970 E-mails:
[email protected],
[email protected],
[email protected] Abstract-The communication network PROFIBUS DP is the field bus most used in the entire world. In this context, grows the importance of diagnostic tools that permit fast and safe failure detection, reducing the maintenance costs, the stop times and consequently the losses on the productive process. The main item of a diagnostic tool is the communication process with the network, being this carried out by a master. The proposed work presents the development stages of a master class 2, which will be part of a broader tool (ProfiDoctor) to be used in maintenance and diagnostic procedures, allowing the devices configuration, evaluation and parametrization.
I.
INTRODUÇÃO
Atualmente, os conceitos sobre a automação transpõem o chão-de-fábrica, ou seja, o foco não está apenas em monitorar plantas ou processos, mas integrar informações oriundas de diversos setores produtivos. Neste contexto, uma rede de comunicação é a principal ferramenta que permite a troca de dados mais enriquecida e precisa entre o chão-de-fábrica e o nível da administração corporativa, aspecto este conhecido como verticalização das informações. A definição do protocolo é peça fundamental para o sucesso na implantação de uma rede de comunicação. O comportamento dos sistemas de comunicação industriais é fortemente dependente do protocolo adotado, visto que são exigidos altos índices de desempenho, confiabilidade e imunidade. Há a necessidade da tecnologia de rede escolhida para integrar o processo ser competitiva, padronizada, possuir arquitetura modular aberta e grande aceitação por parte dos fabricantes de equipamentos. O PROFIBUS possui um sistema de certificação qualificado, atende todos os requisitos para a interconexão entre dispositivos de campo inteligentes [1] e possui mais de 20 milhões de nós instalados, o que demonstra a vasta aceitação deste
fieldbus [2]. Atualmente, o PROFIBUS-DP é um dos fieldbus mais utilizados no mundo inteiro [3]. Por estes motivos, definiu-se que o protocolo a ser selecionado para o desenvolvimento deste trabalho deveria ser o PROFIBUS. Considerando a crescente expansão das redes industriais, cada vez mais o desenvolvimento de novos produtos dotados com esta tecnologia se faz necessário para suprir a demanda crescente do setor [3]. Um setor de destaque é o referente aos procedimentos de manutenção e diagnósticos da rede. Existem algumas ferramentas de análise de redes PROFIBUS disponíveis no mercado, porém sua obtenção envolve um custo elevado, visto que são dispositivos complexos que englobam hardware e software específicos [4]. Dentre as ferramentas de análise de redes PROFIBUS disponíveis no mercado, estão: Profitrace, Amprolyzer, PROFIBUS Analyzer, Comsoft NetTest II, Anybus Master Simulator, PROFIBUS ESCOPE, sioCHECK e PROFIBUS Tester. Normalmente, os pacotes oferecidos por estas ferramentas apresentam suas informações de diagnóstico em diferentes formatos e uma vasta experiência é exigida do usuário para acessar e interpretar os dados de diagnóstico. Visando sanar estas carências existentes nas ferramentas de mercado e reduzir o custo final do produto, é proposta uma nova ferramenta para o diagnóstico das redes PROFIBUS. Este trabalho apresenta as etapas de desenvolvimento um Mestre DP Classe 2 (DPM2), que será parte integrante de uma ferramenta mais ampla (ProfiDoctor – Fig. 1), e uma análise relativa às ferramentas de diagnóstico. O ProfiDoctor será uma ferramenta de diagnóstico (software + hardware) que, além de disponibilizar todas as funcionalidades já existentes para a análise das redes PROFIBUS, terá integrado um sistema baseado em princípios de inteligência artificial para a detecção de falhas da camada física da rede PROFIBUS.
Fig. 1. ProfiDoctor
II.
DESCRIÇÃO DO PROBLEMA
A. Ferramentas de Diagnóstico O diagnóstico da rede é cada vez mais importante para melhorar a disponibilidade dos sistemas Fieldbus, reduzir os custos de manutenção, os tempos de parada e consequentemente os prejuízos no processo produtivo. A descentralização da informação torna a engenharia, o comissionamento e a manutenção de instalações cada vez mais difícil, fazendo com que estes custos muitas vezes ultrapassem o investimento com o próprio hardware. Existem vários procedimentos conhecidos para o diagnóstico de falhas em redes PROFIBUS DP: inspeção visual, verificação dos LEDs dos dispositivos, testes com multímetro, testadores de Barramento (Bus Testers), testes com osciloscópio, testes através de telegramas de diagnóstico, testes utilizando ferramentas de configuração do mestre, testes por ferramentas de monitoração de rede e testes utilizando repetidores com diagnóstico. Os métodos que utilizam inspeção visual, verificação dos LEDs e testes com multímetro, são simplórios e limitados. Já o teste realizado com osciloscópio exige um alto grau de experiência do usuário, além de algumas características especiais de hardware serem necessárias ao equipamento. As outras ferramentas são mais abrangentes, cabendo ao usuário definir a que melhor se encaixa a necessidade do diagnóstico, dentro da viabilidade financeira para aquisição. Neste contexto, a idéia deste artigo baseia-se na edificação de um método mais eficaz e amplo de diagnóstico, a fim de detectar a maior quantidade de erros e facilitar o entendimento da falha detectada. B. Características Real-Time do Protocolo PROFIBUS Em sistemas computacionais de automação e controle industrial, as especificações requerem um
sistema de controle preciso tanto no aspecto lógico, como também em relação ao tempo de resposta [5]. De acordo com [6], um sistema em tempo real é aquele que recebe dados, os processa e emite uma resposta dentro de um limite de tempo específico do problema tratado. As redes industriais geralmente são sistemas de tempo-real do tipo Hard Real-Time, isto é, o não cumprimento de um único requisito temporal é considerado inaceitável. A comunicação em tempo real industrial assegura que cada estação detenha tempo suficiente para executar suas tarefas de comunicação dentro de um prazo máximo de tempo [7]. A rede PROFIBUS trabalha com o Tempo de Rotação do Token (TTR), a fim de definir o tempo necessário para que todos os mestres recebam o token por um determinado período de tempo. O desempenho do software, sistema operacional e hardware especializado [6], também interferem diretamente na característica real-time, sendo necessário um estudo criterioso destes componentes antes da execução de um projeto. C. O Terminal de Engenharia DPM2 desenvolvido A utilização de um Terminal de Engenharia DPM2 possibilita transmitir funções acíclicas de leitura e escrita, bem como alarmes entre mestre e escravos, independentemente da comunicação cíclica de dados [8]. Estes terminais também são utilizados para a otimização dos parâmetros de um dispositivo (escravo), ou ainda para se obter o valor do status de um dispositivo sem perturbar a operação do sistema. O DPM2 desenvolvido possibilitará a configuração, avaliação e parametrização de dispositivos em procedimentos de manutenção e diagnósticos, através de estações de trabalhos dotadas com o software ProfiDoctor. As principais funções disponibilizadas por este software são: a captura e exibição das mensagens, o monitoramento da rede em tempo real sem perda de telegramas, filtros para a visualização apenas dos telegramas selecionados, visualização da Live List, decodificação de telegramas capturados, acesso às estatísticas da comunicação, a leitura das entradas e saídas, a mudança de endereço de estações, entre outros. III.
SOLUÇÃO DO PROBLEMA
A. Desenvolvimento do Mestre PROFIBUS Existem diversas maneiras de se desenvolver dispositivos mestres para a comunicação em redes PROFIBUS. Entre estas estão: mestre implementado com chip ASIC, mestre baseado em
software rodando em PC, mestre embarcado em hardware dotado com sistema operacional, entre outros. A maioria das soluções PROFIBUS é baseada em ASIC, que exige hardware específico a ser construído apenas para aquela aplicação PROFIBUS, o que torna a sua comercialização com custo elevado. B. ASICs Profibus O ASIC é um circuito integrado (CI) construído para executar uma tarefa específica. O uso dos ASICs permite a troca simples e rápida de dados entre dispositivos da automação digital, manipulando as informações de acordo com os conceitos estabelecidos pela norma IEC 61158, cabendo aos fabricantes de dispositivos somente integrar os esquemas dos circuitos disponíveis nas descrições dos ASICs ao seu hardware [8]. C. Solução para o desenvolvimento do mestre Como citado anteriormente, o custo final da aplicação dos ASICs no desenvolvimento de mestre é elevado, fugindo assim do objetivo deste trabalho. Já o desenvolvimento de mestre rodando em PC, possui restrições temporais na camada física [4] e dificuldade no determinismo temporal devido ao sistema operacional Windows [6]. Este projeto traz uma solução diferenciada, que diante dos estudos realizados é a que melhor satisfaz a aplicação: a implementação do mestre embarcado em hardware dotado com sistema operacional µClinux. Assim o mestre pode suprir as características Hard Real-Time da rede PROFIBUS, uma vez que à parte determinística do processamento do protocolo será executada por um firmware. A conexão do hardware com o barramento é feita através da interface RS485; já do hardware com a camada de aplicação é realizada via tecnologia TCP/IP (Fig. 1). D. Algoritmos do Mestre Classe 2 O desenvolvimento da ferramenta de diagnóstico ProfiDoctor exige a implementação de alguns algoritmos: Controle do token e FDL. Com a finalidade de se obter um bom desempenho em sistemas PROFIBUS, o MAC utiliza o algoritmo de passagem do token para gerenciar a transmissão de mensagens no barramento, como descrito por [4]. E. Máquina de estados FDL (Fieldbus Data Link Layer) No protocolo PROFIBUS a camada de enlace é denominada de Fieldbus Data Link (FDL). Esta é responsável pela execução dos serviços referentes ao gerenciamento das mensagens, endereçamento
das estações e o controle do acesso ao meio de transmissão [9]. A Máquina de Estados do FDL é a peça fundamental para o desenvolvimento do mestre PROFIBUS. Portanto, uma devida explanação acerca do tema será apresentada a seguir. A máquina de estados FDL é composta por 11 estados que descrevem as ações e transições das estações mestres e escravos no transcorrer da comunicação, como descrito por [9]. Outro aspecto fundamental no desenvolvimento de um mestre é elaboração dos telegramas e caracteres PROFIBUS, que são descritos na norma PROFIBUS [11]. F. Formato do frame de dados Todos os frames PROFIBUS são compostos por 11 bits que atende às normas ISO 1177 e ISO 2022 (um start bit (I) + 8 bits de dados + um bit de paridade (P) + 1 stop bit (S)). A troca de dados do PROFIBUS DP é realizada por código NRZ (Non Return to Zero). O frame a seguir se aplica a todos os bytes de dados/caracter, incluindo os bytes de cabeçalho do telegrama.
Fig. 2. PROFIBUS NRZ-Coded Character Frame
G. Estrutura do telegrama (Mensagem) PROFIBUS Um telegrama PROFIBUS pode conter até 256 bytes, com até 244 bytes de dados e mais 11 bytes de overhead. Um tempo de sincronização, ou seja, um estado ocioso de pelo menos 33Tbits deve estar presente antes de cada pedido do telegrama a ser enviado [8].
Fig. 3. Exemplo de telegrama PROFIBUS
1. Start Delimiter (SD) O Start Delimiter identifica o início de um telegrama. O PROFIBUS DP utiliza quatro tipos de SDs para a solicitação e resposta de telegramas, além de um quinto frame utilizado na resposta de confirmação curta, sendo eles: SD1(Request_FDL_Status), SD2 (telegrama de dados com tamanho variável), SD3 (telegrama de dados com tamanho fixo), SD4 (telegrama de Token) e SC (confirmação curta). 2. Length of Telegram (LE & LEr) Este byte indica o comprimento de um telegrama SD2 estipulado entre o DA até o fim de DU.
Geralmente o comprimento do DU é limitado a 32 bytes, mas o padrão permite o comprimento de até 244 bytes. O LE é repetido no campo LEr para a proteção de dados por redundância. 3. Destination Address & Source Address No campo DA o dispositivo mestre atribui o endereço de 8 bits da estação escrava a qual será destinada a informação. Já no campo SA, é copiado o endereço da estação remetente. Os endereços válidos devem variar de 0 a 127, sendo o endereço 126 reservado para o comissionamento e o endereço 127 reservado para broadcast. Para o envio da resposta do dispositivo escravo, os campos de endereço são invertidos. 4. Function Code ou Frame Control (FC) O campo Function Code (FC) ou Frame Control especifica o tipo de telegrama (pedido, resposta ou aviso), tipo de estação (slave ou mestre), a prioridade e o reconhecimento telegrama (bem ou mal sucedido). 5.
Pontos de Acesso de Serviço (SSAP & DSAP) As trocas de dados são manipuladas no cabeçalho do telegrama usando o Service Access Points (SAP). Somente os telegramas SD2 e SD3 possuem campos de dados para o uso do DSAP (Destination Service Access Point) e SSAP (Fonte Service Access Point) que indica o serviço(s) a ser executado. Os SAPs são: SAP=0, utilizado na troca cíclica de dados (Write_Read_Data); SAP54, comunicação Master-to-Master; SAP55, mudança de endereço da estação (Set_Slave_Add); SAP56, leitura das entradas (Rd_Inp); SAP57, leitura das saídas (Rd_Outp); SAP58, comandos de controle do escravo DP (Global_Control); SAP59, leitura dos dados de configuração (Get_Cfg); SAP60, leitura dos dados de diagnóstico (Slave_Diagnosis); SAP61, envio dos dados de parametrização (Set_Prm) e SAP62, verificação dos dados de configuração Data (Chk_Cfg). 6. Data Unit (DU) Este campo contém os dados para a estação em DA (Request_Data), ou os dados para a estação em SA (Response_Data). DU é geralmente limitado a 32 bytes, mas o padrão permite um tamanho de até 244 bytes. 7. Frame Check Sequence (FCS) Este campo contém o Frame Check Sequence ou telegrama Checksum. É representado pela soma dos bytes ASCII das informações compreendidas entre DA e DU, operado com a função mod 256 (Checksum = (DA + SA + FC + DU) mod 256).
8. End Delimiter (ED) Este byte utiliza um valor fixo (16H) para identificar o fim de um telegrama PROFIBUS. H. Request FDL Status O frame Request FDL Status é empregado na FDL para obter o estado operacional das demais estações (Fig. 4). Este frame pode ser solicitado a pedido do usuário para mapear o estados de todas as estações elaborando uma lista denominada de Live List e por iniciativa da FDL, quando expira o tempo para atualização da GAP [10]. A resposta do pedido retorna codificada no campo Function Code (FC), que funciona como confirmação indicando o grau de sucesso da mensagem enviada e o tipo de falha ocorrida.
Fig. 4. Estrutura do frame Request FDL Status
I.
O frame do token O token é um frame que tem como principal função transferir a autorização de acesso ao meio (barramento) entre a estação detentora do token e uma estação candidata à sua recepção. Desta forma, o frame do token (Fig. 5) contém três bytes (caracteres de UART) que o representam [10].
Fig. 5. Estrutura do token
J.
Funções de comando São funções de comando que podem ser executadas em escravos (E) e mestres classe 1 (M): Data_Exchange (E/M), Rd_Inp (E), Rd_Outp (E), Slave_Diag (E/M), Set_Prm (E/M), Chk_Cfg (E/M), Get_Cfg (E), Global_Control (E/M), Set_Slave_Address (E), Get_Master_Diag (M), Start_Seq (M) e Download (M). Todos os comandos descritos são opcionais para o mestre classe 2. O mestre classe 2 desenvolvido implementa as seguintes funções de comando: Rd_Inp, Rd_Outp, Slave_Diag, Get_Cfg e Set_Slave_Address.
1. Telegrama Set_Slave_Add (SAP 55) Antes do comissionamento, a estação deve ter atribuído um endereço único entre 0 e 125. Este endereço geralmente é disponibilizado pelo hardware do dispositivo, mas caso isto não ocorra, o endereço pode ser definido por um comando de um mestre classe 2.
Fig. 6. Telegrama Set_Slave_Add
Fig. 8. Telegrama de pedido de Diagnóstico Diag_Data
Após a conclusão da rotina de inicialização e a correta definição do endereço do escravo, o processo é encaminhado ao estado Wait_Prm, aguardando assim a parametrização [5].
Fig. 9. Telegrama de resposta do pedido de diagnóstico
2. Parametrização Após o término do processo de inicialização, a estação escrava aguarda um telegrama de parametrização (Set_Prm) do mestre, que serve para identificar o mestre ao escravo e especificar o modo de operação [8]. 3. Telegrama Set_Prm - SAP 61 Esta função é utilizada para definir os parâmetros de um escravo durante o start-up, reinicialização do sistema e a qualquer tempo, exceto durante a troca de dados (Data_Exchange). O telegrama de parametrização contém no mínimo 7 bytes de informações específicas, exigidas pela norma PROFIBUS. Dentre estas informações estão: monitoramento da resposta / Watchdog Time TWD, TSDR Tempo para Mestre / Slave timing, ativar / desativar Freeze / Sync Mode, Bloquear / Desbloquear Slave para o mestre, endereço do mestre e o número de identificação.
Fig. 7. Telegrama Set_Prm
4. Configuração de I/O Após a parametrização (Set_Prm), o escravo aguarda o telegrama de configuração (Chk_Cfg). Este telegrama especifica o número de bytes de entrada e saída que devem ser trocados em cada ciclo com o escravo. 5. Telegrama Get_Cfg - SAP 59 A leitura dos dados de configuração (Get_Cfg) é aceita pelo escravo em todos os estados e permite ao mestre verificar a configuração atual do escravo (Real_Cfg_Data). 6.
Telegrama Diag_Data (Slave Diagnosis) - SAP 60 O telegrama Diag_Data é usado pelo mestre para pedir informações de diagnóstico do escravo. Durante a inicialização, um mestre solicita dados de diagnóstico antes de enviar o telegrama de parametrização e após a configuração, antes de assumir o estado de troca de dados com o escravo.
7. Estado de Troca de Dados Após a parametrização e configuração, o mestre pode iniciar a troca cíclica de dados I/O com os escravos. Os seguintes serviços estão disponíveis no modo de troca de dados: Read_Inp (leitura das entradas de qualquer escravo), Read_Outp (leitura das saídas de qualquer escravo), e Data_Exchange (envio e recebimento dos dados parametrizados e configurados pelo mestre. 8. Telegrama Read_Inp - SAP 56 O mestre pode utilizar este telegrama de forma assíncrona para ler os dados de entrada (Inp_Data) em qualquer escravo que esteja no modo Data_Exchange.
Fig. 10. Telegrama Read_Inp
Já o formato do telegrama de resposta é o mesmo acima, mas com o campo do DSAP / SSAP trocados e com o campo DU incorporado. 9. Telegrama Read_Outp - SAP 57 O mestre pode utilizar este telegrama de forma assíncrona ler os dados de saída (Outp_Data) em qualquer escravo que esteja no Data_Exchange.
Fig. 11. Telegrama Read_Out
Já o formato telegrama de resposta é o mesmo acima, mas com a DSAP / SSAP trocados e com o campo DU incorporado. IV.
RESULTADOS
Os resultados da primeira etapa no desenvolvimento do mestre classe 2 são apresentados a seguir. Nesta etapa realizou-se a validação dos frames de comunicação PROFIBUS (Fig. 12).
Fig. 12. Esquema para validação dos frames PROFIBUS
Para os testes foi utilizada uma placa PCI integrada a um PC, com velocidade de comunicação de 12 Mbit /s e com uma porta de saída (COM) configurável para RS485. Por meio de um software de comunicação serial foram enviados os frames a uma estação slave DP. Com a ferramenta de diagnóstico ProfiTrace da PROCENTEC, também conectada ao barramento, foram capturados e analisados os frames de envio e de resposta provenientes do slave.
ProfiDoctor. Os altos custos das ferramentas de diagnóstico existentes no mercado, cerca de $2200 dólares, podem ser reduzidos, oferecendo ainda aos consumidores uma ferramenta mais ampla, visto que o ProfiDoctor terá uma funcionalidade baseada em conceitos de inteligência artificial. Os resultados obtidos na primeira etapa do projeto mostram que os frames necessários para o desenvolvimento do mestre foram validados. Este fato possibilita a continuidade no desenvolvimento do sistema para uma plataforma embarcada, cuja adequação de implantação a sistemas tempo-real é descrita na literatura [12], atendendo portanto de maneira satisfatória as restrições temporais da rede. AGRADECIMENTOS Os autores agradecem à estrutura acadêmica de pesquisa da Escola da Engenharia de São Carlos Universidade de São Paulo. REFERÊNCIAS BIBLIOGRÁFICAS [1]
[2] [3]
[4] Fig. 13. Tela do Profitrace com um exemplo de captura dos frames [5]
Com a análise das capturas (Fig. 13) foram validados os frames elaborados, onde para cada frame enviado foi obtida uma resposta do slave. No caso do frame de resposta estar dentro do padrão esperado, entende-se que o frame foi construído corretamente. Como exemplo, tem-se a fig. 13, onde foi solicitado um pedido de Request_Status pelo frame (10 2F 01 49 79 16) ao Slave de endereço 47, que responde com o frame (10 01 2F 00 30 16). Os próximos passos experimentais serão a validação do firmware desenvolvido, os testes com ambiente gráfico de interface com o usuário – onde serão solicitadas ao mestre as tarefas de diagnóstico – e a análise temporal das mensagens transmitidas no barramento objetivando a verificação do determinismo.
[6]
[7]
[8] [9]
[10]
[11]
V.
CONCLUSÕES
O desenvolvimento do mestre classe 2 é a peça fundamental para a elaboração do projeto do
[12]
J. Xu, Y. Fang, “Profibus Automation Technology and Its Application in DP Slave Development, ” Proceedings of 2004 International Conference on Information Acquisition. SMAR, “Protocolo Profibus,” [Online]. Available: http://www.smar.com/Brasil2/profibus.asp L. Liu, Q. Song, X. Chen, “The Developmental Design of the Intelligent Slave Station Based on the Profibus-DP Fieldbus,” International Conference on Computer Science and Information Technology, 2008. V. P. Venturini, “Desenvolvimento de um Mestre Profibus com a Finalidade de Análise de Desempenho,” Dissertação de Mestrado em Engenharia Mecânica, Escola de Engenharia de São Carlos, Universidade de São Paulo, São Carlos, 2007. I. M. Tristão, “Implementação do protocolo PROFIBUS para aplicações industriais baseadas em microcontroladores,” Dissertação (Conclusão do curso de Ciência de Computação) – Universidade Luterana do Brasil, 2004. R. V. Aroca, “Análise de sistemas operacionais de tempo real para aplicações de robótica e automação,” Dissertação de Mestrado, Escola de Engenharia de São Carlos, Universidade de São Paulo, São Carlos, 2008. E. Tovar, F. Vasques, “Real-Time Fieldbus Communications Using Profibus Networks,” IEEE Transactions on Industrial Eletronics, Vol. 46, No. 6, December, 1999. M. Popp, The New Rapid Way to PROFIBUS DP (from DP-V0 to DP-V2), 2003. M. P. Moro, “Análise e Estimativa de Desempenho de Redes Profibus,” Dissertação de mestrado, Instituto de Informática, Universidade Federal do Rio Grande do Sul, Porto Alegre, 2002. J. A. Carvalho, “Avaliação do Desempenho de Redes PROFIBUS-DP Suportada em Técnicas de Injecção de Faltas,” Tese de Doutorado, Departamento de Engenharia Eletrotécnica e de Computadores, Universidade do Porto, 2006. PROFIBUS Specification - Normative Parts of PROFIBUS FMS, -DP, -PA according to the European Standard, EN 50 170 Vol. 2, March, 1998. D. K. Tran, P. Pisa, P. Smolik, “An Open Implementation of Profibus DP,” 2009.
