Protocolo PTP na Aquisição de Dados e Ensaios Protocolo PTP na Aquisição de Dados e Ensaios | HBM

Protocolo PTP na Aquisição de Dados e Ensaios

Nas últimas décadas, diversos mecanismo de temporizador foram criados para sincronizar equipamentos entre si. Um dos primeiros protocolos padrão baseados em sincronia de temporizadores em rede Ethernet foi o Protocolo NTP (Networked Time Protocol), que foi criado em 1982, com uma grande atualização em 1994 - NTPv4 -  que proporcionou seu uso em uma fonte principal local ou pública de temporizador.

Baseado nos trabalhos de 1956, os time codes B do Inter-Range Instrumentation Group (IRIG) são outra opção pra sincronizar sistemas distribuídos. Neste caso, receivers satélites são freqüentemente usados como fonte para um temporizador preciso. Aqui, a informação de temporizador é transferida diretamente como sinais analógicos ou digitais.

A FireWire padronizou o IEEE1394b em 2002 para oferecer um mecanismo de sincronização automática de tempo de fácil uso. Este padrão teve grande aceitação em periféricos tanto nos mercados de consumo quanto profissional. Por exemplo, todos os módulos QuantumX da HBM oferecem duas portas FireWire.

Mesmo com padrões como NTP, IRIG B e IEEE1494b disponíveis, surgiu uma clara necessidade para o uso da infra-estrutura Ethernet para sincronizar sistemas distribuídos. Dentre os requisitos, a nova abordagem necessária para oferecer mais flexibilidade e facilidade de uso a um baixo custo. De infraestruturas de TI na indústria até domicílios no mercado consumidor, a rede Ethernet é o padrão mundial para comunicações máquina-máquina ou humano-máquina. Mesmo em aparelhos móveis, como smartphones ou até mesmo em veículos, uma rede baseada Ethernet pode ser ligada através de redes móveis de telecomunicação como LTE, EDGE ou GSM.


Quão precioso é a sincronia de tempo?

Confiamos em relógios para nos ajudar a chegarmos a tempo em reuniões e em outros compromissos. Nos esportes, uma fração de segundo pode determinar quem ganhou ou perdeu. Para o mercado de ações, uma simples diferença de microsegundo pode mudar o preço de compra e venda em milhares de dólares. Nas aplicações de teste e medição, entrada de sinais de um temporizador de alta precisão representa o mesmo processo físico capturado no mesmo momento de tempo rege uma importante regra na qualificação e análise de dados de medição em tempo real ou durante o modo de pós-processamento. Em cada um destes exemplos e muito mais, a definição de "precisão" dos relógios depende de suas aplicações específicas.

Qual a diferença entre tempo absoluto e tempo relativo?

O tempo absoluto é necessário quando os dados de medição precisam ser mapeados até um certo evento real ou quando dois ou mais sistemas DAQ não estão na mesma rede. Um exemplo onde tempo absoluto é relevante é quando a influência da carga de um trem atravessando uma ponte necessita ser monitorada e a identificação do trem pode ser solicitada para alertar qualquer tipo de atividade, como alerta de sobrecarga. O tempo absoluto é representado por um relógio.

Uma fonte de tempo absoluto pode ser:

  • Relógios Grandmaster Protocolo PTP
    • para uso em laboratórios com GPS, da empresa Meinberg;
    • para uso móvel com GPS, da empresa OMICRON.
  • Sensores GPS
    • usando diretamente o Serviço PPS (Precise Positioning Service) do sensor GPS;
    • assumindo o protocolo baseado no tempo absoluto quando iniciando um trabalho com DAQ.
  • Protocolo mestre NTP (Network Time Protocol)
    • publicamente disponível em um acesso de internet como, por exemplo, NIST;
    • distribuído localmente e baseado em GPS pelas empresas Hopf ou Meinberg;
    • executando em um PC e tomando o tempo absoluto do sistema operacional.
  • Baixa freqüência terrestre transmitida via sinal de rádio
    • o exemplo aqui é o DCF-77 (relógio atômico), funcionando por PTB na Alemanha.
  • Servidores de tempo baseados no Protocolo SNTP (Simple Network Time Protocol)

A maioria das aplicações em teste e medição ou processos podem usar um sistema de tempo relativo, particularmente quando um teste é reproduzível e o tempo relativo dos sinais é o mais importante. Se houver neessidade, o tempo absoluto deve ser parte do dado META ou integrado no próprio nome do arquivo, como por exemplo, 2015-08-03_RLDA-test_Viper_No12.

