Serveur OPC

Transcription

Serveur OPC

electrical & safety · industrial connectivty · software & electronics · advanced connectivity
Woodhead
Serveur OPC
applicom® 3.7
un produit Woodhead Software & Electronics
Opc.doc
Copyright © 2003 Woodhead Software & Electronics. Tous droits réservés.
http://www.applicom-int.com
04/09/2003
Woodhead
Opc.doc
04/09/2003
®
TM
TM
Copyright © 2003 Woodhead Software & Electronics. Tous droits réservés. Tous les produits applicom , Direct-Link , RJ-Lnxx ,
TM
SST sont des marques déposées de Woodhead Software & Electronics. Tous les autres noms de produits sont des marques
déposées de leurs fabricants respectifs.
http://www.applicom-int.com
Woodhead
Table des matières
1.
Présentation du serveur OPC .......................................................3
Contexte d'utilisation du serveur OPC ....................................................................3
Démarrage du serveur OPC (local et distant) .........................................................5
Interface graphique du serveur OPC ......................................................................6
2.
Paramétrage du serveur OPC .......................................................7
Paramètres de base ................................................................................................7
Mode de paramétrage 'expert' ................................................................................7
3.
Principe d’accès aux données......................................................8
Le ProgID ................................................................................................................9
Le browsing des ItemID.........................................................................................10
Gestion des groupes (OPC Group).......................................................................11
Mode d'accès aux données du serveur OPC........................................................13
Horodatage des données ......................................................................................14
Qualité des items...................................................................................................14
Limitation du nombre d’I/O Items (SW1000ETH seulement) ................................15
Types de topic d’accès aux variables ...................................................................17
Configuration des topics........................................................................................18
4.
Accès aux Variables images ou locales ....................................19
Paramètrage minimal d’un topic "variable image" ou "variable locale".................21
Syntaxes des variables internes ...........................................................................21
Accès aux variables unitaires................................................................................24
Optimisation des requêtes synchrones et asynchrones .......................................24
Utilisation du mode tableau ...................................................................................25
Utilisation du mode message ................................................................................26
Bit de mots ............................................................................................................27
Suffixe optionnels ..................................................................................................28
Descripteur standard pour l’accès à la data-base.................................................29
Descripteur standard d’accès aux variables images.............................................31
Information de diagnostics et contrôle ..................................................................32
Les noms symboliques..........................................................................................34
5.
Accès aux Variables images d’un contrôleur Logix 5000 ........37
Paramétrage d’un topic "variable image" d’un contrôleur Logix 5000 ..................37
Syntaxes des variables internes ...........................................................................38
Optimisation des requêtes synchrones et asynchrones .......................................38
Limitations .............................................................................................................39
Information de diagnostics et contrôle ..................................................................39
6.
Accès aux paramètres des fonctions cycliques .......................41
Contrôle des fonctions cycliques de PCCYC ........................................................41
Items liés à un topic "fonction cyclique" ................................................................42
7.
Accès aux informations générales du serveur (Topic
"SYSTEME") ..................................................................................................45
Serveur OPC
•i•
Table des matières
Woodhead
8.
Accès au WatchDog et à l’entrée TOR (Topics "CARDx") .......46
9.
Accès aux signaux modems (Topic "CHANx") .........................47
10.
Interface de Diagnostic ...............................................................48
Les requêtes de communication ...........................................................................50
Optimisation de la communication ........................................................................50
Vue d'espionnage des items .................................................................................51
Vue des messages................................................................................................53
11.
Développement d'un client OPC.................................................54
Contextes de développement ...............................................................................54
Développement d'un client en C et C++ ...............................................................55
Informations nécessaires au développement .......................................................59
12.
Serveur OPC
Index .............................................................................................62
• ii •
Table des matières
Woodhead
1.
Présentation du serveur OPC
Contexte d'utilisation du serveur OPC
Le package applicom® inclut des interfaces logicielles de haut niveau, permettant de rendre
totalement transparent pour l’utilisateur l’accès aux données. Ces interfaces logicielles permettent à
des applicatifs "client" de manipuler les données mises à disposition par applicom® sans se soucier
de la gestion d’accès vers les interfaces applicom (ou vers l’émulateur) et de l’optimisation de la
communication.
OPC : Qu'est ce que c'est?
OPC est un standard de communication basé sur la technologie OLE/COM. Cette dernière
constitue le moyen d’échange d’informations préconisé par Microsoft entre applications MSWindows. Le modèle COM est destiné à assurer une interopérabilité entre des composants
logiciels développés de manière indépendante par des éditeurs distincts. Cette interopérabilité est
indépendante des langages de développement utilisés. COM peut être considéré comme un “bus
logiciel” assurant un rôle de “Plug And Play” entre des modules logiciels.
OPC n’est en fait que la spécification d’un standard. Celui-ci décrit l’ensemble des objets et de
leurs interfaces que tout “serveur OPC” devra implémenter de façon à assurer une plus grande
interopérabilité entre des applications de contrôle/commande/supervision, des équipements
industriels (API, capteurs, actionneurs) et des applications bureautiques de gestion. Pour plus
d’informations sur les spécifications OPC vous pouvez consulter le site de la fondation OPC
http://www.opcfoundation.org.
Serveur OPC
•3•
Woodhead
Le serveur OPC
Le serveur OPC applicom® est une application ("APP_OPC.EXE") pouvant s’exécuter sous les
environnements Windows 32 bits et jouant le rôle de serveur de données industrielles auprès de
toute application cliente OPC compatible avec les spécifications Custom Data Access 1.0A et 2.0.5
Il est donc aisément utilisable à partir de tout logiciel intégrant de base une interface client OPC :
progiciels de supervision,…
ActiveX de communication applicom®
mais également à partir de développements spécifiques
applications écrites en C ou C++
Le serveur OPC peut être utilisé localement (depuis une application cliente située sur la même
machine) ou à distance à travers DCOM (depuis une application cliente située sur une autre
machine connectée par le réseau).
Le serveur OPC fonctionne avec tous les protocoles supportés sur les solutions applicom®,
exceptés Batibus et 3964 en messagerie libre.
Dans le cas des kits de développement, certaines limitations liées à la nature de votre protocole
peuvent intervenir. Nous consulter.
Note : Le serveur OPC applicom® ne peut pas fonctionner simultanément avec le serveur
DDE/Suitelink applicom®. Mais il peut cohabiter avec une application utilisant l'interface librairie
applicom® "APPLICOM.DLL".
Voir également:
Dans ce manuel
Développement d'un client OPC
Dans la base de connaissance
Introduction à DCOM avec un serveur OPC
Serveur OPC
•4•
Woodhead
Démarrage du serveur OPC (local et distant)
Le démarrage du serveur OPC ne nécessite aucune intervention manuelle sur le poste où est
localisé le serveur. En effet, la technologie COM sous-jacente automatise le lancement lors de la
première demande d'une application cliente.
Si le serveur est un serveur local, aucune configuration préalable du système n'est
nécessaire. (sauf si le client est un service - voir Client OPC sous forme de service)
Si le serveur est un serveur distant (utilisé à travers DCOM), l’installation de certains
composants sera nécessaire sur le poste client. De plus, une configuration préalable du
système devra être effectuée aussi bien sur le poste client que sur le poste serveur (voir
Introduction à DCOM avec un serveur OPC)
Les composants nécessaires pourront être installés :
Soit en effectuant une installation complète du produit applicom sur le poste client
Soit en installant le produit applicom Communication ActiveX Control
Voir également:
Dans la base de connaissances
Introduction à DCOM avec un serveur OPC
Client OPC sous forme de service
Serveur OPC
•5•
Woodhead
Interface graphique du serveur OPC
Par défaut, le serveur OPC applicom® ne possède pas d’interface graphique. Après son
lancement, la présence du serveur est matérialisée par une icône insérée dans la barre de tâches
(si les critères de sécurité DCOM le permettent). Par défaut cette icône ne possède pas de menu
contextuel. Cependant, celui-ci peut être activé à partir de la boîte de configuration des paramètres
OPC, en validant l'option autoriser la vue de diagnostic du serveur. Ce menu vous permet alors,
par clic droit de la souris :
d’afficher l’environnement de diagnostic (Menu Diagnostic).
de fermer le serveur (Menu Quitter)
Voir également:
Dans ce manuel
Interface de Diagnostic
Paramètres de base
Dans la base de connaissance
Client OPC sous forme de service
Serveur OPC
•6•
Woodhead
2.
Paramétrage du serveur OPC
Paramètres de base
Tout le paramétrage nécessaire à l’utilisation du serveur OPC est réalisé à partir de la console
applicom®, dans la vue de description de la configuration.
Attention : ces paramètres sont pris en compte au démarrage du serveur OPC. Toute modification
devra donc donner lieu à un redémarrage de ce dernier.
Voir également :
dans la documentation :
Configuration : Paramètres du serveur OPC
Mode de paramétrage 'expert'
Un mode expert de paramétrage du serveur OPC devient disponible au sein de la console
applicom® lorsque cette dernière est elle-même commutée en mode expert (voir renvoi
"Commande globale du menu Fichier"). Ce mode n'est utile que dans des cas précis tels que la
nécessité :
d'utiliser des fonctionnalités avancées et non courantes du produit
de modifier certains facteurs de temps
L'utilisation de ce mode de paramétrage devrait normalement être conditionnée par l'intervention de
notre support technique. Certains des paramètres pourraient en effet avoir de lourdes
conséquences s'ils venaient à être mal positionnés. Cependant, certaines des fonctionnalités
avancées sont documentées dans la Base de connaissance (voir renvois).
Voir également :
dans la documentation :
Configuration : Paramètres du serveur OPC
Mise en œuvre : Commande globale du menu Fichier
dans la base de connaissance :
Validation et dévalidation du mode diagnostic
Serveur OPC
•7•
Woodhead
3.
Principe d’accès aux données
La spécification OPC prévoit que l'application cliente référence une variable à l'aide d'une chaîne
de caractères nommée ItemID. Dans le cas d’applicom®, cette chaîne est la concaténation :
du chemin du périphérique contenant la variable
A partir de la version 3.1 du produit applicom®, le chemin d’accès à la variable est représenté
par un topic. En fonction du type de variable visée, ce nom de topic correspondra à l’un des
topics configurés:
de type “variable image” pour un accès dans un équipement distant.
de type “variable locale” pour un accès à la zone de donnée partagée data-base
applicom®.
de type "fonction cyclique" pour le contrôle des fonctions cycliques. (
en Direct-Link )
Non supporté
Ou à l'un des topics prédéfinis:
le topic "SYSTEME" permettant d'accéder à des informations générales du serveur.
les topics "CARDx" (x de 1 à 8) permettant de piloter le watchdog et l'entréee TOR
d'une interface applicom® particulière. ( Non supporté en Direct-Link )
les topics "CHANx" (x de 0 à 31) permettant de piloter les signaux modem d'un canal
particulier. ( Non supporté en Direct-Link )
Serveur OPC
•8•
Woodhead
d’une syntaxe désignant la nature et l’adresse de la variable
Pour les topics de type “variable image” ou “variable locale”, un item est le plus souvent un
élément de mémoire de type bit, octet, mot, flottant IEEE, message ASCII, etc... Cependant, le
serveur OPC met aussi à votre disposition certains items réservés, utilisables uniquement
avec ces types de topic.
Pour les topics de type "fonction cyclique"( Non supporté en Direct-Link ), un Item est
représentatif d'un paramètre de la fonction cyclique correspondant au topic.
A chaque topic "prédéfini", sont associés des items spécifiques.
Remarques :
Dans la chaîne référençant l’item, le délimiteur de champs par défaut est le point “.”. En
cas de besoin, ce délimiteur peut être modifié dans le paramétrage du serveur OPC,
La spécification OPC prévoit également la possibilité pour un client d'utiliser un
AccessPath. Le serveur applicom® ne nécessite pas de l'utiliser. Cependant, si celui-ci n'est
pas vide, il sera concaténé avec la chaîne ItemID fournie par le client pour fabriquer l'ItemID
utilisé par le serveur. Par exemple, si le client fournit comme AccessPath la chaîne "TOPIC" et
comme itemID la chaîne "ITEM" le serveur utilisera la chaîne TOPIC.ITEM comme ItemID.
Une compatibilité avec les versions précédentes est assurée :
Pour accéder à des variables locales, le chemin pourra donc être de la forme :
- Card1.Database
Pour accéder à des variables images, le chemin pourra être de la forme :
- Card1.Channel0.EquipmentZ
Z représentant le numéro de l’équipement (configuré dans la console applicom de 0 à 255)
Voir également :
dans ce manuel :
Limitation du nombre d’I/O Items (SW1000ETH seulement)
Types de topic d’accès aux variables
Configuration des topics
Le ProgID
Lorsque vous êtes utilisateur d’un progiciel, lui-même client OPC, le serveur OPC applicom® est
identifié dans celui-ci à l’aide de son ProgID (identificateur de programme) :
ProgID
Serveur OPC
“APPLICOM.OPCServer.1” ;
•9•
Woodhead
Le browsing des ItemID
Le serveur OPC applicom® supporte les capacités optionnelles de browsing (interface
IOPCBrowseServerAddressSpace). Elles permettent aux applications clientes d'effectuer une
recherche parmi les items disponibles de l'espace d'adressage du serveur OPC en fournissant une
liste classée d'itemID valides.
L’application client peut utiliser le browser de la façon suivante :
"OnLine" si la solution applicom est initialisée.
"OffLine" si la solution applicom n'est pas initialisée. Dans ce cas, le serveur OPC
reprend la configuration que le client a défini dans la console applicom et considère cette
configuration comme son espace d’adressage.
Attention : Pour les topics associés à des équipements de type « Logix5000 – Messagerie
Logix5000 (OPC seulement) », aucune syntaxe liée au contrôleur Logix5000 ne sera
retournée par le browser en mode OffLine.
Serveur OPC
• 10 •
Woodhead
Gestion des groupes (OPC Group)
Les groupes constituent pour le client un moyen simple d’organisation des données auxquelles il
souhaite accéder. Cette organisation est laissée entièrement libre pour le client. Par conséquent,
un groupe peut contenir des variables totalement hétérogènes collectées sur des équipements
différents.
Lorsque vous êtes utilisateur d’un progiciel, lui-même client OPC, celui-ci gère généralement les
groupes de données de façon totalement transparente et cachée pour l'utilisateur. Si ce n'est pas le
cas, des éléments importants sont cependant à prendre en compte dans la création des groupes :
c’est au niveau du groupe que le client a la possibilité de régler la période de
rafraîchissement. Toutes les données (OPC Items) contenues dans un même groupe sont
donc impérativement scrutées par le serveur OPC à la même fréquence.
le client a la possibilité d’activer ou de désactiver un groupe, c’est à dire d’autoriser ou
d’interdire les remontées de données événementielles sur l’ensemble des données du groupe.
la gestion de la bande morte, telle qu'elle est prévue par la spécification OPC, s’effectue
au niveau du groupe.
Attention :
Certains logiciels client fixent la période de rafraîchissement du groupe à 0 (retour des informations
au plus vite). Il se peut dans certains cas (par exemple lorsque de grandes quantités de points
bougent simultanément ou lors de l'utilisation en DCOM), qu’une période très faible dégrade les
performances du système en raison de l’importance du flux d’informations circulant entre le serveur
et le client. Il est possible de modifier de façon externe la période minimale du rafraîchissement de
tous les groupes en modifiant le champ Période de rafraîchissement minimale des groupes.
Serveur OPC
• 11 •
Woodhead
Bande morte
Le client a la possibilité de spécifier pour un groupe une “bande morte” qui affectera l’ensemble des
items contenus dans le groupe. Ce paramètre indique le pourcentage minimum d’évolution qui
provoquera l’envoi de la donnée vers l’application client. Il est apparu que tous les clients OPC ne
positionne pas ce paramètre de la même façon. C’est pourquoi le serveur OPC applicom® permet
par configuration de définir la plage utilisé. Il peut donc être compris selon ce choix entre :
0 et 100 (1% =1).
Ou entre 0 et 1 (1% = 0.01).
Cette “bande morte” influence uniquement le mode de remontée événementielle de données
La notion même de “bande morte” nécessite que la variable visée soit du type analogique et qu’elle
possède une valeur maximale et une valeur minimale permettant de calculer un pourcentage
d’évolution. La remontée de la donnée vers l’application client sera effectuée si :
valeur absolue(dernière valeur remontée- valeur courante) > pPercentDeadband *(valeur maxvaleur min)
La valeur min et valeur max d’une donnée est fixe, elle est définie par son type :
VT_UI1
de 0 à 255
VT_I1
de -128 à 127
VT_UI2
de 0 à 65535
VT_I2
de -32768 à 32767
VT_UI4
de 0 à 4294967295
VT_I4
de -2147483648 à 2147483647
VT_R4
de –3.4e+38 à 3.4e+38
VT_R8
De -1.79e+308 à 1.79e+308
Serveur OPC
• 12 •
Woodhead
Mode d'accès aux données du serveur OPC
Pour accéder aux données depuis un client OPC, la spécification prévoit trois méthodes :
Méthode
Commentaire
Evénementielle
Le client s'abonne sur un groupe afin d'être averti de façon
événementielle des changements intervenus sur les valeurs des
items. Seuls les points actifs du groupe ayant changé sont retournés
au client. La période de rafraîchissement du groupe fixe la durée
minimale entre deux envois de valeurs.
Synchrone
Le client demande explicitement la lecture ou l'écriture d'un item. Le
client reste bloqué pendant le traitement de sa demande. La lecture
synchrone peut s'effectuer depuis deux sources distinctes :
Le device : les valeurs sont lues dans l'équipement physique.
Le cache : les valeurs sont lues dans le cache interne du serveur
OPC.
Asynchrone
Le client demande explicitement la lecture ou l'écriture d'un item.
L'appel est non bloquant. Le résultat de la lecture ou de l'écriture
sera retourné ultérieurement. La lecture peut s'effectuer depuis deux
sources distinctes :
Le device : les valeurs sont lues dans l'équipement physique.
Le cache : les valeurs sont lues dans le cache interne du serveur
OPC.
Lorsque vous êtes utilisateur d’un progiciel, lui-même client OPC, celui-ci gère généralement le
mode d'accès aux données de façon totalement transparente et cachée pour l'utilisateur. Si ce n'est
pas le cas, des éléments importants sont cependant à prendre en compte :
Le mode événementiel génère un trafic minimum entre le serveur et le client puisque
seules les variables ayant bougé sont retournées. Il est donc le plus efficace des trois modes.
En mode asynchrone, si les demandes sont effectuées plus rapidement que ne peut les
traiter le serveur, elles sont empilées. Si trop de requêtes sont mises en attente, des
demandes peuvent être refusées.
Les lectures dans le cache sont par définition plus rapides que les lectures effectuées
dans l'équipement.
Serveur OPC
• 13 •
Woodhead
Horodatage des données
Avec le serveur OPC applicom®, l’horodatage d’une donnée indique le temps correspondant au
dernier accès à la variable par le serveur. Il n’indique pas le dernier changement de valeur mais la
dernière obtention de la valeur. Ainsi, si l’application client effectue deux lectures successives en
mode synchrone ou asynchrone sur une même variable, l’horodatage retourné pourra être différent
même si la valeur n’a pas changé. Par contre, cette variable ne sera pas envoyée au client par le
mode événementiel puisque la valeur n’a pas évolué.
Le serveur OPC optimise en dynamique l'acquisition des données en minimisant les accès aux
équipements distants :
une variable ne sera insérée que dans une seule trame de communication, même si cette
variable est demandée par le client au sein de plusieurs groupes (chaque groupe pouvant
être configuré avec des périodes de rafraîchissement différentes). Il en est de même si
plusieurs applications client demandent la même variable. La variable est alors rafraîchie
en tenant compte de la période minimale existante pour cette variable.
le serveur OPC regroupe toujours le maximum de variable dans une même trame de
communication. Une telle trame peut donc contenir des items appartenant à des groupes
possédant des périodes de rafraîchissement différentes. C'est la période minimale qui est
alors utilisée.
Dans les deux cas précédents, l'acquisition des données s'effectue avec la période la plus basse
de tous les items concernés. La valeur d'horodatage sera en conséquence mise à jour à la même
fréquence.
Qualité des items
A chaque item retourné vers le client sont associés une qualité et un horodatage.
Le tableau suivant indique les différentes qualités utilisées par le serveur OPC applicom® :
Qualité
Signification
Déc
Hexa
Bit
0
0x0000
0000 0000
La qualité du point est mauvaise. La valeur retournée n'est pas
exploitable.
20
0x0014
0001 0100
La qualité du point est mauvaise. La valeur retournée correspond à la
dernière valeur connue de bonne qualité.
24
0x0018
0001 1000
La donnée n'a pu être lue ou écrite suite à un problème de
communication entre les équipements et le serveur. La valeur de la
donnée retournée n'est pas exploitable.
64
0x0040
0100 0000
La qualité de la donnée est incertaine. La valeur retournée n'est pas
exploitable.
192
0x00C0
1100 0000
La donnée a été correctement lue et les conversions éventuelles ont pu
être effectuées.
Serveur OPC
• 14 •
Woodhead
En cas d’utilisation du produit SW1000ETH, en correspondance avec votre commande produit, une
limitation d’I/O Items utilisables par l’ensemble des applications clientes peut être appliquée.
Les I/O Items sont des items visant des équipements distants. Ainsi, les items sur la database
applicom, ou les items du topic SYSTEME ne sont pas considérés comme des I/O Items. Dans le
cas d’un item tableau, le nombre d’I/O Items est égal au nombre de données unitaire du tableau.
Dans le cas d’une chaîne, le nombre d’I/O Items comptabilisé est de 1.
Si la même variable physique est accédée par plusieurs applications clientes distinctes, un I/O item
est comptabilisé pour chaque client. Lorsque la limite est atteinte, l’ajout de nouveaux items
(AddItem) est refusé. Le décompte total est un décompte instantané. Une application peut donc
supprimer des I/O items pour en rajouter d’autres.
Des items du topic SYSTEME vous permettent de récupérer au niveau du client OPC les
indications importantes relatives à la limitation du nombre des I/O Items. Il s’agit des quatres items
suivants :
LIMIT_ALLOWED :
Nombre d’I/O Items maximum utilisables
Ce nombre est directement lié à la limitation réclamée lors du passage de votre
commande produit.
LIMIT_USED :
Nombre d’I/O Items instantané
Cet item vous permet d’accéder au nombre d’I/O Items utilisés à cet instant
donné.
LIMIT_MAX_USED :
Nombre d’I/O Items maximum
Cet item vous permet de connaître le nombre maximum atteint d’I/O Items utilisés
par le serveur OPC depuis son lancement.
LIMIT_OVERFLOW :
Avertissement d’atteinte de limitation
Cet item peut prendre 3 valeurs :
0 : Le nombre d’I/O Items maximum est resté inférieur à 90% de la limite
autorisée
1 : Le nombre d’I/O Items maximum à atteint 90% de la limite autorisée
2 : Le nombre d’I/O Items maximum à dépassé la limite autorisée. Des
I/O Items n’ont pu être ajoutés dans le serveur.
Serveur OPC
• 15 •
Woodhead
De plus, la barre d’état de la fenêtre de diagnostic d’OPC affiche les informations sur l’utilisation
des I/O Items et sur l’état des dépassements.
Si le nombre d’I/O Items maximum atteint est inférieur à 90% de la limite autorisée, la barre
d’état indique les informations de limitation sur un fond gris :
Si le nombre d’I/O Items maximum atteint est supérieur à 90% de la limite autorisée, la barre
d’état indique les informations de limitation sur un fond orange :
De plus, un message indiquant cet état est affiché dans la vue des messages.
Si le nombre d’I/O Items maximum atteint est supérieur à la limite autorisée, la barre d’état
indique les informations de limitation sur un fond rouge :
De plus, un message indiquant cet état est affiché dans la vue des messages.
Voir également :
dans ce manuel :
Accès aux informations générales du serveur (Topic "SYSTEME")
dans la base de connaissance :
Validation et dévalidation du mode Diagnostic
Serveur OPC
• 16 •
Woodhead
Types de topic d’accès aux variables
Le serveur OPC utilise un nom arbitraire appelé topic en tant que chemin d’accès aux variables.
Différents types de topics sont disponibles :
Les Topics “variable image” et “variable locale” :
L'utilisateur attribue par configuration un nom significatif à un équipement distant (variable
image) ou à la base de données des interfaces (ou de l’émulateur) applicom (variable
locale), et l'utilise en tant que topic pour accéder ensuite aux variables internes de celui-ci
(par ex. DATA_BASE, AUT1...). Le nombre de topics configurables n’est pas limité.
Vous pouvez définir plusieurs noms de topics pour un même équipement.
Le Topics “prédéfinis” :
Le serveur OPC reconnaît un certain nombre de topics prédéfinis :
le topic "SYSTEME", permettant d’accéder à des informations générales du
serveur
les topics "CARDx" (x de 1 à 8) permettant d’accéder à des fonctionnalités
ratachées à une interface applicom( Non supporté en Direct-Link )
les topics "CHANx" (x de 0 à 31) permettant d’accéder à des fonctionnalités
ratachées à un canal particulier ( Non supporté en Direct-Link )
Le Topics “Fonction cyclique” : (
Non supporté en Direct-Link )
L'utilisateur attribue par configuration un nom significatif à une fonction cyclique
configurée à l’aide de "PCCYC", et l’utilise en tant que topic pour accéder aux paramètres
de la fonction cyclique et pour modifier celle-ci à volonté.
Voir également:
Dans ce manuel :
Accès aux Variables images ou locales
Dans la documentation :
Fonctionnalité : Database
Serveur OPC
• 17 •
Woodhead
Le serveur OPC utilise un nom arbitraire appelé topic en tant que chemin d’accès aux variables. La
configuration de ces topics s’opère à partir de la console applicom.
Vous pouvez accéder à la configuration de tous les topics (variable image, variable locale, fonction
cyclique) à partir de la vue description de la configuration, en utilisant les nœuds Topic
configuration.
Pour configurer le topic attribué à un équipement connecté au réseau de terrain (variable image),
vous pouvez également :
Sélectionner le nœud Topic configuration directement situé sous l’équipement concerné
dans la zone vue protocole de la console applicom.
Lancer la commande Propriétés ou double-cliquez sur le nœud.
La configuration des topics vous permettra de modifier notamment le nom du topic, le commentaire
associé ainsi que des paramètres avancés tel que les longueurs maximum des trames et la gestion
des messages.
Voir également:
Dans ce manuel :
Paramètrage minimal d’un topic "variable image" ou "variable locale"
Mise en œuvre : configuration des topics
Serveur OPC
• 18 •
Woodhead
4.
Le serveur OPC met à votre disposition deux principaux types de variables :
Les “variables locales” :
Ce sont les variables d’une zone de données locales (data-base) maintenue en mémoire par les
interfaces ou l’émulateur logiciel.
Domaines d’utilisation :
Vous devrez impérativement accéder à ces variables dans le cas d’un fonctionnement en
mode esclave ou serveur. En effet, le dialogue avec les équipements distants ne peut se
faire qu’à travers la data-base.
Cependant, dans le cas d’un canal maître/client, l’utilisateur peut préférer configurer lui
même ses trames de lecture (fonctions cycliques configurées avec l’utilitaire PCCYC) pour
accéder à un équipement distant ( Non supporté en Direct-Link ).
La data base constitue également un moyen possible de partage de données entre
plusieurs applications cliente OPC
Avantages :
Le nombre minimum de topics est restreint (un seul topic par carte peut suffire).
Restrictions :
Dans le cas d’un dialogue avec un équipement distant au travers d’un canal maître/client, il
n’est pas possible d’effectuer une écriture directement dans l’équipement. L’écriture
s’effectuera uniquement dans la data-base. Ce problème peut éventuellement être
Non supporté en
contourné en utilisant des fonctions cycliques d’écriture déclenchées
Direct-Link .
De plus, vous devrez impérativement utiliser le “Descripteur standard pour l’accès à la
Data-base”. L’applicatif ne pourra pas forcément utiliser des adresses identiques à celles
des automates (mapping data-base).
Les “variables images”:
Ce sont les variables disponibles dans les équipement distants. Elles sont accessibles au travers
d’un topic de type “variable image”.
Domaines d’utilisation :
Elles sont accessibles en lecture et écriture au travers des canaux Maîtres/clients des
solutions applicom®.
Serveur OPC
• 19 •
Woodhead
Avantages :
Dans ce cas, des requêtes de lecture sont automatiquement créées par le serveur en
fonction des besoins en variables dans les applications clients. Jusqu'à 1024 trames
peuvent être générées par canal. Elles sont en permanence optimisées pour minimiser la
communication.
Vous avez la possibilité de travailler avec des adresses et des syntaxes constructeurs. Une
écriture est directement répercutée dans l’équipement distant.
Restrictions :
Ce mode vous impose de définir autant de topics que d’équipements distants.
Voir également:
Dans ce manuel :
Syntaxes des variables internes
Contrôle des fonctions cycliques de PCCYC
Descripteur standard pour l’accès à la data-base
Fonctionnalité : Database
Serveur OPC
• 20 •
Woodhead
Le simple fait d’avoir créé un topic et de lui avoir associé le chemin d’accès auquel il correspond
(numéro de carte, numéro de canal et numéro d’équipement) suffit à son utilisation dans l’applicatif
client. Pour la plupart des protocoles, chaque ajout d’équipement donnera lieu à la création
automatique d’un topic.
Tous les autres paramètres nécessiteront éventuellement une modification dans les cas suivants :
si vous utilisez certaines fonctionnalités particulières du produit (mode message ou
tableau, items personnalisés,…).
si des options avancées s’avèrent nécessaires pour s’adapter à des protocoles ou des
types d’équipements particuliers.
Voir également:
Dans ce manuel :
La syntaxe de la variable correspond au nom de l’item.
Cette dernière permet de désigner la variable locale ou la variable image. Pour les variables
images, la syntaxe à utiliser est liée au type d’équipement visé. Un descripteur de syntaxe
approprié vous permet en effet d’utiliser certains mnémoniques constructeur, rendant ainsi
l’interfaçage plus convivial.
Dans le cas de “variables locales”, vous devrez utiliser des mnémoniques applicom®. Par
exemple, le mot de 16 bits situé à l’adresse 10 sera désigné par W10. L’ensemble des
mnémoniques utilisables est décrit dans le chapitre “Descripteur standard pour l’accès à la
Data-base”
Dans le cas des “variables images”, vous pourrez utiliser des mnémoniques semblables
aux syntaxes constructeur. Par exemple, sur un équipement Siemens Simatic® S7, le mot
10 du DB1 sera identifié par DB1.DBW10. Le descripteur adapté à l’équipement visé est
déterminé de façon automatique par le logiciel applicom®. Pour consulter les syntaxes
autorisées par les différents descripteurs fournis pour votre protocole, reportez-vous au
tableau suivant.
Remarque avancée :
Vous avez cependant la possibilité de forcer l'utilisation d'un autre descripteur (en général,
le descripteur standard, composé de syntaxes génériques utilisables quel que soit le
protocole ou la messagerie. Ce descripteur peut être positionné par le biais des options
avancées). Attention cependant, le descripteur de syntaxes détermine également certaines
capacités d’optimisation des requêtes liées au type d’équipement visé et au mapping des
données de cet équipement. Si vous changez le descripteur par défaut, certaines
optimisations d'accès aux équipements se trouveront ainsi dévalidées, au détriment
possible des performances.
Serveur OPC
• 21 •
Woodhead
Type de protocole
Descripteur d’items
Nom du fichier
du descripteur
Cegelec sur TCP/IP
Alspa C80-35 et C80-75
ITEMCEGE.DLL
UniTe sur TCP/IP
Telemecanique TSX
Premium
ITEMTSX.DLL
Mitsubishi sur TCP/IP
Mitsubishi Serie A, Serie Q
ITEMMIT.DLL
GE Fanuc sur TCP/IP
Séries 90-30 et 90-70
ITEMSNPX.DLL
Alnet II TCP/IP (Altus) sur TCP/IP
ALNET II
ITEMALT.DLL
EtherNet/IP (Allen Bradley) sur TCP/IP
Allen-Bradley
ITEMAB.DLL
Equipement Sysmac C
Sysmac C
ITEMOMRO.DLL
Equipement Sysmac CS
Sysmac CS
ITEMOMRO.DLL
Equipement Sysmac CV
Sysmac CV
ITEMOMRO.DLL
Equipement Modicon
Modbus Modicon TSX
ITEMMOD.DLL
Equipement Telemecanique
Telemecanique TSX/PMX
ITEMTSX.DLL
Autres equipement
Modbus Générique
ITEMMDB.DLL
Messagerie S5/TF
Simatic S5 (Indus.
Ethernet)
ITEMIES5.DLL
Messagerie TI
Texas Instrument
ITEMTI.DLL
Messagerie S7
Siemens série 7
ITEMS7.DLL
Equipement SMC
April-SMC
ITEMSMC.DLL
Equipement APRIL
April-série 1000
ITEMPB.DLL
Autres équipements
Descripteur standard
ITEMSTD.DLL
ITEMSTD.DLL
Equipement APRIL
April-série 1000
ITEMPB.DLL
Autres équipements
Télémécanique TSX/PMX
ITEMTSX.DLL
3964/3964R, Maître-Client/Serveur
Siemens Simatic S5
(syntaxe allemande et
française and syntaxe
anglaise)
ITEMSIEM.DLL
Sucoma, Maître
ITEMSTD.DLL
Data Link, Maître
Otic Fischer&Porter
(DataLink)
ITEMOTIC.DLL
Kit4000
ITEMSTD.DLL
Siemens Simatic S5
ITEMSIEM.DLL
Omron sur TCP/IP
Modbus sur TCP/IP
Industrial Ethernet
Jbus RTU
Modbus RTU (solution hardware)
Uni-Telway
Profibus
Messagerie S5
Serveur OPC
• 22 •
Woodhead
française et syntaxe
anglaise)
Messagerie MPI et S7
Descripteur automates
Siemens série 7 pour MPI
et S7)
ITEMS7.DLL
Messagerie PROFIBUS DP
DP)
ITEMDP.DLL
Equipement APRIL
April-série 1000)
ITEMAPRL.DLL
Autres equipements
PLC)
ITEMTSX.DLL
Sysmac Way, Maître
Omron (Sysmac-Way))
ITEMOMRO.DLL
DF1
Allen-Bradley
ITEMAB.DLL
S-Bus, Maître
SAIA
ITEMSAIA.DLL
PPI, Maître
Siemens Simatic S7
ITEMS7.DLL
Equipement APRIL
April-série 1000
ITEMAPRL.DLL
Autres equipements
PLC
ITEMTSX.DLL
AS511 (prog. port), Maître
Siemens Simatic S5
française et syntaxe
anglaise)
ITEMSIEM.DLL
TI-Dir, Maître
Texas Instrument
ITEMTI.DLL
SNP-X, Maître
GE-Fanuc
ITEMSNPX.DLL
InterBus-S G3, Maître
ITEMSTD.DLL
Equipement TSX QUANTUM
Modbus Modicon TSX
ITEMMOD.DLL
Equipement TSX PREMIUM
ITEMTSX.DLL
Equipement Modicon 984
Modbus Modicon 984
ITEMMOD2.DLL
Equipement Modbus générique
Modbus générique
ITEMMDB.DLL
Equipement TSX QUANTUM
Modbus Modicon TSX
ITEMMOD.DLL
Equipement TSX PREMIUM
ITEMTSX.DLL
Equipement Modicon 984
Modbus Modicon 984
ITEMMOD2.DLL
Equipement MODBUS générique
Modbus générique
ITEMMDB.DLL
Ethway
Fipway, Client/Serveur
Modbus Plus, Client/Serveur
Modbus ASCII pour solution hardware
Modbus RTU/ASCII pour SW1000SER
Voir également:
Dans ce manuel :
Serveur OPC
• 23 •
Woodhead
Accès aux variables unitaires
Les variables unitaires désignent les variables natives locales ou images. Elles peuvent être des
types simples suivants :
bits (bit internes, bits d’entrée, bits de sortie)
octets (octets internes, octets d’entrée, octets de sortie)
mots (mots internes, mots d’entrée, mots de sortie)
mots doubles
mots flottants
certains ‘objets’ spécifiques à certains équipements
informations de diagnostic
Les syntaxes des variables internes utilisables dépendent du type d’équipement visé.
Voir également:
Dans ce manuel :
Optimisation des requêtes synchrones et asynchrones
Lorsque l'application client veut effectuer une demande de lecture ou d'écriture synchrone ou
asynchrone, elle appelle une des méthodes disponibles en passant en argument la liste des items
concernés par la requête (sauf dans le cas de IOPCAsyncIO::Refresh où tous les items du groupe
sont implicitement concernés). Le serveur OPC effectue une analyse préalable de cette liste de
manière à optimiser le flux de communication nécessaire :
Dans le cas des méthodes de lecture, l'ensemble des items est scruté et ceux-ci sont
regroupés de manière à minimiser le nombre de requêtes.
Dans le cas des écritures, les mécanismes mis en œuvre sont plus compliqués. En effet,
des variables pouvant être écrites par une même requête doivent impérativement être
contiguës. De plus il est impératif de préserver l'ordre d'envoi des différents items. Le
serveur OPC pratique donc de la façon suivante :
il commence le parcours de la liste en partant du premier item.
pour chaque item suivant, il vérifie si celui-ci est d'adresse directement supérieure
à l'item précédent.
si l'item n'est pas associable avec le précédent, il envoie la requête correspondant
aux items précédents et continue l'exploration jusqu'à la fin de la liste.
Exemple : L'application client souhaite écrire trois mots et deux bits dans la data-base applicom®
si la liste est ordonnée ainsi :
Serveur OPC
W10
W11
W12
• 24 •
Woodhead
B20
B21
Dans ce cas, le serveur OPC satisfera à la demande en effectuant seulement deux
requêtes. Une d'écriture de trois mots à partir de l'adresse 10 et une autre
d'écriture de deux bits à partir de l'adresse 20
si la liste est ordonnée ainsi :
B20
W12
W10
W11
B21
Dans ce cas, le serveur OPC satisfera à la demande en effectuant quatre requêtes.
écriture du bit d'adresse 20
écriture du mot d'adresse 12
écriture de deux mots à partir de l'adresse 10
écriture du bit d'adresse 21
Il est donc de la responsabilité de l'application client d'ordonner les items de façon croissante et
contiguë pour assurer les performances maximales.
Utilisation du mode tableau
Il est possible de regrouper les informations de mêmes types et d’adresses contiguës dans un
même “item” sous forme soit :
D’une chaîne ASCII de données séparées par un délimiteur configurable (voir chapitre
“Configuration du mode tableau”),
D’un tableau de données binaires
Pour le paramétrage lié à l’utilisation du mode tableau, reportez vous au chapitre - Syntaxes des
variables internes.
L’emploi du mode tableau (ASCII ou binaire) s’effectue en concaténant à la syntaxe de la première
variable une extension du type :
_n pour le mode tableau ou n réprésente le nombre de données.
Les syntaxes utilisables dépendent du type d’équipement visé. Pour consulter les syntaxes
autorisées par le descripteur choisi, reportez vous au chapitre - Configuration du mode tableau.
Attention !
Pour certains protocoles ou certaines messageries, les modes message et tableau nécessitent
quelques précautions d'utilisation. En effet, certains protocoles offrent la possibilité dans la console
de configurer :
l’alignement des données lors de la lecture de mots de 16 bits
et/ou
l’alignement des données lors de la lecture de mots de 32 bits
Serveur OPC
• 25 •
Woodhead
Ces paramètres agissent directement sur la façon dont sont remontées les données durant leur
lecture. Ils n’agissent pas pour l’écriture. Ainsi, dans le cas d'un alignement sur des adresses octets
lors de la lecture de mots de 16 bits ou d'un alignement sur des adresses octets ou mots lors de la
lecture de mot de 32 bits, l'écriture continue de s'effectuer en adressage mot pour les mots 16 bits
et mots doubles pour les mots 32 bits. Avec le mode tableau, un item symbolisant par exemple un
tableau de mots (WOx_n) ne désigne pas les mêmes variables en écriture qu'en lecture. Le mode
tableau ne pourra donc être utilisé qu'en lecture.
Voir également:
Dans ce manuel :
Accès aux variables unitaires
Configuration du mode tableau et matrice
Principe de remontée des données sous forme ASCII
Configuration du mode tableau et matrice
La configuration du mode tableau s’effectue par l’onglet Mode message et tableau de la
configuration des topics, accessible depuis la console applicom.
Voir également:
Dans ce manuel :
Configuration des topics : mode tableau et matrice
Principe de remontée des données sous forme ASCII
Exemples :
Item représentant une chaîne de données correspondant à 4 mots à partir du mot 0.
Syntaxe de l’item : W0_4
Représentation des données :
Valeur ASCII
De W0
Délimiteur
Valeur ASCII
de W1
Délimiteur
Valeur ASCII
de W2
Délimiteur
Valeur ASCII
de W3
Les applications clients traitent les données comme des chaînes ASCII.
Utilisation du mode message
Le mode message permet d'échanger jusqu’à 131 caractères ASCII en lecture et en écriture entre
vos applications clients et les équipements. Une suite d'octets dans l'équipement peut être
assimilée à une chaîne de caractères ASCII. Si la suite est localisée dans les octets, le premier
octet correspond au premier caractère de la chaîne. Si la suite est localisée dans les mots, le
premier caractère de cette chaîne peut être localisé sur les 8 bits de poids faibles ou les 8 bits de
poids forts du premier mot de cette suite. Vous devez définir la taille du tableau pouvant contenir
cette chaîne. Cette définition est réalisée dans le nom de l'item. La taille de la chaîne de caractères
peut être variable, sa valeur maximum étant bien sûr celle de la table allouée pour les octets ou
deux fois la taille allouée pour les mots. La chaîne est sauvegardée dans cette table de l'adresse la
plus faible vers l'adresse la plus haute.
Serveur OPC
• 26 •
Woodhead
Différents choix permettent de définir un ou plusieurs caractères d'arrêt dans le cas de requêtes de
lecture. La chaîne de caractères est tronquée et le ou les caractères d'arrêts définis sont intégrés
en fin de chaîne. Dans le cas d'une écriture, ce ou ces caractères d'arrêt sont intégrés dans le
message ASCII. Le caractère “NULL”(0) est prioritaire sur les caractères d'arrêt de fin de message
configurés. il sera également intégré implicitement au message.
Pour le paramétrage lié à l’utilisation du mode message, reportez vous au chapitre Configuration du
mode message.
autorisées par le descripteur choisi, reportez vous au chapitre - Syntaxes des variables internes
Voir également:
Dans ce manuel :
Configuration des topics : mode message
Configuration du mode message
La configuration du mode message s’effectue par l’onglet Mode message et tableau de la
configuration des topics, accessible depuis la console applicom.
Il vous permet notamment de configurer le Délimiteur de fin de messages.
Voir également:
Dans ce manuel :
Configuration des topics : mode message
Bit de mots
Les différents descripteurs vous proposent parfois des syntaxes vous permettant d’accéder à un bit
au sein d’un octet, d’un mot ou d’un mot double (exemple Ox.b et Wx.b du descripteur standard)
même lorsque le protocole ne propose pas cette fonctionnalité de façon native. Le serveur génère
dans ce cas des trames d’octets (ou de mots).
autorisées par le descripteur choisi, reportez vous au chapitre reportez vous au chapitre - Syntaxes
des variables internes.
Voir également:
Dans ce manuel :
Serveur OPC
• 27 •
Woodhead
Suffixe optionnels
Ces suffixes permettent de personnaliser un “item”.
Représentation en valeur signée => item_S
Type de variables
OCTET
MOT 16 BITS
Syntaxe de l’item
item_S
Exemple
O100_S
W100_S
item : Représente l’item d’une variable numérique simple.
Ce suffixe permet de traiter l’extension de signe pour les valeurs octets (-128 à +127) et les mots
de 16bits (de-32768 à + 32767).
Sans ce suffixe ces grandeurs numériques sont de types non signés (de 0 à 255 pour les octets) et
(0 à 65535 pour les mots de 16bits).
Représentation en valeur BCD => item_B
Type de variables
OCTET
MOT 16 BITS
MOT DOUBLE 32
BITS
Syntaxe de l’item
item_B
Exemple
O100_B
W100_B
D100_B
item : Représente l’item d’une variable numérique simple.
Ce suffixe permet de transcoder les données d’un octet, mot ou mot double stocké dans
l’équipement comme une entité BCD de 1, 2 ou 4 octets non signés (décimal digit) et les convertit
au format binaire.
Cette extension n’est pas autorisée dans le cas des chaînes ou des matrices et elle s’applique en
lecture et en écriture.
Croisement des octets => item_Xx
Ces suffixes permettent le croisement des octets composant une donnée de type mot 16 bits, mot
double 32 bits ou mot flottant. Ils peuvent être utilisés sur des données de type numérique simple,
sur l’ensemble des données d’un tableau ou sur un objet.
Le tableau suivant présente les différents types de croisement en fonction du suffixe et du type de
l’item :
_X1
Serveur OPC
Mot 16 bits
O1 O2 -> O2 O1 (Croisement
des octets)
Double mot 32 bits / Flottant
O1 O2 O3 O4 -> O4 O3 O2 O1 (Croisement
des octets)
• 28 •
Woodhead
_X2
des octets)
_X3
des octets)
O1 O2 O3 O4 -> O3 O4 O1 O2 (Croisement des
mots)
O1 O2 O3 O4 -> O2 O1 O4 O3 (Croisement
des octets dans les mots)
Le croisement des octets, pour un item "variable locale", peut aussi se configurer directement dans
le topic. L’utilisation de ce suffixe est prioritaire par rapport à la configuration pour le topic.
Mode Unitaire
Mode Tableau
Bits
Bx
Bx_n
Octets
Ox
Ox_n
Bits dans des octets
Ox.b
Chaîne ASCII dans les octets
Mots
M_Ox_n
Wx
Bits dans des mots
Wx_n
Wx.b
Chaîne ASCII dans les mots
M_Wx_n
Mots doubles
Dx
Dx_n
Mots flottants
Fx
Fx_n
Voir également:
Dans ce manuel :
Utilisation du mode tableau
Utilisation du mode message
- Bits => Bx (type : BIT)
x : Numéro du premier bit (0 à 32767)
Exemple : B4
- Bits => Bx_n
x : Numéro du premier bit (0 à 32767)
n : Nombre de bits.(2 à 128)
Exemple : B4_10
- Octets => Ox (type : OCTET)
x : Numéro du premier octet (0 à 13999)
Exemple : O4
Serveur OPC
• 29 •
Woodhead
- Octets => Ox_n
n : Nombre d’octets (2 à 128)
Exemple : O4_10
- Bits dans des octets => Ox.b (type : BIT)
b : Rang du bit dans l’octet(0 à 7).
Exemple : O4.3
- Chaîne ASCII dans les octets => M_Ox_n (type : OCTET)
Pour plus d'information sur l'utilisation des chaînes ASCII, vous pouvez consulter le chapitre
"Utilisation du mode message".
x : Numéro du premier octet contenant la chaîne (0 à 13999).
n : Nombre d’octets potentiels pouvant contenir la chaîne ASCII (1 à 131).
Exemple : M_O100_30
Dans l’exemple la table d’octets O100 à O129 peut contenir la chaîne.
- Mots => Wx (type : MOT 16 bits)
x : Numéro du premier mot (0 à 32767).
Exemple : W4
- Mots => Wx_n
n : Nombre de mots(2 à 64).
Exemple : W4_10
– Bits dans des mots => Wx.b
b : Rang du bit dans le mot(0 à 15).
Serveur OPC
• 30 •
Woodhead
Exemple : W4.10
- Chaîne ASCII dans les mots => M_Wx_n (type : MOT 16 bits)
Pour plus d'information sur l'utilisation des chaînes ASCII, vous pouvez consulter le chapitre
"Utilisation du mode message".
x : Numéro du premier mot contenant la chaîne.
n : Nombre de mots potentiels pouvant contenir la chaîne ASCII (1 à 65).
Exemple : M_W100_30
Dans l’exemple la table de mots W100 à W129 peut contenir la chaîne.
- Mots doubles => Dx (type : MOT 32 bits)
x : Numéro du premier mot double (0 à 32766).
Exemple : D4
- Mots doubles => Dx_n
x : Numéro du premier mot double (0 à 32766).
n : Nombre de mots doubles.(2 à 64)
Exemple : D4_10
- Mots flottant => Fx (type : MOT 32 bits IEEE)
x : Numéro du premier mot de32 bits IEEE(0 à 32766)
Exemple : F4
- Mots doubles => Fx_n
x : Numéro du premier mot de32 bits IEEE(0 à 32766)
n : Nombre de mots doubles.
Exemple : F4_10
Descripteur standard d’accès aux variables images
Dans le cas des “variables images”, vous pourrez utiliser des mnémoniques semblables aux syntaxes
constructeur. Par exemple, sur un équipement Siemens Simatic® S7, le mot 10 du DB1 sera identifié par
DB1.DBW10. Le descripteur adapté à l’équipement visé est déterminé de façon automatique par le
logiciel.
Vous avez cependant la possibilité de forcer l'utilisation d'un autre descripteur (en général, le descripteur
Serveur OPC
• 31 •
Woodhead
standard, composé de syntaxes génériques utilisables quel que soit le protocole ou la messagerie. Ce
descripteur peut être positionné par le biais des options avancées). Attention cependant, le descripteur de
syntaxes détermine également certaines capacités d’optimisation des requêtes liées au type
d’équipement visé et au mapping des données de cet équipement. Si vous changez le descripteur par
défaut, certaines optimisations d'accès aux équipements se trouveront ainsi dévalidées, au détriment
possible des performances.
Syntaxes du descripteur standard :
Mode unitaire
Mode tableau
Bits
Bx
Bx_n
Bits d’entrée
BIx
BIx_n
Bits de sortie
BOx
BOx_n
Octets
Ox
Ox_n
Octets d’entrée
OIx
OIx_n
Octets de sortie
OOx
OOx_n
Bits dans des octets
Ox.b
Chaîne ASCII dans les octets
M_Ox_n
Mots
Wx
Wx_n
Mots d’entrée
WIx
WIx_n
Mots de sortie
WOx
WOx_n
Bits dans des mots
Wx.b
Chaîne ASCII dans les mots
M_Wx_n
Mots doubles
Dx
Dx_n
Mots flottants
Fx
Fx_n
x : adresse de la donnée. Doit être calculée selon la formule précisée dans le manuel du protocole visé.
b : offset du bit dans l’octet (de 0 à 7) ou dans le mot (0 à 15).
n : taille du tableau
Information de diagnostics et contrôle
Status des équipements => STATUS
Type de variables
Syntaxe de l’item
Exemple
MOT 16 BITS
STATUS
STATUS_READ
STATUS_WRITE
STATUS
STATUS_READ
STATUS_WRITE
MOT 16 BITS
MOT 16 BITS
Pour chaque Topic, vous pouvez lire un status local d’écriture (STATUS_WRITE), un status local
de lecture (STATUS_READ) et un status recoupant les deux (STATUS). Ils vous donnent des
informations concernant les accès aux équipements. La valeur des Status peut évoluer de 0 à
65535. Ci-dessous les principaux status sont répertoriés.
Serveur OPC
• 32 •
Woodhead
Pour plus d’informations, veuillez consulter les manuels protocoles au chapitre “Status de retour
des fonctions”.
Valeurs courantes :
0 : Aucune erreur.
255 : c’est la valeur initiale des items de status pour un topic tant qu’aucune transaction n’a été
effectuée.
Pour les autres valeurs, référez-vous au manuel protocole.
Nombre de défauts d’advise => ADVISE_FAILED
Permet d’accéder au nombre de défauts d’advise survenus pour un “Topic standard”, c’est à dire le
nombre de points refusés par OPC en raison d’une mauvaise syntaxe. Cette donnée n’est
accessible qu’en lecture.
Nombre d’erreurs d’écriture => WRITE_ERROR
Permet d’accéder au nombre d’erreurs d’écriture survenues pour un “Topic standard”. Cette
donnée n’est accessible qu’en lecture.
Nombre d’erreurs de lecture => READ_ERROR
Permet d’accéder au nombre d’erreurs de lecture survenues pour un “Topic standard”. Cette
Serveur OPC
• 33 •
Woodhead
Les noms symboliques
Le serveur OPC applicom®, met à votre disposition un moyen supplémentaire d’accès aux
variables :
Les “noms symboliques”
Le but du “nom symbolique” est de remplacer le nom d’une “variable locale” ou d’une “variable
image” par un mot ayant un sens pour l’utilisateur. Par exemple, Il est possible de remplacer la
syntaxe “DB1.DBW10” par le mot “Température”, ce dernier étant beaucoup plus expressif pour un
utilisateur.
Fonctionnement
Serveur
Serveur
OPC
OPC
Fichier .CSV
Utilitaire de
Conversion
Fichier .SCY
Fichier .FEF
Fichier
Symbols.sym
Pour reconnaître un symbole, le serveur OPC se constitue des listes d’associations (symbole,
syntaxe). Celles-ci sont chargées à partir d’un fichier Symbols.sym. Ce dernier est généré à l’aide
d’un utilitaire de conversion permettant d’importer ces symboles soit depuis des fichiers provenant
d’outils du marché (exemple : PL7 junior de SCHNEIDER) , soit depuis des fichiers d’un format
propriétaire (.CSV).
Remarque : Le fichier SYMBOLS.SYM est présent dans le répertoire d’installation du produit
applicom®. Il est possible de le visualiser à l’aide du “bloc note” afin de connaître l’ensemble des
symboles actuellement reconnus par le serveur OPC. Cependant, il ne faut en aucun cas le
modifier directement ou l’utiliser dans l’une de vos applications car son format est sujet à
modifications. Si vous désirez importer d’autres formats de fichiers que ceux actuellement
proposés, consultez-nous.
Serveur OPC
• 34 •
Woodhead
Création d’une nouvelle liste de noms symboliques
Pour attacher une nouvelle liste de noms symboliques à un équipement, il faut importer ceux-ci au
préalable avec un utilitaire de conversion à partir d’un fichier :
propriétaire au format “.CSV”,
Les fichiers CSV peuvent être créés avec EXCEL ou avec le “Bloc-notes”. Ce sont des fichiers
texte utilisant le “;” comme séparateur de champs. Ces fichiers ont le format suivant :
NomSymbolique1;Syntaxe1
La syntaxe correspond à un mnémonique utilisable en fonction de l’équipement visé. Ces
mnémoniques sont documentés dans les différents manuels protocole.
au Format .SCY ou FEF (fichier d’exportation des noms de symboles générés avec le
logiciel PL7 junior de SCHNEIDER),
Cette importation se fait au moyen de l’utilitaire IMPSYMB. Celui-ci se présente sous la forme
suivante :
La zone “Type de Variable”
La zone Type de Variable permet d’indiquer à quoi vont se rattacher les symboles qui vont être lus
dans le fichier source (CSV, SCY, FEF). Les variables peuvent être de type :
variables locales (donc attachée à la data-base). Il faut alors indiquer le numéro de carte
sur laquelle se trouve la data-base,
variables images. Dans ce cas, il faut renseigner le numéro de carte, de canal ainsi que le
numéro d’équipement sur lequel on désire affecter les symboles.
Serveur OPC
• 35 •
Woodhead
Le bouton “Ouvrir un fichier”
Le bouton Ouvrir un fichier... affiche une boîte de dialogue permettant de localiser et d’ouvrir le
fichier de symboles. Attention, l’extension du fichier détermine sa façon d’être importé. Si
l’extension est .CSV le fichier est considéré comme étant au format CSV décrit plus haut, Si
l’extension est .SCY ou FEF, le fichier est traité comme un fichier de symboles provenant du
logiciel PL7 junior.
La zone “Si des symboles existent déjà, que doit faire IMPSYMB ?”
Cette zone permet de choisir le comportement de l’utilitaire de conversion :
Supprimer les anciens symboles. : supprime avant l’importation les symboles déjà
existant sur l’équipement visé.
Garder les symboles existant ; en cas de doublon supprimer l’ancien symbole
permet de garder l’ensemble des symboles. En cas de doublon le symbole actuellement dans
le fichier est supprimé et le nouveau est inséré.
Garder les symboles existant ; en cas de doublon ne pas insérer le nouveau permet
de garder l’ensemble des symboles. En cas de doublon le symbole le nouveau n’est pas
inséré.
Garder les symboles existant ; en cas de doublon demander à l’utilisateur permet de
garder l’ensemble des symboles. En cas de doublon l’utilisateur est interrogé.
le bouton “Importer”
Après avoir renseigné les autres champs, le bouton Importer lance l’importation des symboles et
leur insertion dans le fichier SYMBOLS.SYM.
Désignation des noms symboliques dans OPC
Une fois l’importation des noms symboliques effectuée pour un équipement donné, l’application
client référence un nom symbolique en effectuant la concaténation :
du chemin du périphérique contenant la variable
En utilisant un nom de topic configuré
NomTopic.Symbols
Les syntaxes du type "CardX.Database.Symbols" et
"CardX.ChannelY.EquipmentZ.Symbols" sont également supportées pour compatibilité.
d’un nom de variable symbolique
Exemple de syntaxe : Card1.Channel0.Equipment1.Symbols.TEMPERATURE
Serveur OPC
• 36 •
Woodhead
5.
Accès aux Variables images d’un contrôleur
Logix 5000
Les “variables images”:
Ce terme désigne les variables disponibles du ou des contrôleur(s) Logix 5000 distant(s). Elles sont
accessibles au travers d’un topic de type “variable image”. Vous devrez définir autant de topics que
d’équipements distants.
Les variables images sont accessibles en lecture et en écriture
Les requêtes de lecture sont automatiquement créées par le serveur en fonction des besoins en
variables dans les applications clients. Jusqu'à 1024 transactions peuvent être générées par canal.
Elles sont en permanence optimisées pour minimiser la communication. Ces transactions
contiennent des tags directement définis au sein du contrôleur Logix 5000 auquel vous accédez.
Les écritures sont directement répercutées dans l’équipement distant.
Paramétrage d’un topic "variable image" d’un contrôleur Logix 5000
Le simple fait d’ajouter un équipement de type « Logix5000 - Messagerie Logix5000 (OPC
Seulement)» crée un topic associé à cet équipement et suffit à son utilisation dans l’applicatif client.
Cependant, le topic contient le paramètre suivant sur lequel vous pouvez intervenir :
« Optimiser l’accès au champs d’une structure »
Si ce paramètre est coché et qu’un item représentant un champs d’une structure de taille
inférieure ou égale à 488 octets est demandé par un client, le tag identifiant la structure
complète sera placé dans une transaction. Ainsi, si tout autre item représentant un champ
différent de cette même structure est ajouté, aucune modification de transaction ne sera
nécessaire. Si ce paramètre n’est pas coché, chaque champs de la structure sera ajouté
dans les transactions de façon indépendante.
Voir également:
- dans ce manuel :
Serveur OPC
• 37 •
Accès aux Variables images d’un contrôleur Logix 5000
Woodhead
Les syntaxes accessibles dans le serveur OPC applicom® sont divisibles en deux catégories :
Les syntaxes obtenues directement par accès en ligne au contrôleur Logix5000. Lors du
browsing des items, ces syntaxes sont regroupées sous un nœud « online » placé en
dessous du nom du topic. (voir : Accès au données )
Les syntaxes de diagnostic et de contrôle. celles-ci sont spécifiques au serveur OPC
applicom® et sont situées lors du browsing directement sous le nom du topic. (voir :
Informations de diagnostic et contrôle.)
Voir également:
- dans ce manuel :
- dans la documentation :
Manuel Allen-Bradley sur EtherNet/IP : « Accès aux données »
Optimisation des requêtes synchrones et asynchrones
Lorsque l'application client veut effectuer une demande de lecture ou d'écriture synchrone ou
asynchrone, elle appelle une des méthodes disponibles en passant en argument la liste des items
concernés par la requête (sauf dans le cas de IOPCAsyncIO::Refresh où tous les items du groupe
sont implicitement concernés). Le serveur OPC effectue une analyse préalable de cette liste de
manière à optimiser le flux de communication nécessaire :
Dans le cas des méthodes de lecture, l'ensemble des items est scruté et ceux-ci sont
regroupés de manière à minimiser le nombre de requêtes.
Dans le cas des écritures, les mécanismes mis en œuvre sont plus compliqués. En effet,
des variables pouvant être écrites par une même requête doivent impérativement être
contiguës. De plus il est impératif de préserver l'ordre d'envoi des différents items. Le
serveur OPC pratique donc de la façon suivante :
il commence le parcours de la liste en partant du premier item.
pour chaque item suivant, il vérifie si celui-ci est d'adresse directement supérieure
à l'item précédent (valable uniquement pour des items de type tableau).
si l'item n'est pas associable avec le précédent, il envoie la requête correspondant
aux items précédents et continue l'exploration jusqu'à la fin de la liste.
Voir également :
- dans la documentation :
Manuel Allen-Bradley sur EtherNet/IP « Optimisations en Lecture »
Manuel Allen-Bradley sur EtherNet/IP « Optimisations en Ecriture »
Serveur OPC
• 38 •
Woodhead
Limitations
La solution applicom® utilisée avec le contrôleur Logix5000 ne supporte pas les fonctionnalités
standards applicom® suivantes :
Les extensions _B (format BCD)et _S (Forçage en valeur signée)
Les extensions de syntaxes « Bits de mots »
Les noms symboliques
Les mécanismes de redondance entre 2 équipements
Status des équipements => STATUS
Type de variables
Syntaxe de l’item
Exemple
MOT 16 BITS
STATUS
STATUS_READ
STATUS_WRITE
STATUS
STATUS_READ
STATUS_WRITE
MOT 16 BITS
MOT 16 BITS
Pour chaque Topic, vous pouvez lire un status local d’écriture (STATUS_WRITE), un status local
de lecture (STATUS_READ) et un status recoupant les deux (STATUS). Ils vous donnent des
informations concernant les accès aux équipements. La valeur des Status peut évoluer de 0 à
65535. Ci-dessous les principaux status sont répertoriés.
Pour plus d’informations, veuillez consulter les manuels protocoles au chapitre “Status de retour
des fonctions”.
Valeurs courantes :
0 : Aucune erreur.
255 : c’est la valeur initiale des items de status pour un topic tant qu’aucune transaction n’a été
effectuée avec l’émulateur.
Les autres valeurs représente une erreur. Consultez le manuel protocole associé pour connaître la
signification de la valeur
Nombre de défauts d’advise => ADVISE_FAILED
Permet d’accéder au nombre de défauts d’advise survenus pour un “Topic standard”, c’est à dire le
nombre de points refusés par OPC en raison d’une mauvaise syntaxe. Cette donnée n’est
accessible qu’en lecture.
Serveur OPC
• 39 •
Woodhead
Nombre d’erreurs d’écriture => WRITE_ERROR
Permet d’accéder au nombre d’erreurs d’écriture survenues pour un “Topic standard”. Cette
Nombre d’erreurs de lecture => READ_ERROR
Permet d’accéder au nombre d’erreurs de lecture survenues pour un “Topic standard”. Cette
Serveur OPC
• 40 •
Woodhead
6.
(
Accès aux paramètres des fonctions cycliques
Le configurateur de fonctions cycliques “PCCYC” vous permet de configurer jusqu’à 255 fonctions
cycliques par canal. Celles-ci sont chargées sur la carte lors de l’initialisation des interfaces
applicom® et rapatrient dès lors des données des équipements vers la data-base applicom® (ou
inversement) de manière périodique. L’utilisateur peut configurer des topics fonction cyclique,
chacun lui permettant de faire référence à une de ces fonctions cycliques. Au travers de ces topics,
il sera possible de manipuler tous les paramètres afférents à la fonction cyclique, au même titre que
la fonction “createcyc” si vous utilisez la DLL applicom®.
Le champ Période de rafraîchissement conserve la même signification que pour les Topics
standards.
Voir également:
Dans ce manuel :
Items liés à un topic "fonction cyclique"
Mise en œuvre : configuration des topics
(
Les fonctions cycliques configurées par l’outil PCCYC peuvent être contrôlées par :
Un topic fonction cyclique
Un couple “Flag de commande” “Mot d’état”
Le topic fonction cyclique :
Il vous permet d’accéder à tous les paramètres d’une fonction cyclique de PCCYC et d’effectuer
ainsi une reconfiguration en dynamique grâce aux items :
PERIOD
ACTIVE
EQUIPMENT
Serveur OPC
TYPE
DB_TYPE_VAR
NUMBER_VAR
• 41 •
EQUIP_ADDR
DB_ADDR
STATUS_ADDR
STATUS_FCYC
ACTIVE_ONE
Woodhead
Ces items vous permettent notamment de démarrer, d’arrêter, ou de n’activer qu’une seule fois la
fonction cyclique visée.
Le couple “Flag de commande” “Mot d’état” :
Les 128 premières fonctions cycliques de chaque canal de la carte peuvent être déclenchées.
Pour ce faire, une zone de 512 bits de “Flag de commande” et une zone de 512 mots “Mot
d’état” sont réservées dans la data-base applicom®.
La zone des bits commence à l'adresse 32200. La zone des mots commence à l'adresse 32100.
Elles permettent de démarrer, arrêter, ou n’activer qu’une seule fois la fonction cyclique visée.
Cette méthode présente l’avantage de ne pas nécessiter la configuration d’un topic
supplémentaire. C’est cette méthode qui devra être utilisée dans le cas des fonctions
d’écritures déclenchées (émission de variables locales vers un équipement distant),
La formule pour trouver l'adresse du flag de commande est :
32200 + numéro de canal * 128 + numéro de fonction
La formule pour trouver l'adresse du mot d’état est :
32100 + numéro de canal * 128 + numéro de fonction
Numér
o
De
Canal
0
1
2
3
Numéro de
fonction
cyclique
Zone adresse
“Mot d’état”
dans data-base zone mots
1 à 128
1 à 128
1 à 128
1 à 128
32101 à 32228
32229 à 32356
32357 à 32484
32485 à 32612
Zone adresse
“Flag de commande”
dans data-base zone
bits
32201 à 32328
32329 à 32456
32457 à 32584
32585 à 32712
Exemple :
L'adresse du “Flag de commande” et du “Mot d’état” de la fonction numéro 2 du canal 3 est égale
à:
adresse bit = 32200 + 3 * 128 + 2
32586
adresse mot = 32100 + 3 * 128 + 2
32486
En positionnant à un le bit “flag de commande” correspondant à la fonction cyclique voulue, le
Serveur positionnera la fonction dans l’état défini par la valeur du “mot d’état” :
“mot d’état” = 0 : Activation ponctuelle de la fonction cyclique (Une seule fois).
“mot d’état” = 1 : Démarrage de la fonction cyclique.
“mot d’état” = 2 : Arrêt de la fonction cyclique.
Items liés à un topic "fonction cyclique"
(
Ces Items permettent d’accéder au différents paramètres d’une fonction cyclique configurée par le
configurateur de fonctions cycliques PCCYC, au travers du Topic fonction cyclique qui lui est
associé. Les items utilisables sont décrits ci-dessous. La plupart correspondent à un paramètre de
la fonction CREATECYC (indiqué en italique) de la DLL.
Pour connaître les valeurs possibles de chacun de ces paramètres, reportez-vous à la fonction
CREATECYC du “Manuel de référence librairie” applicom®.
Période de rafraichissement
Serveur OPC
=> PERIOD
• 42 •
Woodhead
Paramètre per de la fonction applicom® CREATECYC.
Cet item vous permet d’accéder à la période de la fonction cyclique. La valeur est un multiple de
100 ms.
Accessible en lecture / écriture.
Activation / désactivation
=> ACTIVE
Paramètre act de la fonction applicom® CREATECYC.
Cet item vous permet d’activer (poke de la valeur 1) ou de desactiver (poke de la valeur 0) la
fonction cyclique.
Numéro d’équipement cible
=> EQUIPMENT
Paramètre neq de la fonction applicom® CREATECYC.
Cet item vous permet d’accéder au numéro d’équipement cible.
Type d’échange => TYPE
Paramètre typf de la fonction applicom® CREATECYC.
Cet item vous permet d’accéder au type d’échange.
Type de variable dans data-base
=> DB_TYPE_VAR
Paramètre vardb de la fonction CREATECYC.
Cet item vous permet d’accéder au type de variable dans la data-base.
Nombre de variable
=> NUMBER_VAR
Paramètre nb de la fonction applicom® CREATECYC.
Cet item vous permet d’accéder au nombre de variable.
Adresse variable dans l’équipement
=> EQUIP_ADDR
Paramètre adreq de la fonction applicom® CREATECYC.
Cet item vous permet d’accéder à l’adresse de la première variable dans l’équipement.
Adresse variable dans data-base
=> DB_ADDR
Paramètre adrdb de la fonction applicom® CREATECYC.
Cet item vous permet d’accéder à l’adresse de la première variable dans la data-base.
Serveur OPC
• 43 •
Woodhead
Adresse status dans data-base => STATUS_ADDR
Paramètre adrstat de la fonction applicom® CREATECYC.
Cet item vous permet d’accéder à l’adresse de rangement du mot status dans la data-base.
Status de la fonction cyclique => STATUS_FCYC
Cet item vous permet d’accéder au status de la fonction cyclique.
Accessible en lecture.
Activation ponctuelle
=> ACTIVE_ONE
Cet item vous permet d’activer ponctuellement (par poke de la valeur 1) la fonction cyclique.
La valeur remontée lors d’une lecture n’est pas significative (toujours = 0).
Serveur OPC
• 44 •
Woodhead
7.
Accès aux informations générales du serveur
(Topic "SYSTEME")
Ce topic prédéfini permet d’accéder à des informations générales du serveur. Il est utilisable avec
les items suivants :
Nombre de topics en cours
=> NB_TOPIC
Cet item vous permet d’accéder au nombre de topics accessibles.
Nombre de points en cours
=> NB_POINT
Cet item vous permet d'obtenir le nombre de points en communication.
Nombre d’I/O Items maximum utilisable
=> LIMIT_ALLOWED (SW1000ETH seulement)
Ce nombre est directement lié au code d’installation qui vous a été délivré.
Nombre d’I/O Items instantané => LIMIT_USED (SW1000ETH seulement)
Cet item vous permet d’accéder au nombre d’I/O Items utilisé à cet instant donné.
Nombre d’I/O Items maximum => LIMIT_MAX_USED (SW1000ETH seulement)
Cet item vous permet de connaître le nombre maximum atteint d’I/O Items utilisés par le
serveur OPC depuis son lancement.
Etat d’atteinte de limitation
=> LIMIT_OVERFLOW (SW1000ETH seulement)
Cet item peut prendre 3 valeurs :
0 : Le nombre d’I/O Items maximum est resté inférieur 90% de la limite autorisée
1 : Le nombre d’I/O Items maximum à atteint 90% de la limite autorisée
2 : Le nombre d’I/O Items maximum à dépassé la limite autorisée. Des I/O Items
n’ont pu être ajoutés dans le serveur.
Voir également:
Dans ce manuel :
Serveur OPC
• 45 •
Accès aux informations générales du serveur (Topic "SYSTEME")
Woodhead
8.
(
Accès au WatchDog et à l’entrée TOR (Topics
"CARDx")
Le ‘x’ est le numéro de carte applicom® compris entre 1 et 8. Chacun de ces topics identifie une
carte applicom®. Ils sont utilisables avec les items suivants :
Chien de garde => WATCHDOG
Un contact de chien de garde est à la disposition de l’utilisateur sur chaque interface applicom®.
Ce contact peut être forcé fermé, ouvert ou rafraîchi pour une période donnée. Cette fonction se
comporte comme un monostable.
Le contact se ferme sur une écriture de cet item et retombe après le temps défini dans la variable
WATCHDOG.
Ce monostable est automatiquement réarmé à chaque nouvelle écriture. Si votre application
génère des écritures périodiques à une fréquence inférieure à la valeur passée au cours de
l’écriture, le contact reste fermé.
WATCHDOG = 0
WATCHDOG =-1
WATCHDOG >0 et !=-1
ouverture maintenue du contact
fermeture maintenue du contact
fermeture du contact durant cette valeur en secondes
Attention : Les accès sont en lecture/écriture.
Si l’interface applicom® est équipée de Prom supérieure ou égale à 3.2, la valeur de retour est le
nombre de seconde restant. Dans le cas contraire, la valeur remontée est sans signification
(toujours = 0).
Entrée TOR
=> INPUT
Pour les interfaces équipés d’une entrée TOR, Cet item vous permet de remonter le niveau de
celle-ci (0 ou 1)
Attention : Les accès sont en lecture seulement.
Serveur OPC
• 46 •
Accès au WatchDog et à l’entrée TOR (Topics "CARDx")
Woodhead
9.
(
Accès aux signaux modems (Topic "CHANx")
Le ‘x’ est un numéro de canal applicom® compris entre 0 et 31. Chacun de ces topics identifie un
canal. Ils sont utilisés pour la gestion des signaux modems avec les items suivants :
Signaux RS232 RTS et DTR
=> RTS_DTR
Cet item vous permet de positionner les signaux RTS et DTR.par une écriture. L’accès se fait en
écriture seulement. En lecture, cet item remonte la valeur 255 (non significative).
Poke de la valeur 0:
RTS =0 et DTR = 0
RTS =0 et DTR = 1
RTS =1 et DTR = 0
RTS =1 et DTR = 1
Signal RS232 CTS
=> CTS
Cet item vous permet d’accèder au signal CTS. Seule la lecture est autorisée.
Signal RS232 DCD
=> DCD
Cet item vous permet d’accèder au signal DCD. Seule la lecture est autorisée.
Serveur OPC
• 47 •
Accès aux signaux modems (Topic "CHANx")
Woodhead
10. Interface de Diagnostic
Pour accéder à l'interface de diagnostic, il convient au préalable de sélectionner l'option Autoriser
la vue de diagnostic du serveur dans les paramètres du serveur OPC (voir renvoi ci-dessous).
Son affichage se fera par l'icône présente dans la barre des tâches de Windows au démarrage du
serveur OPC.
Un double clic sur l'icône affiche l'environnement de diagnostic. Un clic avec le bouton droit de la
souris propose le menu permettant :
d'afficher la fenêtre de diagnostic. Menu Diagnostic
de fermer le serveur OPC. Menu Exit
L'interface de diagnostic n’est utile que pour les phases de mise au point de votre application. Son
utilisation est consommatrice de ressources. Elle ne doit donc pas être activée durant les phases
d’exploitation. L'interface de diagnostic permet :
de générer un fichier, exploitable par l’application « DumpLogger.exe », contenant des
informations sur les requêtes de communication
de générer un fichier, exploitable par l’application « DumpLogger.exe », contenant des
informations sur l’optimisation de la communication
d'espionner plus particulièrement les évènements survenant sur un item
d'afficher des informations sur le déroulement du serveur.
Serveur OPC
• 48 •
Woodhead
Description des commandes générales
Icône
Menu
Description
Diagnostic – Communication Request
Diagnostic
communication
–
Optimisation
Génère le fichier « dumpOPC.xml » dans le
répertoire de configuration, exploitable par
l’application « DumpLogger.exe », contenant des
informations sur les requêtes de communication
Ce bouton lance automatiquement l’application
« DumpLogger.exe » et l’affichage du fichier
« dumpOPC.xml »
Génère le fichier « dumpTopic.xml » dans le
répertoire de configuration, exploitable par
l’application « DumpLogger.exe », contenant des
informations sur l’optimisation de la communication
Ce bouton lance automatiquement l’application
« DumpLogger.exe » et l’affichage du fichier
« dumpTopic.xml »
Diagnostic - Items Spy
Permet d'espionner une liste d'items.
Diagnostic - Output View – None
Ferme la zone de messages.
Diagnostic - Output View – Single
Affiche une zone où tous les messages sont écrits
les uns après les autres quelque soit leur
provenance.
Diagnostic - Output View - Multiple
Affiche une zone de messages en les séparant par
types.
Diagnostic - Run VisuCyc
Démarre l'application de visualisation des fonctions
cycliques VisuCyc. (Non disponible avec DirectLink)
? - About...
Affiche des informations sur le logiciel.
Voir également:
Dans ce manuel :
Les requêtes de communication
Vue d'espionnage des items
Vue des messages
Serveur OPC
• 49 •
Woodhead
Les requêtes de communication
En appuyant sur le bouton suivant :
, le fichier « dumpOPC.xml » est généré dans le répertoire
de configuration courante. L’application « DumpLogger.exe » s’active et charge aussitôt ce dernier
fichier.
Cette vue a pour but de lister l'ensemble des items et des groupes, géré par le serveur OPC.
Un double clic sur l’un des objets de l’arbre affiche une boîte proposant la liste des paramètres
internes de l’objet.
Optimisation de la communication
En appuyant sur le bouton suivant :
, le fichier « dumpTopic.xml » est généré dans le répertoire
de configuration courante. L’application « DumpLogger.exe » s’active et charge aussitôt ce dernier
fichier.
Serveur OPC
• 50 •
Woodhead
L'affichage de cette fenêtre est statique et est construit au moment du clic sur le bouton d'affichage.
La partie droite de la vue donne des informations sur l'objet sélectionné dans la fenêtre de gauche.
Ces informations ne sont pas documentées mais peuvent être utilisées par le support technique.
Vue d'espionnage des items
La vue d'espionnage des items est obtenue en appuyant sur le bouton suivant :
Serveur OPC
• 51 •
Woodhead
Cette vue est divisée en trois parties. En haut à gauche un navigateur permet de consulter les
différentes données accessibles. La partie en bas à gauche montre la liste des items à surveiller et
la partie de droite affiche les messages des évènements affectant les items de la liste.
Pour espionner un item
sélectionnez l'item à surveiller dans le navigateur
effectuez un "glisser - déplacer" du navigateur vers la liste en dessous
complétez éventuellement la syntaxe (appui sur F2 pour renommer) et cliquez sur la case à cocher
pour sélectionner l'item
mettre en route la surveillance en appuyant sur le bouton :
A partir de ce moment, il n'est plus possible de modifier les items en surveillance active. Il est
cependant possible d'ajouter des items dans la liste ou de modifier ceux non actifs.
La surveillance peut être stoppée avec le bouton :
Notes:
La liste des items à surveiller peut être sauvegardée et rechargée
La commande Logger parameters... du menu Diagnostic permet de sauvegarder tous les
messages affichés dans la vue dans un fichier "Spy.log" situé dans le répertoire de configuration.
Attention, ces paramètres sont appliqués à la fois sur le fichier "Spy.log" et sur le fichier "Opc.log"
permettant de sauvegarder les messages de l'application.
Commandes disponibles
Icône
Serveur OPC
Menu
Description
Items Spy – Item set – New list
Créer une nouvelle liste d'items à surveiller. Si une
liste existe déjà et n'a pas été sauvegardée, un
message apparaît.
Items Spy - Item set – Load
Ouvre une liste précédemment sauvegardée sur le
disque. Si une liste existe déjà et n'a pas été
sauvegardée, un message apparaît.
Items Spy - Item set – Save
Permet d'enregistrer sur le disque, la liste active.
Items Spy – Find…
Recherche une chaîne de caractères dans la fenêtre
en cours. La casse n'a pas d'importance.
Items Spy - Trace – Clear
Supprime tous les messages
d'affichage des messages.
de
la
fenêtre
Items Spy - Traces – Copy
Copie le texte sélectionné de la fenêtre de message
dans le presse papier. Il peut donc être facilement
collé dans tout autre fichier de type texte.
Items Spy – Start
Mets tous les items sélectionnés de la liste en
espionnage.
• 52 •
Woodhead
Items Spy – Stop
Arrête l'espionnage de tous les items.
Items Spy – Item set – Add Item
Ajoute l'item sélectionné de l'arbre dans la liste.
Items Spy – Item set – Remove
Item
Supprime l'item sélectionné de la liste.
Items Spy - Item set – Check Item
Sélectionne l'item (ou les items) afin qu'il(s) soit(ent)
espionné(s).
Vue des messages
Cette vue permet d'afficher des informations liées au déroulement de l'application. L'activation de
cette vue est assurée à l'aide des trois boutons suivants :
Le premier ferme la fenêtre des messages.
Le second affiche la vue en séparant les messages en trois onglets :
onglet Lecture : affiche un message à chaque fois que le serveur va acquérir une donnée auprès
de l'émulateur
onglet Ecriture : affiche un message à chaque fois que le serveur envoie une donnée vers
l'émulateur
onglet Erreur : affiche un message à chaque fois qu'une erreur se produit (erreur de syntaxe,
mauvaise conversion d'une valeur,...)
Le troisième affiche la vue en incorporant tous les messages dans la même fenêtre.
Serveur OPC
• 53 •
Woodhead
Il est possible de stopper la trace des messages dans les fenêtres en sélectionnant la commande
Diagnostic – Output View – Stop Messages. La commande Restart Messages permet de
reprendre les traces. Ces deux commandes agissent sur toutes les fenêtres de messages en
même temps. Lors de l'arrêt ou de la reprise, un message est signalé dans chacun des onglets.
Attention : Tous les messages entre l'arrêt et la reprise sont perdus.
La commande Clear Output View permet de supprimer tous les messages de l'onglet visible. Les
messages des autres onglets ne sont pas affectés par cette commande.
Remarque :
La commande Logger parameters... du menu Diagnostic permet de sauvegarder tous les
messages affichés dans la (les) vue(s) dans un fichier "OPC.log" situé dans le répertoire de
configuration. Attention, ces paramètres sont appliqués à la fois sur le fichier "OPC.log" et sur le
fichier "Spy.log" permettant de sauvegarder les messages de surveillance d'items.
11. Développement d'un client OPC
Contextes de développement
Beaucoup de progiciels de supervision intègrent de base la fonctionnalité client OPC. Cependant,
en cas de besoins spécifiques, il est possible de développer soit-même son propre client OPC, à
partir de l'outil de développement de son choix. Les développement peuvent être classés en trois
catégories principales :
Les développements effectués à l'aide de l'ActiveX de communication applicom®
L'activeX rend transparent pour l'application cliente l'accès aux serveurs OPC et ne
demande que peu de connaissance à propos d'OPC. L'activeX facilite grandement le
développement du client en prenant en charge la mise en communication des serveurs et
l'activation des groupes et des items. La définition de l'application est réalisée
graphiquement sans aucune programmation.
L'activeX de communication est utilisable par les environnements de travail container
ActiveX, notamment Visual Basic, Delphi, les outils offices, ...
Les développements utilisant le custom interface.
Cette interface est utilisable depuis les langages du type C/C++. Son utilisation nécessite
une connaissance complète de la spécification OPC Data Access, des mécanismes OPC
en général et des mécanismes OLE/COM.
Les développements effectués à l'aide de la DLL Automation.
Cette interface est plus particulièrement destinée aux outils de développement rapide tels
que VB, Delphi, les outils offices,…Elle constitue en fait une surcouche automation du
custom interface utilisable depuis les langages du type C/C++. Son utilisation nécessite
une connaissance complète de la spécification Data Access Automation Interface et des
mécanismes OPC en général.
Serveur OPC
• 54 •
Woodhead
Le produit applicom ne fournit pas la DLL automation. La voie préconisée pour developper
un client OPC depuis des progiciels client automation est l’activeX de communication
applicom.
En cas de besoin, les sources de la DLL Automation peuvent être récupérés auprès de la
fondation OPC
Voir également :
dans ce manuel :
Contexte d'utilisation du serveur OPC
Développement d'un client en C et C++
Le serveur OPC applicom® est basé sur les spécifications 2.04 de la fondation OPC. Il supporte
les accès au travers de l’OPC custom Interface.
Le but de cette documentation n’est pas de se substituer à la spécification V2.04 éditée par la
fondation OPC. Celle-ci décrit dans le détail les différentes interfaces et le rôle des méthodes qu’ils
exposent. Ce chapitre est destiné à évoquer toutes les particularités liées au développement d'un
client OPC en C++ avec le serveur OPC applicom® et tente de clarifier certains points qui peuvent
donner lieu à des interprétations diverses lors de la lecture de la spécification.
Voir également :
Document externe :
OPC custom interface V2.04
Les objets et les interfaces supportés
L’exécutable APPOPC.EXE est un serveur OPC Data Access compatible avec la spécification 1.0A
et 2.0. Il supporte en effet l’ensemble des objets et des interfaces obligatoires définis par ces
spécifications, mais aussi l'interface optionnelle de browsing des ItemID.
Objets
Interfaces
Type
OPCServer
IOPCServer
Obligatoire pour V1.0 et V2.0
IOPCItemProperties
Obligatoire pour V2.0
IOPCCommon
IconnectionPointContainer
IOPCBrowseServerAddressSpace
Optionnelle
IOPCGroupStateMgt
IOPCSyncIO
IOPCAsyncIO
IOPCAsyncIO2
IOPCItemMgt
IdataObject
IconnectionPointContainer
IenumOpCItemAttributes
OPCGroup
EnumOpCItemAttributes
Voir également :
Serveur OPC
• 55 •
Woodhead
dans ce manuel :
Le browsing des ItemID
Création d’un objet OPCServer
Le serveur OPC applicom® sera identifié dans le système d’exploitation MS-Windows à l’aide de
son ProgID (identificateur de programme) et de son CLSID (identificateur de classe), enregistrés
dans la base de registres de la machine durant l’installation.
Le CLSID est l’identificateur unique et universel du serveur et il est indépendant de sa version. Le
ProgID est une chaîne de caractères traduite du CLSID au moyen de la base de registres. Il
constitue un synonyme lisible du CLSID.
Pour créer un objet serveur OPC applicom®, l’application client doit :
1 - Initialiser la librairie COM
2 - Obtenir le CLSID du serveur OPC à partir du ProgID
3 - Créer un objet OPCServer
4 - Appeler une ou des fonctions de l’objet OPCServer
5 - Relâcher les interfaces utilisées.
Voici un exemple de code effectuant les étapes précédentes (pour la lisibilité du code les cas
d'erreur ne sont pas traités):
//Etape
1
:
Initialiser
la
librairie
COM
HRESULT
hr;
hr
= CoInitialize(NULL);
//Etape
2
:
Obtenir
le
CLSID
du
ProgID
CLSID
clsid;
hr
=
CLSIDFromProgID((L"
APPLICOM.OPCServer
"),&clsid);
//Etape 3 : Creer l'objet OPCServeur et obtenir la
premiere
interface
(ici
IOPCServer)
IOPCServer*
pServer;
hr
=
CoCreateInstance(clsid,NULL,
CLSCTX_LOCAL_SERVER,IID_OPCServer,(void**)&pServer);
//Etape
4
:
Appeler
l'une
des
fonctions
de
l'interface.
…
pServer->GetStatus(…);
…
//Etape
5
:
Relacher
les
interfaces
pServer->Release();
UnInitialize();
Remarque :
Le package d’installation, comprend deux fichiers, “APPCLSID.H” et “APPCLSID.C” qui contiennent
le ProgID et le CLSID du serveur OPC applicom® et que vous pouvez inclure directement dans
votre projet CLIENT en C ou C++.
Voir également :
dans ce manuel :
ProgID et CLSID
Serveur OPC
• 56 •
Woodhead
Création d'un objet OPCGroup
La création d’un groupe par le client s’effectue par un appel à la méthode AddGroup de l’interface
IOPCServer de l'objet OPCServer.Celle-ci comporte notamment les paramètres suivants :
Nom
Description
szName
Nom du groupe. S'il n'est pas fourni, le serveur en génère un unique (de la
forme APPGROUP + un numéro incrémental).
dwRequestedUpdateRate
Période de rafraîchissement demandée par le client. La période réellement
admise par le serveur sera retournée dans le paramètre de retour
dwRequestedUpdateRate.
dwLCID
Ce paramètre n’est pas exploité.
pPourcentDeadBand
Ce paramètre permet de limiter le retour de la variable au forte variation
(voir "Gestion des groupes")
Voir également :
dans ce manuel :
Gestion des groupes (OPC Group)
Gestion des items
La création d’items par le client s’effectue par un appel à la méthode AddItem de l’interface
IOPCItemMgt de l'objet OPCGroup. Chaque item symbolise une connexion vers une variable
physique. En fait, le client décrit la variable qui l’intéresse par le biais d’une structure
OPCITEMDEF.
Les champs de cette structure sont les suivants :
Nom
Description
szAccessPath
®
Non exploité par le serveur OPC applicom .
szItemID
Chaîne de caractères référençant l’item.
bActive
indique l'état d'activation de l'item au moment de sa création.
hClient
Handle de référence du point pour le client.
dwBlobSize
le mécanisme de “blob” n’est pas exploité par le serveur OPC applicom®.
pblob
le mécanisme de “blob” n’est pas exploité par le serveur OPC applicom®.
vtRequestedDataType
Type du variant demandé par le client . La valeur VT_EMPTY désigne le type
par défaut (décidé par le serveur). Utilisez le renvoi 1 pour connaître les types
de variant supportés.
Remarques :
Lors de l’ajout d’un nouvel item dans un groupe par la méthode AddItems, le serveur OPC
détermine automatiquement le type canonique de la variable et le retourne dans le champ
vtCanonicalDataType de la structure OPCITEMRESULT.
Sauf besoin particulier, Il est donc conseillé à l’application client de toujours passer la
valeur VT_EMPTY dans le champ vtRequestedDataType, laissant ainsi le serveur
déterminer lui-même le type de la variable.
Serveur OPC
• 57 •
Woodhead
Voir également :
dans ce manuel :
Types de données supportés par le serveur OPC
Remontée des données
L'objet OPCGroup et ses différentes interfaces offrent au client quatre voies possibles pour lire des
données :
Mécanisme événementiel (IDataObject/IAdviseSink en V1.0A ou
IConnectionPoint/IOPCDataCallback en V2.0)
Lecture synchrone (IOPCSyncIO::Read )
Lecture asynchrone (IOPCAsyncIO::AsyncRead en V1.0A ou
IOPCAsyncIO2::AsyncRead en V2.0)
Rafraîchissement asynchrone du groupe (IOPCAsyncIO::Refresh en V1.0A ou
IOPCAsyncIO2::Refresh en V2.0)
et deux possibilités pour écrire :
Ecriture synchrone (IOPCSyncIO::Write)
Ecriture asynchrone (IOPCAsyncIO::AsyncWrite en V1.0A ou
IOPCAsyncIO2::AsyncWrite en V2.0)
Remarques :
Lors de lectures/écritures asynchrones, si les demandes sont envoyées plus rapidement
qu'elles ne peuvent être traitées par le serveur, celui-ci les empile. Si trop de requêtes sont
empilées, les demandes sont refusées.
Attention : en version 1.0A, le mode événementiel s’appuie, en conformité avec la
spécification, sur les interfaces standards OLE IDataObject et IAdviseSink. L’appel par le
serveur de la fonction OnDataChange du client est en fait un appel asynchrone (cf aide en
ligne de l’interface IAdviseSink). Il est par conséquent impératif que l’application client soit
en mesure de récupérer les données aussi rapidement que le serveur les transmet. Dans
le cas contraire, les appels sont empilés par le système, entraînant une diminution de la
mémoire disponible pouvant aller jusqu'à épuisement. Ce phénomène peut survenir
d’autant plus que le serveur est rapide. Il peut donc être provoqué lorsque le client
demande une surveillance de données en constante évolution (variables analogiques,...) à
des périodes de rafraîchissement très faibles.
Voir également :
dans ce manuel :
Exemple de client OPC en C++
Le package du serveur OPC inclut un client OPC développé à l’aide de Visual C++ 6.0. Ce client,
dont tous les codes source sont fournis (dans le sous-répertoire OPC), vous permettra de tester la
fonctionnalité du serveur OPC et pourra constituer un modèle de base pour votre propre
développement.
Attention :
Serveur OPC
• 58 •
Woodhead
Ce client a été développé à but d’exemple de programmation et de test. Il s’agit d’une application
monothread dont les mécanismes d’affichage ne sont vraiment pas optimisés (l’utilisation de liste
pour l’affichage des items est très gourmande en ressources CPU). Dans le cas de périodes de
rafraîchissement demandées très petites, des changements de valeurs fréquents peuvent
engendrer un blocage du rafraîchissement du client. Ce phénomène ne peut pas être imputé aux
performances du serveur OPC, mais au contraire, aux remontées rapides effectuées par celui-ci et
engendrant un engorgement au niveau du redessin de l’application client.
Informations nécessaires au développement
ProgID et CLSID
Le serveur OPC applicom® sera identifié dans le système d’exploitation MS-Windows à l’aide de
son ProgID (identificateur de programme) et de son CLSID (identificateur de classe), enregistrés
dans la base de registres de la machine durant l’installation :
ProgID “APPLICOM.OPCServer” ;
CLSID
{283618B2-8349-11D0-8F82-0080C85344A1}.
Types de données supportés par le serveur OPC
Le serveur OPC applicom® supporte les types de donnée suivants :
Type de variant
Type de donnée
VT_BOOL
Booléen
VT_UI1
octet non signé
(de 0 à 255)
VT_I1
octet signé
(de -128 à 127)
VT_UI2
entier 16 bit non signé
(de 0 à 65535)
VT_I2
entier 16 bit signé
(de -32768 à 32767)
VT_UI4
entier 32 bit non signé
(de 0 à 4294967295)
VT_I4
entier 32 bit signé
(de -2147483648 à 2147483647)
VT_R4
flottant IEEE sur 4 octets
(de -3.4e+38 à 3.4e+38)
VT_R8
flottant IEEE sur 8 octets
VT_BSTR
chaîne ASCII
Limite
Les types précédents (excepté VT_BSTR) peuvent être associés avec le type VT_ARRAY pour
indiquer que la variable est de type tableau.
Voir également :
dans la base de connaissances :
Serveur OPC : Types de données retournées par le serveur OPC
Serveur OPC
• 59 •
Woodhead
Remontée des données et comportement du serveur
Le tableau suivant résume le comportement du serveur OPC en fonction de l’état du groupe, de
celui de l’item et de la provenance des données.
Fonction
Provenance
des données
Groupe
Active
Item
Activé
Comportement et code de retour
Lecture synchrone
CACHE
O
O
La valeur et la qualité des items demandés
sont retournées.
CACHE
O
N
Les items sont retournés avec le drapeau de
qualité OPC_QUALITY_OUT_OF_SERVICE
CACHE
N
O|N
Les items sont retournés avec le drapeau de
DEVICE
O|N
O|N
La valeur et la qualité des items sont
retournées après une lecture dans les
équipements
CACHE
O
O
La valeur et la qualité des items demandés
sont remontées par l’appel à OnDataChange
ou par l'interface IOPCDataCallback.
CACHE
O
N
Les items demandés sont retournés par
l’appel à OnDataChange ou par l'interface
IOPCDataCallback avec le drapeau de
CACHE
N
O|N
Les items demandés sont retournés par
l’appel à OnDataChange ou par l'interface
IOPCDataCallback avec le drapeau de
DEVICE
O|N
O|N
La valeur et la qualité des items sont
retournées par l’appel à OnDataChange ou
par l'interface IOPCDataCallback après une
lecture dans les équipements
CACHE
DEVICE
O
O|N
La valeur et la qualité de tous les items actifs
dans le groupe sont retournées par l’appel à
OnDataChange
ou
par
l'interface
IOPCDataCallback.
Le serveur retourne E_FAIL si aucun item
n’est actif dans le groupe.
N
O|N
Le serveur retourne E_FAIL immédiatement.
O
O|N
Les données sont remontées (pour les items
actifs ayant changés depuis la dernière
remontée).
N
O|N
Les données ne sont plus remontées.
Lecture
Asynchrone
Rafraîchissement
du groupe
Mode
événementiel
Les flags de qualité
A chaque item sont associés des “flags” de qualité permettant à l’application client de connaître la
validité de l’item. Les flags sont disposés suivant le modèle suivant :
QQSSSSLL
Serveur OPC
• 60 •
Woodhead
QQ : ce sont les bits de qualité principaux. Les valeurs retournées par le serveur applicom®
peuvent être 0 (mauvais), 1 (incertain) ou 3 (OK)
SSSS : le sous-status commente la valeur du satus QQ. Le serveur OPC retourne entre autre
valeur 7 (Out Of Service) quand les bits QQ sont positionnés sur 0 (mauvais). Ce sous-status est
retourné si le client effectue une lecture synchrone ou asynchrone dans le cache alors que l’item
n’est pas actif.
LL : Permet d'indiquer un dépassement haut ou bas de la valeur.
Voir également :
dans ce manuel :
Qualité des items
Serveur OPC
• 61 •
Woodhead
12. Index
AccessPath, 9
ActiveX de communication, 75
ADVISE_FAILED, 41, 54
Asynchrone, 15, 28, 51, 81, 86
Bande morte, 13
Bit de mots, 32
Browsing, 12
Cache, 86
Client OPC, 74, 82
CLSID, 78, 84
Configuration, 30, 31
Configuration des topics, 21, 24, 49
CTS, 64
Custom interface, 75
DCD, 64
Descripteurs, 24, 35, 38
Developpement, 74
Device, 86
Diagnostic, 39, 52
Diagnostic du serveur OPC, 65
DLL automation, 75
Evénementiel, 15, 81
Flags de commandes, 58
Fonctions cycliques, 57, 58, 60
Groupes OPC, 13, 79
Horodatage, 16
INPUT, 63
Interface, 77
Interface graphique, 6
Item, 9, 33, 60, 80
ItemID, 9
LIMIT_ALLOWED, 62
LIMIT_MAX_USED, 62
LIMIT_OVERFLOW, 62
LIMIT_USED, 62
Limitation Logix, 52
Limitations, 18
Mode expert, 8
Mode Message, 31
Mode tableau, 29, 30
Modems, 64
NB_POINT, 62
NB_TOPIC, 62
Noms symboliques, 44
Optimisation Logix, 49, 51
Paramètres serveur OPC, 7
ProgID, 11, 78, 84
Qualité d'une donnée, 17, 87
READ_ERROR, 43, 56
RTS_DTR, 64
Serveur OPC, 3
Signaux modems, 64
Serveur OPC
• 62 •
Index
Woodhead
STATUS, 40, 53
Synchrone, 15, 28, 51, 81, 86
Syntaxe Logix, 50
SYSTEME, 62
Topic, 9, 20
Topics Fonction cyclique, 20, 58, 60
Topics prédéfinis, 20, 62, 63, 64
Topics variable image, 20, 22
Topics variable locale, 20, 22
Variable image, 22, 48
Variable internes, 24
Variable locale, 22
Variable Logix, 48
Variable OPC, 22, 48, 85
Variables internes, 50
WATCHDOG, 63
WRITE_ERROR, 42, 55
Serveur OPC
• 63 •
Index

Serveur OPC

Transcription

Documents pareils

performance appraisal form template

TP liaison OPC

CENTRE COMMERCIAL LA PART-DIEU

retrocessions opc

source SIX Financial Information France - CM

Fiche produit - CM-CIC Asset Management

Exploitation des données industrielles via OPC - OPC - 30 h

Passerelle OPC - TIL Technologies