Blog Factory Software/AVEVA

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 ?

Rédigé par Denis LUBRUN | 12 févr. 2021 10:46:37

En tant qu’utilisateur averti d’InTouch depuis de nombreuses années, vous avez certainement du être confronté aux contraintes liées à l’administration de la base de données Microsoft SQL Serveur qui assure l’archivage des alarmes et événements.

Vous pouvez tout d’abord tomber dans un 1er écueil lié à l’édition SQL Server Express limitée à 10Go, et faire que cette édition ne soit pas suffisante pour assurer l’archivage des alarmes et événements de votre application InTouch de 60 000 variables.

Pour juguler cette limitation de 10Go, vous mettrez peut-être en place des opérations planifiées de purge et export des alarmes et événements afin de rester dans cette limite à travers les outils Alarm DbPurge / Archive et Alarm DB Restore.

Ensuite à des fins de conserver un certain niveau de performance de votre base de données SQL, vous mettrez en place des procédures planifiées de re compactage des données. Tout cela, nécessitant en plus des connaissances SQL Serveur.

Sans oublier la configuration et le démarrage de l’outil AlarmDbLoggerManager pour assurer l’archivage des alarmes et événements dans la base de données WWALMDB.

A la lecture de ces quelques lignes vécues, j’imagine que vous êtes bien-sûr à la recherche d’une solution alternative qui balayerait d’un coup d’un seul toutes ces problématiques et contraintes.

Pour cela, je vous propose de mettre en place le tandem industriel AVEVA, je veux parler d’InTouch 2020R2 + Historian 2020R2.

Tout d’abord, sachez que l’intégration d’InTouch 2020R2 et Historian 2020R2 est dorénavant totale et fonctionne à l’identique d’un projet System Platform. En d’autres termes, l’application InTouch pousse les données que vous souhaitez archiver dans Historian. Dans le cas d’une rupture de communication entre le poste InTouch et Historian, les données sont archivées localement sans limite de temps et de capacité de stockage. A cela s’ajoute le fait qu’il n’y a aucune configuration dorénavant à effectuer dans la console de configuration. Ci-dessous liste des premiers bénéfices apportés.

  • Bénéficier des mécanismes avancés d’archivage de données de System Platform
  • Réduire de 100% le temps de configuration InTouch/Historian
  • Simplifier la prise en compte de nouvelles variables à archiver
  • Bénéficier implicitement de la fonction locale d’archivage « store & forward »
  • Aucune opération d’administration coté SQL Serveur

Pour rappel, sachez que les données archivées (mesures, alarmes et événements) par Historian ne sont pas archivées dans une base de données SQL Serveur mais volontairement dans des fichiers journaliers compressés et cryptés à des fins de fournir un haut niveau de performance tant dans la phase d’archivage que dans la phase d’extraction et d’analyse des données. Bien sur, toutes les données sont exposées vis à vis des applications clientes qui les sollicitent dans le format universel SQL.

Activation d’Historian comme système d’archivage global de vos applications InTouch.

Comme souhaité précédemment et pour répondre précisément à la question principale de ce blog, nous allons voir qu’avec la version 2020R2 d’InTouch, il est possible d’archiver les alarmes et les événements directement dans les blocs d’historiques Historian au même titre que les mesures. Vous trouverez ci-dessous les autres bénéfices apportés par cette fonctionnalité.

  • Centraliser les mesures/alarmes/événements dans un système fédérateur unique Historian
  • Bénéficier de la compression des données (alarmes et événements) dans les blocs d’historiques
  • Bénéficier de la fonction d’archivage local des données en cas de rupture de communication
  • Contextualiser les situations d’alarmes et les acquittements sur le tracé des courbes
  • S’affranchir de la maintenance de la base de données SQL pour les alarmes et événements
  • L’archivage des alarmes et événements dans les blocs d’historiques InTouch ne consomme aucune variable de votre licence Historian

Bien évidemment, l’objet « bandeau d’alarmes » a été modifié pour permettre la relecture des alarmes et événements non pas dans la base de données WWALMDB mais dans les blocs d’historiques. Vous pouvez également exploiter et analyser vos alarmes et événements par le biais de requête SQL et API REST/oData.

En plus des différents bénéfices évoqués ci-dessus, vous allez également améliorer l’analyse de vos données puisque dorénavant sur le tracé des courbes les situations d’alarmes et d’acquittements sont matérialiser directement sur le tracé des courbes comme présenté ci-dessous dans les copies d’écrans à travers les solutions d’analyse de données AVEVA Historian Client et AVEVA Historian Web Client.

Conclusion : En optant pour le tandem « InTouch 2020R2 + Historian 2020R2 », vous allez vous affranchir de toute les actions d’administration identifiées précédemment et notamment liées à une base de données SQL Serveur et augmenter l’efficacité opérationnelle de vos opérateurs à travers des tracés de courbes enrichis des effets de contextualisation.

Voilà, à travers ces quelques lignes, vous avez tous les éléments en main pour réussir !