Protocolo de Tempo da Rede

O protocolo de tempo de rede, NTP, é como computadores e dispositivos em uma rede concordam sobre o tempo. Um dispositivo pede a um servidor de tempo o tempo atual, corrige seu próprio relógio, e repete a solicitação em intervalos. SNTP é uma variante mais simples usada por dispositivos que precisam de menos precisão.

Em sistemas de energia, NTP é uma das várias saídas que um servidor de tempo fornece, juntamente com PTP e IRIG-B. A folha de dados do servidor de tempo do fabricante dá a precisão NTP/SNTP de 10 milissegundos, contra a precisão PTP de 0,2 microsegundos, e afirma que PTP é preferido em vez de porque NTP perde a precisão de tempo GNSS. Essa diferença decide qual protocolo usar: NTP se adapta ao registro de eventos e coordenação geral; não se adequa à proteção ou medição que precisa de sub-microsegundo acordo.

Utilize este guia como uma explicação do protocolo quando escolher um servidor de tempo. Os servidores públicos, os servidores gratuitos e as construções de amadores não substituem um servidor de tempo por hardware num sistema de energia. Para um sistema de energia, a fonte de tempo deve ser um servidor local alimentado por sinais de satélite, não um servidor público de internet.

Antes de encomendar um servidor de tempo, confirme os sistemas de satélite disponíveis no site, os protocolos de saída que os dispositivos precisam e os termos de entrega. Peça que a planilha de dados atual seja confirmada por escrito antes de encomendar.

Desenho de um serviço NTP para uma rede elétrica

Desenhe o serviço de tempo a partir dos dispositivos para fora. Enumere os relés, registadores, medidores, controladores e servidores que tomarão a hora de rede, e anote o que cada um faz com ela: ordenação de eventos, registos de avarias, intervalos de medição ou simples visualização. Essa lista decide quanta exatidão e resiliência o serviço precisa, e que dispositivos merecem a atenção mais próxima na colocação em serviço. Um serviço de tempo de rede desenhado a partir da página de catálogo do servidor tende a ser elegante no centro e errado nas bordas, onde realmente se fazem os registos.

Decida a hierarquia e o comportamento perante falhas de antemão. Que fonte seguem os servidores, que servidor segue cada dispositivo e o que acontece quando se perde uma fonte ou um servidor deveriam ser respostas escritas, não descobertas. Acorde a deriva que cada dispositivo pode mostrar antes de alguém atuar, e como se notará a deriva: uma comparação programada, um alarme ou uma verificação integrada noutra rotina. O tempo falha em silêncio, por isso o desenho deve incluir o dar-se conta, ou o primeiro sintoma será um registo de evento que não pode conciliar-se com o seu vizinho.

Colocação em serviço e convivência com o tempo de rede

Coloque em serviço por comparação. Depois da configuração, percorra a lista de dispositivos e compare a hora de cada dispositivo com a referência acordada, registando o resultado por dispositivo em vez de declarar sincronizada toda a rede em conjunto. Os dispositivos que não podem alcançar-se ou não podem manter a hora são descobertas que devem resolver-se ou documentar-se com as suas consequências aceites abertamente. Repita a comparação depois de mudanças de rede, substituições de dispositivos e atualizações de firmware, porque cada um deles pode devolver em silêncio um dispositivo a uma fonte errada ou a um deslocamento errado.

Quando se comprar um servidor de tempo para este trabalho, escreva a consulta a partir da lista de dispositivos: os protocolos que os dispositivos falam, as fontes disponíveis no local e o comportamento de resiliência requerido. Peça que o servidor oferecido se confirme perante essa lista por escrito, incluindo as suas saídas para qualquer dispositivo que não possa tomar a hora de rede diretamente. Conserve a comparação de colocação em serviço com a documentação de rede, datada e assinada, para que quando dois registos discordem no futuro possa examinar-se o historial do próprio serviço de tempo antes de culpar os dispositivos.

Incidentes de deriva de tempo e o que costumam significar

Quando se encontrarem dispositivos que discordam sobre a hora, resista ao impulso de simplesmente corrigir os relógios e seguir adiante. Um incidente de deriva é evidência: um dispositivo que perdeu a sua fonte, uma mudança de rede que quebrou um caminho, uma configuração restabelecida em silêncio ou um servidor cuja própria fonte falhou primeiro. Registe que dispositivos derivaram, em quanto e o que se encontrou, antes de corrigir o que quer que seja, porque o padrão de deriva é o diagnóstico. Corrija depois, compare de novo e arquive o incidente com os registos do serviço de tempo. Um serviço com um historial de incidentes honesto pode ser de confiança; um com relógios misteriosamente perfeitos costuma ter um historial sem examinar.

Dê ao serviço de tempo uma entrada no processo de mudança do local, não apenas na sua documentação de rede. Qualquer mudança em comutadores, servidores, registadores ou na sua configuração deve fazer uma pergunta: toca isto algo que faz, leva ou consome tempo? Essa pergunta, feita no momento da mudança, evita a maioria dos incidentes de deriva, que raramente são causados pelo próprio serviço de tempo e costumam sê-lo por uma mudança vizinha que ninguém ligou ao tempo. Mantenha a pergunta visível no próprio formulário de mudança, porque uma regra que depende da memória será esquecida por exatamente a mudança que a precisava.

O que confirmar antes de encomendar

Antes do pagamento, confirme o modelo, a especificação da ficha de dados atual, a quantidade, o preço, o prazo de entrega e os termos de entrega, por escrito. Peça na sua consulta a confirmação dos termos de pagamento, dos termos comerciais e do tempo de resposta que deve esperar, em vez de presumir qualquer um deles. Confirme o preço, a encomenda mínima e o prazo de entrega do seu pedido com o fornecedor por escrito antes do pagamento.