Às vezes, a precisão do tempo é misturada com o tempo reativo, latente ou real. A capacidade de tempo real pode ser atingida usando, por exemplo, protocolos de tempo real como EtherCAT, ProfiNET, EtherNET/IP ou diversos outros protocolos de diferentes empresas.

O que precisa ser levado em consideração quando análise em tempo real e em alta velocidade com uma solução DAQ?

Em teste e medição, lidamos com diversos tipos de aplicações. Um aspecto do teste e medição foca na medição síncrona e análise de dados. Exemplos incluem teste de carga estrutural, testes em veículos e RLDA (Road Load Data Acquisition - Levantamento de Carga em Rodagem) ou monitoramento de pontes. Outra parte do teste e medição lida com atuador dinâmico baseado em ensaios laboratoriais, focando em simulação, estimulação, controle ou in-the-loop. Aqui, a aquisição de dados com o propósito de análise não executa um papel importante. A seguinte lista proporciona alguns aspectos-chave:

  • Algumas aplicações usam taxas de dados de até 100 kS/s por canal e mais ainda com o propósito de análise de dados. Respostas em tempo real não são o principal critério e também não são possíveis com protocolos de tempo real regular. Isso adicionaria complexidade e diminuiria o grau de autonomia;
  • Instrumentos de alta precisão trabalham com conversores e filtros 24 Bit Sigma Delta AD causando deslocamento de fase e atraso no tempo. Aplicações em tempo real são focadas na determinação da faixa de milisegundos e precisam de respostas rápidas. Soluções DAQ modernas, como o QuantumX da HBM, permitem dividir a entrada de sensores em dois sinais para diferentes propósitos (1º - tempo real; 2º - marcação de tempo de alta velocidade e dado filtrado);
  • Tanto a "análise" quanto o "controle" possuem diferentes características, fluxo de trabalho, propósito e, até mesmo, responsabilidade. Combinar ambos em uma única solução pode causar conflito, como por exemplo, conduzir um teste dinâmico para carga estática ou elétrica e, em paralelo, adquirir dados dinâmicos de alta velocidade do sistema sob teste, o drivetrain. Portanto, dividir responsabilidade e fluxo de trabalho faz sentido quando Controle e Análise são solicitados;
  • Até o momento, não existe disponível nenhum protocolo padrão de alta performance em tempo real. Todas as soluções, como ProfiNET RT, EtherCAT e muitas outras são direcionadas pelos principais players da indústria global para auxiliar sua própria tecnologia em seus mercados e, mais ainda, em aplicações específicas. 
  • O Grupo Time-Sensitive Networking (TSN) está criando um protocolo Ethernet IEEE padronizado em tempo real, como parte do IEEE802.1AS para oferecer um padrão mundial. Soluções DAQ estão prontas para se conectar a muitos protocolos de tempo real usando gateways.
  • Tempo real necessita de uma aplicação principal rodando em tempo real. Interromper esta aplicação para alguma reconfiguração não é uma opção.

O que é tempo real e o que é tempo latente?

Tempo real significa comportamento determinante: uma "decisão" ou "resposta" necessita ser realizada em uma determinada fração de tempo e é principalmente usada em tarefas de controle ou automação (sensor → controle algorítimo → reação / atuador).

Tempo latente é um aspecto que tem sido usado em cálculos quando se deseja criar algorítimos de controle ou uma resposta é necessária dentro de um determinado prazo máximo. Aplicações de controle em tempo real normalmente requisitam latência de tempo fixa e muito baixa do sensor ao controlador. Para protocolos não-determinísticos como Ethernet TCP/IP, CANbus ou para qualquer atividade baseada em PC, o tempo latente é variável. Este tempo também executa uma regra quando o dado é transmitido para um controlador em tempo real para propósitos de monitoramento no caso do marcador de tempo enviado com o valor do dado não seja ou não possa ser levado em consideração.


O que é o Protocolo PTP - IEEE1588:2008 ou PTPv2 e como ele funciona?

O Protocolo PTP é uma especificação padrão internacional no IEEE1588 e revisada em 2008 com a versão 2. O PTPv2 é um protocolo de comunicação sincronizada de tempo baseada em rede Ethernet que pode ser usado para sincronizar relógios de diferentes equipamentos, proporcionando precisão de tempo em faixas de sub-microsegundo. Se comparado com o NTP, o PTPv2 é incorporado em uma camada física e, portanto, falamos a respeito de um verdadeiro hardware marcador de tempo para sincronização precisa de tempo de todos os componentes em uma rede Ethernet.

