Mise à jour OPAF: O-PAS version 1.0 expliquée – Bien choisir son serveur d impression

Dans cet épisode de Control Amplified, Jim Montague est accompagné de Dennis Brandl, consultant principal de BRL Consulting Inc., coprésident du groupe de travail sur les normes de l'OPAF et président du sous-comité de l'architecture technique. Brandl et Montague discutent de l'historique, des objectifs et des nouvelles du forum Open Process Automation.

Transcription

Jim Montague: Bonjour, voici Jim Montague, rédacteur en chef du magazine Control et ControlGlobal.com, et voici le dernier né de notre série de podcasts Control Amplified. Dans ces enregistrements, nous discutons avec des sources expertes au sujet du contrôle des processus et de l’automatisation et essayons simplement d’aller au-delà de notre couverture imprimée et en ligne pour vraiment explorer certains des problèmes sous-jacents qui ont un impact sur les utilisateurs, les intégrateurs de systèmes, les fournisseurs et d’autres personnes et organisations de ces industries. .

Pour notre septième podcast, nous nous entretenons avec Dennis Brandl, consultant principal chez BRL Consulting Inc.et coprésident du Forum Open Process AutomationDu groupe de travail sur les normes, et également président du sous-comité de l’architecture technique. À ce titre, il fait partie de la douzaine d’experts qui s’efforcent de concrétiser la vision du Forum de développer un système de contrôle de processus véritablement plug-and-play. De même, il était aussi l’un des nombreux contributeurs à ContrôleArticle de couverture de mars La mise à jour des efforts de l’OPAF a également été d’une aide précieuse. Nous avons donc pensé qu’il serait bon d’obtenir une version audio de ce travail.

Dennis, désolé pour le préambule habituel et merci de vous joindre à nous aujourd'hui.

Dennis Brandl: Eh bien, je suis content d’être ici. Je suis content de parler de ça.

JM: OK, tout d’abord, beaucoup de gens s’expriment pour la première fois, quels sont les rouages ​​de l’initiative Open Process Automation et que tente-t-il de faire?

DB: Oui, oui. Les écrous et les boulons, assez simple. Le concept ici est de parler d’ouverture, ce qui a été techniquement un marché relativement fermé, qui est le DCS marché. Et nous le faisons à travers Le groupe ouvert. Si vous n'êtes pas familier avec The Open Group, The Open Group est une organisation dont le slogan est la clé du succès. Donc, ils ne développent pas nécessairement des normes, mais ils les prennent et les promeuvent. Ils ont donc travaillé sur des logiciels que vous connaissez peut-être, tels que POSIX, qui est la norme d'interface pour les systèmes d'exploitation. TOGAF, qui est un standard pour les architectures d'entreprise; et FACE, le futur environnement de capacité aéroporté, utilisé dans les avions du monde entier, essentiellement pour vous offrir une capacité plug-and-play.

Donc, ce que nous essayons de faire avec le forum Open Process Automation, c’est d’apporter une ouverture plug-and-play au marché DCS pour le faire évoluer de la même époque qu’au début des années 80, lorsque les architectures avaient été développées. Là où il peut être aujourd'hui avec les toutes nouvelles capacités que nous avons dans l'électronique, les logiciels, les réseaux, et nous allons rendre toutes ces fonctionnalités disponibles, nous allons les créer, en espérant créer des marchés pour de nombreux produits différents et beaucoup de capacités différentes.

JM: Depuis le début des années 80, 90 et même aujourd’hui, il existe une quantité énorme de protocoles, de technologies et autres technologies propriétaires, et leur interopérabilité n’était pas possible. Donc, OPA et OPAF tentent d’aller au-delà de cela, vous savez, je pense que cela m’a été décrit comme une chaîne stéréo. Vous savez, vous pouvez simplement brancher les câbles des haut-parleurs et c’est ce que nous essayons de faire comprendre aux systèmes de contrôle de processus, non?

