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)