O PTPv2 é um mecanismo de sincronização de tempo relativo. Um componente é selecionado para trabalhar como relógio master, que envia mensagens de sincronia de tempo a todos os slaves. O processo de sincronização começa com uma mensagem de sincronização de tempo enviado para a rede. Todos os componentes (slaves) calculam a diferença de tempo (delay) entre suas horas locais, a enviada pelo master e se adaptam passo a passo para a diferença de tempo em menos de 2 µs. Por exemplo: assume-se que a fonte PTP envia uma mensagem PTP anunciando um horário de 13h00m00. O problema é que esta mensagem vai levar um tempo até chegar em seus destinatários. Se a informação PTP levou 1 seg. para chegar em sua fonte, então o horário seria 13h00m01, quando a fonte recebe uma informação PTP indicando 13h00m00. Então a latência da rede precisa ser compensada, o que é feito através da troca de uma série de mensagens entre o relógio master e os slaves, como mostra a próxima figura.

  1. O relógio master envia a mensagem de Sync. O tempo que a mensagem de Sync leva para deixar o master é o tempo marcado como T1, o qual pode ser incluso na mensagem de Sync (operação de um passo) ou enviada na mensagem de Follow Up (operação de dois passos);
  2. O slave recebe a mensagem de Sync; T2 é o tempo que o slave recebe a mensagem de Sync.
  3. O slave envia a mensagem Delay_Req, que é o marcador de tempo T3 quando deixa o slave e marcador de tempo T4 quando é recebido pelo master.
  4. O master responde com uma mensagem Delay_Resp que contém o marcador T4.

Exemplo: o master time, inicialmente, é de 100 segundos e o slave time é de 80 segundos. É assim que deveria ser ajustado no slave.

Todos os componentes PTP necessitam ser capacitados em PTP; isso inclui switches Ethernet, mas não o dissipador de dados (isto é, um PC rodando software DAQ). O relógio em um módulo DAQ é chamado de Relógio Comum (Ordinary Clock). Um relógio em um switch Ethernet é chamado de Relógio Limite (Boundary Clock).  O Master é selecionado automaticamente se nenhum Relógio Grão-Mestre (Grandmaster Clock) envia informação de tempo absoluto. Este mecanismo é chamado de BMC (Best Master Clock Algorithm).

Alguns tipos de DAQ são estruturas lineares ou em forma de anél com muitos switches, e assim, os Relógios Limite (Boundary Clock) usam seu próprio time control loops. Como uma alternativa, os chamados Relógio Transparentes (TC - Transparent Clock) permitem um controle de sincronia End-to-End (E2E) e mensagens de follow up. A introdução dos TCs permite uma solução muito mais simples para corrigir a latência variável do switch. A idéia básica do TC é medir o tempo que uma mensagem de um evento PTP levou no switch (chamado de tempo residente). O tempo residente é reportado ao receiver por uma mensagem dele mesmo ou por uma mensagem de Follow_up ou Delay_Resp subseqüente. Para isso, um novo campo na mensagem foi adicionado, chamado de Campo de Correção (Correction Field), que é um tipo de Intervalo de Tempo que pode ser usado para acumular tempo de residência ao longo do caminho da mensagem e também pode ser usado para outros tipos de correção. As principais vantagens são:

  • Não há necessidade de configurações: os TCs não precisam executar cálculos e não precisam ser considerados no cálculo do algorítmo BMC, logo não necessariamente precisam enviar ou receber mensagens de gerenciamento;
  • Rápida configuração da rede em caso de falhas;
  • Rápido tempo de ajuste: na fase de inicialização e após a mudança na topologia, os TCs não precisam ser resincronizados ao relógio master antes de serem considerados parte de um caminho sincronizado válido;
  • Perfeito para pequenas configurações.

Os TCs usam escala P2P (Peer-to-Peer) com o número de equipamentos ligados a uma subrede e podem adequar-se rapidamente às mudanças na topologia da rede. Então este mecanismo oferece uma grande escalabilidade e é mais adequado para grandes topologias em forma de cascata (grandes sistemas em escala usando muitos switches como opção em série).

