INTRODUCTION A LA SUPERVISION

SUPERVISION
Les logiciels de supervision sont une classe de
programmes applicatifs dédiés au contrôle de
processus et à la collecte d'informations en temps
réel depuis des sites distants, en vue de maîtriser un
équipement.

Place de la supervision dans le Système de

Production
SCADA (supervisory control and data acquisition)

Un système SCADA inclut des composants hardware

et software.

Les éléments hardware assurent la collecte des

informations qui sont à disposition du calculateur sur
lequel est implanté le logiciel de supervision.

Le calculateur traite ces données et en donne une

représentation graphique réactualisée périodiquement.

Le système SCADA enregistre les évènements dans des

fichiers ou les envoie sur une imprimante, par mail...

Le système surveille les conditions de fonctionnement

anormal et génère des alarmes.
 Fonctionnalités d’un système SCADA

L’objectif du système SCADA est de mener une

conduite réactive de processus. Les fonctions en marche
normale sont:

L'envoi de consignes vers le procédé dans le but de

provoquer son évolution.

L'acquisition de mesures ou de compte-rendus

permettant de vérifier que les consignes envoyées vers le
procédé produisent exactement les effets escomptés.

L'acquisition de mesures ou d'informations permettant

de reconstituer l'état réel du procédé et/ou du produit.

La recherche des causes de l'apparition d'un

fonctionnement ne correspondant plus à ce qui est attendu.

L'envoi vers le procédé d'ordres prioritaires