DB: Oui exactement. Traditionnellement, les systèmes DCS, les systèmes de contrôle, même certains des Systèmes PLC ont été fermés. Donc, si vous voulez que certains travaillent ensemble, le processus est coûteux et prend beaucoup de temps. En réalité, vous vous retrouvez avec des systèmes fragiles, ils ne fonctionnent pas très bien ensemble parce que tout semble être fait sur mesure. . Nous voulons nous en débarrasser, non? Nous voulons faire en sorte que votre clé USB soit connectée à votre ordinateur et que tout semble fonctionner ensemble, vous ne devez utiliser aucun logiciel, vous ne devez effectuer aucune configuration.

JM: Bon, alors, juste pour avoir un peu d'histoire, comment est-ce arrivé? Pouvez-vous résumer les événements fondamentaux qui ont conduit à ce qui se passe avec ExxonMobil et les efforts de Lockheed et de l’OPAF?

DB: Oui, oui, oui. Au cours de la dernière décennie, il y a eu beaucoup de travail, alors que les gens examinaient différentes architectures et environnements de systèmes de contrôle et commençaient à réfléchir, OK, comment pouvons-nous tirer parti de certains d'entre eux?

Ce qui s’est passé chez Exxon, c’est qu’ils avaient, ils avaient encore beaucoup de systèmes DCS très anciens, car il est très coûteux de remplacer un système DCS dans une raffinerie. Donc, ils ont des TDC 2000 et des TDC 3000 en fonctionnement. Le problème que vous avez ici est que ces choses sont bien passées de leur temps de maintenance. Nous avions un dicton, si vous ne pouvez pas acheter les pièces de rechange sur eBay, alors c’est définitivement obsolète. Et je pense que c’est la situation dans laquelle ils se trouvent. Ils ont donc lancé un projet visant à déterminer ce qu’ils vont faire. En fait, plusieurs projets. L’un de ces projets était un projet de recherche: Ok, si vous partez de zéro, si vous ne regardez pas dans votre historique, comment concevriez-vous un système aujourd’hui? À la suite de cet effort, ExxonMobil a rédigé quelques livres blancs. Ils ont parlé des exigences du système et de la façon dont vous pourriez y remédier. Et puis, Exxon s'est rendu compte que c'était plus gros qu'eux, qu'il allait falloir toute une industrie pour examiner certaines de ces solutions. Alors, ils sont allés au Open Group pour commencer ce travail, simplement pour dire OK, voyons si nous pouvons prendre ces concepts et ces idées issus de ce projet de recherche et les rendre réels. Et c’est ce que le forum Open Process Automation est.

Lire la suite: L'OPAF étend ses effectifs et publie la version 1.0 de O-PAS

Parallèlement à cela, ExxonMobil a travaillé avec Lockheed Martin pour développer une preuve de concept afin de s’assurer que ces concepts fonctionneraient réellement dans la vie réelle, dans des applications réelles, et c’est ce qu’ils ont fait avec Lockheed Martin.

Nous avons donc pu, dans le forum Open Process Automation, examiner le problème et dire: «OK, ces concepts, nous savons qu'ils vont fonctionner. Nous avons beaucoup de travail à faire pour les faire fonctionner, mais nous savons que ça va marcher. Nous savons que, du point de vue de l’architecture, les choses vont travailler ensemble et jouer ensemble, et nous allons obtenir l’interopérabilité et la portabilité que nous espérons pouvoir obtenir.

JM: Et puis, pour que tout le monde soit au rendez-vous, la première version d'Open Process Automation Standard, qui s'appelle O-PAS, vient d'être annoncée en février dernier et comporte cinq parties. Il serait probablement bon de laisser savoir aux utilisateurs ce qu'ils tous couvrent.