Quais as vantagens do PTPv2?

  • Permite sincronização de tempo entre diferentes tipos de equipamentos de diferentes fabricantes via protocolo padronizado;
  • Permite grandes distâncias entre módulos DAQ;
  • Permite sincronização de diferentes linhas de produtos HBM entre si. QuantumX, SomatXR e Genesis High Speed oferecem PTPv2 e permitem aquisição de dados em todos os tipos de situações, incluindo:
    • Distribuído, móvel, externo em ambientes adversos;
    • Ensaio em laboratório ou em campo com centenas de canais ou até alguns mega samples por segundo e por canal.
  • Alta precisão de tempo em faixas de sub-microsegundo entre todos os componentes quando trabalhando com altas faixas de dados;
  • Usando Ethernet como padrão:
    • Elétrico: até 100m de cabo padrão Ethernet;
    • Ótico: grandes distâncias (alguns quilômetros) entre os módulos e o isolamento galvanizado;
    • Sem a necessidade de linhas extras para sincronia.
  • Simples, sem a necessidade de administrador na configuração:
    • seleção automática de master;
    • robusto contra falhas no master (smart slaves);
    • robusto contra mudanças na topologia da rede;
    • escala de tempo contínua (sem pular marcadores de tempo; sem roll over).
  • Temporizador absoluto, se necessário
    • Um Relógio Grão-Mestre (Grandmaster Clock) baseado em GPS pode ser integrado e serve como tempo absoluto quando um ou diversos sistemas DAQ não estão funcionando na mesma rede, mas seus dados necessitam ser analizados rapidamente.

Quais são algumas aplicaçõs típicas em Teste & Medição usando a Sincronização de Tempo PTP?

Aqui está uma lista de algumas aplicações típicas que ilustram os benefícios do Protocolo PTP:

  • Módulos de aquisição de dados amplamente distribuídos usados para:
    • Ensaios móveis em veículos terrestres de grande escala (trens, construções):
    • Ensaios em laboratório de aeronaves: mecânico (iron bird), estrutural (durabilidade);
    • Monitoramento de grandes estruturas: pontes, torres, fazendas de geração de energia eólica usando tempo absoluto baseado em GPS.
  • Sistemas híbridos de aquisição de dados usados para:
    • Teste dyno em veículos elétricos ou híbridos combinando o sistema de aquisição de dados de alta velocidade Genesis High Speed captando tensão e corrente com 2 MS/s por canal com o QuantumX captando via sensor de dados mecânicos e térmicos;
    • Ensaio em laboratório de aeronaves: elétrico (copper bird);
    • Ensaio em laboratório de máquinas ou geradores: elétrico, mecânico e térmico;
    • Ensaio em veículos em movimento ou seu monitoramento usando câmeras, sensores de força nas rodas ou outros complementos para dados de protocolos analógicos ou digitais do veículo;
    • Em geral, combinando diferentes sistemas DAQ de diferentes fabricantes para qualquer finalidade.
  • Arquitetura mesclada de sistema combinando sistemas clássicos de aquisição de dados analógicos com câmeras ou outras fontes de informação.

 

 

Quais são os procedimentos para a Parametrização do PTP no Software DAQ?

Como o QuantumX suporta diferentes mecanismos de sincronia de tempo, uma parametrização é necessária na primeira que você configura a rede. O mecanismo do relógio temporizador do sistema padrão ou AUTO é FireWire. Além disso, você pode selecionar as seguintes fontes ou mecanismos de temporizador:

  • PTPv2;
  • NTP;
  • IRIG-B;
  • EtherCAT.

Você pode usar a parametrização PTPv2 do software catmanEasy, MX Assistant ou perception. Clique nas imagens para ampliar. 

Quais são alguns Switches Ethernet PTP e Grandmaster Clocks recomendados?

As seguintes características básicas são necessárias na seleção de um switch PTPv2:

  • Suporte de IEEE1588:2008 (PTPv2);
  • Transparent Clock (TC);
  • Mecanismo de delay: End-To-End (E2E) ou Peer-To-Peer (P2P);
  • Mecanismo de transporte: IPv4 ou IPv6.