permettant de déclencher des procédures de sécurité
(arrêts d'urgence par exemple)

La recherche des conséquences de l'apparition d'un

fonctionnement non prévu ou non contrôlé
 L'élaboration de solutions permettant de pallier le
fonctionnement non prévu

La modification des modèles utilisés pendant le

fonctionnement prévu pour revenir à ce fonctionnement:

Changement de la commande, réinitialisations, etc.,

La collaboration avec les opérateurs humains pour

les prises de décision critiques

Sous-ensembles du système SCADA

Le système SCADA comprend 3 sous-ensembles

fonctionnels:

- la commande

- la surveillance

- la supervision

Partie Commande du système SCADA

 Son rôle est de faire exécuter un ensemble
d'opérations au procédé en fixant des consignes de
fonctionnement en réponse à des ordres d'exécution.

Il s'agit de réaliser généralement une séquence

d'opérations constituant une gamme de fabrication dans le
but de fabriquer un produit en réponse à une demande
d'un client.

La commande regroupe toutes les fonctions qui

agissent directement sur les actionneurs du procédé qui
permettent d’assurer :

- le fonctionnement en l'absence de défaillance,

- la reprise ou gestion des modes,
- les traitements d'urgence,
- une partie de la maintenance corrective.

Partie Surveillance du système SCADA

 La partie surveillance:

- recueille en permanence tous les signaux en

provenance du procédé et de la commande

- reconstitue l'état réel du système commandé

- dresser des historiques de fonctionnement

- met en oeuvre un processus de traitement de

défaillance le cas échéant.

Partie Supervision du système SCADA

 Contrôler et surveiller l'exécution d'une opération.

En fonctionnement normal, son rôle est surtout de

prendre en temps réel les dernières décisions.

Pour cela elle est amenée à modifier en ligne la

commande et à gérer le passage d'un algorithme de
surveillance à l'autre.

En présence de défaillance, la supervision va prendre

toutes les décisions nécessaires pour le retour vers un
fonctionnement normal.

Cahier des charges externe d’un système SCADA

Accéder aux informations (lecture et écriture) des unités
de traitement (automates, régulateurs, chaînes
d’acquisition, cartes E/S, terminaux...) en temps réel.

Ces périphériques sont hétérogènes: ils utilisent des

communications physiques diverses (liaison série, réseau
TCP/IP…) et des protocoles différents (Modbus, ….).

Visualiser les informations dans une interface HMI du

type graphique réactif.

L’environnement graphique peut être propriétaire

(logiciel graphique intégré au superviseur) ou standard.

La visualisation graphique sur poste distant est souvent

demandée par l’exploitant.

La visualisation peut être répartie sur plusieurs postes

graphiques pour les applications de grande dimension.

Agir automatiquement sur le processus (par

l’intermédiaire des automates)

Calculer des grandeurs définies par des formules et/ou

des séquences d’évènements
Détecter prioritairement les situations d’alarme, gérer les
alarmes multiples, lancer les actions sur le processus et
prévenir les opérateurs, y compris à distance (envoi de
sms, mails, appel téléphonique automatique)

Gérer la prise en compte des alarmes par les opérateurs

(acquittement)

Donner les moyens de contrôle direct des opérateurs sur

le processus (forçage)

Fournir des recettes pour les changements de gamme de

fabrication

Enregistrer les valeurs des variables et les actions des

opérateurs en vue d’une analyse ultérieure des incidents

Archiver sélectivement les données (grandeurs sources,

variables internes calculées, commandes, alarmes)

Donner des outils d’analyse de données en vue d’une

exploitation statistique.

Cahier des charges d’un système SCADA

Gérer la sûreté de fonctionnement

 - sûreté interne des programmes

- sûreté de la machine support du superviseur

- sûreté vis à vis des demandes de l’utilisateur

(verrouillage de fonctionnalités suivant le niveau
hiérarchique de l’utilisateur)

- identification de l’utilisateur

- sûreté des communications (détection des

défauts de mise à jour des variables)

Analyse des caractéristiques d’un SCADA

Système d’exploitation
 - Mono ou multi-utilisateurs

- mono ou multi-tâches (traitement de la base de

données, rafraîchissement des vues, alarmes,
communications, édition...)

- périodicité des tâches garanties ou non

- interruption de tâches

Communications

- type et nombre de cartes supportées

- communications entre tâches

Supervision répartie

- postes autonomes en réseau

- répartition des tâches ou des variables entre

plusieurs postes
- postes clients d’un serveur Multi-Utilisateur

Base de données « variables» du superviseur

 - contient les informations venant des processus
relatives aux automatismes

- rafraîchissement :
* Cyclique (mise à jour périodiquement)
* Sélectif (mise à jour uniquement des
variables des vues de l’écran actif)
* Flash (mise à jour à l’ouverture d’une
vue)
* Sur exception (rafraîchissement sur
changement d’état des variables)

- Capacité

Traitements graphiques

- cartes et résolutions supportées

- redimensionnement des vues
- redimensionnement des textes
- courbe de conduite, historique d’une variable

Conduite
- télécommande directe du processus par forçage
des variables
 - validation de la conduite

Traitement des alarmes

- hiérarchie et priorité des alarmes
- datation
- acquittement par des postes multiples

Archivage
- historique des variables
- archivage sélectif
- archivage court terme/long terme
- capacité et structure d’archivage
- archivage sur structure standard (SQL, Oracle...)

Programmation
- éditeur graphique
- bibliothèque de composants
- programmation des fonctions prédéfinies
- développement de traitements spécifiques
- extensions matérielles (nouveau couplage)
- extension logicielle par ajout de composants
externes

Sûreté de fonctionnement
- sûreté de communication
 - sûreté du matériel de traitement (coupure
d’alimentation, fiabilité du système d’exploitation)
- sûreté du logiciel de supervision
- sûreté des commandes (contrôle d’accès aux
vues, protection des variables)

Performances/Prix
- prix de l’équipement complet (matériel +
système d’exploitation + logiciel)
- mise à jour, assistance, documentation

Application
Rôle de la supervision
Chercher des informations dans l’automatisme pour
renseigner l’opérateur
Envoyer des informations à l’automatisme à partir des
ordres donnés par l’opérateur

Le logiciel de supervision
Un logiciel de supervision est souvent désigné par le
terme SCADA
Un SCADA s’installe et s’utilise sur un micro-ordinateur
de type PC.

Un SCADA permet de créer une application graphique

qui reproduit à l’écran le procédé à automatiser.

Il permet d’utiliser des langages de programmation. Mais,

ce n’est pas un langage de programmation.

Ses outils graphiques permettent de définir une interface

utilisateur à partir d’objets graphiques qui sont une
représentation graphique d’un procédé.

Un SCADA gère également les fonctionnalités telles que

les alarmes, les consignations, les tendances (courbes
temps réel ou historiques), le stockage de données, …

Un SCADA communique avec l’automatisme via des

réseaux ou des bus.
Les liens entre le procédé et la supervision
Termes et concepts de base
- Télé-commande ou Télé-réglage : pour envoyer une
information vers l’automatisme
- Télé-signalisation ou Télé-mesure : pour obtenir une
information de l’automatisme
A chaque objet graphique est associé un type
d’animation et une variable de l’automatisme
Télé-Signalisation (TS)
- visualiser un état de type tout ou rien (TOR)
- associé à un bit de l’automatisme
Changement de couleur en fonction de l’état du bit lu
dans l’automatisme.
Ex : savoir si le moteur est en marche ou à l’arrêt
Ex : être informé d’un défaut moteur
Télé-Mesure (TM )
- visualiser une valeur de type analogique (ANA)
- associé à un mot de l’automatisme
Ex : connaître la vitesse en cours
Télé-Commande (TC)
- commander une action de type tout ou rien (TOR) -
associer à un bit de l’automatisme
Ex : action opérateur pour mettre en marche ou en arrêt
un moteur
Télé-Réglage (TR )
- envoyer une valeur de type analogique (ANA)
- associé à un mot de l’automatisme
Ex : saisie opérateur d’une consigne de vitesse à atteindre
 Types d’animation utilisés

Chaînage des synoptiques

La navigation entre les synoptiques s’effectue à partir de
« boutons » paramétrés avec l’animation « Chaînage ».

Visualisation des messages d’alarmes

L’animation « Liste des alarmes » permet de visualiser
les alarmes sous forme de messages

Enregistrement des changements d’état

L’animation « Consignation » permet d’enregistrer tout
changement d’état ou de valeur dans une base de données
pour la visualiser ultérieurement sous forme de liste.

Enregistrement périodique
La fonction « Tendance » permet d’enregistrer une
valeur dans une base de données pour la visualiser
ultérieurement sous forme de courbes.

Visualisation des changements d’états

L’animation « Liste des consignations » permet de
visualiser la liste des changements d’états qui ont été
enregistrés dans la base de données.
Visualisation sous forme de courbes
L’animation « Courbes temps réel » permet de
visualiser une valeur sous forme de courbes.
Les étapes à suivre pour développer une application.
 Lecture du cahier des charges

Description du procédé

Un « réservoir » est alimenté par l’intermédiaire

d’une vanne V1.

Une navette est alimentée à partir de ce réservoir par

l’intermédiaire d’une pompe P1.

Un opérateur placé à proximité de la navette doit

contrôler visuellement son remplissage avant son
évacuation.

Pour cela il dispose d’un système de commande

composé d’un automate et d’un poste de supervision à
base de PC.
 Lecture du cahier des charges
Partie automate / traitement du procédé

L’automate gère le procédé et dispose des entrées

/ sorties suivantes :
- pour V1 : commande d’ouverture,
commande de fermeture, défaut vanne
- pour P1 : commande de marche, commande
d’arrêt, défaut pompe
- pour le réservoir : indicateurs niveaux
haut/bas atteints et capteur de niveau analogique
 Partie PC / supervision

Le PC communiquera avec l’automate en bus.

L’opérateur devra pouvoir :

- surveiller l’état de V1, P1 et le niveau du

réservoir.
- commander l’ouverture/fermeture de V1 et
l’arrêt/marche de P1.

- visualiser la liste des défauts apparus.

- visualiser le niveau du réservoir sous forme

de courbe.

Toutes les commandes, changements d’états et

alarmes seront consignés sur le disque dur du PC et
visualisables.

Le niveau du réservoir sera historié sur le disque

dur du PC.
 Analyse du cahier des charges

L’analyse du cahier des charges permet

d’identifier les points qui seront discriminants pour le
développement de l’application :

1/ comment s’effectuera la communication

entre le PC et l’automate :

- le type de liaison utilisée : bus xxxx sur la

prise yyyy de l’automate / sortie ‘COM1’ du
PC
- le type et le nombre d’objets automate
nécessaires au pilotage du procédé à partir du
PC :
12 bits pour les commandes/états/défauts/niveaux
haut/niveau bas et 1 mot pour le niveau du réservoir

2/ comment sera représenté et comment sera

suivi le procédé :
- un synoptique représentant la vue d’ensemble du
procédé
- un synoptique visualisant les alarmes en cours
- un synoptique visualisant tous les changements
d’états et alarmes apparus
 - un synoptique visualisant l’historique du niveau
du réservoir
- les actions opérateur nécessaires à la navigation
inter-synoptiques

3/ comment s’effectuera la surveillance et la

commande des organes du procédé :

- voyants permettant de visualiser les 3 états de

V1, les 3 états de P1 et les niveaux haut/bas réservoir.

- animation permettant de visualiser l’évolution de

niveau du réservoir.

- actions opérateur permettant de commander

l’ouverture/fermeture de V1 et l’arrêt/marche de P1.

4/ quels sont les états ou valeurs à enregistrer :

- consignation de tous les changements d’états et

des alarmes

- historisation du niveau du réservoir

 Analyses fonctionnelle et organique Cette
étape est primordiale

Ces deux analyses permettent de définir de quelle

manière seront résolus les points identifiés lors de
l’analyse du cahier des charges et de se synchroniser avec
la personne qui développe le programme automate.

A ce stade la connaissance des fonctionnalités du

logiciel de supervision est nécessaire.

1/ Communication entre le PC et l’automate :

- Prévoir une communication xxxx installer
le driver sur le PC

- Affecter les zones d’adresses des objets

automate nécessaires au pilotage du procédé

2/ Représentation et suivi du procédé :

- 4 synoptiques : Procédé, Liste des larmes, Liste
des consignations et Evolution du niveau réservoir

- Le synoptique Procédé sera le synoptique

d’accueil et permettra d’accéder aux trois autres
 3/ Surveillance et commande des organes du
procédé :
- 3 voyants pour V1, 3 voyants pour P1, 2 voyants
pour le niveaux haut atteint et bas atteint du réservoir.
- réservoir sous forme de barre graphe permettant
de visualiser l’évolution de niveau du réservoir.

- 2 boutons pour V1 et 2 boutons pour P1.

4/ Etats et valeurs à enregistrer :

- consignation des TS, TC et alarmes (table

« consignation » de la base de données)

- historisation (tendance) du niveau du réservoir

(table « tendance » de la base de données)
 Synthèse des analyses

Synthèse sous forme de représentation symbolique

 Organisation des données dans l’automate
Le traitement du procédé (programme automate) est
supposé être déjà en partie réalisé.
Recommandation : réservation d’une zone de bits et
de mots spécifiques à la supervision.
1/ le programme automate doit recopier les
entrées/sorties utilisées pour la conduite du procédé dans
une zone d’adresses consécutives réservée à la
supervision.
2/ chaque objet est « nommé » par un symbole qui
sera utilisé par la suite dans le logiciel de supervision.
Puis les variables doivent être exportées dans un fichier

Exemple de fichier (api.*)

 Configuration de la communication
Choisir le mode Diagnostic
Paramétrer la communication
Indiquer le chemin du fichier (api.*)

Test de la communication
Lancer le “client de test” et vérifier la présence des
variables “nommées” dans l’automate.
Sélectionner une variable et vérifier son comportement en
correspondance avec une table d’animation.

Représentation graphique du procédé

Créer un nouveau synoptique « Procédé » et utiliser

les outils graphiques pour :

Identifier le synoptique dans la barre de titre

Représenter la surveillance et la commande des organes

du procédé

Représenter le procédé
 Animation et affectation des variables
Utiliser les outils d’animation :

1/ Choisir le type d’animation

2/ Affecter la variable correspondante : Vanne_ouverte
3/ Définir l’animation

Test des animations

Si l’automate est connecté:

1/ Soit en forçant directement les entrées/sorties des

coupleurs (automate en RUN)
2/ Soit à partir d’une table d’animation (l’automate en
STOP)
Vérifier la correspondance Etat / Valeurs <==>
Animations

Les alarmes
Caractéristiques d’une alarme :

Les alarmes sont destinées à informer l’opérateur d’un

danger susceptible d’occasionner des dégâts d’ordre
matériel (sécurité des machines) ou corporel (sécurité
des personnes).
Les événements liés aux alarmes sont de caractère
« exceptionnel ».

En règle générale :

- l’apparition d’une alarme nécessite une action

d’acquittement par l’opérateur (prise en compte du
danger).
- les alarmes sont également consignées, c’est à dire
enregistrées sur disque dur (traçabilité des défauts).
Toutes les variables du procédé concernées par ce cas
seront déclarées « Alarmes » et « Consignations ».

Dans notre exemple 4 variables seront déclarées alarme

et consignation :
- Vanne_defaut
- Pompe_en_defaut
- Cuve_niv_haut
- Cuve_niv_bas

Les alarmes peuvent être visualisées de deux manières

différentes :

Sous forme graphique (outils d’animation)

Sous forme de liste
 Les consignations

Caractéristiques d’une consignation :

Les consignations sont destinées à dater et enregistrer sur

le disque dur les changements d’état ou de valeur des
variables de l’application à des fins de traçabilité.

En règle générale la consignation concerne :

- les alarmes : apparition, acquittement, disparition

- certaines actions opérateur :

- commande d’un organe : « ouverture vanne »,
« fermeture vanne »
- modification d’une consigne : « valeur de
remplissage à atteindre »
- accès à un synoptique

- les états d’un organe : « moteur en marche », « moteur à

l’arrêt »

Toutes les variables du procédé concernées par ce cas

seront déclarées « Consignations ».
Dans notre exemple 8 variables en suppléments des
alarmes seront déclarées consignation :

- Vanne_ouverte, Vanne_fermée
- Pompe_en_marche, Pompe_en_arret
- Ouverture_vanne, Fermeture_vanne
- Marche_pompe, Arret_pompe

Courbes de tendance « temps réels /

historiques »

La visualisation sous forme de courbes d’une valeur

analogique peut être traitée de deux manières différentes :

Mode temps réel :

- Visualisation de l’évolution d’une variable à

l’instant T.
- C’est à dire sans enregistrement sur le disque
dur.
- Les valeurs « passées » sont perdues.
- L’animation est uniquement graphique : Objet
« courbes de tendances »
- Aucun paramétrage de base de données.
Mode historique :

- Visualisation de l’évolution d’une variable à

l’instant T, et depuis le démarrage de l ’application.
- C’est à dire avec enregistrement sur le disque
dur.
- Les valeurs « passées » ne sont pas perdues.
- L’animation est identique au mode temps réel :
objet « courbes de tendances »
- Nécessité d’utiliser et de paramétrer une base de
données.

Les courbes de tendances historisées

Caractéristiques d’une tendance :

Les tendances sont destinées à dater et enregistrer sur le

disque dur les évolutions d’état ou de valeur des
Variables de l’application de manière périodique.

En règle générale les tendances concernent les valeurs

analogiques de type « Niveau de fluide », « Température
de four », « Débits de pompe », ...

Toutes les variables du procédé concernées par ce cas

seront déclarées « Tendances »
Dans notre exemple :

- aucune variable n’est utilisée en mode temps réel.

- une variable est utilisée en mode historisée :
Niveau_cuve

Elle sera déclarée tendance :

La période d’enregistrement est définie par défaut à 10
Secondes

Paramétrage des périodes d échantillonnage

N’oubliez pas de paramétrer les fréquences de mise à jour

Attention :

Les différentes fréquences de mise à jour paramétrées

dans le logiciel de supervision déterminent les
Périodes de scrutation dans l’automate et donc les
fréquences auxquelles les variables seront « surveillées ».

Par exemple, si une variable automate est capable de

changer de valeur en 3 secondes il est conseillé de prévoir
une fréquence de mise à jour du 1/3, c’est à dire 1seconde.
 Architecture client serveur

Dans une application client-serveur, on distingue le client,

qui va générer des questions ou requêtes à travers le
réseau, et le serveur, qui gère les informations et va
effectuer les traitements, en fonction des requêtes émises
par les clients.

Le contenu théorique du modèle

Le modèle client-serveur peut se résumer en un dialogue

entre deux programmes.
Ce dialogue consiste en un échange d'information ( de
données ou le résultat d'un calcul). Lors de ce dialogue, la
relation entre ces deux programmes est de type "égal à
égal" (peer to peer en anglais) et non pas un rapport
"maître-esclave" comme on le pratiquait dans un
environnements centralisés.

Le client-serveur implique un dialogue d'égal à égal.

Remarques :
Cette relation d'égal à égal n'implique pas que les deux
programmes soient identiques, ni dans leur nature, ni
dans leurs rôles, ni dans les systèmes d'exploitations qui
les supportent. .
On peut dégager un premier niveau de différence en
identifiant celui des deux programmes qui a initié le
dialogue, et celui qui s'est contenté de répondre.
C'est ici que se situe la distinction entre le client et le
serveur.
Le client, c'est le programme ayant provoqué
l'établissement de la "conversation", et le serveur, c'est le
programme "répondant" fournissant des données ou des
résultats.
Le client est à la base du dialogue.
Le serveur est un programme générique dont le seul objet
est de répondre aux demandes des applications clientes en
fournissant en retour des données ou des résultats de
calcul. Le client est une application au sens propre du
terme. ingenieur etude client
Les demandes des applications sont généralement
qualifiées de requêtes.
Le serveur est, part nature, indépendant des applications
qui l'interrogent, il y a aucun lien fonctionnel avec ces
dernières, il ignore tout des clients qui lui soumettent des
requêtes si ce n'est leur niveau d'autorisation et leur
adresse réseau.

Les principes de bases

architecture client serveur
Définition
Une application est conforme au modèle client-serveur
lorsqu'elle fait appel à des services distants au travers
d'un échanges de message plutôt que par un échanges de
fichiers. , ingenieur etude client

Ce modèle suppose un fonctionnement "associant"

plusieurs ordinateurs reliés entre eux par un réseau. Ce
fonctionnement associatif repose sur un dialogue :
reseau client serveur

• émission de requêtes
• appels de service par le client et émission des résultats
par le serveur

tous ceci régi par un protocole qui assure le bon

déroulement des échanges.

LIAISON DDE (Dynamic Data Exchange)

PRINCIPE DE LA LIAISON DDE ENTRE TACHES

 · Processus d’échange sous Windows
- existe depuis les premières versions de Windows

* intégré à de nombreux logiciels usuels (Word, Excel,

Matlab, OpenOffice...)
* mode d'échange parmi les plus utilisés dans le monde
industriel.

Chaque application possède une interface de gestion de la

liaison DDE.
Un lien DDE ne peut être lancé sur une application
serveur que si cette dernière a été conçue pour répondre à
ce type d'événement (interface serveur).

Fonctionnement général du service:

· Demande d'ouverture du canal de communication faite

par le client. DDEInitiate
- Le client reçoit un « handle » identifiant sa connexion
au serveur.
- Si l'application serveur n'est pas lancée, le système peut
la lancer automatiquement (option) .
- En cas d'échec d'accès à l'application serveur, le client
est informé.
- Le serveur peut rejeter la demande de connexion
· Fermeture du canal en fin d’échange
DDETerminate

Echange de données à la demande du client

Demande de lecture d’une donnée:
DDERequest
Demande d’écriture d’une donnée:
DDEPoke

Type de données échangées:

Toute donnée en format « clipboard » (presse-papier)

en ASCII TEXT DDE FORMAT
en BINARY TABLE DDE FORMAT ("Fast-
Table")

Eléments de définition du lien

 Un lien vers une application serveur est défini par 3
champs:
le champ Application qui désigne le nom de
l'application serveur.
Le nom du service DDE peut être différent du nom du
programme
le champ Topic interprété par le serveur.
Généralement, ce champ désigne une fonctionnalité
de base du serveur, comme par exemple le fichier sur
lequel le serveur doit travailler.
le champ Item interprété par le serveur; désigne
généralement le nom De la variable à échanger.
Ce champ est optionnel; certaines applications
"serveur" n'y font pas référence

Structure de données d’un serveur

multi-applications
Certains serveurs peuvent présenter plusieurs services
DDE; chaque service est spécifié par un nom
d'application différent

Exemple: Lien DDE sous Excel

· Excel est à la fois serveur et client DDE

· L'écriture d'une liaison DDE est directe dans le sens

Serveur--Excel
le lien DDE fait partie du vocabulaire des formules de
calcul Excel(champ calculé)

· Pour affecter à une cellule une valeur fournie par une

autre application, il suffit définir une formule dont la
syntaxe est la suivante:
 = Application | Topic ! Item
L'affectation d'une valeur à une cellule par un lien DDE
est équivalente à un DDERequest
automatique

· Exemple: échange entre deux applications

Excel ouvertes simultanément

serveur « Compta » client « Recap »

-lecture de la cellule A1 du classeur « Compta » par

l ’application « Recap » ;la valeur sera affichée dans la
cellule B1 du classeur "Recap »

formule de B1 : = ‘ Excel ’ | ‘ Compta.xls ’ ! ’L1C1 ’

Remarques:

· La syntaxe de désignation des cellules du type

Ligne/Colonne .
· Le lien DDE écrit sous forme de fonction dans une
cellule est exécuté automatiquement lors de la réécriture
de la valeur source sur le serveur . La suppression du
recalcule automatique côté client entraîne l'arrêt de
l'échange DDE.

Serveurs OPC

OPC signifie
Object Linking and Embedding for Process Control.

Objectifs du standard OPC

• Standardiser les échanges de flux entre équipements

hétérogènes communicants.

• Limiter la prolifération des protocoles

• Faciliter la maintenance des communications

• Pérenniser les installations

• Donner le choix des fournisseurs aux utilisateurs

• Permettre aux exploitants de ce concentrer sur leur
métier.

Sans OPC

‫ ـ‬Conflits d ’accès
Deux logiciels ne peuvent pas accéder simultanément à la
meme ressource matérielle

‫ ـ‬Incompatibilité entre différents vendeurs

Des ressources matérielles peuvent ne pas être pas
supportées par certains logiciels

‫ ـ‬Evolutions matérielles difficiles

Une évolution des spécifications d’un matériel peut
bloquer le fonctionnement d’un logiciel qui demande une
réécriture

‫ ـ‬Duplication des efforts de développement

Chaque logiciel doit s’interfacer avec chaque matériel

Avec OPC
 Que comprend la spécification OPC ?

- une spécification commune à tous les serveurs

OPC Common et OPC Security

- l’accès aux données en temps réel

OPC Data Access .

- la gestion des alarmes et événements

 OPC Alarm & Event.

- la construction d ’historiques

OPC Historical Data Access

- les traitements par lot

OPC Batch

Sur quelle architecture repose OPC [version

"classique"] ?
- la spécification COM/DCOM de Microsoft

Distributed Component Objet Model

- COM implémente les connections entre les

différents composants logiciels d'une application et forme
un "bus" logiciel indépendant du langage de
programmation.

- COM n'estintégré que sur machine Windowsd'où

difficulté d'intégration directe d'un serveur ou d'un
client sur une machine embarquée( automate...).
 -Concrètement, OPC est limité à l'architecture Windows
-Un serveur OPC est donc généralement une machine
Windows externe reliée à des automates, des E/S
déportées, des capteurs "intelligents"...
-Une machine peut inclure plusieurs serveurs OPC.