Conforme descrito no capítulo5foi desenvolvida uma metodologia para sincronizar o RTC do módulo gateway Ethernet-CAN, com o servidor Linux do SMIT. O objectivo principal é permitir efectuar a aquisição de dados de forma sincronizada em diferentes pontos geográficos. De seguida apresentam-se os resultados relativos ao acerto dos relógios através da rede TCP/IP entre dois sistemas, referentes à metodologia exposta no capítulo5.
Para estudar o comportamento do sistema, isto é, do filtro e do ganho exposto nas Figs. 5.6 e 5.7 da pág. 74 e seguintes, desenvolveu-se um simulador em Matlab, que permite estudar o comportamento dos dois sistemas referidos. A diferença com a realidade reside nos seguintes aspectos: a) As mensagens na rede levam 45ms a ser transmitidas (valor alterável); b) Os tempos de envio e recepção são registados correctamente, logo, sem erros; c) A duração dos cálculos no controlo é considerada nula, não influenciando o resultado, sendo, portanto, equivalente a parar o
tempo durante esses instantes; d) O passo da simulação é de 1s, alterando-se para 45ms sempre que há mensagens para enviar ou para receber entre o nó mestre e o nó escravo.
(a) Diferença entre o relógio do Mestre e do Escravo (µs). Esquerda: instantes iniciais. Direita: instantes finais;
(b) Esquerda: Erro ∆t no momento de aplicar o controlo (µs). Direita: Evolução do valor de
CNT_TICK_MAX;
Figura 8.3: Experiência no1. Valores calculados e recolhidos no momento da recepção das men- sagens Follow UP e Delay Response.
Os dados considerados para a simulação são os seguintes: no mestre, o período do relógio é abaixo de 1ns; nos nós escravos, a frequência do relógio é de f reqs= 50MHz (período 20ns),
podendo-se apenas alterar as variáveis Ns: Nns e o valor de CNT _T ICK_MAX . O aspecto mais
importante da simulação foi ter-se considerado um desvio de 5.263% na frequência de 50MHz, o que introduziu a necessidade da PLL variar o parâmetro CNT _T ICK_MAX (ver pág. 74).
A Fig.8.3apresenta os resultados da simulação para o protocolo PTP a funcionar normalmente ao longo de 1500s. Pode-se observar a convergência dos relógios, ao fim de 40 mensagens de
8.1 Resultados práticos 127
(a) Esquerda: erro∆t ao controlar. Direita: diferença entre o relógio do Mestre e do Escravo (µs);
Figura 8.4: Experiência no2: Precisão de zero casas decimais no parâmetro CNT_TICK_MAX.
sincronismo e, em regime final, um desvio máximo de 40 ns. Nesta experiência considerou-se uma precisão de duas casas decimais no parâmetro CNT_TICK_MAX, tendo o seu valor final sido estimado em 526315.79 para um valor real de 526315.789474. No desfecho, o relógio do escravo estava adiantado em 2 ns. As mensagens Delay Request foram aleatoriamente enviadas entre 2 e 30 TSync.
A Fig.8.4apresenta a mesma simulação alterando a precisão no parâmetro CNT_TICK_MAX para zero casas decimais, tendo, no final, sido estimado o valor de 526316.0. O relógio do escravo encontrava-se, após a simulação, atrasado de 769 ns. O erro em regime final foi de cerca de 800ns.
(a) Esquerda: Erro∆t ao controlar. Direita: Diferença entre o relógio Mestre e Escravo (µs);
Figura 8.5: Experiência no 3: Precisão de duas casas decimais no parâmetro CNT_TICK_MAX. Apenas envia uma mensagem Delay Request.
A Fig.8.5apresenta a mesma simulação alterando a precisão no parâmetro CNT_TICK_MAX para duas casas decimais, tendo, no final, sido estimado o valor de 526315.79. No entanto, neste
exemplo, apenas se envia a primeira mensagem Delay Request, não havendo lugar ao envio de mais nenhuma. O resultado aparece evidenciado na figura através do valor em regime final, que representa um erro grosseiro devido à má estimação do tempo de propagação na rede. No entanto, em termos de variação, o resultado mantém a precisão de 40 ns (gráfico à direita na Fig.8.5).
A Fig. 8.6 apresenta o resultado de acordo com a alteração proposta ao protocolo PTP, no- meadamente a nível das mensagens de Sync e Follow Up, tal como indicado na Fig. 5.7 (pág. 75). A diferença, quando comparada com os resultados da Fig. 8.3, reside no erro inicial, com melhorias significativas nesta última experiência. Na experiência no1, os erros iniciais foram na casa das centenas de milissegundos e, na última passaram para as décimas de µs. A nível da estabilidade final, o resultado é idêntico, sendo, portanto, a vantagem conseguida na rapidez para obter estabilidade após uma mudança drástica do tempo. As especificações para esta norma, a nível do hardware, nomeadamente no suporte de registo do tempo de recepção e envio das men- sagens Ethernet, corresponde à abordagem para se obterem precisões na casa dos nanossegundos. Torna-se perfeitamente praticável a alteração proposta, obviamente com hardware que registe no pacote o tempo de envio das mensagens (o sistema implementado não tem esta funcionalidade).
Na implementação real no micro controlador, o registo de CNT_TICK_MAX é inteiro. A pergunta é a seguinte: como se obtém precisão de duas casas decimais? Recorde-se que este valor representa o número necessário de contagens do relógio base do micro controlador para se conseguirem intervalos de 10ms. Num segundo, existem 100 intervalos de 10ms. Supondo um valor de 456.78, ter-se-ia de colocar neste registo em 100 intervalos, 78 com o valor 457 e 22 com o valor 456.
Nas simulações verificou-se ainda que, para determinados desvios de frequência, o sistema consegue eliminar completamente o erro, levando muito pouco tempo a consegui-lo. Depende da relação do desvio e da influência no contador CNT_TICK_MAX. Se o resultado der um valor inteiro, o sistema elimina o erro, caso contrário é necessário sempre aplicar o controlo para não permitir o desvio dos relógios (o que é obrigatório num sistema real).
A Fig. 8.7 apresenta os resultados num sistema real. Na Fig. 8.7(c) mostra-se a utiliza- ção de um programa para detectar vários protocolos num interface real de Ethernet. Neste caso apenas mostra os pacotes do protocolo em questão, com o nó escravo a enviar sempre uma men- sagem Delay Request ao mestre após a recepção da mensagem Follow UP (o protocolo assume valores aleatórios para não sobrecarregar o processador do relógio mestre). Nos resultados reais confirmou-se a pouca influência em enviar sempre um pedido Delay Request após a recepção da mensagem de sincronismo, quando comparado com o facto do mesmo pedido ser aleatório entre valores de [2;30].TSync.
A Fig. 8.7(a)apresenta, à esquerda, o erro total. A experiência iniciou-se com o relógio do nó mestre num PC real. Em determinado momento desligou-se o servidor de relógio no PC e passou-se o relógio mestre para um PC virtual em VMWare2. O PC normal apenas tinha instalado o Linux Slackware e o servidor de relógio; no PC virtual foi instalado o mesmo sistema, acrescido da base de dados SMIT que se encontrava em funcionamento. Este gráfico pretende mostrar a
8.1 Resultados práticos 129
(a) Esquerda: Erro ∆t no momento de aplicar o controlo (µs). Direita: Evolução do valor de
CNT_TICK_MAX;
(b) Diferença entre o relógio do Mestre e do Escravo (µs);
Figura 8.6: Experiência no4. Novo método com condições análogas à experiência no1 (Fig.8.3).
obrigatoriedade da estabilidade do relógio mestre que, como era previsível num PC virtual, não é assegurada. A consequência desta instabilidade fica patente no gráfico ilustrado nos instantes 600 e 700, quando o mestre do relógio era o PC da máquina virtual. O gráfico da direita apresenta o erro em regime final, na casa dos 30 µs, sendo mais credível considerar um erro em regime final de 40 µs (Fig.8.7(a), direita), em função das várias experiências realizadas.
A Fig.8.7(b)expõe o resultado no gráfico da esquerda da experiência na qual apenas se envia uma mensagem Delay Request ao início. Conforme se verifica, o sistema estabiliza mas com um erro grande em regime final, cerca de 345 µs, tal como previsto na simulação equivalente indicada na Fig. 8.5(a), à direita. Tal influência pode ainda ser verificada na Fig. 5.5 da pág. 73advindo o erro de estimação do tempo de propagação na rede, que sofre influências do desvio de frequência do processador. Nas experiências reais realizadas utilizou-se um switch LinkSys
(a) Esquerda: Erro total∆t (µs). Direita: Erro em regime final;
(b) Erro∆t (µs). Duas experiências com 1 mensagem Delay Request (esquerda) e 10 mensagens Delay Request (direita);
(c) Detecção dos pacotes PTP com um filtro de pacotes Ethernet;
8.1 Resultados práticos 131
operativo windows e uma máquina virtual Linux VMWare, um computador com o sistema operativo
Linux e uma placa com o processador ARM.
Listagem 8.1: Pseudo-código para controlo do acerto no relógio local
u n s i g n e d l o n g A j u s t a C o n t r o l o ( I n t e g e r 3 2 D e l t a _ T ) { s t a t i c I n t e g e r 3 2 g v _ l a s t _ D e l t a T = 0 ; s t a t i c u n s i g n e d l o n g g v _ l a s t _ c o n t r o l o =500000∗TICKNS ; 5 u n s i g n e d l o n g c o n t r o l o , CNT_TICK_MAX_TIMES_TICKNS ; d o u b l e mm; mm= ( D e l t a _ T + g v _ l a s t _ D e l t a T ) / 2 ; g v _ l a s t _ D e l t a T = D e l t a _ T ; 10 mm = mm / SYSTICKHZ ; / / 100 ( n a n o s e g u n d o s d e s l i z a d o s em 10ms )
/ / C o n t a a g o r a o tempo de 10ms de a c o r d o com o CNT_TICK_MAX ∗ 20 n s . / / s e r á a m e d i d a d e l e p a r a 10ms em n a n o s e g u n d o s . i f ( g _ u l S y s t e m T i c k R e l o a d > = 1 0 0 ) c o n t r o l o = ( g _ u l S y s t e m T i c k R e l o a d ) ∗ TICKNS ; 15 e l s e c o n t r o l o = ( S y s C t l C l o c k G e t ( ) / SYSTICKHZ ) ∗ TICKNS ; i f (mm> 9 0 0 0 0 ) mm = 9 0 0 0 0 ; / / l i m i t e d e v i d o ao e r r o i n i c i a l não p r o v o c a r i n s t a b i l i d a d e i f (mm< −90000) mm = −90000; / / A c t u a l i z a o CNT_TICK_MAX ( = c o n t r o l o / TICKNS ) 20 c o n t r o l o = c o n t r o l o − mm∗ 0 . 6 ; / / ( m e d i d a em n a n o s e g u n d o s ) CNT_TICK_MAX_TIMES_TICKNS= ( g v _ l a s t _ c o n t r o l o + c o n t r o l o ) / 2 ; g v _ l a s t _ c o n t r o l o = c o n t r o l o ; 25 r e t u r n CNT_TICK_MAX_TIMES_TICKNS ; }
Quanto ao controlador, as mensagens recebidas do PTP foram utilizadas de acordo com as equações indicadas no final da secção5.2.2, em concreto através do cálculo de dm2e, de2m, tprope ∆t. Dividindo o∆t em unidades de 10ms sabe-se quanto é preciso adaptar CNT_TICK_MAX. Pri-
meiro utiliza-se a média das duas últimas amostras, de seguida limita-se o valor obtido a ±90000, aplicando-se um factor de 0.6 para estabilizar. É feita ainda a média do valor de controlo para as duas últimas amostras. A média é equivalente a um filtro digital passa-baixo. O pseudo-código encontra-se na Listagem8.1. Quer o limite, quer o factor 0.6 encontram-se de acordo com o es- quema da Fig. 5.6 (pág. 74), nomeadamente a média das duas últimas amostras equivale a um filtro passa-baixo FIR.