Switches Recomendados:

  • HBM: Switch Gigabit Ethernet EX23-R com os seguintes parâmetros:
    • Design do sistema: robusto para uso externo com 10 portas, fornecimento DC de 10-30 V, IP65/IP67, à prova de choques;
    • Mecanismo de delay: E2E;
    • Mecanismo de transporte: IPv4, IPv6.
  • Siemens:  Scalance XR324-12M
    • Design do sistema: tamanho padrão rack com até 16 portas (elétricas ou óticas);
    • Mecanismo de delay: E2E;
    • Mecanismo de transporte: IPv4/UDP;
    • Modo: Transparent Clock.
  • Hirschmann: switch Ethernet RSP
    • Design do sistema: montado em trilho tipo DIN com 11 portas no total;
    • Mecanismo de delay: E2E.
  • Oregano Systems: switch Ethernet syn1588® Gbit
    • Design do sistema: Desktop com 8 portas;
    • Mecanismo de delay: 1-step com E2E;
    • Mecanismo de transporte:  IP4 (IPv6 não foi testado);
    • Modo: Transparent Clock (sem parametrização).
  • B&K: Switch PTPv2 nas séries LAN-XI
    • Design do sistema: Desktop com 8 portas elétricas e 2 óticas

Outros switches disponíveis no mercado, mas não testados ainda:

  • CISCO: Switch IE 3000;
  • MOXA: Switch Tipo Rack PT-7728-PTP;
  • MOXA: Séries EDS-405A-PTP.

Grandmaster Clocks Ethernet Recomendados

Integrar um grandmaster clock em uma rede não é obrigatório, já que o PTP oferece um mecanismo "best clock", mas em algumas aplicações, informações de um absolute clock são necessárias:

  • Meinberg: Grandmaster Clock LANTIME M600 - IEEE 1588-2008 (baseado em GPS);
    • Design do sistema: tamanho padrão rack, fornecimento AC de 110 – 230 V;
    • Portas: 6 no total (RJ45).
  • Omicron: OTMC 100 (GPS integrado)
    • Design do sistema: pequeno, para instalações externas (IP67, fornecimento DC de 24 V, de -40°C até +70°C / de -40°F até +158°F);
    • Portas: 1 no total, suporte de Power over Ethernet (PoE) de acordo com IEEE 802.3af com < 2 W.
  • Seu PC também pode ser usado como Grandmaster Clock
    • Recomendamos o uso de um adaptador de rede com chip i210 Intel.

O PTPv2 é compatível com a versão anterior PTPv1?

A versão 1 do PTP foi destinada primeiramente para teste e medição e automação industrial. É um protocolo multicast para uso em uma LAN com performance que excede a capacidade do Protocolo NTP.

A PTPv2 ou IEEE-1588-2008 é um aprimoramento da versão 1. As versões são compatíveis. Algumas das muitas características do novo PTPv2 padrão incluem:

  • Mensagens multicast;
  • Relógio two-step;
  • Mecanismo de delayPeer-to-peer (P2P) ou end-to-end (E2E);
  • Intervalo de sincronia: 1, 2, 4, 8, 16, 32, 64 ou 128 pacotes/segundo;
  • Intervalo de Solicitação de Delay: 1, 2, 4, 8 ou 16 segundos;
  • Suporta os Protocolos de Transporte: IPv4 e o moderno IPv6.

Qual a precisão que eu consigo usando o PTPv2?

A precisão do tempo depende necessariamente do tipo de rede e dos equipamentos. Recomendamos configurar uma rede LAN privativa onde todos os integrantes da rede suportam PTPv2. Com esta configuração, a precisão do tempo pode chegar em 100 nanosegundos de equipamento para equipamento e seus canais. Você precisa considerar ainda que as diferentes taxas de dados e filtros podem introduzir tensão no temporizador e atraso de fase.

 

Qual a diferença entre amostragem de tempo no hardware e no software?

A principal diferença está na precisão de sincronização que é conseguida. Com o software baseado na amostragem de tempo usado no exemplo do Protocolo NTP, você pode ver as precisões de sincronização dos slaves abaixo de 100 microsegundos em pequenas redes, mas, basicamente, 1 ms. Com a amostragem de tempo do hardware, é possível atingir precisão na sincronização do tempo abaixo de 100 nanosegundos. Entretanto, para se atingir este nível de precisão, a topologia da rede, bem como os switches e o hardware slave devem suportar amostragem de tempo de hardware.

Também posso usar um switch padrão? Se sim, qual o efeito?

É arriscado usar switches sem capacidade de PTP. A transferência de mensagens PTP depende do tráfego da rede e, portanto, é crítico no tempo global. No caso do switch suportar QoS, isso pode ser resolvido com uma regra para aumentar a prioridade dos pacotes PTP. Em geral, não recomendamos o uso de switches sem suporte a PTPv2. Na pior das hipóteses, pacotes PTP podem se perder e, portanto, os dados necessários já não seriam confiáveis.