DB: Oui, oui. La première version, ce n’est pas une barre très haute à franchir. Le concept de cette solution consistait à obtenir une interopérabilité, afin de s'assurer que les utilisateurs puissent créer des périphériques qui deviendront les périphériques du DCS qui fonctionneront ensemble. Mais c’est aussi, comme je le vois, c’est de jeter les bases du prochain niveau de fonctionnalité que nous essayons de définir.

Ainsi, cette fondation inclut la première partie de la norme, qui est une architecture technique. Maintenant, je tiens à préciser que ce que nous définissons n’est pas une architecture système, mais ce que nous définissons en réalité sont des interfaces. Nous ne disons pas comment les gens devraient accomplir leurs tâches, nous disons simplement que si vous voulez que le périphérique A parle au périphérique B ou que le logiciel A parle au logiciel B, ce sont les interfaces que vous utiliserez pour cette communication. Aujourd'hui, une grande partie de cela est basé sur le modèle OPC-UA, mais les plus récents sont également basés sur d'autres normes existantes.

La deuxième partie de la première version traite vraiment de la sécurité, car nous reconnaissons que si nous ne concevons pas la sécurité au début, il est impossible de la brancher plus tard. Nous travaillons donc en étroite collaboration avec les personnes qui font partie du comité ISA-99 et de la norme 64223-IEC pour définir les exigences de sécurité minimales requises pour la construction d'un système, car nous souhaitons que cette solution soit sécurisée et prête à l'emploi. et nous voulons qu’elle puisse être mise à niveau à mesure que de nouvelles menaces apparaissent.

La troisième partie de la première version est un résumé des profils. Les profils définissent la fonctionnalité qu'un fournisseur vous fournirait. Ainsi, par exemple, nous avons un profil qui explique comment vous effectuez la gestion du système, et nous avons deux options différentes pour le faire. De même, nous avons plusieurs options sur le travail du CPVP. Donc, la troisième partie est une sorte de résumé.

La quatrième partie de la première version traite de l'OPC-UA, ou nous l'appelons le cadre de communication de l'OPAF. Et ce qu’il définit, c’est la fonctionnalité d’interopérabilité. L’un des problèmes de l’OPC-UA est qu’il est extrêmement flexible. Il est donc parfois difficile de faire fonctionner ces éléments ensemble, en particulier lorsque vous devez vous soucier de la sécurité et des exigences de sécurité, ainsi que de certaines des options associées à OPC-UA. pour que ces choses fonctionnent ensemble. La quatrième partie définit donc les profils. Il indique que si votre système prend en charge ces fonctionnalités, ces fonctions doivent être lues immédiatement.

La cinquième partie de la première version traite de la gestion du système. Maintenant, imaginez un système existant et composé de milliers, voire de dizaines de milliers, de petits DCN très intelligents et intelligents, de nœuds de contrôle distribués, qui communiquent tous et exécutent tous vos fonctions de contrôle de manière distribuée. Eh bien, vous devez gérer ces milliers à des dizaines de milliers d'appareils. Donc, nous avons sélectionné un poisson rouge standard, qui est plus du côté informatique, qui vous donne la possibilité de dire, OK, je dois savoir si cet appareil est en marche, quelles sont certaines des statistiques ou certaines informations dessus, comme si elle chauffait, si la température était trop élevée, si elle avait un ventilateur, si le ventilateur fonctionnait. Ce genre de choses que vous pouvez utiliser pour examiner tous ces périphériques de tous ces différents fournisseurs dans un même environnement. Nous avons donc quelques profils pour cela également. Quiconque est familier avec les batteries de serveurs connaît probablement un poisson rouge et sa gestion. Alors, considérez un système OPAF comme une batterie de serveurs avec des dizaines, voire des milliers, de très petits serveurs répartis sur le terrain ou distribués par vos systèmes de contrôle, et vous devez les gérer.

Ce sont donc les cinq parties de la première version en février.

Pour en savoir plus, accordez-vous à Control Amplified: le podcast d'automatisation et de contrôle des processus