Programmation graphique des applications de contrôle-commande

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. Généralités... S 8 205 2 1.1 Applications de contrôle-commande... 2 1.2 Conception et programmation des applications de contrôle-commande 2 1.3 Programmation graphique en contrôle-commande... 4 2. Langage graphique G... 6 2.1 Programmation graphique flot de données... 6 2.2 Environnement de développement en langage G : LabVIEW... 12 2.3 LabVIEW et le contrôle-commande de procédés... 17 3. Langage graphique G : développements spécifiques et exemples industriels... 23 3.1 BridgeVIEW : un environnement de développement orienté supervision... 23 3.2 GrafcetVIEW : un langage orienté modèle... 25 3.3 Langage G pour la vision industrielle... 27 3.4 Exemples industriels... 28 Pour en savoir plus... Doc S 8 205 U 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 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.). 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- S 8 205 2 Techniques de l Ingénieur, traité Informatique industrielle

PROGRAMMATION GRAPHIQUE DES APPLICATIONS DE CONTRÔLE-COMMANDE Consignes Visualisation Opérateur Figure 1 Architecture logicielle d une application de contrôle-commande d un procédé industriel Mesures Consignes Acquisition de données Interface hommemachine Récupération Réseau Liaison réseau Traitements des données Liaison stockage Sauvegarde Unité de stockage Analyse et traitement de données Application contrôlecommande Interface entrées/ sorties Restitution de données Mesures Commandes Procédé Commandes 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 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 Analysis- Real 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]. 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 / Famic- Eurilor, 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. 1.2.2 Programmation des applications de contrôle-commande 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...). 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 É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 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 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 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) S 8 205 4 Techniques de l Ingénieur, traité Informatique industrielle

PROGRAMMATION GRAPHIQUE DES APPLICATIONS DE CONTRÔLE-COMMANDE Tableau 1 Classification des langages graphiques Type de programmation Impératif Déclaratif 1.3.3 Programmation flot de données 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). Terminal d'entrée a x b Fonctionnel Logique Nœud Exemples de langages graphiques Layout (Objects Inc.) LabVIEW (National Instruments) HP-Vee (Hewlett Packard) Prograph CPX (Pictorius Incorporated) Visual Designer (Intelligent Instrumentation) Spreadsheet 2000 (Emergent Behavior) Arc orienté Terminal de sortie Figure 4 Diagramme flot de données représentant le calcul de l équation y = ax + bx 2 y i j k Figure 5 Encapsulation du diagramme flot de données représentant le calcul de l équation m = ik + jk 2 explicité dans la figure 4 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 m 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 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]. 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) Réels (orange) Booléen (vert) Chaîne de caractères (rose) Matrice de réels codés sur 16 bits Cluster DBL double SGL single I integer TF true false 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 Numéro du capteur Type de thermocouple Valeur mesurée Récupération de données Mesures température Cluster Numéro du capteur Type de thermocouple Valeur mesurée 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 S 8 205 6 Techniques de l Ingénieur, traité Informatique industrielle

PROGRAMMATION GRAPHIQUE DES APPLICATIONS DE CONTRÔLE-COMMANDE 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. Nombre de mesures Indice d'itération Nombre d'itérations Lecture température Période d'acquisition Mesures 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. 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). Numéro voie Initialisation du port série Numéro voie 5 5 Début_Acquisition Architecture incorrecte Architecture correcte Envoi d'un message Début_Acquisition Figure 8 Exemple d utilisation de la structure de «séquence» Indice d'itération 500,00 Période d'acquisition Condition d'arrêt Figure 10 Exemple d utilisation de la structure itérative «Tant que» 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. 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. 2.1.1.3 Variables locales et globales 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 Techniques de l Ingénieur, traité Informatique industrielle S 8 205 7

PROGRAMMATION GRAPHIQUE DES APPLICATIONS DE CONTRÔLE-COMMANDE Nombre mesures Registres à décalages Boucle de mesures 200 Initialisation 4 Température Boucle de commande Écriture Variable globale 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 Choix unité 9 5 32 Conversion en Fahrenheit False Température en centigrade 2.1.1.4 Événements 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. 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 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. 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. 2.1.2 Programmation en langage G 2.1.2.1 Création de programmes : quelques exemples simples 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). 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). À 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 Techniques de l Ingénieur, traité Informatique industrielle

PROGRAMMATION GRAPHIQUE DES APPLICATIONS DE CONTRÔLE-COMMANDE Température mesurée Activation Alarme Température maximale Attente Création Événement Figure 14 Exemple d utilisation d un événement pour activer une procédure d alarme Fonctions numériques (extrait) Fonctions booléennes (extrait) Fonctions simples Fonctions de conversion entre types Fonctions trigonométriques Fonctions de traitement des tableaux (extrait) Fonctions logarithmiques Dimension Remplacement d'un élément Construction d'un tableau 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 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 2 e degré (figure 18), calcul du PPCM et du PGCD de deux nombres (figure 19), filtre numérique (figure 20). 2.1.2.2 Méthodologie de développement Les langages de programmation graphique permettent à leurs utilisateurs (même non informaticiens) de développer facilement et 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) ; 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). 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é : 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 ; 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 Nombre de points Amplitude Nombre de périodes n A P 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 Discriminant x1 c x2 a Racines réelles 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 Techniques de l Ingénieur, traité Informatique industrielle

PROGRAMMATION GRAPHIQUE DES APPLICATIONS DE CONTRÔLE-COMMANDE PPCM Nombre 1 Nombre 2 PGCD Figure 19 Exemple du calcul du PGCD et du PPCM de deux nombres avec le langage G Nombre de points Valeur initiale de Y Coefficient a Y n 1 a Y n 1 Signal de sortie a b c Exemple correct a x b (a x b) + c Signal d'entrée Nombre de points Amplitude Nombre de périodes onde sinusoïdale Valeur initiale de X X n Exemple incorrect X n 1 b (X n + X n 1 ) c Coefficient b a (a x b) + c 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 : Y n = ay n 1 + b (X n + X n 1 ) b a x b Figure 20 Exemple de la réalisation d un filtre numérique passe-bas du premier ordre avec le langage G [16] Nombre de périodes onde sinusoïdale 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 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. Face avant Programme 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 (Apple- MacOS, 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 Lab- VIEW. 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 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 : S 8 205 12 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 50 Boucle d'acquisition Analyse Limite haute Limite basse Analyse 25 Maximum Minimum Période Température moyenne Écart type 0 0,0 Acquisition Figure 24 Exemple du programme correspondant à la face avant de la figure 23 développé en langage G avec l environnement LabVIEW 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é, 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). Techniques de l Ingénieur, traité Informatique industrielle S 8 205 13

PROGRAMMATION GRAPHIQUE DES APPLICATIONS DE CONTRÔLE-COMMANDE Manipulation Liaisons Point d'arrêt Menu Pop-up avant-plan sélectionner, positionner arrière-plan colorer Écriture Défilement Copier couleurs Sonde Figure 25 Boîte à outils utilisée pour l édition des programmes en langage G dans l environnement LabVIEW utilisateur, des performances globales plus élevées, la capacité de tirer avantage des machines à architecture multiprocesseurs. 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 message Liaison brisée x + 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 5 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 PPCM Nombre 1 Nombre 2 30,00 20,00 30,00 20,00 PGCD les nœuds ou les fils de liaison en tireté ne sont pas encore exécutés Figure 27 Mise au point d un programme par visualisation du flot de données (mode animation) S 8 205 14 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 128 64 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 ACQ ACQ FINI 0.00 ANYS 0.00 SAVE INIT SAVE SAVE FINI 10 le développeur peut choisir les priorités respectives de ces opérations Figure 29 Exemple de trois tâches (acquisition, analyse et sauvegarde des données en langage G) 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 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. 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. Génération d'une onde sinusoïdale Génération d'une impulsion Figure 31 Exemple de quelques fonctions de génération de signaux Détection de crêtes Génération d'une rampe Génération d'un bruit blanc gaussien Filtre de Butterworth 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. Tracé de la fonction de transfert Figure 32 Exemple de quelques fonctions de filtrage de signaux Valeur moyenne Loi de probabilité normale Filtre de Chebyshev Écart type Histogramme Figure 33 Exemple de quelques fonctions de statistiques et probabilités é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 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- S 8 205 16 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 process variable PID parameters manual control options iteration Instrument virtuel réalisant la régulation (PID vi) output Figure 34 Exemple d utilisation de la bibliothèque de régulation de type PID 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. 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. 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. 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 Lab- VIEW existants. 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). 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. 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. 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. 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. 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 nombre de balayages à lire entrée d'erreur taskid de sortie données mises à l'échelle 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 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é 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 Figure 39 Exemple de diagramme permettant de communiquer avec un appareil en liaison série Programmes existants 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 S 8 205 20 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 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 40 Assistant de contrôle d instrumentation : identification des instruments et des ports du système Figure 42 Bibliothèque d entrées/sorties sur fichiers : manipulation des fichiers ASCII et binaires 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. 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. Face avant de l'application 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 S 8 205 22 Techniques de l Ingénieur, traité Informatique industrielle

PROGRAMMATION GRAPHIQUE DES APPLICATIONS DE CONTRÔLE-COMMANDE TCP 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 simple et le plus souple. L environnement de développement Lab- VIEW 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 Lab- VIEW, 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 environnements 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 Techniques de l Ingénieur, traité Informatique industrielle S 8 205 23

PROGRAMMATION GRAPHIQUE DES APPLICATIONS DE CONTRÔLE-COMMANDE IHM / Supervision Acquisition de données Réseau FieldPoint Carte d'acquisition de données Ordinateur Réseau Conditionnement de signaux Série API Logiciel 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. Figure 46 Bibliothèques d objets typiquement industriels de BridgeVIEW S 8 205 24 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 X i (=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 ; Étape inactive (l'action A ne s'exécute pas et X 2 = 0) Figure 47 Représentation graphique du nœud «Etape» dans le modèle GRAFCET 2 2 r 3 Convergence «en et» Action A Étape active (l'action A s'exécute et X 2 = 1) Étape d'attente ou initiale (pas d'action A associée) 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 R1 2 3 4 R3 R2 2 r 3 Divergence «en et» Action A Réceptivité R1 vraie 1 Figure 49 Exemple d un modèle grafcet et de son évolution 2 2 Action A 3 r 1 r 2 Divergence «en ou» R1 2 3 4 R3 R2 Action A Réceptivité R2 vraie Réceptivité R3 vraie 2 2 r 1 r 2 3 Convergence «en ou» 1 R1 2 3 4 R3 R2 Action A 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 Marche/arrêt ASSEMBLAGE Assemblage 3.2.2 GrafcetVIEW STOP PRISE AUTOMATIQUE MANUEL 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. 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. 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 Provenance Désignation Nom Opérateur Carte de référence Marche/Arrêt Usinage E0 x Marche/Arrêt Assemblage E1 x Manuel/Automatique E2 x Prise E3 x Pièce usinée E4 x Pièce déposée E5 x Pièce prise E6 x Fin Assemblage E7 x 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. Définition des entrées/sorties 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 Tableau 3 Sorties de l application test réalisée avec GrafcetVIEW Provenance Désignation Nom Opérateur Carte de référence Usinage S0 x x Attente 1 S1 x Attente 2 S2 x Dépose S3 x x Prise S4 x x Assemblage S5 x x S 8 205 26 Techniques de l Ingénieur, traité Informatique industrielle

PROGRAMMATION GRAPHIQUE DES APPLICATIONS DE CONTRÔLE-COMMANDE É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 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 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- 10 E0 20 11 12 S0 2000/X11 /0 S1 1 2 S2 E1 21 E2 or E3 Time out Entrées Stop i t0 22 S4 1800/X22 /0 Tâche de lecture des entrées (l'entrée, appelée t0, correspond à une entrée de synchronisation après initialisation du grafcet) 13 S3 1500/X13 /0 23 S5 Marquage avant i entrées t Sorties marquage après 2000/X23 /0 Tâche d'élaboration des sorties STOP? 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 Techniques de l Ingénieur, traité Informatique industrielle S 8 205 27

PROGRAMMATION GRAPHIQUE DES APPLICATIONS DE CONTRÔLE-COMMANDE 0 0 i E t 100 S t 4 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- Injection mélange air-carburant Systèmes de conditionnement et de mesures Foyer de turbo-réacteur Sonde de mesure Gaz brûlés Laser Système de déplacement 3 axes Figure 55 Exemple d application d IMAQ Vision LCD Liquid Crystal Display 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 S 8 205 28 Techniques de l Ingénieur, traité Informatique industrielle

PROGRAMMATION GRAPHIQUE DES APPLICATIONS DE CONTRÔLE-COMMANDE 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 CO 2 : 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. Initialisation du système de déplacement Initialisation des analyseurs de spectre (BSA) Initialisation des fichiers de mesures Initialisation du maillage de mesures Mesures de vitesse Réalisation des 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 Traitement des mesures 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- 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 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. 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. 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. S 8 205 30 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 Operator Console SCXI-1001 12-Slot Chassis Serial Port Supervisor's Console Modem To Remote Workstation PLC-5/20 Rack Existing Indicator Panel Field Devices 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 Techniques de l Ingénieur, traité Informatique industrielle S 8 205 31