AVEVA Historian : Architectures Tier1/Tier2 – Centralisation des données

    Posté : 13 avril 2021

    AVEVA Historian : Architectures Tier1/Tier2 – Centralisation des données

    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 :

    • Centraliser dans un système unique toutes les données des systèmes de production (mesures process, alarmes et événements)
    • Permettre d’effectuer des études comparatives de fonctionnement entre de multiples machines, de multiples ateliers, multiples lignes de production
    • Mettre à disposition de responsables de production et/ou responsables de sites des informations synthétiques à travers des tableaux de bords.
    • Corréler facilement des données process avec des données entreprise

    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.

    Voir la vidéo

    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.

    Architecture Tier1/Tier2 - Exemples

    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 :

     

    Denis LUBRUN
    Écrit par
    Denis LUBRUN

    Responsable Produits Wonderware, je suis dans le secteur de la supervision industrielle depuis 1994. Retrouvons-nous régulièrement sur le blog pour toutes les nouveautés Wonderware !

    Contactez-nous

    Articles sur le même sujet

    Restez informés : soyez au fait des dernières actualités de cette industrie...

    AVEVA Historian
    AVEVA Historian : Architectures Tier1/Tier2 – Centralisation des données

    Disponible depuis les versions 2012, Historian Server permet de mettre en place des architectures dites multi-niveaux (Tier1/Tier2). Dans ce ...

    AVEVA Historian
    Comment s’affranchir de la gestion d’une base de données Microsoft SQL Server pour l’archivage des alarmes et événements d’une application InTouch ?

    En tant qu’utilisateur averti d’InTouch depuis de nombreuses années, vous avez certainement du être confronté aux contraintes liées à ...

    previous next
    Voir tous les articles

    S'inscrire à notre newsletter

    Soyez informé sur les derniers produits, solutions, services, promotions, événements et autres news de Wonderware France.