Disponible depuis les versions 2012, Historian Server permet de mettre en place des architectures dites multi-niveaux (Tier1/Tier2). Dans ce contexte, les données d’un ou de plusieurs Historian Server Tier1 sont envoyées vers un ou plusieurs Historian Server Tier2 agissant en tant que concentrateur de données.
La mise en place d’un concentrateur de données apporte de multiples bénéfices comme :
Il est possible d’envoyer tout ou partie des données brutes d’un Historian Tier1 vers un Historian Tier2 et/ou d’envoyer des données agrégées (min, moyenne, max, écart type, etc..) d’un Historian Tier1 vers un Historian Tier2.
A des fins de sécurité et de protection des données, les données échangées entre les Tier1 et le Tier2 sont automatiquement cryptées à travers l’usage du protocole sécurisé et standardisé TLS.
Il est possible d’associer un suffixe ou un préfixe à chacune des variables remontées vers l’Historian 2 permettant ainsi de distinguer aisément les informations provenant des différents Tier1 mais aussi de gérer implicitement des éventuels doublons de noms de variables au niveau des Historian Tier1.
Depuis la version 2017, il est également possible de pousser les alarmes et événements archivés dans un Tier1 vers un Tier2.
En termes de licences, les Historian Tier1 peuvent être des licences Historian Standard ou Historian Standard local. A contrario, la licence de l’Historian Tier2 doit être impérativement de type Historian Enterprise. La seule et unique particularité d’un Historian Standard Local est d’être limitée aux sept derniers jours de relecture et analyse des données indépendamment des solutions d’analyse utilisées (AVEVA ou tierces).
En cas de rupture de liaison réseau entre un Tier1 et un Tier2, les données sont archivées localement sans aucune limitation de temps et de taille disque. Les données archivées localement sont également compressées. C’est uniquement la taille du disque local du Tier1 qui limite éventuellement le stockage local. Lors du rétablissement de la liaison les données sont automatiquement transférées vers le Tier2. Afin de ne pas surcharger le réseau lors du rétablissement de la communication réseau suite à longue rupture, il est possible de contrôler le flux d’échanges des données entre un Tier1 et un Tier2.
Sachez que la mise en place d’une architecture Historian Tier1/Tier2 est supportée à travers des réseaux à faibles débits et/ou intermittents. A ce sujet, la version 2020R2 d’Historian dispose d’ailleurs d’une nouvelle option permettant le support de niveaux de latence réseau élevés. L’exemple typique d’utilisation de cette option trouve toute sa place dans une architecture d’Historian Tier1 situés par exemple sur des plateformes de forage pétrolier/gazier et échangeant des données vers un ou plusieurs Historian Tier2 situés à terre et échangeant les données à travers des réseaux satellites.
Dans l’architecture ci-dessous, tout ou partie des données de L’ATELIER A et de L’ATELIER B sont remontées en temps réel des Historian Tier1 vers l’Historian Tier 2 agissant en tant que concentrateur de données. Comme indiqué ci-dessous les alarmes et événements archivés dans les Historian Tier1 sont également remontés en temps réel vers le Tier2.
Dans l’architecture ci-dessous, tout ou partie des données de plusieurs sites équipés d’un Historian Tier 1 sont remontées en temps réel vers l’Historian Tier 2 agissant en tant que concentrateur de données. Comme indiqué ci-dessous les alarmes et événements archivés dans les Historian Tier1 sont également remontés en temps réel vers le Tier2.
Dans l’architecture ci-dessous, tout ou partie des données de plusieurs sites équipés d’un Historian Tier 1 sont remontées en temps réel volontairement vers deux Historian Tier 2 agissant en tant que concentrateur de données. Les alarmes et événements archivés dans les Historian Tier1 sont également remontés en temps réel vers les deux Tier2.
Pour plus d'informations sur Historian, consultez notre site web.
Découvrez également :