Gestion des alarmes OPC : Open Platform Communication

Gestion des alarmes OPCGestion des alarmes industrielles avec OPC

Le sigle OPC correspond à différentes significations, la première qui nous vient à l’esprit dans le BTP, est l’ordonnancement, le pilotage et la coordination, qui déterminent le déroulement d’un chantier  (actions et intervenants) dans  le BTP ou les Travaux Publics.

Quant à nous, ici dans le présent document, nous ferons appel à l’interopérabilité des systèmes industriels, c’est une technique qui est apparue dans les années 1995, peu avant que le dernier siècle ne bascule, qui permet entre autres de standardiser les échanges de flux, d’éviter le prolifération des protocoles et de pérenniser les outils.

Au départ parler du protocole OPC, il s’agissait du simple protocole de communication, technique basée sur les développements Microsoft des OLE.com et des DCOM.  Depuis 2011, les choses ont beaucoup évolué, et en raison de son expansion la dénomination même, a elle aussi changé, et c’est devenu OPEN PLATFORM COMMUNICATION  (OPC).

Son but essentiel est de relier les applications Windows entre les matériels et les logiciels, pour pouvoir contrôler les processus, peu importent les sources de données, la cohérence de la norme permettra d’accéder à toutes les données du terrain, dans une agence industrielle ou bien une usine.

OPC est non seulement devenu un sigle, mais c’est aussi une marque bien déposée par la Fondation qui en porte le même nom.  Aujourd’hui les serveurs OPC permettent d’accéder aux dispositifs des différents processus, comme un simple automatate pourrait le faire.

L’interface commune et personnalisée, peut être utilisée par n’importe quel logiciel d’entreprise de type SCADA, et ou IHM.  Le serveur OPC devenant, un simple périphérique utilisant la technique OLE. Les techniques utilisées et développées par la Fondation OPC, sont basées les COM/DOM et sur les travaux de W3C et OASIS.

Ainsi deux catégories totalement distinctes peuvent être considérées, ces catégories sont des interfaces de type « Customs » et/ou « Automation » :

  1. Tout ce qui concerne, les spécifications liées au WEB
  2. Toutes les autres spécifications basées sur les COM/DOM

 

On inclura :

  • OPC Commun (commune à tous les serveurs)
  • OPC Alarm (Gestion des alarmes OPC et autres évènements)
  • OPC Data (Accédant à toutes les données en temps réel)
  • OPC Historical (pour la construction des historiques)
  • OPC Batch (pour toutes les phases posterieures de traitement).

Quant à l’’autre, elle va regrouper, l’autre spécification décomposée en plusieurs parties, qui sera l’OPC UNIFIED Architecture (Java, Microsoft Net, C, .NET et autres XML et Services Web.

Tout cela pour en venir au concept de base de l’OPC, qui est qu’un client OPC va communiquer avec un autre serveur OPC à travers des interfaces soit « Customs », soit « Automations ». Dit simplement ce sont des DLL, qui vont assurer la conversion des appels « Automation » vers des appels « Customs ».

 

  • Comment utiliser les interfaces de l’application cliente

Les clients pourront être écrits en utilisant le Active X Wrapper, qui va simplifier la connexion OPC OPCX – 2000

 

  • Les interfaces obligatoires

Les développeurs de serveurs OPC doivent implémenter toutes les fonctionnalités des interfaces obligatoires dans leur serveur.

 

  • Les interfaces optionnelles

Les développeurs de serveurs OPC, pourront s’ils le souhaitent développer des interfaces dites optionnelles. Quand une interface optionnelle est implémentée, toutes les fonctions qu’elles contient doivent être implémentées.

 

  • OPC, pour quelles performances

Toutes les performances dépendront forcément des paramétrages appliqués (paramètres) : néanmoins les principaux qui vont influer sont :

  • Le type Asynchrone ou Synchrone
  • Les contraintes techniques liés à la performance du matériel utilisé
  • Le type de serveur, InProcess ou Ouprocess
  • L’endroit d’éxécution, Local ou Remote
  • La famille d’interface utilisée : Custom ou Automation.

 

  • OPC, utilisation chez les éditeurs de superviseurs.

L’intérêt commercial n’est pas évident, car les superviseurs ont pour la plupart déjà la réponse aux problèmes abordés par l’OPC, et il existe bien peu sur le marché d’outil de supervision d’alarmes  « Full OPC ».

 

  • OPC, pratiquement tous les OS sont concernés et en résumé, c’est :
  1. Un vrai standard utilisé dans le monde industriel
  2. Une ouverture maximale, pour integrer les ERP
  3. L’accès aux données, depuis n’importe quel point réseau
  4. L’indépendance vis-à-vis des éditeurs de logiciels
  5. Un futur dans la conduite des procédés, existants ou à venir.

Plus d’information sur nos solutions de gestion des alarmes: