Transcript S8205 - IIS Windows Server

Programmation graphique des
applications de contrôle-commande
par
Francis COTTET
Professeur d’Université
LISI/ENSMA
et
Patrick RENARD
Directeur de la communication
National Instruments France
1.
1.1
1.2
1.3
Généralités.................................................................................................
Applications de contrôle-commande.........................................................
Conception et programmation des applications de contrôle-commande
Programmation graphique en contrôle-commande.................................
2.
2.1
2.2
2.3
Langage graphique G ..............................................................................
Programmation graphique flot de données ..............................................
Environnement de développement en langage G : LabVIEW..................
LabVIEW et le contrôle-commande de procédés......................................
3.
Langage graphique G : développements spécifiques
et exemples industriels ..........................................................................
BridgeVIEW : un environnement de développement
orienté supervision......................................................................................
GrafcetVIEW : un langage orienté modèle ................................................
Langage G pour la vision industrielle ........................................................
Exemples industriels ...................................................................................
3.1
3.2
3.3
3.4
Pour en savoir plus ...........................................................................
S 8 205 – 2
—
2
—
2
—
4
—
—
—
—
6
6
12
17
—
23
—
—
—
—
23
25
27
28
Doc S 8 205
ne application de contrôle-commande peut être définie comme un système
informatique qui réalise l’acquisition de données par l’intermédiaire de capteurs et élabore des commandes envoyées au procédé physique grâce à des
actionneurs. Présentes dans tous les secteurs industriels, ces applications nécessitent un développement rapide, de qualité et fiable. Habituellement réalisées à
partir de langages de bas niveau (assembleurs) ou classiques (C, etc.), la programmation des systèmes informatiques destinés au pilotage de procédés physiques a été bouleversée par l’arrivée de langages graphiques plus simples, plus
intuitifs et plus puissants d’un point de vue des bibliothèques disponibles.
Les ingénieurs ou techniciens, chargés de réaliser ces applications, ont généralement une formation ou une expérience basées plus sur les domaines de
l’automatique ou de l’informatique industrielle que sur la programmation. De
plus, ils utilisent fréquemment des méthodes graphiques de conception orientées vers les schémas blocs ou l’association de blocs fonctionnels comme le
GRAFCET ou la méthode d’analyse SA-RT. Ainsi un langage de programmation
graphique, fondé sur des transferts de données entre des nœuds fonctionnels,
correspond parfaitement au contexte de travail des utilisateurs de ce domaine
du contrôle-commande. Le langage de programmation graphique G, utilisé dans
l’environnement LabVIEW™, possède toutes ces caractéristiques : expression
intuitive, édition graphique, diagramme flot de données, développement de
grande qualité d’un point de vue génie logiciel... De plus, ce langage permet de
U
Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite.
© Techniques de l’Ingénieur, traité Informatique industrielle
S 8 205 − 1
PROGRAMMATION GRAPHIQUE DES APPLICATIONS DE CONTRÔLE-COMMANDE __________________________________________________________________
répondre à des applications de plus en plus larges en utilisant des bibliothèques
spécifiques très nombreuses : traitement du signal, automatique, traitement statistique, logiciels de gestion des cartes d’entrées/sorties, logiciels de gestion des
réseaux locaux ou industriels, etc.
1. Généralités
1.1 Applications de contrôle-commande
1.1.1 Caractéristiques des applications
de contrôle-commande
Les applications de contrôle-commande concernent les systèmes
informatiques destinés au pilotage de procédés physiques. Ces systèmes fonctionnent souvent en ligne (on line) avec le procédé contrôlé. Dans ce contexte particulier d’interaction avec le monde
extérieur, l’informatique de contrôle-commande de procédé doit
satisfaire à des exigences nouvelles comme :
— le respect de contraintes temporelles adaptées au procédé
piloté ;
— la gestion d’une grande diversité de dispositifs d’entrées/
sorties :
• procédés continus (entrées/sorties de type continu ou analogique),
• procédés discrets (entrées/sorties de type numérique) : systèmes à événements discrets,
• procédés mixtes ;
— le respect des propriétés de la sûreté de fonctionnement, en
particulier :
• fiabilité (continuité de service),
• sécurité (garantie de la non occurrence de défaillances) ;
— la prise en compte de comportements concurrents (parallélisme de l’environnement).
Une définition de ces systèmes de contrôle-commande pourrait être la suivante : « un système informatique de contrôlecommande reçoit des informations sur l’état du procédé extérieur, traite ces données et, en fonction du résultat, évalue une
décision qui agit sur cet environnement extérieur dans de sévères contraintes de temps afin d’assurer un état stable ».
La notion d’état stable est liée à la vitesse de réaction du procédé
contrôlé. Selon les applications, la dynamique du procédé peut être
très différente :
— de l’ordre de la milliseconde ou inférieure : systèmes radar,
systèmes vocaux, systèmes de mesures physiques ;
— de l’ordre de la seconde : systèmes de visualisation (interface
homme-machine) ;
— de l’ordre de la minute : chaîne de fabrication ;
— de l’ordre de l’heure : contrôle de réactions chimiques.
1.1.2 Développement des applications
de contrôle-commande
L’informatique de contrôle de procédés diffère fondamentalement
des systèmes informatiques classiques et conduit à la mise en
œuvre de méthodes et de techniques appropriées. En particulier, la
réalisation de telles applications nécessite de conduire simultanément le développement de la partie matérielle (ordinateur, cartes
d’entrées/sorties, etc.) et de la partie logicielle (gestionnaire de cartes, logiciel de pilotage, interface homme-machine, etc.).
S 8 205 − 2
Le matériel, utilisé dans ce type d’applications, peut être très
divers selon les caractéristiques opérationnelles de l’application. Ce
matériel peut être une simple carte, construite autour d’un microcontrôleur, pour gérer des applications de petite taille : compteur
électrique industriel, caméra vidéo, radiotéléphone, appareils électroménager, etc. Mais il peut être constitué aussi de plusieurs microordinateurs reliés par un réseau de type bus de terrain pour des
applications de grande taille ou, plus classiquement, par un simple
micro-ordinateur pour toutes les autres applications. Nous pouvons
noter que les systèmes, constitués de plusieurs micro-ordinateurs
en réseau, le sont pour les trois principales raisons suivantes :
— application formée de multiples équipements (exemple :
chaîne de fabrication) ;
— application nécessitant un haut niveau de sûreté de fonctionnement en utilisant de la redondance matérielle ;
— application requérant une capacité de traitement important
(traitement de signaux).
Il est aussi important de noter que beaucoup d’applications de
contrôle-commande ont été et sont encore réalisées à l’aide d’automates programmables industriels (API). Ces API présentent de nombreux avantages dans le contexte industriel, en particulier celui de la
sûreté de fonctionnement avec la notion d’arrêt d’urgence et reprise
après arrêt. Mais l’amélioration constante des micro-ordinateurs de
type industriel, associés à des langages de programmation spécifiques, amène à les utiliser pour des applications identiques avec les
multiples avantages qu’ils offrent au niveau de la conception et de la
réalisation du logiciel de pilotage (facilité, réutilisabilité, lisibilité,
etc.).
Au niveau de l’architecture logicielle d’applications de contrôle-commande, nous pouvons distinguer cinq grandes parties (cf. figure 1) :
— le traitement des données internes à l’application : analyse
spectrale, loi de commande, etc ;
— les relations avec le procédé à piloter au travers des capteurs/
actionneurs et des cartes d’entrées/sorties : mesures dans le sens
procédé-système de pilotage, et commandes dans le sens système
de pilotage-procédé ;
— la gestion de l’interface vers l’opérateur avec la visualisation
des données et l’entrée des consignes ;
— la relation avec le réseau : réseau local ou bus de terrain ;
— la liaison vers une unité de stockage de masse pour la sauvegarde des données.
Ainsi, dans le cas général, le logiciel d’une application de contrôlecommande remplit successivement les trois fonctionnalités notées
sur la figure 2.
1.2 Conception et programmation des
applications de contrôle-commande
1.2.1 Méthodes utilisées en conception
Concevoir un système de contrôle-commande est un exercice difficile. En effet, la complexité et la diversité des éléments qui composent ces systèmes ne facilitent pas la description simple de leur
fonctionnement. Par conséquent, une démarche méthodologique
rigoureuse doit être suivie. Elle doit permettre d’obtenir une des-
Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite.
© Techniques de l’Ingénieur, traité Informatique industrielle
__________________________________________________________________
d’analyse SA (Structured Analysis) [4] qui permet de décomposer le
processus global du système en sous-processus reliés entre eux par
des échanges de données. La méthode SA-RT (Structured AnalysisReal time) [5] ajoute à la méthode précédente l’aspect comportemental avec la notion d’activation des processus de traitement.
Cette méthode d’analyse peut être couplée à une méthode de
conception telle que DARTS (Design Approach for Real-Time
Systems) [6].
Réseau
Consignes
Visualisation
Liaison
réseau
Interface
hommemachine
Traitements
des
données
Application
contrôlecommande
Interface
entrées/
sorties
Mesures
Commandes
Liaison
stockage
Opérateur
Procédé
Récupération
Sauvegarde
Unité de stockage
Figure 1 – Architecture logicielle d’une application
de contrôle-commande d’un procédé industriel
Mesures
Acquisition
de données
Commandes
Analyse
et traitement
de données
PROGRAMMATION GRAPHIQUE DES APPLICATIONS DE CONTRÔLE-COMMANDE
■ Méthodes orientées objet : pour ne pas privilégier une approche
par les données ou les traitements, ces méthodes regroupent données et traitements au sein d’un même module, appelé objet. Cet
objet est une entité autonome munie d’une structure de données et
de comportements définis par l’exécution de méthodes. Nous pouvons citer la méthode HOOD (Hierarchical Object Oriented Design)
[7] qui est très utilisée dans les développements d’applications spatiales européennes.
La méthode de conception actuellement la plus utilisée dans le
domaine des applications de contrôle-commande de taille moyenne
est celle basée sur le GRAFCET. Le GRAFCET (graphe fonctionnel
de commande étape transition), également appelé « diagramme
fonctionnel en séquence » (CEI/IEC 848), est destiné à représenter
des automatismes logiques (ou discrets), c’est-à-dire des systèmes
à événements discrets dans lesquels les informations sont booléennes (tout ou rien) ou peuvent s’y ramener (exemple de la comparaison d’une pression avec un seuil). Il est destiné à être un moyen de
communication entre l’automaticien et son client pour la rédaction
du cahier des charges d’un automatisme. Le point fort du GRAFCET
est la facilité de passer du modèle, obtenu à la conception, à
l’implantation technologique. Le GRAFCET passe alors du langage
de spécification au langage d’implémentation utilisé pour la réalisation de l’automatisme. Ainsi des outils industriels (CADEPA / FamicEurilor, AUTOMGEN/IRAI, GrafcetVIEW, cf. § 3.2) permettent d’obtenir directement à partir du GRAFCET le code de l’application (en langage C ou autre) à envoyer à un automate programmable industriel
ou à un ordinateur.
Restitution
de données
1.2.2 Programmation des applications
de contrôle-commande
Consignes
Visualisation
Figure 2 – Fonctionnalités d’une application de contrôle-commande
cription structurelle, fonctionnelle et comportementale de l’application.
Les diverses méthodes existantes, utilisées pour l’analyse et la
conception des applications industrielles, peuvent être classées
selon les quatre catégories suivantes.
■ Approche par les données : ces méthodes s’intéressent principalement aux aspects structurels et informationnels du système étudié. Elles permettent d’identifier les entités qui le constituent et
décrivent leurs relations ainsi que les traitements qui s’y rapportent.
Nous pouvons citer le modèle entité-association et la méthode
MERISE (méthodes d’études et de réalisation informatique pour les
systèmes d’entreprise) [1]. Ces méthodes sont les moins utilisées
dans le domaine des applications de pilotage de procédé car elles
ne proposent pas de solution concernant la description de son
aspect comportemental.
■ Approche états/transitions : ces méthodes modélisent bien
l’aspect dynamique du système étudié. Elles s’articulent autour du
concept des états du système, définis par un ensemble de données,
qui conditionnent l’activation de transitions. Nous pouvons citer les
automates à états finis, les réseaux de Petri [2], les StateCharts [3] et
le GRAFCET (norme NF C 03-190).
■ Approche par les traitements : ces méthodes sont issues du
génie logiciel et modélisent les processus de génération, modification ou consommation de données. Ainsi nous avons la méthode
Comme pour tous les systèmes informatiques, le choix du langage de programmation va dépendre de la taille et de la complexité
de l’application mais aussi des matériels et capacités internes à
l’entreprise. Étant donné les fonctionnalités requises par ce type
d’applications, le langage doit supporter les différents services suivants :
— acquisition et restitution de données :
• contrôle de cartes d’entrées/sorties analogiques ou numériques,
• contrôle d’instruments par l’intermédiaire de liaisons
normalisées : GPIB, RS-232, VXI, etc.,
• liaison réseau (par exemple TCP/IP), base de données... ;
— traitement de données :
• traitement numérique des signaux (FFT, corrélation, filtrage,
fenêtrage...),
• traitement statistique des signaux (moyenne, écart type,
régression, lissage...),
• traitement d’images (extraction de contour...),
• élaboration de lois de commande (par exemple, régulation
PID),
• maîtrise statistique du procédé (par exemple, analyse de
Pareto) ;
— présentation des données :
• interface graphique et interactive,
• représentation de courbes 2D et 3D, représentation d’images,
• stockage des données (impression, archivage...), génération
de documents...,
• distribution sur réseau (Internet, Intranet...).
Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite.
© Techniques de l’Ingénieur, traité Informatique industrielle
S 8 205 − 3
PROGRAMMATION GRAPHIQUE DES APPLICATIONS DE CONTRÔLE-COMMANDE __________________________________________________________________
Degré de sophistication des outils
Langages spécifiques
(LabVIEW, ...)
Langages de haut niveau adapté
(Ada, Visual C++)
Langages évolués avec bibliothèques spécifiques
(C, C++, ...)
Assembleur
Degré de complexité de l'application
Figure 3 – Différents groupes de langages utilisés
pour la programmation des applications de contrôle-commande
des procédés
Étant donné l’ensemble de ces fonctions, il est très difficile de
trouver un langage qui offre toutes ces composantes à la fois. Aussi,
ce type d’applications est réalisé grâce à l’association de plusieurs
langages et/ou de bibliothèques de programmes spécialisées (traitement de signaux, traitement d’images, lois de commande, etc.)
(figure 3). Il est très courant par exemple de réaliser les gestionnaires d’interfaces (drivers) à l’aide d’un langage de bas niveau
comme un assembleur, de concevoir des interfaces hommemachine avec des langages ou bibliothèques appropriés (Visual
Basic, Visual C++, Tcl-Tk, Motif…). À l’heure actuelle, une grande
majorité de ces applications sont réalisées à l’aide des langages C
ou C++ qui sont associés à des bibliothèques spécifiques. Toutefois,
pour des applications de grande taille, il est souvent préféré un langage plus structuré et plus « propre » comme Ada. En 1998, plus de
700 projets d’applications de contrôle-commande, implémentés en
Ada, sont en cours. D’autres langages sont également disponibles
pour ces applications comme LabVIEW™ (National Instruments),
MatLab™/Simulink (The Mathworks). Leur essor est lié à l’environnement de programmation offert avec un ensemble de fonctionnalités adapté à ce domaine ou à des domaines connexes comme celui
de la mesure. Le langage LabVIEW, qui est détaillé dans la suite de
cet article (§ 2.2 et § 2.3), doit en particulier son développement à
une programmation naturelle de type blocs fonctionnels très utilisé
dans ce domaine.
Il est intéressant de noter que la normalisation internationale (CEI/
IEC 1131-3), concernant les langages de programmation des automates programmables industriels, définit un langage de conception, le GRAFCET (SFC : Sequential Function Chart aux États-Unis),
et quatre langages d’implémentation dont deux graphiques : les diagrammes à relais (LD : Ladder Diagram) et les blocs fonctionnels
(FDB : Function Block Diagram).
1.3 Programmation graphique
en contrôle-commande
1.3.1 Programmation textuelle et programmation
graphique
Le terme de langage de programmation graphique est employé
ici pour les langages, ou environnements de développement, pour
lequel le programme est décrit de manière graphique et non pour
S 8 205 − 4
désigner des environnements de développement permettant de
définir des interfaces utilisateurs (par exemple Visual Basic). La programmation à l’aide d’un langage graphique est relativement
récente. Les langages de programmation textuels conventionnels
impliquent un mode de conception séquentiel contraint par l’architecture même de la machine, l’exemple le plus simple étant l’assembleur puisqu’il reflète l’architecture du processeur. La possibilité de
dessiner un diagramme ou le contrôle-commande d’un processus
permet au concepteur d’exprimer ses idées d’une manière plus
intuitive et plus naturelle. L’esprit humain perçoit et comprend les
concepts compliqués plus rapidement lorsque ceux-ci sont représentés graphiquement. À cet égard, la représentation textuelle est
moins performante puisqu’elle ne permet qu’une représentation
séquentielle de l’information. D’ailleurs, les efforts mis en œuvre
pour rendre un texte plus rapidement compréhensible repose sur
des moyens graphiques, tels que le surlignage, les italiques, les
caractères gras, la couleur ou l’indentation d’un texte. Lorsque des
objets peuvent être manipulés, la communication homme-machine
est grandement facilitée, ce qui a conduit par exemple au développement des systèmes d’exploitation graphiques (MacOS™ ou Windows™). Les personnes ont tendance à dessiner des schémas pour
expliquer le fonctionnement de mécanismes, de circuits, etc. Nous
retrouvons alors la représentation naturelle de conception sous
forme de « blocs fonctionnels » d’une application de contrôle-commande. Le but de la programmation graphique est donc de faciliter
la mise en œuvre d’applications informatiques. On peut dégager les
avantages suivants :
— la facilité d’utilisation par les non-programmeurs : les images
sont en général préférées aux mots, la programmation devient alors
plus intuitive ;
— la sémantique des images est plus puissante que celle des
mots (davantage de signification dans une unité d’expression plus
concise) ;
— les images ne sont pas sujettes aux barrières des langues.
Il est évident que toute méthode à ses inconvénients. Ainsi les
principaux problèmes liés à la programmation graphique sont les
suivants :
— difficulté de visualisation pour les programmes de taille importante d’où la nécessité d’une architecture modulaire et
hiérarchique ;
— ambiguïté dans l’interprétation des graphismes ;
— difficulté de réalisation d’environnement de développement
efficace (éditeurs, outil de mise au point, outil de test...).
1.3.2 Classification des langages graphiques
Les langages de programmation peuvent être classés selon la
manière de programmer, soit :
— la programmation impérative : elle consiste à exprimer une
suite de commandes ou instructions qui s’exécutent dans un ordre
précis. C’est le paradigme le plus couramment utilisé par les langages textuels ;
— la programmation déclarative : le programmeur ne décrit pas
la structure de contrôle d’exécution car le séquencement des
actions qui constituent l’algorithme est préexistant. L’utilisateur
fournit seulement à celui-ci des informations sur les objets qu’il doit
traiter et les relations entre objets qu’il doit prendre en compte lors
de son exécution. On distingue alors :
• la programmation fonctionnelle : un programme est un
ensemble de fonctions. En général, les diagrammes flots de données sont utilisés pour leur représentation graphique,
• la programmation logique : ces langages sont basés sur le calcul logique et le principe de résolution. Les langages graphiques
utilisant ce paradigme sont souvent de style tableur.
Le tableau 1 illustre cette classification à l’aide d’exemples de langages commercialisés :
(0)
Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite.
© Techniques de l’Ingénieur, traité Informatique industrielle
__________________________________________________________________
Tableau 1 – Classification des langages graphiques
Type de programmation
Fonctionnel
Déclaratif
Logique
j
LabVIEW (National Instruments)
HP-Vee (Hewlett Packard)
Prograph CPX (Pictorius Incorporated)
Visual Designer (Intelligent Instrumentation)
La représentation graphique d’un programme peut être basée sur
deux formalismes déterminant le mode d’exécution du programme : flot de données ou flot de contrôle [8]. Les représentations orientées flot de contrôle ont longtemps été utilisées pour
décrire des algorithmes (avant même l’apparition des premiers ordinateurs). Ces représentations décrivent les programmes comme
étant des nœuds de calcul connectés par des arcs spécifiant quel
calcul doit être effectué ensuite : les réseaux de Petri ou le GRAFCET
sont, par exemple, basés sur ce modèle. Au contraire, dans les graphes flots de données, ce sont les données qui dirigent l’exécution
du programme, fonction analogue à la propagation du signal à travers un circuit électronique. Bien qu’il existe des langages flot de
données textuels tels que LUSTRE [9], SIGNAL en partie [10] ou bien
encore Lucid [11], nous nous intéressons dans la suite de cet article
à la représentation graphique de programmes dont l’exécution est
basée sur le flot de données.
Un diagramme flot de données permet de décrire un programme
de manière graphique, constitué des nœuds de calculs interconnectés par des arcs spécifiant le flot des données transitant entre les
nœuds producteurs de données et les nœuds consommateurs de
données [12] [13]. Le diagramme flot de données est un graphe acyclique qui peut être composé des trois éléments différents suivants
(figure 4).
— des terminaux qui sont les liens avec l’extérieur qui représentent la production et la consommation de données ;
— des nœuds qui sont les traitements à effectuer et qui sont
représentés par une figure géométrique pouvant contenir une
image illustrant leur fonctionnalité. Ils possèdent des connexions
d’entrée et des connexions de sortie ;
— des arcs orientés qui relient nœuds et terminaux et permettent
d’indiquer le passage de données d’un nœud vers un autre. Un arc
orienté peut se séparer en plusieurs arcs (duplication des données) ;
par contre, des arcs orientés ne peuvent pas se regrouper (convergence interdite).
Arc orienté
Nœud
a
m
k
Figure 5 – Encapsulation du diagramme flot de données
représentant le calcul de l’équation m = ik + jk2 explicité
dans la figure 4
Spreadsheet 2000 (Emergent Behavior)
1.3.3 Programmation flot de données
Terminal d'entrée
i
Exemples de langages graphiques
Layout (Objects Inc.)
Impératif
PROGRAMMATION GRAPHIQUE DES APPLICATIONS DE CONTRÔLE-COMMANDE
Terminal de sortie
y
x
b
Figure 4 – Diagramme flot de données représentant le calcul
de l’équation y = ax + bx2
Il est possible de représenter les données transitant sur les arcs
par des jetons. La production et la consommation des jetons dans
le diagramme flot de données est régie par des règles d’évolution.
Ces règles sont les suivantes :
— lors de l’initialisation, chaque terminal d’entrée produit un
jeton sur son arc de sortie ;
— lorsqu’un nœud possède un jeton sur chacun de ses arcs
d’entrée, alors le nœud peut être exécuté : chaque jeton d’entrée est
alors consommé et un jeton est produit sur chacun des arcs de
sortie du nœud.
De ces règles, on déduit que plusieurs nœuds peuvent être exécutés simultanément.
Exemple : dans le diagramme flot de données de la figure 4, les
deux premiers nœuds « * » peuvent être exécutés en même temps en
consommant les données a, b et deux fois la donnée x. La programmation flot de données intègre donc implicitement la notion de parallélisme. Ensuite le troisième nœud « * » peut s’exécuter et enfin le
dernier nœud « + » est exécuté en produisant la donnée y.
Un diagramme flot de données peut être encapsulé afin d’être réutilisé, en tant que nœud ou « macronœud », par d’autres diagrammes flots de données. Les terminaux du diagramme deviennent
alors les connexions d’entrées/sorties de ce nouveau nœud. Ce
mécanisme d’encapsulation est un mécanisme d’abstraction, bien
connu du génie logiciel : il permet de présenter des fonctionnalités
sans décrire leur fonctionnement interne. La figure 5 montre ce
mécanisme pour le diagramme flot de données de la figure 4. Formellement, cette encapsulation revient à donner un nom à un diagramme flot de données. Une fois encapsulées, les variables
internes au nœud ne sont plus visibles de l’extérieur.
1.3.4 Langages flot de données graphiques
existants
De nombreux environnements professionnels de programmation
graphique utilisent le formalisme flot de données dans les domaines de la mesure ou du contrôle-commande, comme LabVIEW™
(National Instruments), HP-Vee™ (Hewlett Packard), Visual Designer™ (Intelligent Instrumentation), DASYLab™ (DATALOG), Prograph CPX™ (Pictorius) ou bien TestPoint (Keithley).
LabVIEW™ (National Instruments) : c’est le premier et le plus
avancé de ces environnements car il est utilisé dans le domaine de
l’instrumentation, de l’acquisition de données et du traitement du
signal depuis 1986. C’est également l’environnement flot de données permettant le plus large éventail de moyens de communication avec le monde extérieur : cartes d’acquisitions analogiques et
numériques, bus GPIB, liaisons séries, réseaux, bus de terrains,
commandes d’axes, acquisition d’images, etc. C’est donc cet environnement que nous prendrons comme exemple et que nous décrirons de façon détaillée dans la suite de cet article (§ 2.2 et 2.3).
HP-Vee™ (Hewlett Packard) : cet environnement, essentiellement
adapté au test et à la mesure, intègre tous les outils de base de ce
Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite.
© Techniques de l’Ingénieur, traité Informatique industrielle
S 8 205 − 5
PROGRAMMATION GRAPHIQUE DES APPLICATIONS DE CONTRÔLE-COMMANDE __________________________________________________________________
type de langage : création d’interfaces opérateurs très complètes et
efficaces, visualisation des données et contrôle d’instruments au
travers des interfaces GPIB, VXI, RS-232, etc. La programmation graphique flot de données est complète au sens langage de programmation sans toutefois donner une large place au graphisme, l’aspect
textuel étant encore fortement présent : ce langage ressemble à des
organigrammes. Il est à noter quelques fonctions intéressantes
comme le routage automatique des flots de données. Il est important de remarquer la disponibilité d’outils d’exécution de test, de
mise au point et d’aide en ligne, indispensables dans ce domaine. Il
est actuellement disponible sur trois plates-formes : PC (Windows)
et station de travail (HP-UX et Solaris).
Visual Designer™ (Intelligent Instrumentation) : cet outil n’est
pas réellement un langage de programmation, mais plutôt un environnement de développement d’application décrite sous la forme
de blocs fonctionnels. Un ensemble de blocs fonctionnels de base
est fourni, mais l’utilisateur peut et en général doit en ajouter en
programmant en C++. Cet environnement est actuellement disponible sur plates-formes PC (Windows).
DASYLab™ (DATALOG) : cet environnement est plus particulièrement destiné aux applications d’acquisition de données. Le logiciel utilise le principe de flot de données et d’icônes graphique pour
permettre au développeur de réaliser son application de manière
très simple, mais il ne s’agit pas d’un langage complet de programmation, ce qui limite naturellement la complexité des applications.
L’utilisateur dispose de fonctions d’acquisition, de contrôle, d’analyse et de visualisation de données, sous forme d’icônes qu’il connecte dans un diagramme schématique. Les fonctions incluent les
entrées analogiques, les sorties analogiques, les déclenchements,
les entrées/sorties numériques, la génération de fonctions, le filtrage numérique, l’analyse de spectre et les opérations mathématiques, statistiques et logiques. L’utilisateur peut afficher les résultats
de son acquisition au travers de graphes très divers. L’utilisateur
peut aussi utiliser des vu-mètres et des voyants. DASYLab offre une
fonctionnalité intéressante pour les applications de supervision : le
développeur peut créer des pages d’écrans animées. Ces écrans
peuvent être activés en fonction des conditions instantanées du processus sous contrôle. Des pages peuvent également être imprimées
en fonction d’événements prédéterminés. L’acquisition de données
et leur visualisation sont limitées respectivement à 1 MHz et
250 kHz, ce qui est suffisant pour la plupart des applications de contrôle-commande de process. Pour plus de puissance et d’ouverture,
notamment lorsque l’utilisateur doit piloter des instruments, un système de vision ou encore exploiter Internet, il est techniquement
possible de migrer les applications DASYLab vers LabVIEW, à l’aide
d’un kit spécial.
Prograph CPX™ (Pictorius) : cet environnement de développement se rapproche plus d’un langage généraliste orienté objet
comme Visual C++, mais avec une programmation graphique (disponible sur plate-forme Apple, MacOS).
TestPoint™ (Keithley) : cet environnement de programmation,
dédié à l’acquisition de données, peut être qualifié de visuel plutôt
que de graphique. En effet, le graphisme est lié à l’interface utilisateur et aux bibliothèques d’objets de base, mais la création du programme est textuel (disponible sur PC, Windows).
2. Langage graphique G
2.1 Programmation graphique
flot de données
2.1.1 Éléments du langage G
2.1.1.1 Structures de données
Le langage G est un langage fortement typé et toutes données ou
structures de données ne peuvent être manipulées qu’avec des
fonctions admettant ce type. Dans le langage G, on trouve les types
de base scalaire : les types entiers (signés ou non, codés sur 8, 16 ou
32 bits), le type réel (codé sur 16, 32 ou 64 bits), le type booléen et le
type chaîne de caractères (figure 6). Il est important de noter que les
éléments représentant ces données, ainsi que les liaisons issues de
ces éléments, sont de forme et de couleur différente.
Le langage permet aussi de créer des structures de données plus
élaborées (figure 6) :
— le type tableau (structure de données homogènes) : les
tableaux peuvent avoir un nombre quelconque de dimensions. La
représentation permet également de les différencier suivant leur
type et leur dimension ;
— le type « cluster » (structure de données hétérogènes) : ce
second constructeur de type est l’équivalent du « record » en Ada
ou du « struct » en C. Les différents composants ou champs de ce
groupe de données (cluster) peuvent être assemblés ou récupérés
par des fonctions spécifiques (figure 7).
2.1.1.2 Structures de programmation
Le langage flot de données pur a été enrichi de quatre types de
structures : la séquence, deux structures d’itération (la boucle
« Pour » avec un nombre d’itérations fixé et la boucle « Tant Que »
avec un nombre d’itérations soumis à condition) et la structure de
choix.
Entiers (bleu)
DBL double
Réels (orange)
SGL single
Booléen (vert)
I
integer
Chaîne de caractères (rose)
TF
true false
Matrice de réels codés sur 16 bits
Cluster
Figure 6 – Différents types de structures de données du langage G
Numéro du capteur
Type de thermocouple
Valeur mesurée
Assemblage de données
Mesures température
Cluster
Numéro du capteur
Le modèle flot de données pur est trop simple pour être utilisé en
tant que langage de programmation. En particulier ce type de flot de
données souffre du manque de structures conditionnelles et de
structures itératives. Une des solutions choisies est d’étendre le flot
de données pur en conservant les règles d’évolution et d’acyclicité
vues dans le chapitre précédent (cf. § 1.3.3) tout en y incorporant les
bénéfices de la programmation structurée. Cela a été fait dans le
cadre du langage G [8] [14] [15].
S 8 205 − 6
Type de thermocouple
Valeur mesurée
Numéro du capteur
Type de thermocouple
Valeur mesurée
Récupération de données
Figure 7 – Exemple de manipulation des données avec le type
cluster : assemblage de la structure (trois champs) et récupération
des trois composants du cluster
Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite.
© Techniques de l’Ingénieur, traité Informatique industrielle
__________________________________________________________________
La structure de « séquence » permet de spécifier l’ordre d’exécution de flots de données indépendants qui, sinon, s’exécuteraient
en même temps étant donné le parallélisme implicite du langage.
Cette structure se présente sous la forme d’un cadre et a le statut
d’un nœud. Des connexions d’entrées ou de sorties à ce nœud,
appelés tunnels, sont automatiquement créées lorsque des arcs
arrivent ou sortent de cette structure. L’identifiant du cas représenté
est indiqué en haut de la structure. Par contre, cette structure ne permet de représenter à l’écran qu’un cas à la fois, les autres parties
étant cachées en arrière-plan.
Exemple : sur la figure 8, l’utilisation de la séquence s’impose : il
s’agit d’initialiser un port série puis d’envoyer une chaîne de caractères. Le premier flot de données risque de provoquer des erreurs car
rien n’empêche le nœud d’écriture sur le port série de s’exécuter avant
le nœud d’initialisation de ce port : l’utilisation de la séquence permet
d’ordonner (de séquencer) correctement les opérations.
PROGRAMMATION GRAPHIQUE DES APPLICATIONS DE CONTRÔLE-COMMANDE
Nombre d'itérations
Mesures
Période d'acquisition
Indice
d'itération
Figure 9 – Exemple d’utilisation de la structure itérative « Pour »
Les deux structures itératives, la boucle « Pour » et la boucle
« Tant que », ont aussi le statut d’un nœud ordinaire. La boucle
« Pour » permet d’exprimer la répétition (ou itération) pour un nombre de fois prédéterminé défini par une connexion d’entrée obligatoire : le nombre d’itérations à effectuer N. À l’intérieur de la boucle
« Pour » se trouve un terminal d’entrée local générant l’entier indiquant l’indice d’itération de la boucle (i varie de 0 à N–1).
Lecture température
Mesures
Exemple : l’utilisation de cette structure, présentée sur la figure 9,
concerne l’acquisition de N mesures avec un temps fixe entre chacune, défini par un nœud de temporisation (cf. § 2.2.3). Les N données
de sortie sont assemblées pour former un vecteur avec une autoindexation.
La boucle « Tant Que » permet d’exprimer la répétition pour un
nombre de fois non connu à l’avance. À l’intérieur de la boucle
« Tant Que » se trouve un terminal d’entrée local générant l’entier
indiquant l’indice d’itération de la boucle. Un terminal de sortie de
type booléen permet d’arrêter la boucle lorsque la valeur « False »
lui est envoyée.
Lecture température
Nombre
de mesures
500,00
Condition
d'arrêt
Période d'acquisition
Indice
d'itération
Figure 10 – Exemple d’utilisation de la structure itérative
« Tant que »
Exemple : l’utilisation précédente décrite sur la figure 9, est reprise
avec cette structure « Tant Que » en arrêtant l’acquisition pour une
valeur trop grande de la mesure (figure 10).
Dans les deux cas de structure itérative lorsque des tableaux de
données arrivent ou partent des tunnels, ceux-ci ont la possibilité
d’être automatiquement indexés : récupération un par un des éléments du tableau ou concaténation pour créer un tableau. Dans le
cas des deux structures, il est possible de mémoriser des résultats
produits lors d’itérations antérieures et de les récupérer ensuite. Ces
registres à décalage sont des variables locales à une boucle.
5
Numéro voie
Début_Acquisition
Initialisation du port série
Envoi d'un message
Architecture incorrecte
Exemple : la figure 11 présente une utilisation de ces registres à
décalage dans le cas de la boucle « Pour ». Il est important de remarquer que ces registres à décalage constituent un des effets de bord du
langage. Il est de plus nécessaire d’initialiser ces mémoires locales
pour réaliser une utilisation contrôlée et cohérente.
La dernière structure nécessaire est celle qui va permettre d’exprimer l’alternative (le choix). La sélection du cas exécuté est faite par
la valeur de la variable connectée à l’entrée représentée par un point
d’interrogation (figure 12). L’identifiant du cas représenté est indiqué en haut de la structure. Comme pour la structure séquence, il
n’est possible de visualiser qu’un seul cas à la fois.
Numéro voie
5
2.1.1.3 Variables locales et globales
Début_Acquisition
Architecture correcte
Figure 8 – Exemple d’utilisation de la structure de « séquence »
Pour faciliter la mise en place de la fonction de mémorisation de
données, autrement qu’avec les registres à décalage des structures
itératives, il a été ajouté au langage G deux types d’unités de stockage pur : les variables globales et les variables locales.
Une variable globale peut être considérée comme une entité possédant un point d’entrée/sortie dont la visibilité est totale. Cette
Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite.
© Techniques de l’Ingénieur, traité Informatique industrielle
S 8 205 − 7
PROGRAMMATION GRAPHIQUE DES APPLICATIONS DE CONTRÔLE-COMMANDE __________________________________________________________________
Registres à décalages
Nombre mesures
Boucle de mesures
200
Température
Écriture
Initialisation
Variable globale
4
Boucle de commande
Lecture
Figure 11 – Exemple d’utilisation des registres à décalage
dans une boucle « Pour » : calcul d’une moyenne glissante
sur quatre valeurs
Figure 13 – Exemple d’utilisation d’une variable globale,
donnée partagée de type scalaire réel entre deux boucles
de pilotage d’un procédé
Température
2.1.1.4 Événements
9
Choix unité
32
5
Conversion en Fahrenheit
False
Température
en centigrade
Figure 12 – Exemple d’utilisation de la structure de choix :
choix de l’unité de la température mesurée, conversion ou non
de la température en degré Fahrenheit
Les événements (ou occurrences) ont été introduits dans le langage G afin d’éviter de faire de l’attente active d’état de variables,
c’est-à-dire de la scrutation (polling). Ces entités sont l’équivalent
des interruptions et de leur routine de traitement dans les systèmes
d’exploitation. Trois fonctions de manipulation des événements sont
proposées :
— « Création d’un événement » pour créer un événement
unique ;
— « Signaler un événement » pour générer un événement, c’est
l’équivalent d’une interruption ;
— « Attendre un événement » pour se mettre en attente d’un événement.
Exemple : la figure 14 présente un exemple d’utilisation des événements pour gérer une procédure d’alarme en cas de dépassement
d’une valeur de consigne.
2.1.2 Programmation en langage G
2.1.2.1 Création de programmes : quelques exemples
simples
variable globale va contenir un ensemble de données qui peuvent
être de type différent, chacune de ces données étant accessible en
écriture ou en lecture individuellement (figure 13). Il est important
de noter que d’une part cette mémorisation est un effet de bord et
que d’autre part il y a possibilité d’accès concurrents et donc de
conflits d’accès. Un autre inconvénient réside dans la gestion
mémoire de ces variables qui peut conduire à un dépassement
mémoire. Un dernier point négatif pour l’utilisation de ces variables
globales est le fait qu’elles cachent le flot de données en supprimant
le lien explicite et diminuent ainsi la lisibilité des diagrammes.
Le langage G possède les instructions de base d’un langage de
programmation permettant de traiter les différents types de données. Ainsi, nous avons des fonctions liées aux variables numériques (entiers, réels et complexes), aux variables booléennes,
aux chaînes de caractères, aux tableaux (figure 15).
Les variables locales se présentent sous la même forme que les
variables globales, mais leur visibilité est limitée au nœud contenant cette variable locale. Aussi les diagrammes flots de données
appelant les nœuds, créés par duplication de ce diagramme flot de
données, ne peuvent pas accéder à cette variable locale.
À partir des structures de contrôle, des fonctions et des opérateurs de base, il est alors possible de traduire un algorithme quelconque et d’enrichir la bibliothèque des fonctions en utilisant le
mécanisme d’encapsulation. Un diagramme complet est alors
réduit à un nœud qui peut être ensuite réutilisé (figure 17).
S 8 205 − 8
Il est important de noter que certaines de ces fonctions sont polymorphes. Par exemple à la fonction « + », il est possible d’appliquer
aussi bien deux entiers que deux réels et même deux vecteurs qui
seront additionnés terme à terme. Nous trouvons aussi les opérateurs de test liées à ces différents types de données (figure 16).
Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite.
© Techniques de l’Ingénieur, traité Informatique industrielle
__________________________________________________________________
PROGRAMMATION GRAPHIQUE DES APPLICATIONS DE CONTRÔLE-COMMANDE
Activation
Température mesurée
Alarme
Température maximale
Création
Attente
Figure 14 – Exemple d’utilisation
d’un événement pour activer
une procédure d’alarme
Événement
Fonctions numériques (extrait)
Fonctions booléennes (extrait)
Fonctions simples
Fonctions de
conversion entre types
Fonctions
trigonométriques
Fonctions de traitement des tableaux (extrait)
Remplacement
d'un élément
Fonctions
logarithmiques
Construction
d'un tableau
Dimension
Fonctions pour les
variables de type complexe
Extraction
d'un élément
Extraction
d'une partie du tableau
Figure 15 – Exemple de quelques instructions de traitement de données (icônes) du langage G
rapidement des applications informatiques. Cependant, pour obtenir un logiciel de qualité, cette programmation doit se plier à certaines règles, celles du génie logiciel. On peut distinguer deux types de
paramètres de la qualité du logiciel :
— les paramètres internes : modularité (finesse du découpage en
modules autonomes et communicants), clarté (facilité à interpréter
le code), compacité (occupation minimale d’espace de travail), logique (choix d’algorithmes rapides) ;
Figure 16 – Exemple de quelques opérateurs de test du langage G
Exemples : trois programmes très simples vont permettre d’illustrer les principaux aspects du langage G : résolution d’équation du
e
2 degré (figure 18), calcul du PPCM et du PGCD de deux nombres
(figure 19), filtre numérique (figure 20).
— les paramètres externes : validité (conformité au cahier des
charges et à la spécification), fiabilité (assurer l’exactitude des résultats indépendamment des conditions et du temps), extensibilité
(ajout de fonctions), efficacité (utilisation optimale du matériel), portabilité (passage du code d’une plate-forme à une autre).
2.1.2.2 Méthodologie de développement
Nous allons illustrer la capacité d’un langage programmation graphique, comme le langage G, à respecter les règles citées précédemment. Ainsi, prenons l’exemple de quelques paramètres de
qualité :
Les langages de programmation graphique permettent à leurs utilisateurs (même non informaticiens) de développer facilement et
— la modularité : le langage G permet par sa capacité d’encapsulation des fonctions (figure 17) ou des données (cluster, figure 7) de
réaliser une abstraction cohérente de l’application ;
Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite.
© Techniques de l’Ingénieur, traité Informatique industrielle
S 8 205 − 9
PROGRAMMATION GRAPHIQUE DES APPLICATIONS DE CONTRÔLE-COMMANDE __________________________________________________________________
Nombre de points
Nombre de périodes
Onde
sinusoïdale
Amplitude
n
A
P
Nombre de points
Amplitude
Nombre de périodes
onde sinusoïdale
ce diagramme peut ensuite être encapsulé pour être utilisé dans d'autres diagrammes
Figure 17 – Exemple d’un diagramme
permettant de générer une onde sinusoïdale
caractérisée par le nombre de périodes,
l’amplitude et le nombre de points
constituants
–b
b
x1
Discriminant
c
x2
Racines réelles
a
Solution
2a
– b/2a
Racine réelle
Racines complexes
Figure 18 – Exemple de la résolution d’une équation du deuxième degré avec le langage G
S 8 205 − 10
Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite.
© Techniques de l’Ingénieur, traité Informatique industrielle
__________________________________________________________________
PROGRAMMATION GRAPHIQUE DES APPLICATIONS DE CONTRÔLE-COMMANDE
PPCM
Nombre 1
PGCD
Nombre 2
Figure 19 – Exemple du calcul du PGCD et du PPCM de deux nombres avec le langage G
Nombre
de points
Valeur
initiale
de Y
Exemple correct
a
Yn –1
Signal
de sortie
a Yn –1
axb
b
(a x b) + c
Coefficient
a
c
Nombre de points
Amplitude
Nombre de périodes
Signal
d'entrée
Xn
Valeur
initiale
de X
Exemple incorrect
Xn –1
Coefficient
b
onde sinusoïdale
b (Xn + Xn –1)
c
(a x b) + c
a
Le filtre est synthétisé selon la méthode de transformation appelée
équivalence à la dérivation, soit l'équation aux différences du filtre :
Yn = aYn–1 + b (Xn + Xn–1)
Figure 20 – Exemple de la réalisation d’un filtre numérique passe-bas
du premier ordre avec le langage G [16]
b
Nombre de périodes
onde sinusoïdale
axb
Nombre de points
Amplitude
Figure 21 – Exemples d’application de règles de clarté
de programmation avec le langage G
— la clarté : dans les langages textuels, la notion de clarté est liée
à l’indentation, à l’espacement des instructions, au nombre d’instructions par lignes. Dans la perception des graphiques, l’œil n’est
pas contraint à une discipline linéaire. L’acquisition est néanmoins
plus rapide car il n’y a pas de traduction orale. Cependant, cette
acquisition est fortement dépendante de la clarté du programme
graphique. Quelques règles de présentation permettent d’améliorer
fortement cette « lisibilité » graphique (figure 21) : tracé des flots de
données de gauche à droite, croisement de flot de données à éviter,
position des entrées à gauche et des sorties à droite, icônes avec des
graphismes clairs et si possible universels … La mise en place de
commentaires associés aux liaisons ou aux nœuds est un apport
considérable pour la lisibilité du programme, même si on s’écarte de
la programmation purement graphique.
2.1.2.3 Propriétés des nœuds
Des propriétés de modification ou d’exécution peuvent être associées à chaque nœud d’un diagramme flot de données : visibilité,
pas de modification, priorités, réentrance, etc. Par exemple, la priorité, affectée à un ensemble de nœuds, permet de privilégier l’exécution de certains nœuds plutôt que d’autres en cas d’exécution
parallèle possible sur une architecture monoprocesseur.
Une des propriétés la plus importante est sans doute celle de
réentrance. En effet, lorsque plusieurs instances d’un même nœud,
encapsulant un diagramme flot de données, sont utilisées dans un
diagramme, par défaut, elles ne sont pas exécutées en parallèle
Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite.
© Techniques de l’Ingénieur, traité Informatique industrielle
S 8 205 − 11
PROGRAMMATION GRAPHIQUE DES APPLICATIONS DE CONTRÔLE-COMMANDE __________________________________________________________________
même si cela est possible. Ainsi, la première instance à avoir ses
entrées fournies en données s’exécute. Pendant cette exécution, si
une autre instance voit également ses entrées fournies en données,
alors elle est mise en attente dans une file d’attente (type FIFO, First
In First Out) sur la fin d’exécution de l’instance en cours. L’option de
réentrance d’un diagramme flot de données (DFD) permet que chaque instance de ce DFD puisse s’exécuter en parallèle avec les
autres. De plus, cette exécution a lieu dans un contexte propre à
l’instance. Cela signifie que chaque instance possède alors son propre espace de données.
2.2 Environnement de développement
en langage G : LabVIEW
LabVIEW (Laboratory Virtual Instrument Engineering Workbench)
est un environnement de développement d’applications où le langage de programmation utilisé est le langage G [8] [14]. Bien que
tout à fait utilisable dans un grand nombre de domaines, LabVIEW
est plus particulièrement destiné à l’acquisition de données, au traitement du signal et au contrôle-commande de procédé. La version
LabVIEW 5, disponible sur six types de plates-formes (AppleMacOS, PC-Windows, Sun-Unix, HP-UX, Concurrent PowerMax,
Linux), permet une portabilité quasi complète des applications
développées entre les différents environnements.
2.2.1 Concept d’instrument virtuel
LabVIEW est centré autour du principe d’instrument virtuel (Virtual Instrument ou encore VI). Un instrument de mesure analogique
classique peut se décomposer en deux parties :
— la première partie, partie interne de l’instrument, est constituée des circuits électroniques de traitement et/ou d’analyse des
signaux (lissage, filtrage, fenêtrage, etc.) ;
— la seconde partie (partie visible de l’instrument), appelée face
avant, réalise l’affichage des résultats (par exemple, un tube cathodique d’un oscilloscope, ou des afficheurs digitaux d’un voltmètre)
et permet de changer les paramètres de l’instrument (par exemple,
un potentiomètre réglant l’échelle de visualisation sur l’écran de
l’oscilloscope).
De la même manière, l’environnement LabVIEW va créer une
application sous la forme d’un instrument virtuel VI de mesure
composé des deux mêmes parties :
— la première partie (partie cachée ou interne) : algorithme du
programme décrit sous la forme d’un diagramme flot de données
en langage G ;
— la seconde partie (partie visible) est constituée de l’interface
utilisateur.
Avec LabVIEW, on peut manipuler ces instruments virtuels
comme s’il s’agissait d’instruments réels : on peut par exemple tourner un potentiomètre (virtuel puisque c’est une image de potentiomètre) grâce à la souris ou bien visualiser une courbe sur une
portion de l’écran représentant un oscilloscope. Par extension, on
appelle VI (Virtual Instrument) toute application réalisée avec LabVIEW. Un instrument virtuel est composé de trois parties liées :
— une face avant (Panel en anglais) : interface utilisateur de
l’application ;
— un diagramme (Diagram en anglais) : programme de
l’application ;
— une icône (Icon en anglais) : encapsulation de ce programme
ou instrument virtuel.
Ainsi lorsque l’environnement LabVIEW est actif, nous nous trouvons en présence d’un instrument virtuel nouveau sous la forme de
deux fenêtres vierges (figure 22). Une fenêtre est dédiée à la face
avant ou Panel de l’application et l’autre fenêtre va permettre d’éditer le programme en langage G (diagramme ou Diagram). Chacune
S 8 205 − 12
Face avant
Programme
Figure 22 – Fenêtres de l’environnement de développement
en langage G : face avant (à gauche) et programme (à droite)
de ces fenêtres est composée d’une barre de titre, d’une barre de
menus déroulants et d’une barre d’exécution/édition.
■ La face avant d’un instrument virtuel est l’interface (ou moyen
de communication) avec l’utilisateur. Elle symbolise la face avant de
l’instrument physique. Cette fenêtre est personnalisable à souhait
grâce à des objets graphiques, tels que des interrupteurs, des potentiomètres, des zones d’affichage de courbes, etc. Ces objets sont
disponibles au travers d’une fenêtre, appelée controls, composée
de sous-menus classés par type d’objet (valeur numérique, booléenne, chaîne de caractères, etc.). La figure 23 montre une face
avant d’une application de contrôle-commande d’un procédé régulé
en température. À chaque objet de la face avant, et suivant sa fonctionnalité (passage de paramètres ou affichage de résultat), correspond un terminal d’entrée ou un terminal de sortie dans la fenêtre
de programmation (fenêtre Diagram).
■ Le diagramme d’un instrument virtuel décrit le fonctionnement
interne de l’instrument virtuel. C’est dans le diagramme que l’on
édite ses programmes écrits en langage G sous forme de diagrammes flot de données étudiés dans le paragraphe 2.1. Cette édition se
fait en disposant des objets provenant d’une fenêtre, appelée functions, composée de sous-menus où sont classés par catégories les
nœuds disponibles sous LabVIEW. La figure 24 montre le diagramme terminé correspondant à la face avant de la figure 23.
■ La création des programmes en langage G dans la fenêtre Diagram se fait à l’aide de différents outils de l’environnement d’édition (figure 25). Ces outils permettent de manipuler les divers
objets graphiques. Deux principaux outils servent à cette programmation en langage G : l’outil de selection/position (flèche), utilisé
pour mettre en place les divers nœuds du programme et l’outil de
câblage (bobine de fil) qui sert à réaliser les liaisons entre les nœuds.
Il est important de noter qu’une vérification en ligne de l’édition permet à chaque instant de visualiser une liaison correcte ou non avec
un fil brisé dans le dernier cas.
2.2.2 Outils de mise au point
La qualité d’un environnement de programmation se juge souvent aux outils de mise au point. En effet, s’il est relativement facile
de réaliser une édition de programme correcte (niveau de vérification syntaxique), obtenir un programme juste au sens de son adéquation avec les spécifications initiales est toujours plus délicat.
Comme nous l’avons vu, l’environnement d’édition des programmes sous LabVIEW permet rapidement de vérifier que le programme est correctement « dessiné » : aucune liaison brisée, flèche
d’exécution disponible et fenêtre de report d’erreur vide (figure 26).
Mais un deuxième niveau d’aide à la réalisation de programme
est la vérification en exécution lorsque le programme est exempt
d’erreurs de type syntaxique. L’environnement propose trois techniques qui peuvent être associées pour répondre à ce problème :
Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite.
© Techniques de l’Ingénieur, traité Informatique industrielle
__________________________________________________________________
PROGRAMMATION GRAPHIQUE DES APPLICATIONS DE CONTRÔLE-COMMANDE
Figure 23 – Exemple d’une face avant
d’application développée avec l’environnement
LabVIEW
0,0
Boucle d'acquisition
50
Analyse
Limite haute
25
Maximum
Limite basse
Analyse
Minimum
Période
Température
moyenne
Écart type
0
0,0
Acquisition
— utilisation d’un outil sonde (probe) : cet outil permet de vérifier
des valeurs intermédiaires dans un diagramme flot de données. Le
positionnement d’une sonde sur un fil de liaison ouvre une petite
fenêtre de visualisation de la donnée transportée par ce fil ;
— exécution pas à pas (exécution d’un diagramme nœud par
nœud) avec arrêt à tout instant par un mode pause. Il est possible de
placer des points d’arrêt pour procéder à une exécution plus rapide
sur certaines parties du programme ;
— mode animation : grâce à ce mode, le mouvement des données dans un diagramme est visualisé par le déplacement de jetons
et chaque nœud exécuté indique les valeurs des données en sortie
(figure 27). La progression de l’exécution du programme est ainsi
simulée.
Un autre outil peut être ajouté à l’ensemble de ces fonctions de
mise au point, c’est la différenciation graphique. Cette possibilité,
Figure 24 – Exemple du programme
correspondant à la face avant de la figure 23
développé en langage G avec l’environnement
LabVIEW
offerte avec la dernière version du langage LabVIEW, permet à un
utilisateur de comparer deux programmes. Il peut alors aisément se
rendre compte des différences entre les diagrammes. Cette fonctionnalité, déjà disponible dans le contexte des langages textuels,
présente dans le cas des langages graphiques un avantage considérable car il est extrêmement difficile de comparer des graphismes
par rapport à des lignes de textes. Lorsque les utilisateurs développent des applications sophistiquées ou travaillent en équipe et utilisent le contrôle de code source, l’outil de différenciation graphique
permet de réaliser facilement le contrôle des versions. En utilisant
cet outil pour comparer deux programmes LabVIEW, l’utilisateur
obtient une liste des différences entre les deux programmes. En cliquant sur un point de cette liste, la différence correspondante est
alors mise en surbrillance dans le programme. L’utilisateur peut
même choisir de ne visualiser que les différences esthétiques ou
seulement les différences fonctionnelles (figure 28).
Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite.
© Techniques de l’Ingénieur, traité Informatique industrielle
S 8 205 − 13
PROGRAMMATION GRAPHIQUE DES APPLICATIONS DE CONTRÔLE-COMMANDE __________________________________________________________________
utilisateur, des performances globales plus élevées, la capacité de
tirer avantage des machines à architecture multiprocesseurs.
sélectionner, positionner
Manipulation
Écriture
Liaisons
Défilement
Point d'arrêt
Copier couleurs
Menu Pop-up
Sonde
avant-plan
arrière-plan
colorer
Figure 25 – Boîte à outils utilisée pour l’édition des programmes
en langage G dans l’environnement LabVIEW
En réalité, aujourd’hui, seules quelques applications sont réellement multithread, tout simplement parce que cette technologie est
difficile à mettre en œuvre. LabVIEW intègre complètement cette
technologie de façon transparente. Comme LabVIEW est un langage
de programmation par flot de données, dont la structure est intrinsèquement parallèle, il est naturel pour les utilisateurs de créer un
code qui peut s’exécuter simultanément dans des threads séparés.
L’utilisateur n’a pas besoin d’apprendre de nouvelles techniques de
programmation. Cependant, pour les experts qui veulent pouvoir
contrôler précisément leurs threads et pouvoir par exemple définir
des priorités d’exécution, une boîte de dialogue paramétrable est à
leur disposition. Contrairement aux programmeurs en langages textuels qui doivent apprendre de nouvelles méthodes de programmation pour créer une application multithread, un utilisateur LabVIEW
écrit simplement son application (VI) comme il l’a toujours fait
(figure 29). Par exemple, le pilotage de l’interface utilisateur graphique, toujours très pénalisante en terme de temps de réponse, peut
être affectée à une tâche de priorité faible pour privilégier les autres
tâches de traitement.
2.2.4 Langage G et applications temps réel
Flèche d'exécution brisée
200
x
+
message
5
Liaison brisée
Figure 26 – Environnement d’édition des programmes en langage G
permettant de vérifier en ligne la correction d’un programme :
erreur de câblage
2.2.3 Multitâche (multithreading)
Pour répondre aux besoins de vitesse et de fiabilité des applications sur les plates-formes de type PC, les systèmes d’exploitation
les plus récents (à partir de Windows NT, Windows 95 et Sun Solaris) sont multitâche ou « multithread », c’est-à-dire qu’ils permettent
d’individualiser différentes tâches (« thread ») à l’intérieur d’une
même application pour autoriser leurs exécutions en parallèle. Les
applications qui utilisent le multithreading présentent de nombreux
avantages : une utilisation optimisée du processeur, une plus
grande fiabilité du système, une meilleure réponse pour l’interface
Certaines applications de test automatique et de contrôle-commande de processus industriel nécessitent un traitement temps réel
des informations. C’est le cas en particulier des applications de
contrôle de moteurs avec dynamomètres, de contrôle de systèmes
hydrauliques, de test de vibrations, etc.
Répondre en temps réel est la capacité de répondre de façon fiable à un événement dans un laps de temps garanti. Ce laps de temps
varie d’une application à une autre. C’est pourquoi, il n’y a pas de
contrainte temporelle universelle qui permette de qualifier un système de temps réel.
Par exemple, lorsque l’on exécute une boucle de contrôle, on doit
garantir que la sortie du contrôleur répond à une sollicitation en
entrée à l’intérieur d’un intervalle de temps spécifié, que l’on appelle
temps de cycle de la boucle. Si ce temps de cycle peut être garanti,
le système est qualifié de déterministe ou de temps réel. Si une
boucle de contrôle n’est pas déterministe, alors la stabilité du système de contrôle n’est pas garantie. Avec des systèmes d’exploitation « classiques » comme Windows 3.1/95/98 ou MacOS, cette
garantie n’est pas possible. Ce qui explique que l’utilisation de plus
en plus répandue des PC dans l’automatisation industrielle se fasse
encore souvent en conjonction avec des automates programmables, qui intègrent leur propre processeur. Dans bien des cas, l’automate pourrait être remplacé par une simple carte d’acquisition de
données, mais il présente sur celle-ci l’avantage précieux de pouvoir
garantir le caractère temps réel d’une application. Alors qu’avec une
carte d’acquisition de données, le programme est soumis aux aléas
du système d’exploitation de l’ordinateur hôte.
600,00
Nombre 1
30,00
Nombre 2
20,00
30,00
PGCD
20,00
les nœuds ou les fils de liaison en tireté ne sont pas encore exécutés
S 8 205 − 14
PPCM
Figure 27 – Mise au point d’un programme
par visualisation du flot de données
(mode animation)
Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite.
© Techniques de l’Ingénieur, traité Informatique industrielle
__________________________________________________________________
PROGRAMMATION GRAPHIQUE DES APPLICATIONS DE CONTRÔLE-COMMANDE
Commentaire non pris en compte
dans la différenciation
64
64
128
128
–2
–2
Surbrillance
Programme 1
Programme 2
Figure 28 – Exemple de l’aide à la mise au point : outil de différenciation graphique utilisé pour la comparaison de deux programmes LabVIEW
ACQ
INIT
0.00
ACQ
ACQ
FINI
ANYS
0.00
SAVE
INIT
SAVE
SAVE
FINI
10
le développeur peut choisir les priorités respectives de ces opérations
Cependant, les utilisateurs de programmes écrits en langage graphique disposent d’une alternative depuis l’apparition d’une version
temps réel de LabVIEW (« LabVIEW RT », RT : Real-Time). Celle-ci
permet d’utiliser des cartes d’acquisition de données dites intelligentes, sur lesquelles est intégré un processeur DSP (Digital Signal
Processor). Des programmes graphiques complet peuvent ainsi être
instantanément embarqués sur le processeur de la carte. Une fois
Figure 29 – Exemple de trois tâches
(acquisition, analyse et sauvegarde
des données en langage G)
embarqué, LabVIEW RT s’exécute directement sur la carte, en totale
indépendance vis-à-vis du processeur du PC hôte. Les utilisateurs
disposent ainsi d’un moyen de réaliser de véritables applications
temps réel, déterministes. En effet, ces applications continuent de
tourner à plein régime même si la souris est déplacée ou si d’autres
applications tournent sous Windows, et même si ce dernier tombe
en panne.
Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite.
© Techniques de l’Ingénieur, traité Informatique industrielle
S 8 205 − 15
PROGRAMMATION GRAPHIQUE DES APPLICATIONS DE CONTRÔLE-COMMANDE __________________________________________________________________
En fait, LabVIEW RT est constitué de deux éléments : le système
de développement RT et le moteur RT (noyau temps réel associé
aux programmes développés en langage G). Le premier est une
application LabVIEW classique pour Windows NT/98/95 qui tourne
sur le PC hôte. Le moteur RT tourne sur le processeur de la carte
intelligente et exécute les programmes LabVIEW RT embarqués.
L’utilisateur peut conserver le système de développement actif, et
s’en servir comme interface utilisateur pour le programme
LabVIEW RT embarqué. Le système de développement échange
alors des messages avec le moteur RT pour mettre à jour les éléments de contrôle et les indicateurs de la face avant. Ces communications s’effectuent de façon automatique et de façon transparente.
Pour revenir au temps de cycle d’une boucle de contrôle quelconque, c’est le degré d’incertitude ou de gigue (« jitter ») de chaque
temps de cycle qui définit la nécessité de temps réel d’un système.
Exemple : considérons une application de régulation basée sur un
PID, qui s’exécute sous LabVIEW RT. Supposons que cette régulation
soit effectuée à partir d’une seule entrée analogique. Entre la mesure,
le calcul de la commande selon le PID, puis la génération d’un signal
sur une sortie analogique, la gigue correspondante est d’environ 10 µs,
temps compatible avec la plupart des applications de régulation.
2.2.5 LabVIEW : bibliothèque de fonctions
L’environnement LabVIEW possède des bibliothèques de fonctions
spécialisées dans le domaine de la mesure, du test et du contrôlecommande. Ces bibliothèques de fonctions ont été réalisées soit à
partir des fonctions et opérateurs de base vus précédemment, soit
directement par des programmes écrits en langage de haut niveau,
compilé et ensuite intégré sous la forme d’un nœud graphique.
Cette dernière possibilité est aussi offerte aux utilisateurs de cet
environnement LabVIEW par l’intermédiaire de la construction de
nœuds particuliers appelés « nœud d’interface vers code » (CIN :
Code Interface Node). L’utilisation de ces fonctions qui peuvent être
assez complexes est facilitée par une aide en ligne qui donne pour
chaque fonction une description sommaire, mais souvent suffisante
de ses spécifications (figure 30).
Dans l’ensemble des bibliothèques fournies, nous pouvons en
citer quelques-unes qui sont parmi les plus importantes pour le
domaine de l’analyse du signal : cette bibliothèque très complète se
décompose en de nombreuses sous-bibliothèques spécifiques :
génération de signaux (figure 31), traitement des signaux (transformée de Fourier, intercorrélation, intégration, etc.), filtrage des
signaux (figure 32), fenêtrage (fenêtre triangle, fenêtre de Hanning,
fenêtre de Blackman, etc.), statistiques et probabilités (figure 33),
analyse par ondelettes…Ces bibliothèques se trouvent en standard
dans l’environnement LabVIEW.
échantillons
amplitude
phase (degrés)
périodes
onde sinusoïdale
erreur
Génération d'une onde sinusoïdale
Cette fonction permet de générer une onde sinusoïdale composée
de plusieurs périodes. Soit x les échantillons d'entrée, les échantillons
de sortie y sont :
y[i] = A * sin(x[i])
pour i = 0 .. n–1
avec x[i] = 2 π * i * k / n + ph * π /180
(A : amplitude, k : nombre de périodes, ph : la phase initiale en degré,
n : nombre d'échantillons)
Figure 30 – Exemple de la fenêtre d’aide offrant la description d’une
fonction fournie dans la bibliothèque de l’environnement LabVIEW
S 8 205 − 16
Génération
d'une onde
sinusoïdale
Génération
d'une impulsion
Génération d'une rampe
Génération d'un bruit
blanc gaussien
Figure 31 – Exemple de quelques fonctions de génération de signaux
Détection de crêtes
Filtre de Butterworth
Tracé de la
fonction de transfert
Filtre de Chebyshev
Figure 32 – Exemple de quelques fonctions de filtrage de signaux
Valeur moyenne
Écart type
Loi de probabilité
normale
Histogramme
Figure 33 – Exemple de quelques fonctions de statistiques
et probabilités
Il en existe de nombreuses autres proposées en option pour
répondre à des besoins particuliers.
La bibliothèque de contrôle PID ajoute aux fonctions standard de
LabVIEW un ensemble d’algorithmes de régulation P, PI, PD et PID
en boucles ouvertes ou fermées, avec toutes les options que l’on
trouve généralement dans les systèmes de régulation complets, y
compris la compensation de soudure froide et la génération de rampes de points de consigne (figure 34).
La bibliothèque de logique floue est destinée à accélérer le développement d’applications de contrôle pour les systèmes non linéaires ou complexes. Elle propose une interface graphique prête-àl’emploi pour la conception de contrôleurs de logique floue et des VI
pour créer ces contrôleurs dans LabVIEW. La logique floue est basée
sur des lois qui émulent la prise de décision humaine. Les lois
créées peuvent utiliser des termes linguistiques comme « chaud »,
« bas » ou « gauche ». À partir de ces lois, des modèles mathémati-
Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite.
© Techniques de l’Ingénieur, traité Informatique industrielle
__________________________________________________________________
PROGRAMMATION GRAPHIQUE DES APPLICATIONS DE CONTRÔLE-COMMANDE
2.3 LabVIEW et le contrôle-commande
de procédés
2.3.1 Matériels d’entrées/sorties (E/S)
2.3.1.1 Cartes d’acquisition de données
Face avant d'une application de contrôle continu
de niveau avec les paramètres de réglage du PID
setpoint
output
process variable
Le langage G, rapide en exécution car compilé, se prête particulièrement bien aux opérations d’acquisition et de traitement en temps
réel, aux suivis de réactions dans le monde « physique ». Il existe de
nombreuses façons de récupérer des données issues du monde
physique et de générer des données de commande. L’une des plus
simples et des plus directes consiste à installer dans l’ordinateur
une carte dite d’acquisition de données, dont la fonction de base est
de convertir les données du monde physique en données informatiques, immédiatement exploitables par le programme d’application.
En fait, le terme d’acquisition de données est impropre, car la plupart de ces cartes servent à acquérir des données mais aussi à en
générer. Il faudrait en fait parler de cartes d’entrées/sorties, lesquelles permettent de couvrir une grande partie des besoins en contrôlecommande de processus. Pour être exact, on distingue six fonctions
dans les cartes les plus complètes (dites cartes d’acquisition de données multifonction).
Figure 34 – Exemple d’utilisation de la bibliothèque de régulation
de type PID
■ Les entrées analogiques font appel à autant de convertisseurs
analogique/numérique (CA/N) que d’entrées, ou à un seul couplé
avec un multiplexeur. Elles permettent de convertir en bits informatiques un signal analogique, présenté sous forme d’une tension
variant dans le temps, à l’intérieur d’une fourchette qui peut être de
0 à 10 V, ou encore de –5 à +5 V. En tout cas, une entrée analogique
d’une carte d’acquisition de données n’est pas en mesure d’accepter
autre chose que des tensions, et dans une gamme donnée. C’est
pourquoi, il convient souvent d’installer, entre les signaux à acquérir
et la carte, un système dit de conditionnement de signaux. C’est tout
aussi vrai pour les autres types d’entrées et de sorties, décrites ciaprès.
ques définissent des algorithmes de prise de décision. Les contrôles
de logique floue sont utilisés dans les applications de contrôle de
processus, de mélange chimique, d’identification de signaux ou de
reconnaissance de forme… pour répondre plus efficacement à des
problèmes de prise de décision particulière.
Grâce au conditionnement de signaux, on peut utiliser les entrées
des cartes d’acquisition de données pour mesurer des températures, des forces, des débits, des vibrations, des courants et naturellement des tensions. Pour les températures par exemple, le
conditionnement consiste à transformer les signaux issus des capteurs (très faibles tensions non linéaires) en tensions linéaires compatibles avec la gamme d’entrée de l’amplificateur qui précède le
CA/N sur la carte.
PID parameters
manual control
options
iteration
Instrument virtuel réalisant
la régulation (PID vi)
La bibliothèque Test Executive sert à l’exécution automatique de
programmes de test en production. Il comprend une application de
séquencement de tests prête à l’emploi, développée dans LabVIEW,
que l’on peut utiliser telle quelle ou que l’on peut personnaliser pour
mieux répondre à des besoins particuliers.
■ Les sorties analogiques font appel à un ou plusieurs convertisseurs numériques/analogiques (CN/A), qui permet de convertir une
suite de bits informatiques en variation de tension, c’est-à-dire en
signal analogique. Là aussi un système de conditionnement peutêtre requis. Le but est de pouvoir générer un signal de stimuli sur un
dispositif dont on peut mesurer l’effet sur les entrées analogiques. Il
peut aussi s’agir de réagir à un événement, comme dans le cas de la
régulation.
Exemple : une entrée analogique acquiert une température, le programme analyse cette température, alerte d’un éventuel dépassement
de consigne et déclenche un refroidissement au travers d’une sortie
analogique.
La bibliothèque de symboles d’automatismes contient un ensemble de contrôles standard ISA (International Society for Measurement and Control) utilisables pour créer des applications d’IHM
(interface homme-machine) et de supervision sous LabVIEW. La
bibliothèque donne accès aux contrôles et aux indicateurs d’automatisation symboliques les plus connus. L’utilisateur peut les intégrer dans la face avant de son application mais peut aussi créer ses
propres contrôles à partir des représentations de ces symboles. On
trouve des symboles de pompes 2D et 3D, de vannes, de moteurs et
de cuves. Ils sont disponibles sous forme d’objets de contrôles et
d’indicateurs mais aussi sous forme de fichiers metafile que l’on
peut utiliser comme décorations ou importer sur des objets LabVIEW existants.
■ Les entrées/sorties numériques sont fréquentes car les dispositifs du monde physique communiquent assez souvent par des informations numériques, sous la forme simple d’une tension à deux
états 0 ou 5 V par exemple. C’est le cas des capteurs de présence, et
de la plupart des relais. La conversion en bits informatiques est
quasi immédiate. C’est dans les applications de contrôle-commande
de processus que l’on trouve le plus souvent ce genre de dispositifs.
Nous sommes alors dans le domaine des systèmes à événements
discrets. De même, de nombreux dispositifs se commandent en tout
ou rien, comme les vannes, les interrupteurs, les relais, les
moteurs... Généralement, le courant produit par la carte est suffisant
pour commuter ces dispositifs et aucun conditionnement n’est
nécessaire.
La bibliothèque de fonctions MSP (maîtrise statistique de procédé) est destinée aux applications de contrôle-commande nécessitant une analyse de la qualité, en vue de son amélioration. Elle
intègre les trois principales fonctionnalités relatives à la MSP : les
cartes de contrôle, les statistiques de processus et l’analyse de
Pareto. Pour chacun de ces domaines, l’utilisateur dispose de fonctions d’analyse des informations et d’affichage des résultats.
Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite.
© Techniques de l’Ingénieur, traité Informatique industrielle
S 8 205 − 17
PROGRAMMATION GRAPHIQUE DES APPLICATIONS DE CONTRÔLE-COMMANDE __________________________________________________________________
■ Les entrées de comptage permettent de compter les occurrences
d’un événement numérique. Cela permet notamment de définir la
base de temps qui détermine les opérations du compteur intégré
sur la carte. Les sorties de synchronisation permettent de générer
des impulsions numériques pour synchroniser ou commander des
dispositifs extérieurs. Parmi les applications types des entrées/
sorties de comptage et de synchronisation, on citera le positionnement à partir d’encodeurs linéaires ou rotatifs.
2.3.1.2 Pilotes des cartes d’acquisition de données
Pour piloter les cartes d’entrées/sorties, acquérir et générer des
données, le programme graphique, comme tout logiciel d’application, fait appel à une couche logicielle qui sert d’interface avec les
registres de fonction de la carte. Cette couche, qui pourrait se résumer à une bibliothèque de fonctions, s’appelle le « pilote » de la
carte. Le terme anglais « driver » est plus souvent employé. Sans
driver, une carte peut être utilisée, mais au travers de fonctions de
très bas niveau, très complexes à mettre en œuvre. Le driver permet
aussi de gérer tous les aspects d’interruption et de transfert des
données en mémoire, sans que le programmeur ait à entrer dans les
détails compliqués de ces opérations.
Le driver se suffit à lui-même pour piloter une carte d’E/S. Il offre
généralement une interface utilisateur intuitive qui permet de configurer et de faire fonctionner une carte de manière assez simple.
Mais dès qu’il s’agit d’automatiser les opérations d’acquisition de
données, ou simplement de traiter les données acquises, le driver
ne suffit plus et il faut faire appel soit à un logiciel d’application, soit
à un langage de programmation. Le driver doit être compatible avec
cette couche logicielle supplémentaire. Ce n’est plus un problème
depuis que le principe de DLL (Dynamic Link Library) s’est développé. Il s’agit d’un conditionnement standard des fonctions, qui
permet à tout logiciel supportant ce standard (la très grande majorité) de communiquer avec le driver (§ 2.3.4).
Pour qu’un driver soit complet, il ne suffit pas qu’il permette
d’acquérir et de générer des données sur les E/S de la carte. Il doit
remplir les fonctions suivantes :
— acquérir les données à des fréquences d’échantillonnage
spécifiées ;
— acquérir les données en tâche de fond pendant que le traitement se réalise en tâche principale (principe de l’acquisition de données en continu) ;
— supporter les entrées/sorties programmées, les interruptions
et le DMA (Direct Access Memory) pour le transfert des données ;
— transférer les données du et vers le disque dur de l’ordinateur ;
— remplir plusieurs fonctions simultanément ;
— supporter plusieurs cartes d’acquisition de données ;
— intégrer le pilotage de l’éventuel système de conditionnement
associé à la carte.
Il faut noter que parfois, le fournisseur de la carte et le fournisseur
du driver sont différents. Ce qui peut être dangereux dans le sens où
le driver risque de ne pas donner accès à l’ensemble des fonctions
offertes par la carte.
Dans LabVIEW, les bibliothèques d’acquisition de données sont
installées en standard (figure 35). Elles contiennent des VI, construits de manière hiérarchique sur trois niveaux : Easy I/O (niveau le
plus simple), Intermediate (niveau intermédiaire) et Advanced
(niveau supérieur). Comme tous les VI, chacun présente des entrées
et des sorties. Le programmeur assemble les VI dans son diagramme, les paramètre et les connecte entre eux pour obtenir le
sous-programme d’acquisition de données proprement dit
(figures 36 et 37). Il obtient ainsi un VI dans lequel sont encapsulés
les VI qu’il a assemblés. Ce VI de haut niveau peut être ensuite intégré avec ceux dont le rôle est d’exploiter les données acquises. Le
driver se charge de traduire les commandes manuelles ou automatiques envoyées par l’opérateur, au travers de l’interface graphique
de l’application ou par le programme lui-même si le contrôle de la
carte est assujetti à des résultats de traitement.
D’autres cartes d’entrées/sorties spécifiques que celles d’acquisition des données sont utilisées dans les applications de contrôlecommande. Nous trouvons par exemple les cartes suivantes.
■ Cartes de commande d’axes moteurs
Si les cartes d’acquisition de données multifonctions intègrent
généralement des sorties permettant d’agir sur le procédé, il faut
faire appel à des cartes spécialisées pour le contrôle des moteurs en
particulier. Dans ce cas aussi, le programmeur en langage G,
comme pour tout langage, fait appel à un driver ou à une DLL pour
intégrer le contrôle de mouvement dans son application. Il existe
une bibliothèque de VI pour piloter facilement les cartes de contrôle
d’axes au sein d’un programme G.
taskID d'entrée
taskID de sortie
nombre de
balayages à lire
données mises
à l'échelle
entrée d'erreur
sortie d'erreur
Figure 35 – Icône permettant de demander la lecture d’une mesure
sur l’une des voies d’une carte d’acquisition de données
Graphe tension
Périphérique (1)
Canal (0)
Points à acquérir (1000)
Vitesse d'acquisition (4000 scans/sec)
Figure 36 – Assemblage des icônes permettant d’acquérir 1 000 points sur le canal 0 de la carte n° 1
S 8 205 − 18
Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite.
© Techniques de l’Ingénieur, traité Informatique industrielle
__________________________________________________________________
PROGRAMMATION GRAPHIQUE DES APPLICATIONS DE CONTRÔLE-COMMANDE
Face avant du programme de contrôle
Figure 37 – Interface utilisateur correspondant au diagramme
de la figure 36
■ Cartes d’acquisition d’images
Autre matériel susceptible d’être intégré dans une application de
contrôle-commande, la carte d’acquisition d’image est aussi fournie
avec son driver. Il existe des bibliothèques de VI spécifiquement
destinés aux applications de vision. Deux types de cartes d’acquisition d’images peuvent être choisis : pour les caméras analogiques et
pour les caméras numériques. Dans les deux cas, il existe des versions monochrome (niveaux de gris plus exactement), ainsi que
couleur. Il est possible également de trouver des caméras infrarouges. En plus des entrées vidéo, une carte d’acquisition d’images dispose souvent d’E/S numériques. Ainsi, la carte après avoir acquis
une image et que cette image ait été traitée, peut servir à piloter un
relais ou un solénoïde pour enlever par exemple un objet défectueux d’une ligne d’assemblage. Le driver d’une carte d’acquisition
d’images doit notamment remplir les fonctions suivantes : acquérir
les images dans la mémoire de façon continue, acquérir les images
de plusieurs sources vidéo, utiliser le DMA pour transférer les images, contrôler les E/S numériques, déclencher l’acquisition sur un
événement, gérer la mise à l’échelle des images...
2.3.2 Pilotes d’instruments de mesure
■ Instruments GPIB
Le pilotage de l’instrumentation GPIB (General Purpose Interface
Bus) fut l’une des toutes premières applications de la programmation graphique. Le GPIB est rapidement devenu, depuis son apparition en 1965, un standard de communication (IEEE 488) qui permet
aujourd’hui de contrôler la plupart des instruments de mesure électronique (oscilloscopes, multimètres, générateurs de fonctions, analyseurs de spectre, etc.). On trouve donc généralement des
systèmes GPIB dans les laboratoires et dans le domaine du test électronique. En production, on parle de bancs de test, composés de
plusieurs instruments GPIB contrôlés par un PC équipé d’une carte
d’interface GPIB. Le programme commande les instruments, récupère les mesures, les traite, les affiche et réagit en fonction des
résultats.
Le principe est donc le même qu’en acquisition de données, si ce
n’est qu’il s’agit d’instruments autonomes, externes au PC, au sein
desquels sont effectuées les opérations de conversion A/N et N/A.
Les données sont déjà numérisées lorsqu’elles parviennent au PC. A
noter qu’il existe également de nombreuses centrales d’acquisition
de données dotées d’une interface de communication GPIB. La carte
d’interface sert à convertir le format de données propre au GPIB
Programme de pilotage qui consiste à assembler des icônes
de commande manipulant des chaînes de caractère
Figure 38 – Exemple du pilotage d’un multimètre par une liaison
GPIB
(langage de contrôle-commande sous forme alphanumérique).
Comme pour les cartes d’acquisition de données, les cartes GPIB
sont fournies avec leur driver qui est utilisé par le programme graphique au travers de la bibliothèque de VI GPIB (figure 38).
■ Instruments VXI
Extension du bus VME (Versatile Module Europe) pour l’instrumentation, le bus VXI permet en quelque sorte de réduire un banc
d’instruments GPIB autonomes à un châssis où les instruments sont
limités à des modules sans faces avant. Les instruments GPIB sont
effectivement dotés de faces avant pour pouvoir être utilisés de
façon indépendante, manuellement. Mais un instrument VXI ne
peut être utilisé que par le biais d’un PC de contrôle, via un logiciel.
Les applications se situent donc essentiellement dans le domaine
du test automatique, avec des performances élevées en terme de
rapidité (les instruments sont interconnectés sur le fond de panier).
Le contrôle d’un système VXI par un PC peut se faire au travers de
différentes interfaces :
— l’interface MXI (carte d’interface dans l’ordinateur, câble MXI
et module d’interface dans le châssis VXI) est la plus rapide. Tout se
passe comme si le PC de contrôle était directement relié au bus VXI
qui interconnecte les instruments (transferts à 100 Mo/s) ;
— l’interface GPIB (carte d’interface dans l’ordinateur, câble GPIB
et module d’interface dans le châssis VXI) est la plus lente mais aussi
la plus simple à mettre en œuvre. En comparaison des 100 Mo/s du
MXI, le bus GPIB est limité à 8 Mo/s, ce qui peut être pénalisant pour
les applications de test haute vitesse ;
— l’interface FireWire (carte d’interface dans l’ordinateur, câble
IEEE-1194 et module d’interface dans le châssis VXI) est une solution qui est apparue en 1998 et qui promet des vitesses de transfert
aussi élevées que le MXI (plus de 100 Mo/s).
Nota : VXI Versatile exchange Interface
MXI Multisystem extension Interface
Enfin, il est aussi possible d’intégrer le PC de contrôle dans un
châssis VXI. Les performances sont alors optimales et la compacité
Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite.
© Techniques de l’Ingénieur, traité Informatique industrielle
S 8 205 − 19
PROGRAMMATION GRAPHIQUE DES APPLICATIONS DE CONTRÔLE-COMMANDE __________________________________________________________________
totale. Dans cette configuration, le PC peut d’ailleurs accueillir des
cartes d’acquisition de données, d’acquisition d’images, de contrôle
d’axes et/ou d’interface GPIB. Comme pour le GPIB, il existe des drivers que les développeurs peuvent utiliser dans leurs programmes
graphique, en utilisant la bibliothèque des instruments virtuels VXI.
■ Instruments avec liaison série
La liaison série RS-232 (RS pour Recommended Standards) est un
moyen de communication très répandu pour la transmission de
données entre un ordinateur et un périphérique tels qu’une imprimante, un traceur ou un instrument programmable. Dans le
domaine de la mesure, la liaison RS-232 est depuis très longtemps
le standard de communication des instruments de mesure physicochimiques. On trouve aussi de nombreuses centrales de mesure et
des appareils en tous genres programmables en RS-232. La liaison
série utilise un émetteur pour envoyer les données les unes derrière
les autres, bit par bit, sur une ligne de communication unique, à destination d’un récepteur. Cette technique de communication est classique pour les transferts à faible vitesse ou sur de longues
distances. Les données peuvent ainsi être transférées via des
modems sur des lignes téléphoniques.
Le succès de la liaison série s’explique du fait que la plupart des
ordinateurs ont un ou deux ports série, l’inconvénient majeur étant
toutefois que le port série ne permet de communiquer qu’avec un
seul équipement à la fois. Pour pouvoir communiquer avec plusieurs équipements, il faut faire appel à une carte d’interface multiport ou à un module de multiplexage.
Étant donné la simplicité de la liaison série, la bibliothèque pour
le port série se résume à cinq instruments virtuels (VI): Serial Port
Init, Serial Port Write, Serial Port Read, Bytes at Serial Port et Serial
Port Break. Un programme de gestion de port série, réalisé en langage G dans l’environnement LabVIEW est donc très simple
puisqu’il consiste à mettre en séquence les différents VI de base
(figure 39).
■ Drivers d’instruments de mesures
L’agencement des VI de communication avec les instruments de
mesure peut être fastidieux. C’est pourquoi il existe ce que l’on
appelle des drivers d’instruments, dont le rôle essentiel est la manipulation de chaînes de caractères, dites de commande. À chaque instrument correspond un driver qui fournit à l’utilisateur une sorte de
face avant dans laquelle il va pouvoir entrer de manière explicite les
paramètres de configuration et obtenir des données compréhensibles (une tension en volt par exemple) et non une chaîne de caractères codée, que lui retourne le driver de l’interface de communication.
Ce driver d’instrument permet en quelque sorte d’obtenir à l’écran
une face avant virtuelle de contrôle de l’instrument. Mais plus
important, il va pouvoir être utilisé au sein d’un programme d’application, et notamment au sein d’un programme écrit en langage G,
sans que l’utilisateur ait besoin de connaître le protocole de programmation de chaque instrument. Il existe en effet des VI drivers
d’instruments pour un très grand nombre d’appareils différents,
couvrant la grande majorité de l’offre (sites Internet cités en [Doc. S
8 205]). Le développeur peut ainsi inclure un VI driver dans un diagramme et intégrer le contrôle-commande de ses instruments de
mesure dans son application LabVIEW.
La disponibilité du driver d’instruments est essentielle car il permet de développer très rapidement des applications de test automatique. En 1998, une association de fabricants et d’utilisateurs s’est
créée (La Fondation IVI, pour Interchangeable Virtual Instruments,
cf. [Doc. S 8 205]) afin d’organiser la standardisation des drivers de
manière à pouvoir notamment remplacer un instrument dans un
banc de test par un autre sans avoir besoin de modifier le programme de test.
Il existe également des instruments réalisés sous forme de cartes
enfichables dans l’ordinateur (multimètre, oscilloscopes...). Leur
pilotage s’effectue comme celui des cartes d’acquisition de données.
2.3.3 Pilotes de bus et d’automates
programmables
La standardisation de la communication a longtemps été un point
noir dans le domaine industriel et en particulier dans celui des
réseaux de terrain et des automates programmables.
Un bus de terrain permet de relier différents dispositifs répartis
dans une unité de production par exemple, afin de centraliser le
contrôle-commande de l’ensemble. Un bus de terrain peut relier des
capteurs, des actionneurs, des régulateurs, des E/S déportées, des
automates... à un ordinateur qui sert de poste de supervision. La
liste des bus de terrain est très longue, mais diminue au fil des
années. Actuellement il reste principalement les bus suivants : Profibus, FIP (Factory Instrumentation Protocol), WorldFIP, Foundation
Fieldbus, Interbus, CAN (Controller Area Network), Fieldpoint...
cette liste n’étant pas exhaustive. Tous ces bus font appel à une ou
plusieurs liaisons série synchrones ou asynchrones mais diffèrent
dans leur architecture et dans le protocole utilisé pour communiquer les commandes et les données. Certains de ces bus nécessitent, côté PC de contrôle, un port série simple ou une carte
d’interface particulière. Le plus délicat est, au niveau logiciel, de
supporter le protocole utilisé. Heureusement pour le langage graphique, une multitude de bibliothèques de VI ont été développées,
souvent par les utilisateurs eux-même, pour répondre aux besoins
des différents bus existants.
En ce qui concerne les automates, depuis l’arrivée du standard
OPC (OLE for Process Control) en 1996 et la disponibilité de clients
OPC en langage graphique, il est possible de piloter n’importe quel
serveur OPC, indépendamment du type de liaison mise en œuvre.
Le nombre de matériels proposés avec un serveur OPC augmente
très rapidement.
2.3.4 Outils pour accélérer le développement
des applications de contrôle-commande
■ Programmes existants
Figure 39 – Exemple de diagramme permettant de communiquer
avec un appareil en liaison série
S 8 205 − 20
La première approche consiste à faire appel à des exemples déjà
créés. LabVIEW contient en effet un ensemble de solutions (DAQ
Solutions Gallery) qui rassemble les cas les plus courants de l’acquisition de données. L’utilisateur peut y trouver la ou les solutions qui
correspondent le mieux à ses besoins, comme par exemple un
Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite.
© Techniques de l’Ingénieur, traité Informatique industrielle
__________________________________________________________________
PROGRAMMATION GRAPHIQUE DES APPLICATIONS DE CONTRÔLE-COMMANDE
oscilloscope, un multimètre, un générateur de fonctions, un enregistreur de données, un système de mesure par capteur, un analyseur de signaux, etc. Les diagrammes, qui contiennent le code
source G, peuvent être adaptés pour répondre spécifiquement aux
besoins de l’utilisateur.
■ Assistants pour l’acquisition de données
Pour développer rapidement une application d’acquisition de
données, l’utilisateur dispose dans l’environnement LabVIEW
d’assistants appelés « DAQ Wizards ». Il s’agit d’utilitaires de génération automatique de programmes. En pratique, l’utilisateur décrit
son application à l’aide d’une série de boîtes de dialogue, sans avoir
besoin de connaître la programmation graphique. Il indique les
caractéristiques de ses entrées/sorties analogiques, de ses entrées/
sorties numériques, de ses fichiers d’entrées/sorties, etc. Lorsque la
description est terminée, LabVIEW génère automatiquement l’application en langage G prête à exécuter. Éventuellement, l’utilisateur
n’a plus qu’à enrichir cette application avec les bibliothèques de
fonctions de LabVIEW. Les programmes générés étant strictement
des VI, le concepteur peut les exécuter immédiatement comme il
pourrait le faire avec un progiciel configurable, basé sur des menus.
L’utilisateur expérimenté, qui développe des applications complexes, va pouvoir améliorer sa productivité en exploitant cette génération automatique de programmes comme point de départ de ses
développements.
Sans utiliser les assistants, le développeur doit passer beaucoup
de temps à définir les types de signaux, les connexions, les formules
de conversion, etc., avant de pouvoir faire le développement proprement dit.
Exemple : l’utilisation d’un thermocouple nécessite de résoudre le
problème de compensation de soudure froide, de déterminer les algorithmes de conversion des tensions délivrées par le capteur en valeur
de température, d’appliquer des facteurs de forme (dépendant du type
de thermocouple utilisé), puis de convertir la température dans l’unité
appropriée (°C, °F ou K). Avec l’assistant de configuration des E/S (DAQ
Channel Wizard), le même développeur n’a plus qu’à remplir des
cadres pour indiquer le nom et la description de son entrée analogique,
le type de thermocouple utilisé, l’algorithme de compensation approprié et l’unité souhaitée. Tous ces paramètres sont alors référencés
dans l’application, avec tous les processus de conversion mis en
œuvre de façon transparente.
■ Assistants pour le contrôle d’instrumentation
L’utilisateur de LabVIEW peut facilement identifier et tester les instruments connectés à son système. L’assistant « Instrument
Wizard » installe automatiquement les drivers d’instruments et
génère ensuite des exemples d’applications qui utilisent ces drivers
d’instruments (figures 40 et 41). Les utilisateurs peuvent ainsi rapidement établir la communication avec leurs appareils, sans manipuler une seule icône. L’assistant crée entièrement l’application, avec
son code source, que l’utilisateur peut modifier à sa guise.
Figure 40 – Assistant de contrôle d’instrumentation : identification
des instruments et des ports du système
Figure 41 – Assistant de contrôle d’instrumentation : installation
des drivers d’instruments nécessaires puis génération d’un exemple
complet pour l’instrument connecté avec le code source modifiable
2.3.5 Échanges de données informatisés
■ Entrées/sorties sur fichiers
Un programme, écrit en langage graphique, est capable d’effectuer du post-traitement sur des données stockées dans un fichier, et
aussi inversement de générer des fichiers de données. Il existe une
bibliothèque de VI propre aux échanges sur fichiers. Le développeur
y trouve des fonctions qui, en plus d’assurer la lecture et l’écriture
de donnée, permettent de déplacer et de nommer des fichiers et des
répertoires, de créer des fichiers au format tableur contenant du
texte de type ASCII et d’écrire des données en format binaire pour
gagner de la place et de la vitesse (figure 42).
■ Échanges avec les bases de données SQL
Il existe une bibliothèque de fonctions conçues pour permettre
une interaction directe avec une base de données, locale ou distante, compatible avec le standard de communication SQL (Structured Query Language). L’utilisateur peut ainsi sauvegarder ses
données, les mettre à jour ou en importer dans plus de trente formats de base de données différents, en utilisant des fonctions
d’affectation de haut niveau. Il existe également des VI de bas
niveau qui permettent d’accéder directement aux colonnes, enregistrements et tables.
Il est intéressant de noter que les utilisateurs n’ont pas besoin de
disposer de leur propre base de données. La bibliothèque SQL est
en effet fournie avec un moteur de base de données qui permet de
créer sa propre base de données directement dans l’environnement
LabVIEW.
Figure 42 – Bibliothèque d’entrées/sorties sur fichiers :
manipulation des fichiers ASCII et binaires
Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite.
© Techniques de l’Ingénieur, traité Informatique industrielle
S 8 205 − 21
PROGRAMMATION GRAPHIQUE DES APPLICATIONS DE CONTRÔLE-COMMANDE __________________________________________________________________
■ Échanges de données entre applications
De gros progrès technologiques ont vu le jour dans les années 90
en ce qui concerne l’échange de données entre différentes applications. Un grand pas a été franchi avec la technologie DDE (Dynamic
Data Exchange) de Microsoft, qui permet d’envoyer des données
d’une application vers une autre. Est apparue ensuite la technologie
OLE (Object Linkink and Embedding), rebaptisée ActiveX, permettant d’aller plus loin avec la possibilité de contrôler une application
à partir d’une autre. Ces progrès ont été réalisés avant tout dans le
cadre des applications classiques de l’informatique, comme la
bureautique. Il s’agissait de permettre l’utilisation conjointe de plusieurs logiciels afin d’obtenir un résultat optimal. L’exemple le plus
simple consiste à intégrer, dans un document texte créé avec un
traitement de texte, un tableau créé avec un tableur.
Dans les applications scientifiques et industrielles, ce type de possibilité se révèle particulièrement intéressant. Les outils logiciels
sont souvent spécialisés et se révèlent excellents dans des fonctions
très précises, tout en étant moins performants dans d’autres domaines. Bref, il est intéressant de combiner plusieurs outils ensemble.
Par ailleurs, de plus en plus de personnes doivent travailler de
concert au sein d’une même entreprise. C’est ainsi qu’il est devenu
de plus en plus important de partager le code au travers d’environnements de programmation différents.
Face avant de l'application
La technologie ActiveX est basée sur le principe d’ « objets » de
code, écrit dans un langage donné mais pouvant être appelés à partir de tout autre environnement. C’est très important dans le cadre
des applications industrielles pour deux raisons. Premièrement, les
objets réutilisables permettent aux entreprises d’optimiser la rentabilité de leurs développements. Deuxièmement, ils offrent aux développeurs la possibilité d’utiliser les outils logiciels les mieux adaptés
à différentes tâches données et de pouvoir ensuite intégrer ces
tâches, comme des composants, dans d’autres applications à l’intérieur de l’entreprise.
Les objets ActiveX s’appellent en fait des contrôles ActiveX. Ils
représentent le type d’objets réutilisables le plus répandu dans le
monde. On en trouve des milliers sur Internet. Ce sont des morceaux de code généralement optimisés pour une fonction particulière. Ce peut être par exemple l’affichage d’un graphe en 3D. Pour
être utilisable dans un environnement, il faut que cet environnement soit « Container ActiveX ». C’est le cas de Visual Basic et de
Visual C++. C’est aussi le cas de LabVIEW depuis la version 5.0. C’est
ainsi qu’il est possible d’intégrer dans une face avant d’application
graphique, un navigateur Web, un document Word, une feuille
Excel, un calendrier, un document HiQ (visualisation 3D), ou
n’importe quel contrôles ActiveX. Le développeur peut modifier ces
objets directement à partir de la face avant de son application ou
contrôler leurs comportements et leurs propriétés par programmation graphique. Cette capacité à réutiliser des composants développés dans d’autres langages facilite grandement l’intégration de
LabVIEW avec d’autres outils logiciels au sein d’une organisation
complexe (figure 43).
2.3.6 Contrôle d’une application par une autre
Aujourd’hui, la plupart des entreprises mettent en place des standards pour valider des environnements de programmation au sein
de leur organisation. Le but est de diminuer le nombre d’outils de
développement validés, afin de créer une base d’utilisateurs
experts, de partager du code dans une unité, de diminuer le coût de
formation, de mises à jour et de support et de s’assurer que tout le
code écrit répond à des standards de qualité. Les outils de développement choisis doivent être très ouverts, afin qu’ils puissent intégrer du code provenant d’autres langages et qu’ils puissent aussi
générer du code utilisable dans d’autres applications. Cela assure
une grande flexibilité et une grande efficacité au cours du processus
de développement, si bien que les utilisateurs peuvent tirer parti des
outils les mieux adaptés à une tâche donnée.
S 8 205 − 22
Programme en langage G
Figure 43 – Intégration dans une application LabVIEW de divers
éléments compatibles Active X comme un navigateur Web,
une feuille de tableur, etc.
Ainsi, Visual Basic est souvent utilisé pour développer les frontaux d’applications de bases de données. LabVIEW est quant à lui
souvent utilisé comme outil logiciel pour développer des systèmes
de test de production et d’acquisition de données. Les utilisateurs
souhaitent pouvoir intégrer ensemble ces deux systèmes, ou simplement appeler des applications LabVIEW à partir de Visual Basic.
Aussi LabVIEW intègre un serveur Automation qui permet aux utilisateurs d’appeler des programmes LabVIEW en dehors de l’environnement LabVIEW lui-même. En d’autres termes, l’utilisateur peut
appeler un VI LabVIEW à partir de n’importe quel client Automation,
donc par exemple à partir d’un programme écrit en C ou en Visual
Basic, d’une macro Excel ou alors d’une autre copie de LabVIEW. Il
est aussi facile pour l’utilisateur d’appeler une DLL à partir d’un programme que d’appeler un VI LabVIEW à partir d’une autre application. De plus, l’utilisateur peut piloter l’environnement de
développement LabVIEW dans son ensemble, à partir d’une autre
application.
2.3.7 Contrôle d’applications à distance
Il existe divers moyens de contrôler une application à distance.
Depuis l’avènement d’Internet, le réseau mondial s’est imposé
comme le moyen de contrôle à distance le plus économique, le plus
Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite.
© Techniques de l’Ingénieur, traité Informatique industrielle
__________________________________________________________________
simple et le plus souple. L’environnement de développement LabVIEW contient en standard des fonctionnalités de publication de
documents et d’images de faces avant d’applications sur un serveur
HTTP (Web). Cela permet de visualiser la face avant d’une application à partir de n’importe quel point du globe. Pour aller plus loin
dans le contrôle à distance, l’utilisateur doit faire appel à une bibliothèque spécialisée.
Cette bibliothèque contient des outils Internet complets, comprenant notamment un serveur HTTP (Web) qui ajoute le principe de
niveaux de sécurité au serveur déjà intégré dans LabVIEW. Ce serveur peut aussi servir à répondre à des clients connectés à l’application tout en mettant régulièrement à jour la face avant accessible
par Internet. Mais surtout, le développeur dispose de VI permettant
de construire des programmes CGI (Common Gateway Interface) en
langage G, ce qui permet à l’utilisateur distant d’agir directement
sur la page Web sur laquelle apparaît la face avant de l’application.
La bibliothèque contient également des fonctions pour l’accès
e-mail, FTP (File Transfer Protocol) et Telnet. En utilisant ces fonctions, côté client, l’utilisateur peut envoyer un message électronique
lorsque des conditions d’alarme surviennent, envoyer des fichiers
ou des données à un serveur FTP, ou encore exécuter des programmes sur des serveurs UNIX délocalisés. Ce sont là des possibilités
intéressantes dans le cadre d’applications de contrôle-commande
distribuées, dans lesquelles il faut par exemple transmettre des données à un réservoir central ou maintenir des opérateurs informés de
l’état du système.
Il convient aussi de noter que LabVIEW inclut une interface serveur TCP/IP, qui permet aux applications clientes LabVIEW de
contrôler facilement d’autres applications LabVIEW directement au
travers d’un réseau local (figure 44).
Pour certaines applications, il est nécessaire que l’exécution
s’effectue sur plusieurs machines. Si l’utilisateur doit exécuter rapidement des routines de calculs intensifs, il peut par exemple souhaiter répartir les tâches sur plusieurs ordinateurs. Ou si une
acquisition déportée impose de collecter des données provenant de
différents sites, un système distribué peut constituer la meilleure
approche. En général, les systèmes distribués nécessitent des programmes complexes à écrire, parce qu’ils réclament un surplus de
code pour transférer les données d’un ordinateur à l’autre ou pour
exécuter des appels sur des machines distantes. Mais avec LabVIEW, les utilisateurs peuvent construire assez facilement ce type de
systèmes.
Imaginons qu’un utilisateur ait développé plusieurs routines
d’acquisition et veuille appeler chacune d’entre elles à n’importe
quel moment à partir de n’importe quel site. La plupart des environ-
TCP
TCP
TCP
Figure 44 – Interface serveur TCP/IP : possibilité
pour une application LabVIEW de contrôler une autre
application LabVIEW à travers un réseau local
TCP
PROGRAMMATION GRAPHIQUE DES APPLICATIONS DE CONTRÔLE-COMMANDE
nements de programmation nécessite l’utilisation de fonctions de
réseau pour envoyer les commandes et les données vers les autres
ordinateurs ; ces ordinateurs distants doivent être en permanence à
l’écoute d’une connexion. En outre, pour envoyer et recevoir les
données à travers le réseau, l’utilisateur doit réaliser des opérations
de conversion souvent fastidieuses. Avec LabVIEW, les utilisateurs
créent simplement leurs programmes d’instrumentation, les chargent sur les machines où ils doivent respectivement s’exécuter, puis
écrivent ensuite un programme simple pour les appeler à partir d’un
poste spécifique. Quand les utilisateurs exécutent ce programme
« maître », celui-ci lance simplement les fonctions localisées sur les
machines cibles. Si on utilise l’interface ActiveX, le serveur peut lancer automatiquement LabVIEW s’il n’est pas déjà ouvert, afin que
LabVIEW ne soit pas nécessairement ouvert en permanence sur
l’ordinateur cible. En outre, l’utilisateur peut choisir d’afficher le programme sur la machine cible ou seulement de le faire tourner en
tâche de fond.
2.3.8 En résumé
Nous pouvons résumer schématiquement toutes les liaisons possibles de l’environnement LabVIEW dans une application de
contrôle-commande de procédé par la figure 45.
3. Langage graphique G :
développements spécifiques et exemples industriels
3.1 BridgeVIEW : un environnement
de développement orienté supervision
Conçu au départ pour les applications de test et de mesure, et
exclusivement utilisé dans ce cadre pendant de nombreuses
années, LabVIEW a peu à peu été utilisé dans des applications
industrielles d’automatisation, tout en montrant certaines limites
essentiellement dues à son orientation « laboratoire » initiale. C’est
ainsi qu’est apparu en 1996 un deuxième logiciel basé sur le langage G, mais architecturé différemment : BridgeVIEW. L’environnement de développement est sensiblement le même, avec un
diagramme, une face avant, des bibliothèques de fonctions graphiques et des outils de mise au point. Mais BridgeVIEW a été développé pour répondre aux besoins spécifiques de l’automatisation
industrielle, laquelle est particulièrement exigeante en matière de
gestion d’alarmes, d’événements, d’enregistrement des données,
de suivi de tendances, etc. C’est pourquoi BridgeVIEW s’appuie sur
un moteur autonome, chargé de gérer une base de données temps
réel (appelée Citadel), extérieure à l’environnement de programmation proprement dit. Ainsi le moteur de BridgeVIEW met à jour les
valeurs d’E/S ainsi que les informations d’état en provenance de serveurs de périphériques (automates programmables, systèmes
d’acquisition de données, entrées/sorties déportées, réseaux de terrain...). Il remplit aussi d’autres fonctions, comme :
— la conversion de données en unités physiques ;
— la mise à l’échelle ;
— le contrôle et l’enregistrement d’événements (alarmes) ;
— le suivi des tendances et d’historique ;
— la sécurité du système.
■ Base de données historiques temps réel
Également utilisée dans un superviseur appelé Lookout™ (National Instruments), la base de données Citadel est architecturée de
manière à optimiser l’enregistrement des données. Ces données
sont compressées dans la base pour limiter l’espace sur le disque
dur. Par ailleurs, la base Citadel garantit une complète intégrité des
Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite.
© Techniques de l’Ingénieur, traité Informatique industrielle
S 8 205 − 23
PROGRAMMATION GRAPHIQUE DES APPLICATIONS DE CONTRÔLE-COMMANDE __________________________________________________________________
Réseau
IH
M
/S
up
er
vis
io
FieldPoint
n
Réseau
Ordinateur
Carte d'acquisition
de données
Ac
Conditionnement
de signaux
qu
isi
Série
tio
API
n
de
do
nn
Logiciel
ée
s
Bus de terrain
Compact PCI/PXI
Commande
Procédé
Contrôle
Acquisition
d'images
Contrôle
d'axes
Figure 45 – Exemples de liaisons à un procédé de l’environnement de développement LabVIEW
données au travers d’une vérification des erreurs CRC 32 bits (CRC
pour contrôle de redondance cyclique). Les données de la base Citadel sont accessibles de différentes façons :
— au travers d’un système d’affichage intégré à BridgeVIEW pour
parcourir les fichiers de données historiques ;
— à partir de n’importe quelle application supportant les standards de communications OLE et DDE ;
— à partir d’autres bases de données compatibles ODBC (Open
Data Base Connectivity) via le langage SQL (Structured Query
Language) ;
— à partir de n’importe quelle application développée dans
l’environnement de programmation graphique.
■ Exploitation du langage graphique
L’intérêt de BridgeVIEW réside particulièrement dans le fait qu’il
puisse être accessible à partir de n’importe quelle application développée dans l’environnement de programmation graphique. Les utilisateurs peuvent développer, en langage graphique, une application IHM classique qui va sélectionner les données de la base Citadel et les traduire à l’opérateur sous la forme d’un affichage graphique. Mais il est en fait surtout possible de construire des
applications de contrôle-commande complètes, intégrant l’acquisition, l’analyse, la visualisation et la génération de données. Étant
donné sa finalité industrielle, la bibliothèque d’objets graphiques de
BridgeVIEW contient des vannes, pompes, tuyaux... et toutes sortes
d’éléments permettant de créer des IHM réalistes quant au processus à contrôler (figure 46). Les développeurs peuvent naturellement
aussi importer des graphiques personnalisés.
S 8 205 − 24
Figure 46 – Bibliothèques d’objets typiquement industriels
de BridgeVIEW
Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite.
© Techniques de l’Ingénieur, traité Informatique industrielle
__________________________________________________________________
PROGRAMMATION GRAPHIQUE DES APPLICATIONS DE CONTRÔLE-COMMANDE
■ Programmation, mais aussi paramétrage
La solution BridgeVIEW pour automatiser le contrôle d’un processus industriel se démarque nettement des approches devenues
classiques de la supervision. En effet, la plupart des superviseurs
sont d’abord des logiciels plus ou moins prêts à l’emploi. C’est pourquoi ces logiciels offrent généralement des outils de programmation, ou plus exactement la possibilité d’écrire des scripts. Ce qui
permet aux intégrateurs de personnaliser leurs systèmes, de générer des rapports ou d’animer des images. Ces langages de
« scripting » sont généralement propriétaires et restent limités lorsque la solution est complexe. Les utilisateurs ont donc souvent tendance à écrire eux-mêmes leurs propres programmes en Visual
Basic ou en C/C++ pour obtenir les fonctionnalités recherchées.
Par essence, BridgeVIEW se distingue donc de l’offre habituelle
en matière de logiciels de supervision, puisqu’il s’agit principalement d’un environnement de programmation. De plus BridgeVIEW
offre une approche « configurative » à l’utilisateur pour construire
son système de supervision. Un grand nombre d’objets système
sont créés et conservés à partir d’outils de configuration et de remplissage interactifs. Un éditeur de configuration crée des objets
appelés étiquettes qui représentent les valeurs d’entrées/sorties
obtenues des périphériques externes et stockées dans la base de
données en temps réel. Cet éditeur d’étiquettes permet également à
l’utilisateur de configurer les paramètres propres aux étiquettes
ainsi que les fonctions système comme le nom, la description, la
connexion des entrées/sorties de périphériques, les unités techniques et la mise à l’échelle, l’enregistrement historique et le déclenchement de l’alarme. Les informations sur la configuration des
étiquettes peuvent s’importer depuis des fichiers de configuration
de périphériques déjà existants comme les automates programmables, et ainsi optimiser la productivité. Finalement, le langage G
peut être transparent si l’utilisateur n’a pas besoin de ses services
pour étendre les capacités de son application.
3.2 GrafcetVIEW : un langage orienté
modèle
Comme nous l’avons vu dans le paragraphe 1 de cet article, le
GRAFCET est un modèle utilisé dans le domaine des applications de
contrôle-commande pour faciliter la compréhension de l’automatisme à réaliser, sa conception et sa mise en œuvre technologique.
3.2.1 Définition du GRAFCET
Le GRAFCET permet de construire des modèles ayant une représentation graphique, appelé grafcet, à laquelle on associe des règles
d’évolution pour appréhender l’aspect dynamique de l’application.
Un grafcet est un graphe cyclique biparti alterné, composé de transitions et d’étapes reliées entre elles par des liaisons orientées. Les
arcs sont de simples traits verticaux lorsque les liaisons sont orientées de haut en bas ou sont munis d’une flèche vers le haut si elles
sont orientées de bas en haut.
Les étapes sont représentées par un carré, identifié par un nombre. L’étape possède deux états : active, représentée par un jeton, ou
inactive. On associe généralement à une étape : une variable booléenne Xi (=1 si l’étape est active et 0 si l’étape est inactive) et une
action de commande vers le procédé (figure 47). L’étape symbolise
un état ou une partie de l’état du système. Les transitions sont représentées par un trait horizontal. On associe généralement à une transition une condition de franchissement ou réceptivité (figure 48).
Cette condition provient du procédé sous la forme du front montant
d’une entrée (↑m), du front descendant d’une entrée (↓m) et/ou de
l’état du système, décrit par les étapes du modèle (si la réceptivité
n’est pas précisée, la condition de transition est vraie). La transition
permet de décrire l’évolution possible de l’état actif d’une étape à
une autre.
Les règles d’évolution sont :
— une transition est validée si toutes les étapes en amont sont
actives ;
2
2
2
Action A
Action A
Étape inactive
(l'action A
ne s'exécute pas
et X2 = 0)
Étape d'attente
ou initiale
(pas d'action A
associée)
Étape active
(l'action A
s'exécute
et X2 = 1)
Figure 47 – Représentation graphique du nœud « Etape »
dans le modèle GRAFCET
2
3
2
3
r
r1
r2
r1
r2
r
2
3
2
Divergence
« en et »
Convergence
« en et »
Divergence
« en ou »
3
Convergence
« en ou »
Figure 48 – Représentation graphique du nœud « Transition »
dans le modèle GRAFCET
— une transition est dite franchissable si elle est validée et si sa
réceptivité est vraie ;
— toutes les transitions susceptibles d’être franchies à un instant
donné (transitions franchissables) sont franchies simultanément ;
— après le franchissement, les étapes suivantes sont activées et
les étapes précédentes désactivées (dans le cas d’une activation et
désactivation d’une étape, celle-ci reste active).
Exemple : la figure 49 montre un grafcet simple et son évolution
selon les règles précédentes. Il est possible d’utiliser des temporisations aussi bien dans l’expression des actions, associées aux étapes
que dans les expressions des réceptivités associées aux transitions.
1
1
R1
2
1
R1
3
Action
A
2
R1
3
R2
Action
A
2
3
R2
Action
A
R2
4
4
4
R3
R3
R3
Réceptivité R1 vraie
Réceptivité R2 vraie
Réceptivité R3 vraie
Figure 49 – Exemple d’un modèle grafcet et de son évolution
Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite.
© Techniques de l’Ingénieur, traité Informatique industrielle
S 8 205 − 25
PROGRAMMATION GRAPHIQUE DES APPLICATIONS DE CONTRÔLE-COMMANDE __________________________________________________________________
Lors du passage à l’implémentation d’un grafcet, deux algorithmes d’évolution sont employés pour appliquer les règles d’évolution. Ces algorithmes diffèrent par la notion de stabilité de la
situation atteinte. L’algorithme, dit sans recherche de stabilité ou
SRS, peut aboutir à un comportement non déterministe et donc à
une mauvaise interprétation d’un grafcet. En effet, cet algorithme
permet l’évaluation des entrées lors d’une évolution d’un grafcet.
Ainsi, si le calculateur est relativement lent par rapport au procédé
physique, un changement (ou plusieurs) de valeur du vecteur des
entrées peut avoir lieu lors du calcul d’une évolution d’un grafcet
(passage d’un état stable à un autre état stable) et est pris en compte
lors du calcul en cours. Le second algorithme, appelé algorithme
avec recherche de stabilité ou ARS, assure à un grafcet un comportement déterministe, car il ne considère une nouvelle valeur du vecteur des entrées que si une situation stable est atteinte. C’est cette
dernière méthode qui est utilisée dans le logiciel GrafcetVIEW.
Usinage
Marche/arrêt
USINAGE
STOP
3.2.2 GrafcetVIEW
L’automaticien travaille déjà avec des langages de programmation graphique (cf. § 1.3). L’objectif de GrafcetVIEW est donc d’intégrer un de ces langages dans le formalisme flot de données de
LabVIEW, afin de donner à l’automaticien la possibilité de développer ses applications sur micro-ordinateur dans un formalisme qu’il
maîtrise et dans un environnement où la mise en œuvre matérielle
est grandement facilitée [17]. Cependant, le passage d’un formalisme GRAFCET vers un formalisme flot de données acyclique n’est
pas immédiat. Les deux principaux problèmes à résoudre ont été :
— le portage du modèle GRAFCET en tant que graphe cyclique
dans l’environnement LabVIEW, c’est-à-dire en utilisant un langage
basé sur les diagrammes flot de données acycliques ;
— la conception et le développement d’une architecture pour le
moteur d’exécution, permettant la prise en compte du caractère
synchrone (réaction à temps nul) du GRAFCET.
Assemblage
Marche/arrêt
ASSEMBLAGE
AUTOMATIQUE
MANUEL
PRISE
Figure 50 – Représentation schématique de l’application test pilotée
par GrafcetVIEW
série, ou encore d’un réseau... c’est l’interface procédé). Dans le cas
d’une carte d’acquisition, il faut souvent convertir une valeur numérique ou alphanumérique en valeur booléenne. Ainsi pour l’application test, nous avons les deux tableaux qui définissent les entrées/
sorties (tableaux 2 et 3).
(0)
Tableau 2 – Entrées de l’application test
réalisée avec GrafcetVIEW
■ Principes de GrafcetVIEW
L’utilisation de GrafcetVIEW requiert une connaissance préalable
du logiciel LabVIEW. La création d’une application de contrôle de
procédés à l’aide de la bibliothèque GrafcetVIEW se décompose en
trois phases :
— la définition des entrées/sorties de la partie commande du système piloté. Ces entrées/sorties peuvent être de deux types :
• logicielles, par le biais de l’interface graphique (vers ou de
l’opérateur,
• matérielles, par le biais de moyens physiques (vers ou du procédé) tel que carte d’entrées/sorties numériques, liaison série,
parallèle, réseau, etc,
— l’édition du grafcet spécifiant le comportement de la partie
commande ;
— l’intégration des deux précédentes phases dans un moteur
d’exécution qui permettra le fonctionnement de l’application.
L’utilisation de GrafcetVIEW va être illustré par la réalisation
d’une application test. L’application choisie est un atelier composé d’une partie fabrication et d’une partie assemblage. La
partie fabrication reçoit des pièces brutes qu’elle usine. Ces pièces sont ensuite déposées en un lieu de stockage. Puis, soit sur
ordre d’un opérateur, soit de manière automatique (lorsque la
pièce est détectée), un bras manipulateur récupère la pièce pour
la soumettre à une machine de montage où un assemblage est
réalisé. La pièce finie est ensuite évacuée. La figure 50 présente
une vue schématique de cette application.
Provenance
Désignation
Nom
de référence
Opérateur
Marche/Arrêt Usinage
E0
x
Marche/Arrêt Assemblage
E1
x
Manuel/Automatique
E2
x
Prise
E3
x
Carte
Pièce usinée
E4
x
Pièce déposée
E5
x
Pièce prise
E6
x
Fin Assemblage
E7
x
Tableau 3 – Sorties de l’application test
réalisée avec GrafcetVIEW
Provenance
Désignation
Nom
de référence
Opérateur
Carte
Usinage
S0
x
x
Attente 1
S1
x
Attente 2
S2
x
■ Définition des entrées/sorties
Dépose
S3
x
Une entrée doit être une variable booléenne, elle peut provenir de
deux sources : l’interface opérateur (la face avant d’un VI) ou bien de
l’extérieur (par exemple d’une carte d’acquisition, d’une liaison
Prise
S4
x
x
Assemblage
S5
x
x
S 8 205 − 26
Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite.
© Techniques de l’Ingénieur, traité Informatique industrielle
x
__________________________________________________________________
■ Édition du grafcet
Les différents objets nécessaires à la construction d’un grafcet
sont disponibles dans le diagramme sous la forme de VI fournis
avec la bibliothèque GrafcetVIEW, accessibles à partir du menu
« Functions ». Nous avons ainsi : étape, étape initiale, transition...
(figure 51).
Il est donc possible de construire complètement le grafcet de
l’application (figure 52). Les étapes 10, 11, 12, 1, 13 correspondent à
la partie usinage ou fabrication et les étapes 20, 21, 2, 22, 23 à la partie assemblage. Les deux étapes initiales 10 et 20 sont respectivement les attentes d’usinage et d’assemblage. Les étapes 1 et 2 sont
des étapes de synchronisations entre les deux processus d’usinage
et d’assemblage : il n’est pas possible de réaliser la « prise » de la
pièce par la partie assemblage si la pièce n’a pas été « déposée » par
la partie usinage. Les temps de réalisation des actions ont été simulés par des temps d’attente dans les réceptivités. Ainsi l’usinage
(étape 11) dure 2 000 ms, la dépose (étape 13) 1 500 ms, la prise
(étape 22) 1 800 ms et enfin l’assemblage (étape 23) 2 000 ms.
Les actions et les réceptivités sont décrites à l’aide d’une syntaxe
précise qui permet d’exprimer des actions conditionnelles, des temporisations ou des fonctions logiques sur les entrées. GrafcetVIEW
tire profit des propriétés de l’éditeur graphique de LabVIEW, ainsi
grâce au typage des arcs entre entités, la correction de la syntaxe
graphique d’un grafcet est immédiate : si un arc est en pointillé alors
PROGRAMMATION GRAPHIQUE DES APPLICATIONS DE CONTRÔLE-COMMANDE
une des règles de construction du GRAFCET n’est pas respectée :
non respect de l’alternance étape-transition, plusieurs étapes sont
reliées directement à une même transition, etc. La syntaxe graphique du grafcet étant correcte, il est aussi possible de vérifier que
plusieurs étapes n’ont pas le même numéro, qu’il n’y a pas de transitions non reliées à une étape, que les actions conditionnelles et les
réceptivités sont correctes.
■ Réalisation de l’application
Lorsque les entrées/sorties de notre partie commande ont été
définies et que le grafcet spécifiant son comportement a été édité, il
reste alors à intégrer ses différents éléments dans le VI final qui fait
vivre l’application. Le principe de fonctionnement de l’application
est basé sur l’exécution en parallèle de deux tâches (figure 53). Une
première tâche se charge de la lecture des entrées et une seconde
de l’élaboration des sorties. L’application est divisée en deux tâches
permettant de garantir un délai maximal entre deux lectures des
entrées afin de ne pas rater d’événement. Ainsi, si l’élaboration des
sorties est plus longue que ce temps maximal alors la tâche de lecture effectue une acquisition des entrées (ce qui aurait été impossible sans ce découplage de l’acquisition et du calcul). Il convient
donc ensuite de câbler les entrées/sorties à ces deux tâches pour
constituer l’application complète (figure 54).
3.3 Langage G pour la vision industrielle
Figure 51 – Différents objets fournis par GrafcetVIEW pour
construire un grafcet : élément « Etape » sélectionné
Il existe de plus en plus d’applications de contrôle-commande qui
font appel à un système de vision industrielle. Aussi pour ce
domaine très spécifique, il existe un logiciel permettant de réaliser
des applications en langage G : IMAQ Vision (National Instruments). Il en existe également un second, appelé IMAQ Vision Builder, plutôt destiné aux novices de la vision et de la programmation
graphique et qui vient en complément d’IMAQ Vision pour accélérer
le prototypage d’une application.
■ Prototypage rapide en vision industrielle : IMAQ Vision Builder
10
Construire une application de vision implique en général de longues heures de travail et de tâtonnements. Ce logiciel IMAQ Vision
Builder a pour but de réduire ces temps de conception. Il permet de
tester plusieurs stratégies et de tester chacune sur divers types
d’images, sans entrer immédiatement dans la programmation gra-
20
E0
E1
11
S0
2
21
S2
Time out
Entrées
Stop
i
t0
2000/X11 /0
E2 or E3
12
S1
1
Tâche de lecture des entrées
22
S4
(l'entrée, appelée t0, correspond à une entrée
de synchronisation après initialisation du grafcet)
1800/X22 /0
13
entrées
S3
Marquage avant
1500/X13 /0
23
t
Sorties
S5
i
marquage après
STOP ?
2000/X23 /0
Tâche d'élaboration des sorties
Figure 52 – Grafcet de l’application test développée
avec GrafcetVIEW
Figure 53 – Tâches de base d’une application développée
avec GrafcetVIEW
Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite.
© Techniques de l’Ingénieur, traité Informatique industrielle
S 8 205 − 27
PROGRAMMATION GRAPHIQUE DES APPLICATIONS DE CONTRÔLE-COMMANDE __________________________________________________________________
0
0
i
4
S
E
t
t
100
Figure 54 – Diagramme flot de données final de l’application test développée avec GrafcetVIEW
phique. L’utilisateur fait face à un logiciel « prêt à l’emploi » interactif, qui lui montre les résultats des changements de paramètres
effectués sur telle ou telle image. Il lui permet aussi de tester une
fonction ou une série de fonctions de traitement. Au terme d’une
session de développement interactif, un script est généré, qui peut
être exécuté autant de fois et sur autant d’images que nécessaire.
L’utilisateur dispose aussi d’un fichier dans lequel sont enregistrés
la description des fonctions testées et les paramètres de chaque
appel de fonction. C’est ce fichier qui va être utile dans l’étape d’utilisation de la programmation graphique, avec IMAQ Vision
(figure 55).
■ Programmation en vision industrielle : IMAQ Vision
IMAQ Vision est essentiellement un ensemble complet de bibliothèques de fonctions d’acquisition et de traitement d’images, fonctions écrites en langage graphique, donc facilement intégrables au
sein d’une application plus large. Parmi les fonctions disponibles,
on trouve toutes celles qui concernent l’affichage (niveaux de gris,
couleur et binaire), le traitement des images (statistiques, filtrage
et transformations géométriques), la comparaison à des modèles,
la comparaison à des formes, le comptage et la mesure dimensionnelle, surfacique, angulaire... Il existe donc des fonctions de très
haut niveau, qui demandent de fixer de nombreux paramètres. C’est
tout l’intérêt que d’avoir réaliser un prototypage rapide avec IMAQ
Vision Builder
■ Reconnaissance de caractères
À noter aussi l’existence d’une bibliothèque de fonctions qui peut
compléter avantageusement IMAQ Vision pour les applications de
reconnaissance de caractères, utilisé notamment au niveau du
conditionnement de produits électroniques, pharmaceutiques, etc.
Bien qu’il s’agissent d’une bibliothèque de VI intégrables donc dans
un environnement graphique, cet « outil » est pratiquement un logiciel prêt à l’emploi.
3.4 Exemples industriels
3.4.1 Application développée en laboratoire
Dans le cadre du Laboratoire de Combustion et de Détonique de
l’ENSMA (unité propre de recherche du CNRS), l’équipe de recherche « combustion « effectue des études expérimentales sur les
écoulements turbulents subsoniques. Les conditions de fonctionnement de foyers de turboréacteur sont reconstituées en laboratoire
afin d’analyser la physique et la chimie de ces moteurs aéronautiques (figure 56).
Dans ces chambres expérimentales de combustion, la mesure
réalisée est très fortement dépendante du point analysé. En effet, les
écoulements étudiés présentent de nombreuses régions différentes : zones de réaction chimiques, zones proches des parois, turbulence, etc. Aussi les expériences doivent être conduites en explo-
Foyer
de turbo-réacteur
Injection mélange
air-carburant
Systèmes
de conditionnement
et de mesures
Gaz brûlés
Sonde
de mesure
Laser
Système
de déplacement 3 axes
LCD Liquid Crystal Display
Figure 55 – Exemple d’application d’IMAQ Vision
S 8 205 − 28
Figure 56 – Représentation schématique du montage expérimental
pour le pilotage des mesures autour d’une chambre à combustion
d’un moteur d’avion
Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite.
© Techniques de l’Ingénieur, traité Informatique industrielle
__________________________________________________________________
rant un ensemble de points de mesures caractérisé par un maillage
tridimensionnel défini préalablement par l’expérimentateur. Le
déplacement du point de mesure est réalisé grâce à un système de
déplacement trois axes (société Charlyrobot) piloté par l’intermédiaire d’une liaison série. Ce système permet une précision de
déplacement inférieure à la dizaine de micromètres sur les trois
axes. La commande de déplacement s’effectue en envoyant les
coordonnées (x, y, z) du point de mesure calculées par rapport à une
position initiale de référence.
En chacun de ces points du maillage d’exploration de la chambre
expérimentale, trois types de mesures simultanées peuvent être mis
en œuvre :
— la mesure de température : cette mesure est réalisée à l’aide de
thermocouples fins et compensés dynamiquement ;
— la mesure de CO2 : le prélèvement des gaz est effectué dans de
petits réservoirs qui sont analysés a posteriori par chromatographie
en phase gazeuse ;
— la mesure de la vitesse d’écoulement : cette détermination de
la vitesse locale d’écoulement est effectuée grâce à la mesure de
vitesse de très fines particules injectées dans l’écoulement. La
lumière émise par ces particules, éclairées par un faisceau laser, est
analysée à l’aide d’une chaîne d’acquisition constituée principalement d’analyseurs de spectre (BSA, Burt Spectrum Analyser, de la
société Dantec). Le principe de la mesure est basé sur le décalage
fréquentiel, effet Doppler, qui permet d’obtenir directement la
vitesse de l’écoulement au point de mesure. La configuration de ces
appareils de mesures est assez complexe : fréquence d’acquisition,
nombre de mesures, calibrage, gestion des mémoires tampon, etc.
Le contrôle-commande de ces analyseurs de spectre est réalisé par
l’intermédiaire d’une liaison GPIB.
Ainsi d’un point de vue contrôle-commande, les différentes
liaisons vers les éléments externes de mesures sont les suivantes :
— liaison série : pilotage du système de déplacement (société
Charlyrobot) ;
— liaison GPIB : pilotage des analyseurs de spectre (société
Dantec) ;
— carte d’entrées analogiques : mesures de température.
Le programme complet de pilotage des mesures a été réalisé en
langage G dans l’environnement LabVIEW. Ce programme
devait répondre à de nombreuse fonctionnalités permettant à l’opérateur de conduire aisément l’expérimentation sans avoir une
connaissance approfondie de la programmation. Les principales
qualités requises spécifiques à cette application étaient :
— la gestion des différentes phases de l’expérimentation : initialisation (réglage des points de référence, configuration des analyseurs de spectre...), conduite de l’essai, arrêt de l’expérience ;
— la possibilité de définir un maillage d’exploration de la chambre de combustion de deux moyens différents : définition analytique
(maillage régulier par zones) ou fichier provenant d’un calcul effectué sur un autre calculateur (maillage quelconque) ;
— la possibilité d’intervention de l’opérateur en cours d’expérience pour modifier la configuration des mesures (configuration
des analyseurs de spectre, modification du maillage, etc.) et cela
sans perte des mesures ou arrêt de l’essai en cours.
Le programme, appelé MERCI (Mesures en Écoulements Réactifs
avec Contrôle Interactif), a été développé en définissant dans une
première phase l’ensemble des différentes interfaces utilisateurs
qui constituent l’environnement de l’expérimentation. Ainsi au
départ, l’expérimentateur se trouve en présence de la fenêtre de
présentation avec le choix de la mesure à réaliser. Ensuite, la
figure 57 présente les différentes fenêtres disponibles lors de la
définition et de la réalisation des mesures de vitesses. Les interfaces
ont été conçues de façon très explicite (textes) pour permettre une
plus grande rapidité de prise en main du logiciel de pilotage par de
nombreux utilisateurs. Il est très important de noter que le programme a été réalisé de façon à minimiser les erreurs de manipulations ; par exemple un enchaînement de certaines actions (initialisation des différents éléments externes) a été rendu obligatoire
avant le lancement des mesures.
PROGRAMMATION GRAPHIQUE DES APPLICATIONS DE CONTRÔLE-COMMANDE
Mesures de vitesse
Initialisation
du système
de déplacement
Initialisation
des analyseurs
de spectre (BSA)
Initialisation
des fichiers
de mesures
Réalisation
des
mesures
Traitement
des
mesures
Initialisation
du maillage
de mesures
Figure 57 – Face avant du programme de pilotage des mesures :
cas des mesures de vitesses
En conclusion, l’utilisation du langage G dans l’environnement
LabVIEW a permis une conception rapide d’une application très
complexe au niveau des liaisons vers des éléments externes (liaison
série, liaison GPIB, entrées analogiques, gestion de fichiers, etc.).
Les interfaces très interactives permettent à l’expérimentateur
d’intervenir à tout moment sur l’essai. Enfin, le développement a été
conçu pour pouvoir facilement enrichir le logiciel initial par l’adjonction de fonctionnalités supplémentaires.
3.4.2 Deux applications développées
en production
3.4.2.1 Pour la distribution de gaz naturel
Les environnements basés sur la programmation graphique,
comme LabVIEW et BridgeVIEW, sont souvent utilisés pour développer des systèmes de supervision (SCADA, Supervisory Control
and Data Acquisition) prêts à l’emploi, conçus pour tel ou tel
domaine précis. La société suisse Soft-Concept a choisi cette voie
afin de créer, avec BridgeVIEW, un système de contrôle-commande
d’installation de pipelines de gaz pour le compte de Gaznat, entreprise suisse de distribution de gaz naturel. Gaznat avait besoin d’un
système permettant de contrôler à partir d’un poste central la distribution du gaz sur une cinquantaine de sites répartis sur un périmètre de 120 km (figure 58).
L’application consiste en un système de télétransmission qui
connecte des automates présents sur chaque site local, au site central. Un opérateur contrôle l’ensemble du réseau à partir du site central via une interface de supervision. Dans un premier temps, Gaznat
souhaitait que les dix principaux sites locaux soient équipés d’une
application SCADA offrant exactement les même fonctionnalités
que l’application centrale (figure 59). Les spécifications étaient les
suivantes :
— des interfaces utilisateurs locales identiques à celle du site
central ;
— une application travaillant en parallèle avec le système de
contrôle à distance ;
— un niveau de sécurité garanti ;
— la possibilité de maintenir rapidement et facilement le système
et d’étendre les fonctionnalités de l’application.
Chacun des dix sites est équipé d’un PC, doté d’un écran tactile et
connecté à un automate programmable (SAT-Système). Chaque
système utilise un protocole Modbus avec environ 320 points d’E/S,
principalement des entrées analogiques et numériques. Il effectue
l’enregistrement des données de façon régulière avec un délai maxi-
Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite.
© Techniques de l’Ingénieur, traité Informatique industrielle
S 8 205 − 29
PROGRAMMATION GRAPHIQUE DES APPLICATIONS DE CONTRÔLE-COMMANDE __________________________________________________________________
3.4.2.2 Pour le traitement des eaux usées
Confronté au besoin d’automatiser ses opérations de traitement
de déchets chromés, McDonnel Douglas a fait appel à une société
de service (PARSEC Engineering) pour concevoir et réaliser un système de contrôle-commande basé sur LabVIEW. Sur le site de Huntington Beach (Californie), McDonnel Douglas produit des éléments
métalliques destinés aux véhicules spatiaux de la NASA. Comme
pour tous les véhicules spatiaux, le chrome est utilisé de manière
intensive. La fabrication des éléments constitutifs produit donc une
grande quantité de déchets chromés qui nécessitent un processus
de traitement des eaux usées particulièrement soigné. En l’occurrence, ce traitement fait appel aux étapes suivantes :
— collection et transfert des eaux usées ;
— ajustement du pH ;
— réduction du chrome ;
— précipitation du chrome ;
— flocage et dépôt ;
— filtrage, pressage et extraction de l’eau.
Figure 58 – Installation de distribution de gaz naturel supervisée
avec BridgeVIEW
Figure 59 – Exemple d’interface utilisateur de l’application
de supervision de Gaznat
mal d’une heure entre deux enregistrements. La base de données
historique de BridgeVIEW est exploitée pour conserver les données
pendant un an. Avec l’enregistrement des données, le responsable
peut observer la tendance historique et identifier un éventuel défaut
au niveau de chaque capteur.
L’accès aux pièces où se trouvent les installations est strictement
réglementé afin d’éviter la modification malencontreuse des paramètres. Les principaux risques critiques concernent d’éventuelles
erreurs de la part des opérateurs. C’est pourquoi trois niveaux
d’accès ont été définis :
— administration : l’opérateur peut modifier et ajouter de nouvelles caractéristiques à l’application ;
— contrôle : l’opérateur peut visualiser et contrôler le procédé ;
— visualisation : l’opérateur peut visualiser le procédé mais sans
possibilité d’intervention sur la face avant.
Le recours à la programmation graphique, et en particulier à BridgeVIEW, a permis de développer cette application en quelques
semaines, y compris l’apprentissage du langage G, le développement des VI, la configuration des serveurs Modbus et des automates et l’installation de l’application. Les fonctions de sécurité
intégrées dans l’environnement de développement BridgeVIEW ont
notamment permis de définir très rapidement les éléments de la
face avant qui nécessitaient d’être inactivés en fonction de chacun
des trois niveaux d’accès sécuritaires.
S 8 205 − 30
Le système utilise une série de réservoirs de traitement, chacun
destiné à une fonction spécifique. Avant l’utilisation de LabVIEW,
l’unité de traitement était contrôlée manuellement ou presque.
Contrairement aux directives du Département de l’Environnement
Californien, il n’y avait pas de système d’enregistrement des données. Comme McDonnel Douglas est essentiellement équipé de
Macintosh, l’entreprise voulait un système basé sur cette plateforme. Il devait être facile à intégrer dans le réseau industriel existant, s’accompagner de multiples consoles opérateurs, être piloté à
partir d’un simple ordinateur de bureau et permettre la génération
de rapports au format Excel. Comme le procédé de traitement est
critique et qu’il ne peut être interrompu par l’activité du système, un
automate dédié s’imposait.
Le système inclut deux ordinateurs, l’un pour l’opérateur, situé sur
le site de traitement, l’autre pour la supervision à partir de la salle de
contrôle. Les deux stations sont connectées au travers d’un réseau
Ethernet. La station principale (celle de l’opérateur) se compose d’un
programme écrit dans l’environnement LabVIEW, doté d’une interface utilisateur graphique, d’une carte d’acquisition de données
(seize voies) associée à un châssis externe de conditionnement de
signaux (SCXI, Signal Conditioning Extensions for Instrumentation)
et d’un automate programmable Allen-Bradley. L’automate est interfacé avec LabVIEW par l’intermédiaire du gestionnaire d’interface
HighwayVIEW (SEG, Software Engineering Group), via le port série
de la station. Cet automate commande les actions des vannes et des
pompes au travers de ses sorties analogiques et numériques. Le
matériel de conditionnement reçoit les signaux de capteurs qui
mesurent la pression, le débit, le pH, le potentiel d’oxydo-réduction
et les niveaux des réservoirs (figure 60).
L’interface homme-machine, créée avec LabVIEW, permet d’afficher les données acquises à la fois par l’automate et par la carte
d’acquisition de données. Le schéma de l’unité de traitement a été
importé en format « bitmap » sur la face avant du programme, ce
qui facilite l’observation globale du procédé, et l’interprétation des
valeurs mesurées par les capteurs, affichées aux endroits appropriés (figure 61).
Le système vérifie périodiquement les conditions d’alarme, affiche les violations sur la face avant et les enregistre sur disque. L’utilisateur définit, au travers d’un écran de configuration d’alarmes, les
signaux qui doivent être surveillés et leurs limites autorisées.
Comme plusieurs opérateurs sont amenés à utiliser le système, le
développeur a créé trois niveaux de protection par mot de passe.
Une seule application LabVIEW a été développée, qui peut tourner
sur la station de l’opérateur mais aussi n’importe où sur le réseau
(notamment sur la station de supervision). La station de l’opérateur
est configurée en serveur TCP/IP de sorte que tout client TCP/IP peut
récupérer les données enregistrées a posteriori ou temps réel. Grâce
à une liaison réseau au travers d’un modem, n’importe quel ordinateur extérieur à l’usine peut superviser le système.
Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite.
© Techniques de l’Ingénieur, traité Informatique industrielle
__________________________________________________________________
PROGRAMMATION GRAPHIQUE DES APPLICATIONS DE CONTRÔLE-COMMANDE
UPS
Network Printer
Existing AppleTalk LAN
1 GB Drive
To
NB-MIO-16
Serial Port
Operator Console
Supervisor's Console
To Remote
Workstation
SCXI-1001
12-Slot Chassis
Modem
PLC-5/20 Rack
Field Devices
Existing Indicator Panel
dans cette application, LabVIEW communique avec un automate Allen-Bradley et gère les mesures issues
de capteurs via un système de conditionnement SCXI et une carte d'acquisition de données NB-MOI-16
Figure 60 – Application de traitement des eaux usées
les objets standards de LabVIEW peuvent être combinés avec une image bitmap
(schéma de l'installation) pour faciliter l'interprétation des informations
Figure 61 – Programmation de l’application
de traitement des eaux usées
Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite.
© Techniques de l’Ingénieur, traité Informatique industrielle
S 8 205 − 31