Protocole de temps du réseau

Le protocole de temps réseau, NTP, est la façon dont les ordinateurs et les appareils sur un réseau s'entendent sur l'heure. Un périphérique demande un serveur de temps pour l'heure actuelle, corrige sa propre horloge, et répète la requête à intervalles réguliers. SNTP est une variante plus simple utilisée par les appareils qui ont besoin de moins de précision.

Dans les systèmes d'alimentation, NTP est l'une des nombreuses sorties fournies par un serveur de temps, aux côtés de PTP et IRIG-B. La feuille de données du serveur de temps du fabricant donne une précision de 10 millisecondes de NTP/SNTP, contre une précision de 0,2 microseconde de PTP, et indique que PTP est préférable à NTP parce que NTP perd la précision de la synchronisation GNSS. Cette différence détermine le protocole à utiliser : NTP convient à l'enregistrement des événements et à la coordination générale; elle ne convient pas à la protection ou à la mesure qui nécessite un accord sous-microseconde.

Utilisez ce guide comme une explication du protocole lorsque vous choisissez un serveur de temps. Les serveurs publics, les serveurs gratuits et les constructions d'amateurs ne remplacent pas un serveur de temps matériel dans un système électrique. Pour un système électrique, la source de temps doit être un serveur local alimenté par des signaux satellite, et non un serveur internet public.

Avant de commander un serveur de temps, confirmez les systèmes satellites disponibles sur le site, les protocoles de sortie dont les appareils ont besoin et les conditions de livraison. Demandez que la fiche technique actuelle soit confirmée par écrit avant de commander.

Concevoir un service NTP pour un réseau électrique

Concevez le service de temps à partir des appareils vers l'extérieur. Listez les relais, enregistreurs, compteurs, contrôleurs et serveurs qui prendront le temps réseau, et notez ce que chacun en fait : classement des événements, registres de défauts, intervalles de mesure ou simple affichage. Cette liste décide de combien d'exactitude et de résilience le service a besoin, et quels appareils méritent l'attention la plus proche à la mise en service. Un service de temps réseau conçu à partir de la page catalogue du serveur tend à être élégant au centre et faux aux bords, là où les registres sont réellement faits.

Décidez la hiérarchie et le comportement en cas de défaillance à l'avance. Quelle source les serveurs suivent, quel serveur chaque appareil suit et ce qui se passe lorsqu'une source ou un serveur est perdu devraient être des réponses écrites, et non des découvertes. Convenez de la dérive que chaque appareil peut montrer avant que quelqu'un agisse, et de la manière dont la dérive sera remarquée : une comparaison programmée, une alarme ou un contrôle intégré à une autre routine. Le temps échoue silencieusement, alors la conception doit inclure le fait de s'en apercevoir, ou le premier symptôme sera un registre d'événement qui ne peut pas se concilier avec son voisin.

Mettre en service et vivre avec le temps réseau

Mettez en service par comparaison. Après la configuration, parcourez la liste des appareils et comparez le temps de chaque appareil à la référence convenue, en consignant le résultat par appareil au lieu de déclarer tout le réseau synchronisé comme un tout. Les appareils qui ne peuvent pas être atteints ou qui ne peuvent pas garder le temps sont des conclusions à résoudre ou à documenter avec leurs conséquences acceptées ouvertement. Répétez la comparaison après les changements de réseau, les remplacements d'appareils et les mises à jour de micrologiciel, car chacun de ceux-ci peut silencieusement rendre un appareil à une source fausse ou à un décalage faux.

Lorsqu'un serveur de temps est acheté pour ce travail, écrivez la demande à partir de la liste des appareils : les protocoles que les appareils parlent, les sources disponibles sur le site et le comportement de résilience requis. Demandez que le serveur proposé soit confirmé par rapport à cette liste par écrit, y compris ses sorties pour tout appareil qui ne peut pas prendre le temps réseau directement. Conservez la comparaison de mise en service avec la documentation réseau, datée et signée, afin que lorsque deux registres divergeront à l'avenir, l'historique du service de temps lui-même puisse être examiné avant que les appareils soient blâmés.

Incidents de dérive de temps et ce qu'ils signifient en général

Lorsque des appareils sont trouvés en désaccord sur le temps, résistez à l'envie de simplement corriger les horloges et de continuer. Un incident de dérive est une preuve : un appareil qui a perdu sa source, un changement de réseau qui a cassé un chemin, une configuration silencieusement réinitialisée, ou un serveur dont la propre source a échoué en premier. Consignez quels appareils ont dérivé, de combien, et ce qui a été trouvé, avant de corriger quoi que ce soit, car le motif de dérive est le diagnostic. Corrigez ensuite, comparez à nouveau et archivez l'incident avec les registres du service de temps. Un service avec un historique d'incidents honnête peut être cru ; un service aux horloges mystérieusement parfaites en a en général un qui n'a pas été examiné.

Donnez au service de temps une entrée dans le processus de changement du site, et pas seulement dans sa documentation réseau. Tout changement de commutateurs, serveurs, enregistreurs ou de leur configuration doit poser une question : cela touche-t-il quelque chose qui fait, porte ou consomme le temps ? Cette question, posée au moment du changement, évite la plupart des incidents de dérive, qui sont rarement causés par le service de temps lui-même et en général par un changement voisin que personne n'a relié au temps. Gardez la question visible sur le formulaire de changement lui-même, car une règle qui dépend de la mémoire sera oubliée par exactement le changement qui en avait besoin.

Ce qu'il faut confirmer avant de commander

Avant le paiement, confirmez le modèle, la spécification de la fiche technique actuelle, la quantité, le prix, le délai de livraison et les conditions de livraison, par écrit. Demandez dans votre demande de confirmer les conditions de paiement, les conditions commerciales et le délai de réponse que vous devez attendre, plutôt que de les supposer. Confirmez le prix, la commande minimum et le délai de livraison de votre commande auprès du fournisseur par écrit avant le paiement.