Logo Passei Direto
Buscar
Material
páginas com resultados encontrados.
páginas com resultados encontrados.

Prévia do material em texto

Arquitetura de um Gateway de Tempo Incorporado
entre PTP e SNTP
Paolo Ferrari, Alessandra Flammini, Stefano Rinaldi Gunnar Prytz, por Christian Juel
Departamento de Engenharia da Informação 
Universidade de Brescia, Via Branze 38, 25123 - Brescia,
Itália. Tel.: +39 030 3715445, Fax: +39 030 380014
{paolo.ferrari,stefano.rinaldi}@ing.unibs.it
Pesquisa Corporativa ABB
Bergerveien 12
NO-1396 Billingstad, Noruega 
{Gunnar.Prytz, Per.C.Juel}@no.abb.com
Resumo—Este artigo trata da sincronização de tempo em 
infraestruturas de rede mista para automação de plantas industriais e 
elétricas, onde dispositivos antigos, que recuperam informações de 
tempo com o conhecido NTP, devem coexistir com novos dispositivos 
compatíveis com IEEE1588 PTP. Como PTP e NTP usam representações de 
tempo e estratégias de sincronização muito diferentes, uma integração 
fácil é bastante difícil e requer hardware adicional. O artigo descreve 
um Time Gateway transparente que é capaz de fazer interface com 
dispositivos SNTP com um domínio de sincronização PTP (dispositivos 
PTP e switches PTP). O Time Gateway foi realizado com um sistema 
embarcado baseado em um FPGA com um processador soft e um 
sistema operacional de código aberto. Resultados experimentais 
preliminares mostram a viabilidade da arquitetura proposta, mesmo 
que algumas melhorias possam ser necessárias para corresponder à 
precisão de sincronização de tempo exigida pelos dispositivos SNTP 
legados.
nível), não pode competir com o desempenho do PTP mesmo quando 
implementações especiais são usadas [6].
Tradicionalmente nos campos de automação industrial e elétrica, 
conforme descrito em IEC61784 e IEC61850, os dispositivos finais 
simples que requerem uma referência de tempo são sincronizados 
usando NTP. Muitas vezes, o baixo poder computacional do dispositivo 
final impõe o uso do SNTP (Simple Network Time Protocol [7]), uma 
versão simplificada do NTP com desempenho reduzido. Além disso, 
apenas produtos mais recentes oferecem suporte para IEEE1588 PTP. 
Tal situação pode criar problemas quando ativos antigos (por exemplo, 
dispositivos antigos já adquiridos e "comprovados em uso") com NTP 
ou SNTP precisam ser integrados em novas plantas que adotam PTP (ou 
vice-versa). É de interesse geral ter uma maneira de aumentar e, em 
algumas situações, apenas manter a precisão da sincronização de 
tempo de dispositivos de automação legados para que eles possam 
continuar a ser usados também em sistemas Ethernet industriais 
modernos.
Palavras-chave - IEEE 1588 PTP, NTP, sincronização de tempo, 
sistemas distribuídos, sistema FPGA.
O objetivo deste trabalho é desenvolver um Time Gateway 
embarcado para interfaceamento adequado de clientes baseados 
em SNTP com uma infraestrutura de sincronização PTP (domínio de 
sincronização PTP). O gateway é capaz de recuperar as 
informações relacionadas ao tempo usando PTP, traduzi-las para o 
formato SNTP e fornecê-las ao cliente SNTP. O artigo apresenta a 
arquitetura de um Time Gateway, que é construído em torno das 
restrições dadas por equipamentos SNTP já existentes para 
aplicações de automação industrial e elétrica. A viabilidade do 
sistema proposto é demonstrada por meio de um protótipo 
embarcado baseado em um FPGA, cujo desempenho foi testado.
Eu. EuNTRODUÇÃO
Nos últimos 9 anos, o IEEE 1588 PTP (Precision Time Protocol) [1] 
tem experimentado uma grande difusão em sistemas que requerem 
sincronização de alto desempenho sobre Ethernet, uma vez que sua 
simplicidade e autoconfiguração são adequadas para aplicações 
embarcadas e de baixo custo [2]. Atualmente, os dispositivos IEEE 1588 
são bastante comuns em sistemas de medição e controle industrial/
elétrico, com precisões de sincronização normalmente 
significativamente abaixo dos milissegundos [3]. O melhor desempenho 
pode ser obtido quando a infraestrutura de rede é atualizada, 
substituindo os switches Ethernet tradicionais por switches compatíveis 
com IEEE 1588; uma infraestrutura compatível com PTP elabora e 
compensa informações de tempo dentro das mensagens PTP (por 
exemplo, levando em consideração atrasos de propagação da rede) 
para melhorar a precisão geral da sincronização para alguns 
nanossegundos em casos ótimos [4].
II.PPROPOSTOUMARQUITETURA
Em termos gerais, os dispositivos SNTP (NTP) podem ser 
conectados e usados livremente em uma infraestrutura com 
reconhecimento de PTP, porque os pacotes SNTP/NTP são quadros UDP 
normais. As informações relacionadas ao tempo são normalmente 
roteadas pelos switches PTP para o servidor SNTP/NTP local. No 
entanto, esse cenário não é o ideal porque as mensagens NTP/SNTP 
são atrasadas aleatoriamente pela infraestrutura PTP e apenas um 
baixo desempenho de sincronização pode ser obtido (na ordem de 
milissegundos no caso de alto tráfego de rede e grandes LANs [6]). Por 
outro lado, uma infraestrutura de rede com reconhecimento de PTP 
recente, obtida usando PTP Boundary Clocks, bem como PTP 
Transparent Clocks, tem constantemente a noção correta do tempo do 
sistema que é transferido para os dispositivos finais por meio de regras 
PTP. O objetivo do trabalho apresentado neste artigo é desenvolver um 
Time Gateway que seja capaz de propagar as informações de tempo 
também para o SNTP Client conectado.
Por outro lado, o protocolo de tempo mais difundido hoje ainda é o 
NTP (Network Time Protocol). O NTP foi proposto pela primeira vez em 
1985 e foi revisado várias vezes [5]. Este protocolo rapidamente ganhou 
popularidade, pois, apesar de sua complexidade, é otimizado para uso 
da Internet, permitindo, por exemplo, que estações remotas 
sincronizem seu tempo com agências nacionais de cronometragem. As 
regras de filtragem de tempo e os algoritmos de regulação servo 
implementados pelos clientes NTP foram projetados para grandes 
redes, portanto, eles são capazes de rastrear o tempo até alguns 
milissegundos em redes de grande escala geográfica. No entanto, o 
protocolo NTP não é projetado para redes locais (LANs) e, devido à 
resposta lenta e implementações de relógio de software (carimbo de 
data/hora no aplicativo/kernel
uso licenciado autorizado limitado a: Pontifícia Universidade Católica do Rio Grande do Sul (PUC/RS). Baixado em 13 de setembro de 2024 às 01:27:24 UTC do IEEE Xplore. Restrições se aplicam.
Traduzido do Inglês para o Português - www.onlinedoctranslator.com
https://www.onlinedoctranslator.com/pt/?utm_source=onlinedoctranslator&utm_medium=pdf&utm_campaign=attribution
A. Descrição e requisitos do sistema sistemas de automação de subestações, a precisão de sincronização de 
destino para o Time Gateway pode ser definida como 250 µs ou menos.O cenário de aplicação de referência do Time Gateway descrito 
neste artigo é mostrado na Figura 1. As informações de tempo são 
transferidas pela infraestrutura de rede usando switches com 
reconhecimento de PTP. O gateway proposto é capaz de converter 
essas informações no formato de tempo preferido, como SNTP: o 
gateway é capaz de atuar como um escravo PTP em um lado da 
rede e como um servidor SNTP no outro. O uso do dispositivo 
proposto em aplicações reais de automação industrial e elétrica 
impõe várias restrições ao design: baixo custo, baixa potência e 
fator de forma reduzido; transparência para ferramentas de 
gerenciamento de rede e fácil configuração e precisão de 
sincronização aprimorada com relação ao desempenho SNTP atual 
(> 1 ms).
B. Descrição do Portal do Tempo
O Time Gateway tem que fazer interface com dois domínios de 
sincronização diferentes, PTP e SNTP. O diagrama de blocos do 
sistema é mostrado na Figura 2. Os elementos básicos do sistema 
são o bloco de controle, usado para implementar o aplicativo para 
controlar o sistema, e duas interfaces de rede: uma para o domínio 
PTP e a outra para o cliente SNTP. Conforme discutido na seção 
anterior, o design do Time Gateway tem baixo custo e baixo 
consumo de energia como requisitos. A arquitetura de hardware 
do Time Gateway é baseada em um sistema de microcontroladorembarcado com periféricos para processar os dados vindos das 
redes.
Em relação ao primeiro ponto, o Time Gateway pode ser 
conectado diretamente no cabo entre o SNTP Client e o switch com 
reconhecimento de PTP. Portanto, o design descrito nas seções a 
seguir é otimizado para reduzir o número de blocos lógicos. Uma 
solução FPGA foi considerada no desenvolvimento porque apenas 
os blocos lógicos essenciais podem ser implementados, mas ao 
mesmo tempo o design permanece flexível. Além disso, um FPGA 
de baixo custo e baixa potência, como o Cyclone IV da Altera, que 
consome cerca de 100 mW de potência estática a 85 °C, pode ser 
considerado na fase final de industrialização do Time Gateway.
O núcleo do sistema proposto é o bloco do processador 
embarcado NIOS da Altera, que é responsável pelo gerenciamento 
da pilha de sincronização e pelo roteamento de pacotes de rede. O 
bloco de controle inclui um núcleo rápido NIOS II, um processador 
soft de 32 bits, e é capaz de sincronizar o horário do sistema 
usando as mensagens de sincronização vindas do link PTP, 
propagando o horário para o outro segmento. O bloco Timer é a 
fonte de tempo para o dispositivo Time Gateway. Sua principal 
tarefa é fornecer uma interrupção periódica (1 ms) que o SO usa 
para obter o horário do sistema. O clock de entrada deste bloco 
(100 MHz, o clock do sistema) é obtido de um PLL que multiplica a 
entrada do clock do FPGA.O Time Gateway tem que ser facilmente configurável. Idealmente, 
ele deve ser um dispositivo plug and play, transparente para as 
ferramentas de configuração e gerenciamento de rede, a fim de evitar 
qualquer esforço adicional. No entanto, interfaces de configuração 
adicionais são necessárias pelo usuário. Por exemplo, uma interface 
web amigável ou serviço telnet pode ser usado para configurar o 
aplicativo PTP ou o Servidor SNTP. Como geralmente esses serviços são 
construídos no Linux, um kernel Linux embarcado pode ser usado 
vantajosamente.
FPGA RDA
Memória SDRAM
RDA
ContrNIOS II
μClinux (PTPd, SNTP, FTP, HTTP, ..)
Clarão
Contr
CLARÃO
Bloco de Lógica de Controle
Ávalon
Étnica
MAC0
MDIO
Contr
PontePLL Temporizador
Portal do Tempo
(Relógio de Fronteira)Receptor GPS
Cliente SNTP MAC 10/100
Étnica
10/100
Étnica
10/100
SMSC
Um 91C111Eth0 Et1 eu
Et0 10/100 1588
Mestre PTP Consciente do PTP
infraestrutura de rede Figura 2. Diagrama de blocos do Time Gateway.
PTP SNTP
Outros blocos lógicos são usados para fazer a interface do sistema 
microcontrolador com periféricos externos. Dispositivos de memória 
externa são necessários para executar o SO (chip DDR SDRAM de 32 
Mbytes no protótipo) e armazenar o firmware e a configuração FPGA 
para a fase de inicialização (Flash de 16 Mbytes). No design do Time 
Gateway, um PHY Ethernet 10/100 com reconhecimento de PTP foi 
selecionado para fazer a interface do sistema com o domínio PTP. Este 
dispositivo é capaz de suportar o protocolo PTP com registro de data e 
hora de hardware, o que pode ser necessário no futuro para satisfazer 
a precisão de sincronização estrita (abaixo de um microssegundo). No 
entanto, neste artigo, os recursos adicionais PTP do Ethernet PHY não 
foram usados porque uma solução baseada em software é 
investigada. Um controlador Ethernet MAC dedicado implementado em 
VHDL é conectado ao Ethernet PHY com reconhecimento de PTP. Por 
outro lado, um chip Ethernet PHY+MAC 10/100 tradicional (LAN91C111) 
é usado para conectar o Time Gateway ao link de rede SNTP, já que o 
protocolo SNTP não suporta registro de data e hora de hardware.
Domínio PTP Domínio SNTP
Figura 1. Arquitetura do Time Gateway.
O padrão PTP [1] tem diferentes perfis, cada um deles dedicado 
a uma aplicação específica; por exemplo, recentemente o padrão 
IEC61850 adotou o perfil PTP para sistemas de energia IEEE 
PC37.238 [3] para sincronizar os Dispositivos Eletrônicos 
Inteligentes em sistemas de automação elétrica. Deve-se notar que 
os perfis PTP diferem e não são compatíveis, portanto, o Time 
Gateway tem que ser flexível para ser facilmente reconfigurado 
para usar diferentes perfis.
Novamente, o padrão IEC61850 sugere considerar 1 ms como a 
precisão geral de sincronização no “barramento de estação” de 
uma Subestação. Para atender a tal restrição em grandes
uso licenciado autorizado limitado a: Pontifícia Universidade Católica do Rio Grande do Sul (PUC/RS). Baixado em 13 de setembro de 2024 às 01:27:24 UTC do IEEE Xplore. Restrições se aplicam.
III.FIRMARE ESSoftware de escritório e fornecer uma interface amigável.
O sistema embarcado NIOS II descrito na seção anterior usa o 
µClinux OS [9], kernel 2.6.30. Este kernel Linux é dedicado a 
processadores MMUless com endereçamento de pelo menos 32 bits. 
Como já mencionado, o design FPGA fornece uma grande flexibilidade: 
um processador NIOS II MMUless foi adotado para reduzir tanto os 
custos quanto os recursos de hardware necessários. O µClinux OS tem 
várias vantagens se comparado a outros sistemas embarcados. Um 
kernel Linux 2.6 completo ocupa menos de 300 Kbytes de memória e os 
binários são muito menores, já que as bibliotecas uClibc, uma biblioteca 
C leve, porém altamente compatível, são usadas. Este SO suporta quase 
toda a API Linux, o que significa que a maioria das chamadas de 
sistema Linux tradicionais estão disponíveis para programação. 
Portanto, os aplicativos desenvolvidos para Linux podem ser portados 
para o µClinux com um pequeno esforço. Além disso, o µClinux fornece 
uma conectividade IP integrada, um ambiente multitarefa completo e 
um kernel preemptivo. No entanto, deve-se notar que o µClinux não 
suporta uma memória virtual: portanto, é necessário um 
gerenciamento cuidadoso da memória. Como cada processo tem uma 
memória fixa atribuída a ele, a memória pode ser muito fragmentada. 
Além disso, nenhuma proteção de memória é fornecida, ou seja, 
qualquer programa pode corromper a memória do kernel, causando 
uma falha no sistema.
Espaço do usuário
MSNTP
Cliente
PTPd
Interface de chamadas do sistema
adjTempo
Kernel µClinux
TS TS
Hora do sistema
IP_FORWARD
Eth0 Drivers de dispositivo Et1
Étnica
FÍSICA0
Étnica
FÍSICA1
PTP Outras mensagens SNTP
Figura 3. Firmware do Time Gateway: mecanismo de roteamento e registro de data e hora.
IV. EAVALIAÇÃO EXPERIMENTAL
O protótipo do Time Gateway foi realizado usando um kit 
de desenvolvimento NIOS II da Altera equipado com um FPGA 
EP2S60F672C3 Stratix II (60k LE). A placa de desenvolvimento 
FPGA fornece um MAC Ethernet 10/100 (SMSC LAN91C111), 32 
MByte DDR SDRAM e 16 MByte Flash. Outros periféricos estão 
disponíveis, mas não são usados para desenvolver o 
protótipo. Uma placa de avaliação externa (DP83640T-EVK), 
equipada com um PHY Ethernet 10/100 com reconhecimento 
de PTP (DP83640 da National Semiconductor), foi conectada à 
placa FPGA principal por meio de um conector de expansão. O 
MAC Ethernet é conectado ao lado SNTP da rede, enquanto o 
PHY Ethernet com reconhecimento de PTP precisa ser 
conectado ao lado PTP para poder, no futuro, auxiliar a pilha de 
sincronização com o registro de data e hora do hardware. O 
protótipo completo é mostrado na Figura 4a. O Time Gateway 
foi projetado para limitar os recursos de hardware exigidos 
pelo FPGA para poder portar o sistema para dispositivos de 
baixo custo (como a série Cyclone) no produto final. O núcleo 
do sistema é o processador soft NIOS II (Fast core), equipado 
com um conjunto mínimo de periféricos. O sistema operacional 
é o µClinux. Os recursos de hardware e software exigidos pelo 
sistema Time Gateway são relatados na Tabela I.
Vários aplicativos foram portados para o µClinux no topo do 
kernel descrito acima, como mostrado na Figura 3. A sincronização 
do Time Gateway é obtida usando o daemon PTPd [3], uma 
implementação somente de software do protocolo PTP. O PTPd 
suporta ambas as versões do protocolo PTP (v2002 e v2008), com 
mensagens mapeadas para a camada 2 ou camada 3. O daemon 
PTPd recebe as mensagens de sincronização enviadas pelomestre 
PTP através da interface eth0 (veja a Figura 3). As mensagens de 
sincronização são marcadas com timestamp no nível do kernel e o 
tempo recebido é usado pelo aplicativo para estimar o 
deslocamento do relógio local do relógio mestre. Então, o 
aplicativo corrige o relógio do sistema local para rastrear o tempo 
mestre (a chamada de sistema adjtime() é invocada). As 
informações relacionadas ao tempo são propagadas pelo Time 
Gateway usando MSNTP (um servidor SNTP de código aberto), que 
responde à solicitação do cliente SNTP vinda de dispositivos 
conectados à interface eth1 encaminhando o tempo local.
A. Configuração experimental
Conforme discutido nas seções anteriores, o principal objetivo do 
Time Gateway é obter as informações de tempo de uma infraestrutura 
PTP e fornecê-las ao cliente SNTP. Nesta seção, o desempenho de 
sincronização do sistema foi avaliado usando a configuração 
experimental mostrada na Figura 4b. Um dispositivo LXI Classe B 
(TriggerBox E5818A da Agilent) é configurado para funcionar como um 
mestre PTPv1. O PTP Master é conectado por meio de um cabo cruzado 
ao Time Gateway e envia uma mensagem de sincronização a cada 2 s. O 
dispositivo Time Gateway é capaz de recuperar o tempo do mestre por 
meio do protocolo PTP. O daemon PTPd (no Time Gateway) corrige 
periodicamente o tempo do sistema local e registra seu deslocamento 
de tempo e seu desvio do relógio do PTP Master em um arquivo de log 
(PTPLog). No experimento, a sincronização entre o mestre e o Time 
Gateway foi monitorada por 2 horas (3600 amostras de deslocamento). 
Um detalhe parcial do deslocamento de tempo registrado é relatado na 
Figura 5. O jitter de sincronização, ou seja, a variação máxima do 
deslocamento de tempo durante as medições, é da ordem de várias 
dezenas de µs, como bem conhecido na literatura para um
Mesmo que a transparência total da Camada 2 seja muito 
importante para o mundo da automação, por uma questão de 
simplicidade o protótipo foi realizado apenas com suporte ao 
roteamento IP. Um pacote IP vindo da interface externa eth0 e 
endereçado ao dispositivo conectado na interface eth1 do Time 
Gateway (e vice-versa) tem que ser roteado pelo kernel. Por esse 
motivo, o arquivo IP_FORWARD do kernel foi configurado para 
suportar o roteamento interno do pacote IP e as tabelas IP são 
modificadas corretamente: o Time Gateway funciona como um 
roteador. Observe que essa solução, embora extremamente 
flexível, não é transparente porque requer a configuração do Time 
Gateway e das tabelas de roteamento IP do dispositivo final para 
funcionar corretamente. Além disso, como o roteamento do pacote 
é gerenciado pelo kernel, o dispositivo pode não ser capaz de 
gerenciar o tráfego de largura de banda total.
Por último, um servidor FTP, um servidor web (servidor Boa) e 
telnet foram portados para o sistema para configurar o dispositivo
uso licenciado autorizado limitado a: Pontifícia Universidade Católica do Rio Grande do Sul (PUC/RS). Baixado em 13 de setembro de 2024 às 01:27:24 UTC do IEEE Xplore. Restrições se aplicam.
implementação PTP somente de software [3]. Deve-se notar que 
durante o experimento, nenhum tráfego adicional foi injetado pelo 
mestre na rede. Tráfego pesado de rede pode afetar severamente 
o desempenho de sincronização de implementações PTP somente 
de software.
esperado por uma implementação somente de software. No lado 
SNTP, o desempenho é significativamente menor por causa dos 
erros combinados nos lados Cliente e Servidor. O próximo passo da 
pesquisa, ainda mantendo a arquitetura baseada em NIOS, cobrirá 
a migração de muitos dos blocos descritos (por exemplo, funções 
de switch/roteador, timestamps, etc.) em hardware dentro do 
FPGA, melhorando o desempenho geral.TABELA I. ORECURSOS DE ARDWARE E SOFTWARE DO PROTÓTIPO
Lógica
Elementos
(ALUTA)
Lógica
Bloquear
Memória
pedaços
Memória
(kBytes)
100
Aplicativo
NIOS II 3184 68864 PTPd 37 50
MAC
Ethernet 1700 48000 MSNTP 58
Temporizador+Pl
eu
Boa
(Servidor Web)
135 0 144 0
Outros 1440 9720 FTP+FTPd 132
Total 6459 126592 Telnet 29 - 50
2000µClinux 1600 2500 3000 3500 4000
Total 2000 Tempo (s)
Figura 5. Deslocamento de tempo PTP do Time Gateway em relação ao relógio mestre.
Portal do Tempo
(PTP -> SNTP)Mestre PTP Cliente SNTP
1500
1000
500
0
- 500
- 1000
Étnica
10/100
Étnica
10/100Eth0 Et1
Agilent LXI
Caixa de gatilho
Registro PTP Registro SNTP
Sincronização PTP
Domínio
Sincronização SNTP
Domínio
- 1500
2000Figura 4. Protótipo do Time Gateway (esquerda). Configuração experimental (direita). 2500 3000 3500 4000
Tempo (s)
Durante o experimento, o Time Gateway atua como um 
Servidor SNTP, respondendo à solicitação periódica de tempo 
enviada pelo Cliente SNTP. Nesta configuração experimental, o 
Cliente SNTP (versão SNTP 4) é um PC (Pentium Dual Core 3 GHz, 2 
GB de RAM, kernel Linux 2.6.37) que periodicamente requer o 
tempo (a cada 2 s), corrige seu relógio local (chamando a função 
adjtime()) e registra o deslocamento de tempo do Time Gateway 
(servidor SNTP). O deslocamento de tempo do Cliente SNTP é 
mostrado na Figura 6. O valor médio da distribuição é de cerca de 
-100 µs (devido à latência fixa no SO), enquanto o jitter é maior que 
1000 µs. O jitter alto, maior que o limite necessário de 250 µs, é 
devido principalmente a desvios esporádicos. Esses desvios são 
causados pela implementação do protocolo SNTP pelo cliente e 
pelo servidor. Do ponto de vista do Time Gateway, o desempenho 
de sincronização do sistema pode ser melhorado otimizando a 
ação de filtragem do PTPd. Além disso, o servidor MSNTP pode ser 
modificado, pegando os timestamps no nível do kernel. Por outro 
lado, nenhuma modificação é possível no lado do SNTP Client.
Figura 6. Deslocamento de tempo SNTP do cliente em relação ao servidor MSNTP.
RREFERÊNCIAS
[1] IEEE 1588-2008, Padrão IEEE para Protocolo de Sincronização de Relógio de 
Precisão para Sistemas de Medição e Controle em Rede, julho de 2008.
[2] P. Ferrari, A. Flammini, D. Marioli, A. Taroni, "Sistema de sincronização 
baseado em IEEE 1588 para uma rede de sensores de deslocamento", IEEE 
Trans. Instrumentation and Measurement, fev. 2008, vol. 57, N. 2, pp. 
254-260
[3] K. Correll, N. Barendt e M. Branicky, "Considerações de design para 
implementações somente de software do protocolo de tempo de precisão 
IEEE 1588", Anais da Conferência de 2005 sobre IEEE 1588, Zurique, Suíça, 
10 a 12 de outubro de 2005.
[4] Moreira, P.; Serrano, J.; Wlostowski, T.; Loschmidt, P.; Gaderer, G.; , "Coelho 
branco: Distribuição de temporização de sub-nanosegundos sobre 
ethernet,". ISPCS 2009.vol., no., pp.1-5, 12-16 out. 2009
[5] Solicitação de comentário 5905 (RFC), Protocolo de tempo de rede versão 4: 
especificação de protocolo e algoritmos, Internet Engineering Task Force 
(IETF), 2010.
V.C.ONCLUSÕES EFFUTUROCORK [6] Ridoux, J.,
(Estendido)”,
58, N.6, pp. 1841 – 1848, junho de 2009.
Veitch, D., “Dez microssegundos sobre LAN, para IEEE 
Trans. Instrumentação e Medição Gratuita, Vol.
Neste trabalho, um Time Gateway embarcado para interfacear 
dispositivo final “comprovado em uso” com SNTP para infraestruturas 
com reconhecimento de PTP foi apresentado. O artigo discute a 
arquitetura de um Time Gateway embarcado adaptado para aplicações 
de automação, demonstrando sua viabilidade. Os resultados 
experimentais preliminares mostram que a precisão de sincronização 
do lado PTP é da ordem de dezenas de µs, como
[7] Solicitação de comentário 4030 (RFC), Simple Network Time Protocol 
(SNTP) versão 4 para IPv4, IPv6 e OSI, Internet Engineering Task 
Force (IETF), 2006.
[8] IEEE PC37.238 D5.0; Rascunho do perfil padrão para uso do protocolo de tempo de 
precisão IEEE 1588 em aplicações de sistemas de energia, junho de 2010.
[9] µClinux: Embedded Linux/Microcontroller Project, disponível on-line 
em: www.uclinux.org.
uso licenciado autorizado limitado a: Pontifícia Universidade Católica do Rio Grande do Sul (PUC/RS). Baixado em 13 de setembro de 2024 às 01:27:24UTC do IEEE Xplore. Restrições se aplicam.
D
es
lo
ca
m
en
to
 (μ
s)
D
es
lo
ca
m
en
to
 (μ
s)

Mais conteúdos dessa disciplina