Avant la création d’OPC, il existait pléthore de normes destinées à transférer des données depuis ou vers les automates. Ces normes étaient typiquement adaptées à des techniques d’entrées-sorties et à des bus conçus pour des environnements particuliers. OPC DA améliora cette situation par la définition d’un standard d’accès aux données unifié.
OPC DX introduit la notion de serveur OPC DX
La fin du premier trimestre 2003 a vu l’arrivée de la version 1 des spécifications d’OC DX. Enfin, diront certains. Cent vingt deux pages auront été nécessaires pour mettre à plat les réunions des OPC-travailleurs.
Voici en exclusivité un large extrait de ces spécifications.
Concepts fondamentaux
Avant la création de OPC, il existait pléthore de normes destinées à transférer des données depuis ou vers les automates. Ces normes étaient typiquement adaptées à des techniques d’entrées-sorties et à des bus conçus pour des environnements particuliers. Les logiciels obligés de collecter des données depuis une variété de capteurs de terrain devaient donc incorporer le code propre à chacun de ces protocoles. Faire dialoguer deux boîtiers réalisés en technologie différentes nécessitait souvent l’utilisation d’un pont d’interface.
OPC DA améliora cette situation par la définition d’un standard d’accès aux données unifié permettant – aux yeux de l’application cliente – une uniformisation des protocoles matériels. OPC DA standardisa donc l’échange de données vertical entre boîtiers terrain et les applications de contrôle, comme illustré en figure 1.
[Fig 1] – Légende – Intégration verticale d’OPC DA
Cependant, OPC DA ne définissait aucun protocole pour l’échange de données directement entre serveurs. C’est ainsi que de nombreux fabricants proposèrent des boîtiers de dialogue, mais, faute de norme, ces derniers disposaient chacun de leur méthode de configuration particulière.
La norme OPC DX répond à ce problème : elle introduit la notion de serveur OPC DX, c’est-à-dire de boîtier capable de transférer d’une façon fiable des données en provenance ou à destination d’un autre serveur OPC DX. De surcroît, la norme définit également des méthodes banalisées pour configurer ces serveurs depuis une application cliente, en vue d’assurer ces transferts horizontaux. La figure 2 représente ces concepts.
[Fig 2] – Légende – Intégration horizontale d’OPC DX
Généralités sur l’architecture
Modèle systémique
OPC DX normalise les transferts horizontaux non critiques depuis un serveur OPC DX ou DA vers un serveur OPC DX. Ce dernier contient l’objet DA destinataire, alors que le premier contient l’objet DA expéditeur.
OPC DX définit le transfert source – destination comme une DXConnexion. Une DXConnexion se représente comme un objet OPC DA en lecture seule. Les DXConnexions se configurent au travers d’un client OPC DX en utilisant des services OPC DX dédiés.
OPC DX définit également des objets OPC DA dérivés que les clients peuvent utiliser pour superviser des DXConnexions en utilisant des interfaces OPC DA. La figure 3 représente une architecture OPC DA.
[Fig 3] – Légende – Architecture DX
Parcourir les objets source et la base de données DX
Les clients de configuration peuvent accéder, au travers d’interfaces OPC DA, aux clients OPC DA ou DX à la recherche des objets source et/ou destination qu’ils gèrent. Les objets destinataires ne peuvent se trouver que dans des serveurs OPC DX, alors que les objets émetteurs peuvent être gérés par des serveurs OPC DA ou DX, y compris le serveur destinataire lui-même.
Le client de configuration choisit les objets source et destination, et les utilise pour créer sa DXConnexion. Cette dernière se définit en termes d’objet source, destination, type de transfert ainsi que d’autres paramètres descriptifs.
Le serveur DX enregistre les DXConnexions dans une base de données DX située dans son champ d’adressage OPC DA. Le serveur DX *sauvegarde* périodiquement sa base de donnée DX en cas de réinitialisation.
Les clients OPC DA peuvent parcourir la base de données DX du serveur DX en utilisant l’interface de consultation OPC DA. Le serveur DX permet aux clients de définir la structure de consultation des DXConnexions grâce au concept de browse path.
Le browse path définit le chemin utilisé pour accéder à la DX Connexion lors de la consultation de la base de données DX. Les branches du browse path représentent des groupes logiques de DXconnexions. Les clients peuvent décider de pointer vers une DXConnexion par plus d’un browse path, ce qui permet à la DXConnexion d’appartenir à plusieurs groupes logiques.
Quoique cela ne soit pas dessiné dans la figure 3, la base de données DX contient également une liste des serveurs émetteurs, lesquels sont des serveurs contenant un ou plusieurs objets émetteurs. Chaque entrée de la base contient la description d’un serveur émetteur, de type DA ou DX, plus le type de protocole (ex. : DA 2.05) mis en oeuvre pour y accéder.
Configuration
Les services OPC DX dédiés peuvent être utilisés concomitamment par les clients de configuration pour configurer et gérer les enregistrements des DXConnexions et des serveurs émetteurs dans la base de données DX.
Les clients peuvent avoir recours à ces services pour modifier les serveurs sources, les DXConnexions ou les browse path. Toute modification apportée à l’un de ces derniers se répercute automatiquement sur toutes les DXConnexions accessibles en suivant celui-ci.
Les DXConnexions et les serveurs émetteurs sont protégés par un attribut de version. Quand un client ajoute ou modifie une DXConnexion, celle-ci se voit attribuer un identifiant unique appelé version. Les clients qui veulent modifier ou détruire cette DXConnexion, doivent communiquer la version correcte, faute de quoi le serveur rejette leur demande.
Les DXConnexions et les serveurs émetteurs deviennent actifs dès leur création par un client, que celui-ci reste ou non connecté au serveur DX. Ils cessent d’exister lorsqu’ils sont explicitement détruits par un client.
Une branche de browse path se créé automatiquement lorsque la première DXConnexion qui l’utilise est initialisée. Elle ne sera effacée que lors de la destruction de la dernière DXConnexion qui l’utilise. Les clients peuvent effacer une branche, ce qui détruit automatiquement toutes les DXConnexions actives qui en dépendent.
Cependant, les DXConnexions et les serveurs émetteurs contiennent des attributs par défaut qui autorisent ou interdisent les transferts de données lorsqu’ils deviennent actifs. Quand un serveur émetteur est invalidé, aucun serveur DX ne peut établir de transfert avec lui, et aucune DXConnexion n’est possible.
Transfert horizontal de données
Une fois qu’une DXConnexion est définie et prête à transférer des données, le serveur DX accède au serveur émetteur pour connaître la valeur de son objet source. Le serveur DX met à jour l’objet destinataire après avoir effectué les conversions, transformations, substitutions ou forçage adéquats.
Le déroulement de la DXConnexion comprend les actions de configuration, les cas de rupture de connexion, de gestion d’erreur, de conversion au vol, et de forçage manuel.
Contrôle et gestion
OPC DX définit un ensemble d’attributs accessibles par OPC DA qui permettent aux clients OPC DA de contrôler le transfert de données en différents points de son parcours. Ces attributs autorisent :
· La connexion/déconnexion de l’objet source
· La validation ou l’invalidation de la mise à jour du destinataire
· La définition de valeurs par défaut lorsque la source est inaccessible
· La définition des valeurs de forçage
· L’utilisation ou non du forçage
OPC DX inclut des services grâce auxquels un client peut enregistrer un ensemble de valeurs d’attributs comme jeu par défaut, puis de rétablir cette configuration par défaut si nécessaire.
Les attributs suivants concernent les branches de browse path :
· Connexion/déconnexion de la source
· Autorisation/interdiction de la mise à jour du destinataire
· Utilisation ou non du forçage
Quand ces attributs sont appliqués sur une branche, ils concernent toutes les DXConnexions qui en dépendent. Par exemple, si un client décide de déconnecter une branche de sa source, toutes les DXConnexions se déconnectent aussi. Comme celles-ci peuvent se reconnecter individuellement, la lecture de la valeur de ces attributs par un client n’est pas significative. Aussi, la norme les définit en écriture seule.
La norme définit aussi un attribut connexe concernant les serveurs émetteurs, qui autorise ou interdit leur connexion à un serveur DX. Lorsque cet attribut passe en l’état interdit, toutes les DXConnexions établies avec un objet source de ce serveur cessent de fonctionner, jusqu’à ce que l’attribut repasse en état autorisé.
OPC DX inclut également un attribut des DXConnexions qui permet aux clients OPC DA de superviser les transferts de données. Les clients OPC DA qui le désirent lisent ou souscrivent à ces attributs, en plus des attributs de configuration, afin d’observer l’état des DXConnexions.
Modèle serveur
Le serveur DX représente une extension d’un serveur totalement compatible à OPC DA, conformément à l’une des normes OPC DA. Le serveur OPC DA sous-jacent permet la supervision et le contrôle de la base de données DX. La technologie de l’interface utilisée par le serveur OPC DA sous-jacent (DCOM et/ou web) est utilisée par les services de configuration du serveur DX. Les composants qui supervisent ou configurent le serveur DX doivent utiliser les mêmes technologies d’interface que le serveur OPC DA sous-jacent. Le serveur DX fournit en sus :
Base de données DX
Le serveur DX exploite une base de données DX dans son espace d’adressage qui contient la description du serveur DX, des DXConnexions et des serveurs sources ;
Interface de configuration
Cette interface permet d’ajouter, de modifier ou de détruire des DXConnexions et des serveurs émetteurs. Les services de cette interface et leur comportement sont associés aux technologies DCOM et web.;
Accès Source
Le serveur DX contient un composant d’accès source qui souscrit à la donnée source. Le serveur DX peut gérer l’accès à plus d’un type de serveur source.
Comportement à l’exécution
Le serveur DX contient un composant « comportement à l’exécution » qui copie la donnée reçue de la source vers la destination. Les règles utilisées pour régir la connexion au serveur émetteur permet au client d’invalider la souscription, et de définir comment le serveur DX doit se comporter lors d’erreur de souscription. Grâce aux règles de mise à jour de la destination, le client peut interdire la mise à jour, forcer manuellement la valeur à écrire, et définir une valeur par défaut lorsque la source n’est pas disponible.
Supervision et contrôle
Le serveur DX contient des objets DA définis précisément pour le contrôle et la supervision du serveur DX, des serveurs émetteurs et de chaque DXConnexion. Ces objets sont accessibles au travers de l’interface OPC DA du serveur DX. Référez-vous à la norme OPC DA pour plus de détails.
La figure 4 ci-dessous illustre ce modèle comportemental.
[fig. 4] – Légende – Modèle du serveur DX
En conséquence, le serveur DX exécute trois fonctions principales
1. Dans un rôle de serveur OPC DA, le serveur DX présente au client des interfaces conformes à OPC DA pour que celui-ci manipule les données, lesquelles peuvent provenir d’autres serveurs OPC, de capteurs ou d’autres sources auxquelles le serveur est relié.
2. Dans le rôle de serveur OPC DX, le serveur OPC DX fournit au client des interfaces pour créer, modifier ou détruire des DXConnexions.
3. Dans le rôle de lecteur de données, le serveur DX examine chaque DXConnexion afin de déterminer s’il peut lire ou non l’objet source spécifié. Le cas échéant, il accède au serveur émetteur pour lire la valeur de l’objet source, comme défini par la DXConnexion. Par exemple, le serveur DX organise les DXConnexions en groupes d’accès lorsqu’il a affaire à des serveurs émetteurs OPC DA qui utilisent DCOM.
Échange de données OPC sécurisé
Les serveurs OPC DX sont essentiellement des clients OPC d’accès données configurables, avec des extensions qui améliorent la fiabilité.
Par conséquent, un serveur OPC DX devrait suivre les principes de sécurité, tels qu’ils ont été définis dans le OPC Security Custom Interface, version 1.0 du 17 octobre 2000. Au fur et à mesure de la publication de nouvelles versions de la norme OPC Security Specification, la norme OPC Data eXchange se verra mise à jour pour prendre en compte les nouvelles fonctions introduites.
La base de données DX
Le serveur DX utilise une partie dédié de son espace d’adressage pour les objets DX, comme illustré par la figure 5. Cet espace réservé représente la base de données DX. Toutes les branches et les nœuds se trouvant à l’intérieur de cet espace sont des objets OPC DA, qui peuvent donc être manipulés au travers de primitives OPC DA.
De fait, chaque objet possède un nom de nœud utilisé pour l’accès, et un ID d’objet DA qui identifie l’objet d’une manière univoque au sein du serveur DX. Les noms de nœuds sont ou bien standardisés par la présente norme, ou bien définis par le client. L’ID d’objet est propre au fabricant et g&ea
ute;néré par le serveur DX. Les serveurs OPC DA parcourent la base à la recherche du nom de nœud, puis appellent la méthode IOPCBrowseServerAddressSpace::GetItemID () en utilisant le nom de nœud ; l’ID d’objet retourné donne accès à l’objet.
[fig. 5] – Légende – Structure d’une branche DX
DXConnectionsRoot
Cet objet est une branche qui contient la définition des DXConnexions. Il est utilisé par un ou plusieurs client(s) pour définir les serveurs émetteurs et les DXConnexions. OPC DX permet à chaque client d’organiser ses propres DXConnexions dans une ou plusieurs sous-branche(s) de cette branche.
DXConnection
Chaque DXConnexion dans la base de données DX est représentée par une branche DXConnexion. Chacune de ces branches possède un nom particulier qui peut figurer dans un ou plusieurs chemin(s) de la base, selon ce que les clients ont défini. Le chemin d’accès (browse path) désigne les branches situées entre la branche DXConnectionRoot et la DXConnexion. On l’appelle Nom de DXConnexion, il est unique à l’intérieur de la branche qui contient la DXConnexion.
Les clients identifient les objets DXConnexion grâce à leur Data Type ID ( value = DXConnextion).
Chaque DXConnexion est en relation univoque avec son objet cible. Chaque DXConnexion ne peut posséder qu’un objet cible, et ce dernier à son tour ne peut être référencé que par une seule DXConnexion.
Chaque DXConnexion contient des variables de configuration utilisées par les clients pour définir le transfert de données assuré par la DXConnexion. Ces variables ne sont modifiables qu’au travers de services, et ne peuvent être écrits en utilisant OPC DA.
Les variables de configuration peuvent néanmoins être lues (lecture seule) au travers d’OPC DA. Les clients de supervision peuvent souscrire à la DXConnexion pour recevoir un message lorsque la variable version de la DXConnexion change.
Services de configuration OPC DX
Il est possible de définir un ensemble de services OPC DX abstraits pouvant être utilisés simultanément par plusieurs clients pour gérer la base de données DX.
Le serveur DX traite les requêtes de service individuellement en ordre chronologique, mettant à jour la base de données DX et les variables d’exécution si nécessaire. Il répond également aux requêtes, si besoin est. Il n’attend pas que les modifications soient effectives, ni que les changements soient confirmés avant de répondre. Quand une requête entraîne un changement dans la base, celui-ci est visible immédiatement par les clients DA et DX ; la même chose vaut pour les variables d’exécution.
Par exemple, si le serveur DX reçoit une requête valable en vue de créer une DXConnexion dont la variable DefaultSourceItemConnected est positionnée à VRAI, le serveur DX ajoute la DXConnexion dans la base, répond, puis créée et initialise les variables d’exécution. Après avoir répondu, le serveur DX termine la souscription à l’objet source, puis commence le transfert de données, en mettant à jour les variables d’état.
Ce modèle comportemental permet aux clients de gérer la base de données indépendamment de l’état des serveurs émetteurs. C’est-à-dire que le comportement du serveur DX est identique, qu’ils fonctionnent ou pas. Les clients gèrent la base au travers des services définis dans cette section, puis observent le déroulement des DXConnexions au travers des interfaces DA.
Vincent Habchi
Guy Fages
J28p4247
OPC DX introduit la notion de serveur OPC DX
La fin du premier trimestre 2003 a vu l’arrivée de la version 1 des spécifications d’OC DX. Enfin, diront certains. Cent vingt deux pages auront été nécessaires pour mettre à plat les réunions des OPC-travailleurs.
Voici en exclusivité un large extrait de ces spécifications.
Concepts fondamentaux
Avant la création de OPC, il existait pléthore de normes destinées à transférer des données depuis ou vers les automates. Ces normes étaient typiquement adaptées à des techniques d’entrées-sorties et à des bus conçus pour des environnements particuliers. Les logiciels obligés de collecter des données depuis une variété de capteurs de terrain devaient donc incorporer le code propre à chacun de ces protocoles. Faire dialoguer deux boîtiers réalisés en technologie différentes nécessitait souvent l’utilisation d’un pont d’interface.
OPC DA améliora cette situation par la définition d’un standard d’accès aux données unifié permettant – aux yeux de l’application cliente – une uniformisation des protocoles matériels. OPC DA standardisa donc l’échange de données vertical entre boîtiers terrain et les applications de contrôle, comme illustré en figure 1.
[Fig 1] – Légende – Intégration verticale d’OPC DA
Cependant, OPC DA ne définissait aucun protocole pour l’échange de données directement entre serveurs. C’est ainsi que de nombreux fabricants proposèrent des boîtiers de dialogue, mais, faute de norme, ces derniers disposaient chacun de leur méthode de configuration particulière.
La norme OPC DX répond à ce problème : elle introduit la notion de serveur OPC DX, c’est-à-dire de boîtier capable de transférer d’une façon fiable des données en provenance ou à destination d’un autre serveur OPC DX. De surcroît, la norme définit également des méthodes banalisées pour configurer ces serveurs depuis une application cliente, en vue d’assurer ces transferts horizontaux. La figure 2 représente ces concepts.
[Fig 2] – Légende – Intégration horizontale d’OPC DX
Généralités sur l’architecture
Modèle systémique
OPC DX normalise les transferts horizontaux non critiques depuis un serveur OPC DX ou DA vers un serveur OPC DX. Ce dernier contient l’objet DA destinataire, alors que le premier contient l’objet DA expéditeur.
OPC DX définit le transfert source – destination comme une DXConnexion. Une DXConnexion se représente comme un objet OPC DA en lecture seule. Les DXConnexions se configurent au travers d’un client OPC DX en utilisant des services OPC DX dédiés.
OPC DX définit également des objets OPC DA dérivés que les clients peuvent utiliser pour superviser des DXConnexions en utilisant des interfaces OPC DA. La figure 3 représente une architecture OPC DA.
[Fig 3] – Légende – Architecture DX
Parcourir les objets source et la base de données DX
Les clients de configuration peuvent accéder, au travers d’interfaces OPC DA, aux clients OPC DA ou DX à la recherche des objets source et/ou destination qu’ils gèrent. Les objets destinataires ne peuvent se trouver que dans des serveurs OPC DX, alors que les objets émetteurs peuvent être gérés par des serveurs OPC DA ou DX, y compris le serveur destinataire lui-même.
Le client de configuration choisit les objets source et destination, et les utilise pour créer sa DXConnexion. Cette dernière se définit en termes d’objet source, destination, type de transfert ainsi que d’autres paramètres descriptifs.
Le serveur DX enregistre les DXConnexions dans une base de données DX située dans son champ d’adressage OPC DA. Le serveur DX *sauvegarde* périodiquement sa base de donnée DX en cas de réinitialisation.
Les clients OPC DA peuvent parcourir la base de données DX du serveur DX en utilisant l’interface de consultation OPC DA. Le serveur DX permet aux clients de définir la structure de consultation des DXConnexions grâce au concept de browse path.
Le browse path définit le chemin utilisé pour accéder à la DX Connexion lors de la consultation de la base de données DX. Les branches du browse path représentent des groupes logiques de DXconnexions. Les clients peuvent décider de pointer vers une DXConnexion par plus d’un browse path, ce qui permet à la DXConnexion d’appartenir à plusieurs groupes logiques.
Quoique cela ne soit pas dessiné dans la figure 3, la base de données DX contient également une liste des serveurs émetteurs, lesquels sont des serveurs contenant un ou plusieurs objets émetteurs. Chaque entrée de la base contient la description d’un serveur émetteur, de type DA ou DX, plus le type de protocole (ex. : DA 2.05) mis en oeuvre pour y accéder.
Configuration
Les services OPC DX dédiés peuvent être utilisés concomitamment par les clients de configuration pour configurer et gérer les enregistrements des DXConnexions et des serveurs émetteurs dans la base de données DX.
Les clients peuvent avoir recours à ces services pour modifier les serveurs sources, les DXConnexions ou les browse path. Toute modification apportée à l’un de ces derniers se répercute automatiquement sur toutes les DXConnexions accessibles en suivant celui-ci.
Les DXConnexions et les serveurs émetteurs sont protégés par un attribut de version. Quand un client ajoute ou modifie une DXConnexion, celle-ci se voit attribuer un identifiant unique appelé version. Les clients qui veulent modifier ou détruire cette DXConnexion, doivent communiquer la version correcte, faute de quoi le serveur rejette leur demande.
Les DXConnexions et les serveurs émetteurs deviennent actifs dès leur création par un client, que celui-ci reste ou non connecté au serveur DX. Ils cessent d’exister lorsqu’ils sont explicitement détruits par un client.
Une branche de browse path se créé automatiquement lorsque la première DXConnexion qui l’utilise est initialisée. Elle ne sera effacée que lors de la destruction de la dernière DXConnexion qui l’utilise. Les clients peuvent effacer une branche, ce qui détruit automatiquement toutes les DXConnexions actives qui en dépendent.
Cependant, les DXConnexions et les serveurs émetteurs contiennent des attributs par défaut qui autorisent ou interdisent les transferts de données lorsqu’ils deviennent actifs. Quand un serveur émetteur est invalidé, aucun serveur DX ne peut établir de transfert avec lui, et aucune DXConnexion n’est possible.
Transfert horizontal de données
Une fois qu’une DXConnexion est définie et prête à transférer des données, le serveur DX accède au serveur émetteur pour connaître la valeur de son objet source. Le serveur DX met à jour l’objet destinataire après avoir effectué les conversions, transformations, substitutions ou forçage adéquats.
Le déroulement de la DXConnexion comprend les actions de configuration, les cas de rupture de connexion, de gestion d’erreur, de conversion au vol, et de forçage manuel.
Contrôle et gestion
OPC DX définit un ensemble d’attributs accessibles par OPC DA qui permettent aux clients OPC DA de contrôler le transfert de données en différents points de son parcours. Ces attributs autorisent :
· La connexion/déconnexion de l’objet source
· La validation ou l’invalidation de la mise à jour du destinataire
· La définition de valeurs par défaut lorsque la source est inaccessible
· La définition des valeurs de forçage
· L’utilisation ou non du forçage
OPC DX inclut des services grâce auxquels un client peut enregistrer un ensemble de valeurs d’attributs comme jeu par défaut, puis de rétablir cette configuration par défaut si nécessaire.
Les attributs suivants concernent les branches de browse path :
· Connexion/déconnexion de la source
· Autorisation/interdiction de la mise à jour du destinataire
· Utilisation ou non du forçage
Quand ces attributs sont appliqués sur une branche, ils concernent toutes les DXConnexions qui en dépendent. Par exemple, si un client décide de déconnecter une branche de sa source, toutes les DXConnexions se déconnectent aussi. Comme celles-ci peuvent se reconnecter individuellement, la lecture de la valeur de ces attributs par un client n’est pas significative. Aussi, la norme les définit en écriture seule.
La norme définit aussi un attribut connexe concernant les serveurs émetteurs, qui autorise ou interdit leur connexion à un serveur DX. Lorsque cet attribut passe en l’état interdit, toutes les DXConnexions établies avec un objet source de ce serveur cessent de fonctionner, jusqu’à ce que l’attribut repasse en état autorisé.
OPC DX inclut également un attribut des DXConnexions qui permet aux clients OPC DA de superviser les transferts de données. Les clients OPC DA qui le désirent lisent ou souscrivent à ces attributs, en plus des attributs de configuration, afin d’observer l’état des DXConnexions.
Modèle serveur
Le serveur DX représente une extension d’un serveur totalement compatible à OPC DA, conformément à l’une des normes OPC DA. Le serveur OPC DA sous-jacent permet la supervision et le contrôle de la base de données DX. La technologie de l’interface utilisée par le serveur OPC DA sous-jacent (DCOM et/ou web) est utilisée par les services de configuration du serveur DX. Les composants qui supervisent ou configurent le serveur DX doivent utiliser les mêmes technologies d’interface que le serveur OPC DA sous-jacent. Le serveur DX fournit en sus :
Base de données DX
Le serveur DX exploite une base de données DX dans son espace d’adressage qui contient la description du serveur DX, des DXConnexions et des serveurs sources ;
Interface de configuration
Cette interface permet d’ajouter, de modifier ou de détruire des DXConnexions et des serveurs émetteurs. Les services de cette interface et leur comportement sont associés aux technologies DCOM et web.;
Accès Source
Le serveur DX contient un composant d’accès source qui souscrit à la donnée source. Le serveur DX peut gérer l’accès à plus d’un type de serveur source.
Comportement à l’exécution
Le serveur DX contient un composant « comportement à l’exécution » qui copie la donnée reçue de la source vers la destination. Les règles utilisées pour régir la connexion au serveur émetteur permet au client d’invalider la souscription, et de définir comment le serveur DX doit se comporter lors d’erreur de souscription. Grâce aux règles de mise à jour de la destination, le client peut interdire la mise à jour, forcer manuellement la valeur à écrire, et définir une valeur par défaut lorsque la source n’est pas disponible.
Supervision et contrôle
Le serveur DX contient des objets DA définis précisément pour le contrôle et la supervision du serveur DX, des serveurs émetteurs et de chaque DXConnexion. Ces objets sont accessibles au travers de l’interface OPC DA du serveur DX. Référez-vous à la norme OPC DA pour plus de détails.
La figure 4 ci-dessous illustre ce modèle comportemental.
[fig. 4] – Légende – Modèle du serveur DX
En conséquence, le serveur DX exécute trois fonctions principales
1. Dans un rôle de serveur OPC DA, le serveur DX présente au client des interfaces conformes à OPC DA pour que celui-ci manipule les données, lesquelles peuvent provenir d’autres serveurs OPC, de capteurs ou d’autres sources auxquelles le serveur est relié.
2. Dans le rôle de serveur OPC DX, le serveur OPC DX fournit au client des interfaces pour créer, modifier ou détruire des DXConnexions.
3. Dans le rôle de lecteur de données, le serveur DX examine chaque DXConnexion afin de déterminer s’il peut lire ou non l’objet source spécifié. Le cas échéant, il accède au serveur émetteur pour lire la valeur de l’objet source, comme défini par la DXConnexion. Par exemple, le serveur DX organise les DXConnexions en groupes d’accès lorsqu’il a affaire à des serveurs émetteurs OPC DA qui utilisent DCOM.
Échange de données OPC sécurisé
Les serveurs OPC DX sont essentiellement des clients OPC d’accès données configurables, avec des extensions qui améliorent la fiabilité.
Par conséquent, un serveur OPC DX devrait suivre les principes de sécurité, tels qu’ils ont été définis dans le OPC Security Custom Interface, version 1.0 du 17 octobre 2000. Au fur et à mesure de la publication de nouvelles versions de la norme OPC Security Specification, la norme OPC Data eXchange se verra mise à jour pour prendre en compte les nouvelles fonctions introduites.
La base de données DX
Le serveur DX utilise une partie dédié de son espace d’adressage pour les objets DX, comme illustré par la figure 5. Cet espace réservé représente la base de données DX. Toutes les branches et les nœuds se trouvant à l’intérieur de cet espace sont des objets OPC DA, qui peuvent donc être manipulés au travers de primitives OPC DA.
De fait, chaque objet possède un nom de nœud utilisé pour l’accès, et un ID d’objet DA qui identifie l’objet d’une manière univoque au sein du serveur DX. Les noms de nœuds sont ou bien standardisés par la présente norme, ou bien définis par le client. L’ID d’objet est propre au fabricant et g&ea
ute;néré par le serveur DX. Les serveurs OPC DA parcourent la base à la recherche du nom de nœud, puis appellent la méthode IOPCBrowseServerAddressSpace::GetItemID () en utilisant le nom de nœud ; l’ID d’objet retourné donne accès à l’objet.
[fig. 5] – Légende – Structure d’une branche DX
DXConnectionsRoot
Cet objet est une branche qui contient la définition des DXConnexions. Il est utilisé par un ou plusieurs client(s) pour définir les serveurs émetteurs et les DXConnexions. OPC DX permet à chaque client d’organiser ses propres DXConnexions dans une ou plusieurs sous-branche(s) de cette branche.
DXConnection
Chaque DXConnexion dans la base de données DX est représentée par une branche DXConnexion. Chacune de ces branches possède un nom particulier qui peut figurer dans un ou plusieurs chemin(s) de la base, selon ce que les clients ont défini. Le chemin d’accès (browse path) désigne les branches situées entre la branche DXConnectionRoot et la DXConnexion. On l’appelle Nom de DXConnexion, il est unique à l’intérieur de la branche qui contient la DXConnexion.
Les clients identifient les objets DXConnexion grâce à leur Data Type ID ( value = DXConnextion).
Chaque DXConnexion est en relation univoque avec son objet cible. Chaque DXConnexion ne peut posséder qu’un objet cible, et ce dernier à son tour ne peut être référencé que par une seule DXConnexion.
Chaque DXConnexion contient des variables de configuration utilisées par les clients pour définir le transfert de données assuré par la DXConnexion. Ces variables ne sont modifiables qu’au travers de services, et ne peuvent être écrits en utilisant OPC DA.
Les variables de configuration peuvent néanmoins être lues (lecture seule) au travers d’OPC DA. Les clients de supervision peuvent souscrire à la DXConnexion pour recevoir un message lorsque la variable version de la DXConnexion change.
Services de configuration OPC DX
Il est possible de définir un ensemble de services OPC DX abstraits pouvant être utilisés simultanément par plusieurs clients pour gérer la base de données DX.
Le serveur DX traite les requêtes de service individuellement en ordre chronologique, mettant à jour la base de données DX et les variables d’exécution si nécessaire. Il répond également aux requêtes, si besoin est. Il n’attend pas que les modifications soient effectives, ni que les changements soient confirmés avant de répondre. Quand une requête entraîne un changement dans la base, celui-ci est visible immédiatement par les clients DA et DX ; la même chose vaut pour les variables d’exécution.
Par exemple, si le serveur DX reçoit une requête valable en vue de créer une DXConnexion dont la variable DefaultSourceItemConnected est positionnée à VRAI, le serveur DX ajoute la DXConnexion dans la base, répond, puis créée et initialise les variables d’exécution. Après avoir répondu, le serveur DX termine la souscription à l’objet source, puis commence le transfert de données, en mettant à jour les variables d’état.
Ce modèle comportemental permet aux clients de gérer la base de données indépendamment de l’état des serveurs émetteurs. C’est-à-dire que le comportement du serveur DX est identique, qu’ils fonctionnent ou pas. Les clients gèrent la base au travers des services définis dans cette section, puis observent le déroulement des DXConnexions au travers des interfaces DA.
Vincent Habchi
Guy Fages
