Publicité
Le SEN 40 prend en charge en alternative le calcul de l'heure locale sur la base de l'entrée de
fuseau horaire d'un serveur de fuseaux horaires (commutateur 4 allumé). Si le mouvement tra-
vaille en mode unicast, il demande l'entrée auprès du serveur NTP configuré. S'il travaille en
mode multicast, il reçoit l'entrée correspondante à l'adresse de groupe réglée (voir aussi cha-
pitre 4.3.2).
Un mouvement esclave en cascade reçoit l'heure locale du mouvement maître et n'exécute pas
de calcul de l'heure locale. Les positions des commutateurs sont sans effet.
5.8 Précision / perte de synchronisation
La dérivation à l'état synchronisé est typiquement inférieure à +/-50 ms.
L'horloge signale une perte de synchronisation au bout de 24 heures par positionnement des
aiguilles sur 12h00. La dérivation après 24 h sans synchronisation est typiquement inférieure à
+/-2 s (précision du quartz : 20 ppm à température ambiante). Le mouvement esclave continue
à fonctionner au total pendant 48 heures sans synchronisation (temporisation de maître + tem-
porisation d'esclave).
Remarque : les dérivations mentionnées dépendent de la précision et de la puissance de la
source horaire (serveur NTP). La réception NTP peut être influencée par la charge du réseau
et les appareils en réseau (hub, commutateur, routeur, pare-feu, etc.).
5.9 Source horaire redondante
La disponibilité de serveurs NTP en tant que source horaire peut être améliorée par exécution
redondante dans le réseau. Selon le mode de fonctionnement du SEN 40, la stratégie suivante
est prévue (vaut aussi pour les serveurs de fuseaux horaires) :
5.9.1 Client NTP unicast
En tant qu'option DHCP/DHCPv6 ou par configuration manuelle (MOBA-NMS), jusqu'à quatre
adresses de serveur NTP différentes peuvent être communiquées au mouvement. Si le serveur
actuel ne répond pas à trois demandes d'heure consécutives, le mouvement passe au serveur
suivant (si disponible), au bout d'une durée qui peut être définie par l'intervalle entre les de-
mandes réglé (par défaut : 3 x 10 secondes). La demande recommence au premier serveur en
cas de redémarrage du mouvement.
5.9.2 Client NTP multicast
Deux serveurs qui envoient des paquets NTP à la même adresse de groupe (IP multicast) doi-
vent être installés. Les intervalles d'envoi des deux serveurs doivent être ainsi choisis que la
synchronisation soit effectuée en fonctionnement normal par le serveur primaire. La synchroni-
sation du serveur secondaire ne se fait que si le serveur primaire présente un dysfonctionne-
ment. Le rapport entre le nombre de paquets envoyés par le serveur primaire et par le serveur
secondaire doit être réglé sur au moins 4:1 :
•
Intervalle d'envoi du serveur primaire : 1 paquet / 1 minute
•
Intervalle d'envoi du serveur secondaire : 1 paquet / 4 minutes
Le choix du serveur repose donc sur la dominance du serveur qui envoie le plus de paquets
NTP par unité de temps. Si le serveur primaire est défaillant, c'est le serveur secondaire qui
domine.
© MOBATIME
14 / 24
800751.07
Publicité
