9
ActivX-fr-intouch.doc 1 14/05/01 MEMO TECHNIQUE Composants ActiveX et FactorySuite Par Steve Lewarne, Wonderware Corporation Introduction Le but de ce document est de montrer l'intérêt et l'utilité des objets ActiveX dans le contexte des logiciels d'automation industrielle, ainsi que de permettre au lecteur de comprendre les concepts de la technologie objet en général et de la technologie ActiveX en particulier. Il fournit pour cela une présentation des concepts fondamentaux de la technologie objet et décrit leur mise en oeuvre dans la technologie ActiveX. Ce document met l'accent sur les points particulièrement importants pour l'automation industrielle et explique les concepts correspondants. Pour comprendre l'utilisation des objets et de la technologie ActiveX, il est important de comprendre leurs origines. C'est pourquoi la première section de ce document est consacrée aux origines des objets et des composants ActiveX. Les sections suivantes décrivent l'utilisation des objets et des composants ActiveX et les avantages qu'ils apportent. Enfin, nous verrons comment la technologie objet en général, et les composants ActiveX en particulier, sont optimisés dans FactorySuite. Rappels du concept des objets logiciels Pour bien comprendre les concepts clés de la programmation orientée objet (POO) et des objets logiciels proprement dits, il est important de comprendre les raisons qui ont motivé leur création. Cette section présente le principe des objets logiciels et décrit le but de la POO et des objets. 2.1 But des objets logiciels Le but ultime des objets logiciels et de la POO est d'économiser du temps et de fiabiliser les développements. Le plus simple pour y parvenir est de développer des objets réutilisables. La conception de systèmes logiciels basée sur des objets permet aux développeurs de créer des bibliothèques de fonctions qu'ils peuvent utiliser d'un projet à l'autre sans avoir à les modifier. Les objets permettent ainsi de réutiliser une fonction de base autant de fois que nécessaire. Ces bibliothèques d'objets diffèrent considérablement des bibliothèques de fonctions traditionnelles en ce sens qu'elles contiennent des données en plus des fonctions qui exploitent ces données. Par conséquent, un objet logiciel peut être considéré comme un ensemble autosuffisant de données et de fonctions associées. Dans les langages de POO, ces objets sont généralement appelés "classes". En général, les langages de POO et les objets sont soumis à trois conditions : ils doivent supporter l'encapsulage, l'héritage et le polymorphisme. Malgré leur aspect obscur, ces concepts sont faciles à comprendre. 2.1.1 Encapsulage L'encapsulage signifie que les données d'un objet ne sont pas accessibles directement à l'extérieur de cet objet ; elles sont encapsulées dans celui-ci. Pour accéder ou utiliser les données d'un objet, il faut utiliser les méthodes que l'objet expose. Ces méthodes sont des fonctions contenues dans l'objet qui permettent d'accéder aux données de l'objet et de les manipuler. Rappelons qu'un objet est un ensemble de données et de fonctions associées (c'est-à-dire de méthodes).

ActiveX Et Factory Suite

Embed Size (px)

Citation preview

Page 1: ActiveX Et Factory Suite

ActivX-fr-intouch.doc 1 14/05/01

MEMO TECHNIQUE

Composants ActiveX et FactorySuite

Par Steve Lewarne, Wonderware Corporation

Introduction Le but de ce document est de montrer l'intérêt et l'utilité des objets ActiveX dans le contexte des logiciels d'automation industrielle, ainsi que de permettre au lecteur de comprendre les concepts de la technologie objet en général et de la technologie ActiveX en particulier. Il fournit pour cela une présentation des concepts fondamentaux de la technologie objet et décrit leur mise en oeuvre dans la technologie ActiveX. Ce document met l'accent sur les points particulièrement importants pour l'automation industrielle et explique les concepts correspondants.

Pour comprendre l'utilisation des objets et de la technologie ActiveX, il est important de comprendre leurs origines. C'est pourquoi la première section de ce document est consacrée aux origines des objets et des composants ActiveX. Les sections suivantes décrivent l'utilisation des objets et des composants ActiveX et les avantages qu'ils apportent. Enfin, nous verrons comment la technologie objet en général, et les composants ActiveX en particulier, sont optimisés dans FactorySuite.

Rappels du concept des objets logiciels Pour bien comprendre les concepts clés de la programmation orientée objet (POO) et des objets logiciels proprement dits, il est important de comprendre les raisons qui ont motivé leur création. Cette section présente le principe des objets logiciels et décrit le but de la POO et des objets.

2.1 But des objets logiciels

Le but ultime des objets logiciels et de la POO est d'économiser du temps et de fiabiliser les développements. Le plus simple pour y parvenir est de développer des objets réutilisables. La conception de systèmes logiciels basée sur des objets permet aux développeurs de créer des bibliothèques de fonctions qu'ils peuvent utiliser d'un projet à l'autre sans avoir à les modifier. Les objets permettent ainsi de réutiliser une fonction de base autant de fois que nécessaire.

Ces bibliothèques d'objets diffèrent considérablement des bibliothèques de fonctions traditionnelles en ce sens qu'elles contiennent des données en plus des fonctions qui exploitent ces données. Par conséquent, un objet logiciel peut être considéré comme un ensemble autosuffisant de données et de fonctions associées. Dans les langages de POO, ces objets sont généralement appelés "classes".

En général, les langages de POO et les objets sont soumis à trois conditions : ils doivent supporter l'encapsulage, l'héritage et le polymorphisme. Malgré leur aspect obscur, ces concepts sont faciles à comprendre.

2.1.1 Encapsulage

L'encapsulage signifie que les données d'un objet ne sont pas accessibles directement à l'extérieur de cet objet ; elles sont encapsulées dans celui-ci. Pour accéder ou utiliser les données d'un objet, il faut utiliser les méthodes que l'objet expose. Ces méthodes sont des fonctions contenues dans l'objet qui permettent d'accéder aux données de l'objet et de les manipuler. Rappelons qu'un objet est un ensemble de données et de fonctions associées (c'est-à-dire de méthodes).

Page 2: ActiveX Et Factory Suite

ActivX-fr-intouch.doc 2 14/05/01

L'encapsulage protège les données d'un objet contre les accès inappropriés et permet à l'objet lui-même de contrôler quand et comment les données sont accessibles. Ceci évite les modifications accidentelles ou incorrectes des données que contient l'objet.

Prenons par exemple un objet boucle PID. Cet objet doit contenir les données (paramètres PID) et fonctions (calculs) nécessaires à la boucle PID. Les paramètres de régulation P, I et D (gains proportionnels, intégral et dérivé) ne doivent pouvoir être réglés qu'à l'aide de fonctions bien définies : SETP, SETI et SETD, évitant ainsi les modifications accidentelles d'un paramètre P, I ou D.

2.1.2 Héritage

L'héritage permet de créer un objet entièrement nouveau possédant tout ou partie des fonctions d'un autre objet. Ainsi, le nouvel objet hérite des structures de données et des fonctions de l'objet parent. Le développeur peut ensuite ajouter de nouvelles structures de données et fonctions à ce nouvel objet "enfant" sans avoir à modifier l'objet "parent".

Prenons l'exemple de l'objet boucle PID. Cet objet offre les structures de données (paramètres) et fonctions (calculs) de base de la boucle PID. A un moment donné, une nouvelle application avec boucle PID à auto apprentissage devient nécessaire. Dans ce cas, au lieu de réécrire l'objet PID à partir de zéro, le développeur peut simplement créer un nouvel objet qui hérite de toutes les structures de données et des fonctions de boucle PID. Il peut ensuite ajouter à cet objet les nouvelles fonctions et structures de données qui répondront aux exigences de régulation à auto apprentissage.

Un autre avantage de l'héritage est que chaque modification de l'objet parent (c'est-à-dire l'objet boucle PID) est implicitement appliquée à tous les objets dérivés de l'objet parent (autrement dit, l'objet PID à auto apprentissage).

2.1.3 Polymorphisme

Le polymorphisme permet de traiter de la même façon différents objets ayant des fonctions similaires. Prenons par exemple deux objets totalement différents : une pompe et une chaudière. Ces deux objets sont associés à une méthode de démarrage. Cependant, ils répondent chacun de manière spécifique à une commande de démarrage.

L'objet pompe peut se contenter de contrôler un ou deux verrous de sécurité avant d'activer le moteur de la pompe. L'objet chaudière peut vérifier un grand nombre de verrous de sécurité, déclencher une alarme sonore, ouvrir une vanne de gaz, déclencher un dispositif d'allumage, ouvrir une vanne d'eau, démarrer une pompe et activer un système de surveillance des fumées. Globalement, le comportement des deux objets est similaire : ils démarrent. Mais leurs procédures de démarrage respectives sont très différentes. Avec le polymorphisme, le système qui émet la commande de démarrage de chaque objet ne connaît pas les détails nécessaires au démarrage des différents types d'équipement. L'avantage du polymorphisme est qu'il cache dans les objets eux-mêmes la complexité associée à leur commande de démarrage.

Présentation des objets ActiveX Le concept d'objets tel qu'il a été décrit précédemment aurait pu s'appliquer à n'importe quel langage de programmation, indépendamment de la plate-forme utilisée. C++ est un langage de programmation orienté objet disponible sur la plupart des plates-formes. Les objets ActiveX sont des objets basés sur le modèle COM (Component Object Model) de Microsoft. COM est une technologie définissant un paradigme commun qui permet l'interaction de différents composants logiciels sous Microsoft Windows.

Le modèle COM permet aux objets d'interagir avec d'autres objets au sein d'un programme spécifique ainsi qu'avec des objets extérieurs à ce programme, alors que la programmation orientée objet (POO)

Page 3: ActiveX Et Factory Suite

ActivX-fr-intouch.doc 3 14/05/01

est limitée aux objets d'un même programme. Cette distinction est essentielle. COM offre une infrastructure standard qui permet aux objets de partager des données et fonctions entre applications.

Si les termes ActiveX, COM et DCOM (Distributed Component Object Model) sont relativement nouveaux, la technologie de base sous-jacente, quant à elle, évolue déjà depuis plusieurs années. Pour bien comprendre ces termes, il est important de connaître l'historique des technologies COM et des technologies qui s'y rattachent.

3.1 Généalogie d'ActiveX

L'histoire des objets ActiveX remonte à plusieurs années ; en fait au début de Microsoft Windows. Pour utiliser une analogie simple mais forte, ActiveX est aux objets ce que Microsoft Windows est aux applications. ActiveX permet aux objets d'utiliser un ensemble commun de services (COM) pour communiquer avec d'autres objets. Microsoft Windows offre une infrastructure commune permettant aux applications d'utiliser un ensemble commun de services périphériques (affichage graphique, clavier, souris, réseau, imprimante, etc.).

Avant Microsoft Windows, chaque programme devait avoir son propre pilote d'imprimante. Maintenant, il suffit de développer un pilote d'imprimante pour Microsoft Windows pour que toutes les applications puissent utiliser l'imprimante sans connaître les codes d'impression et les caractères de contrôle. Avant COM, tous les programmes devaient avoir des objets pour des fonctions spécifiques. A présent, vous pouvez créer des objets ActiveX qui partagent leurs structures de données et leurs fonctions avec n'importe quel programme.

ActiveX a évolué dans le temps et avec les versions de Microsoft Windows. Les sections suivantes fournissent un bref aperçu des technologies qui ont évolué pour aboutir à ActiveX et COM, tels que nous les connaissons actuellement.

3.1.1 Echange dynamique des données (DDE)

Avec DDE, Windows offrait une méthode ouverte et standard d'échange des données. DDE permet aux applications d'échanger des données avec d'autres applications. Il offre également une méthode pour créer des liens dynamiques permettant à une application de signaler à une autre application toute modification de données. C'est une extension naturelle de Microsoft Windows, qui est un environnement dit "événementiel". Les données sont échangées seulement quand cela est nécessaire, et non de manière continue. Cette méthode de communication est optimisée pour réduire les ressources utilisées.

Un autre concept important introduit pour la première fois avec DDE est la capacité pour une application d'exécuter une commande dans une autre application ; cela permettait à une application d'en contrôler une autre. Les concepts utilisés pour fournir cette capacité de commande inter-applications sont à la base de l'automatisation ActiveX, que nous verrons plus tard.

Wonderware Corporation a été l'une des premières sociétés à utiliser DDE en introduisant sur le marché la première interface homme-machine (IHM) basée Microsoft Windows : InTouch. DDE était alors la seule méthode ouverte et standard pour l'échange de données et le contrôle d'applications. Il était également optimisé pour la signalisation des exceptions, permettant ainsi d'utiliser le plus efficacement possible les ressources de la CPU.

3.1.2 Liaison et imbrication d'objets (OLE) 1.0

OLE 1.0 était la première étape permettant à un document de contenir des types d'objets différents. OLE permettait d'imbriquer des objets dans un document ou de les lier à un document. Dans ce dernier cas, le fichier lié était conservé séparément. OLE 1.0 permettait également d'appeler l'éditeur natif des objets en faisant un double-clic sur l'objet OLE. Par exemple, une feuille de calcul du tableur Microsoft Excel pouvait être imbriquée dans un document Microsoft Word. Il suffisait alors de double-cliquer sur la feuille de calculs Excel, dans le document Word, pour lancer le tableur et éditer la feuille de calcul.

Page 4: ActiveX Et Factory Suite

ActivX-fr-intouch.doc 4 14/05/01

OLE 1.0 a été introduit avec Microsoft Windows 2.x et 3.0. Même si le concept était d’avant-garde, OLE 1.0 était handicapé par la limite des 640 Ko de mémoire des PC, qui rendait très difficile l'exécution simultanée de plusieurs applications.

3.1.3 OLE 2.0

OLE 2.0 a apporté plusieurs évolutions par rapport à OLE 1.0. L'objectif restait cependant essentiellement le même : permettre à un document (ou container) de contenir plusieurs objets de différents types. OLE 2.0 marquait l'introduction du concept COM. Les objets OLE 2.0 étaient des objets COM - un cas tout à fait particulier des objets génériques décrits dans la section 2. Le standard COM créait une infrastructure standard pour les objets OLE 2.0. La nature exacte de l'infrastructure COM étant techniquement trop complexe, nous ne la décrirons pas dans ce document ; reportez-vous à la section des lectures conseillées pour de plus amples informations. Parmi les concepts les plus importants introduits par OLE 2.0, citons le GUID (identificateur global unique), la présentation des objets et l'automatisation OLE.

Le GUID permet aux objets OLE de répondre à une condition essentielle : pouvoir être identifiés de manière unique. Les GUID sont des "numéros de série" pour objets OLE. Il n'existe pas deux objets OLE ayant le même GUID. Même si deux objets portent le même nom descriptif, ils peuvent être identifiés de façon unique par leur GUID.

OLE définit des mécanismes standard pour l'affichage des objets. Cela permet à une application container (telle que Microsoft Word) d'allouer de l'espace sur un écran ou une page imprimée pour permettre à l'objet de se dessiner seul.

L'automatisation OLE (également appelée automatisation ActiveX) permet aux applications d'exposer des objets à d'autres applications. L'automatisation OLE permet non seulement aux objets d'échanger des données avec d'autres objets et d'y exécuter des commandes, mais également de connaître les éléments d'information et les commandes proposés par l'autre objet.

OLE 2.0 offrait une méthode standard d'identification, d'affichage et d'utilisation des objets. Ce standard est très important car il permet aux développeurs qui ne connaissent pas les autres applications de créer des objets pouvant être utilisés dans ces applications. InTouch de Wonderware supporte les spécifications OLE 2.0 depuis Windows 3.1. Il supporte également la technologie GOT (Generic Object Technology). Wonderware a développé cette technologie pour permettre la création d'objets génériques pouvant être utilisés conjointement avec InTouch, avant les standards OLE 2.0 et ActiveX.

InTrack, le système de pilotage de fabrication de Wonderware, utilise un serveur d'automatisation OLE comme un moteur de base de données. Ce serveur utilise COM pour exposer les objets qui permettent de manipuler la base de données InTrack. InTouch ou Visual Basic peuvent être utilisés comme clients du serveur d'automatisation OLE InTrack.

3.1.4 Contrôles OLE (OCX)

Les spécifications OLE 2.0 étaient puissantes en ce sens qu'elles permettaient aux objets d'échanger des données et fonctions. Mais il manquait un élément : la capacité pour l'objet de notifier l'application container d'un événement. Par exemple, un objet OLE 2.0 voulant signaler au container que l'utilisateur avait cliqué dessus ne pouvait s'appuyer sur aucun standard. C'est pourquoi OLE a été étendu pour permettre à un objet de signaler à son container l’occurrence d'un événement, améliorant ainsi le dialogue entre l'objet et son container. Ce nouveau type d'objet fut dénommé contrôle OLE, ou OCX.

Les OCX sont récemment devenus des contrôles ActiveX. Ce changement de dénomination correspond à la popularité croissante d'Internet. Les contrôles ActiveX sont de parfaits paradigmes pour Internet car ils utilisent efficacement l'architecture répartie des serveurs d'objets d'Internet. Même si OCX a été renommé ActiveX en raison d'Internet, ce serait une erreur d'associer ActiveX

Page 5: ActiveX Et Factory Suite

ActivX-fr-intouch.doc 5 14/05/01

exclusivement à Internet. ActiveX et COM sont des concepts importants pour n'importe quelle application logicielle, et pas seulement sur Internet.

FactorySuite 2000, de Wonderware Corporation, utilise les contrôles ActiveX, COM et DCOM de manière intensive. InTouch et InControl sont tous deux des containers ActiveX. IndustrialSQL Server, InBatch et InTrack exposent tous les objets client sous la forme d'objets ActiveX. La technologie ActiveX fournit une méthode standard ouverte pour étendre et personnaliser les applications. InTouch et InControl peuvent être facilement étendus avec n'importe quel contrôle ActiveX, et les contrôles ActiveX exposés par IndustrialSQL Server, InBatch et InTrack peuvent être utilisés avec n'importe quel container ActiveX.

Anatomie d'un contrôle ActiveX Les sections précédentes ont présenté le concept des objets en général, et des objets ActiveX en particulier. Nous allons maintenant voir comment les objets ActiveX dialoguent avec les containers. Cette section décrit les interfaces qu'un objet ActiveX expose et quelques-unes des options pour déployer des objets ActiveX.

4.1 Interfaces ActiveX

Nous avons vu que les objets ActiveX contiennent des données et fonctions et qu'ils peuvent signaler des événements à un container. Il existe trois méthodes pour dialoguer et interagir avec un contrôle ActiveX. En terminologie ActiveX, ce sont les Propriétés (données), les Méthodes (fonctions) et les Evénements. L'accès à chacune de ces interfaces s'effectue en utilisant l'automatisation ActiveX. Reportez-vous à la figure 4.1 pour un schéma des Propriétés, Méthodes et Evénements.

Figure 4.1 : Propriétés, Méthodes et Evénements ActiveX

4.1.1 Propriétés

Page 6: ActiveX Et Factory Suite

ActivX-fr-intouch.doc 6 14/05/01

Les objets ActiveX exposent des propriétés à un container. Les propriétés correspondent aux éléments d'information d'un contrôle ActiveX. Dans le cas d'une boucle PID, tous les paramètres PID (SP, PV, OT, P, I, D, etc.) peuvent être traités comme des propriétés.

Les propriétés sont également souvent utilisées pour formater les objets ActiveX. Des informations telles que la police utilisée pour afficher le texte, la couleur de fond de l'affichage et la taille du contrôle sont des propriétés types, utilisées par l'objet pour contrôler la façon dont il sera affiché. Les propriétés peuvent être lues et écrites dans un objet ActiveX.

4.1.2 Méthodes

Les méthodes sont des fonctions exposées par un objet ActiveX. Ces fonctions agissent généralement sur les données contenues dans l'objet. Les méthodes sont l'interface que le container utilise pour commander à l'objet de réaliser une opération.

Un composant boucle PID ActiveX nécessiterait par exemple une fonction de commutation entre le mode automatique et le mode manuel. Cette fonction pourrait être exposée par une méthode appelée AutoManuel. Le container peut appeler cette méthode en fonction des entrées utilisateur. Cette méthode dispense le container de comprendre ce qu'est une boucle PID et lui évite les manipulations de paramètres nécessaires pour changer modifier d'état de contrôle.

4.1.3 Evénements

Les événements sont des mécanismes que l'objet ActiveX utilise pour indiquer au container que quelque chose s'est produit. Les événements peuvent également renvoyer au container les paramètres qui leur sont associés.

Prenons là encore l'exemple d'un composant boucle PID ActiveX. Celui-ci peut générer un événement en réponse au dépassement des limites par une variable de procédé. Ce mécanisme permet au composant ActiveX de signaler cette condition au container. Le container peut ensuite avertir l'utilisateur ou réagir automatiquement à cette condition.

4.2 Mise en œuvre d'ActiveX

Il existe plusieurs façons de mettre en œuvre un objet ActiveX. Un objet ActiveX se comporte comme un serveur vis-à-vis du container, lequel joue le rôle de client. Les objets ActiveX peuvent être mis en œuvre essentiellement de deux façons : comme serveurs internes au processus et comme serveurs externes au processus. Ces deux utilisations correspondent aux objets ActiveX DLL (Dynamic Link Libraries) et aux objets ActiveX EXE (exécutables). Les avantages et inconvénients de ces deux approches sont décrits dans les sections suivantes.

Pour bien comprendre les différences entre les mises en oeuvre internes et externes au processus, il convient d'introduire le concept d'espace de processus. Un espace de processus est un espace mémoire attribué à un processus spécifique (programme, exécutable...). Sous Windows 95 et Windows NT, la mémoire allouée est accessible uniquement au processus auquel elle appartient et au système d'exploitation. Sous Windows 3.x et les versions précédentes, n'importe quel processus pouvait accéder à n'importe quelle partie de la mémoire. Un processus pouvait ainsi accéder à la mémoire d'un autre processus, et l'altérer, provoquant un défaut de protection générale (GPF).

Tout en éliminant le risque d'altération de la mémoire d'un processus par un autre processus, le concept d'espace de processus a compliqué l'échange de données entre processus. L'action qui consiste à déplacer des données d'un processus à un autre s'appelle le Triage. Le standard COM sur lequel ActiveX est construit supporte le triage.

4.2.1 Objets ActiveX DLL

Les composants ActiveX DLL, ou serveurs ActiveX internes au processus, sont chargés dans l'espace de processus de l'application container. Comme ces objets se trouvent dans l'espace de processus de

Page 7: ActiveX Et Factory Suite

ActivX-fr-intouch.doc 7 14/05/01

l'application container, il n'est pas nécessaire de trier les données entre l'application container et l'objet ActiveX. Cela réduit le temps système et augmente les performances.

L'utilisation d'objets ActiveX comme serveurs internes au processus présente de nombreux avantages. L'avantage principal est l'excellente performance obtenue grbce à l'utilisation du même espace de processus que le container. Un autre avantage de ces objets est qu'ils peuvent être utilisés par n'importe quel client d'automatisation OLE, tel que les applications Microsoft Office.

4.2.2 Objets ActiveX EXE

Les exécutables ActiveX, ou serveurs externes au processus, sont chargés dans un espace de processus distinct de celui de l'application container. Comme il n'existe aucune mémoire partagée entre ces applications, les données doivent être triées entre l'objet ActiveX et le container. Ce tri augmente considérablement le temps système et a une incidence importante sur les performances.

L'avantage des exécutables ActiveX est qu'ils permettent l'utilisation des objets par les applications client et par l'exécutable, considéré alors comme une application autonome. De plus, de par leur nature, les exécutables ActiveX opèrent sur un thread distinct et n'interfèrent pas avec le traitement des données dans l'application client.

4.3 Environnements de développement ActiveX

Les objets ActiveX peuvent être développés dans plusieurs environnements de programmation, tels que : Microsoft Visual C++, Borland C++ Builder, Borland Delphi et Microsoft Visual Basic 5.0. L'environnement de développement le plus intéressant est peut-être Visual Basic 5.0 de Microsoft.

Visual Basic Control Creation Edition (VBCCE) de Microsoft est une version de VB 5.0 conçue spécialement pour la création d'objets ActiveX et disponible gratuitement sur le site Web de Microsoft (www.microsoft.com). Bien qu'offrant des fonctionnalités limitées par rapport aux versions Standard, Professional ou Enterprise de VB, VBCCE permet de créer aisément des composants ActiveX simples pour présenter et manipuler les données.

VB 5.0 et VBCCE 5.0 permettent à l'utilisateur final et aux intégrateurs système de résoudre un nombre considérable de problèmes. Grbce à ces environnements, les programmeurs peuvent développer des contrôles adaptés aux applications containers et permettant d'enrichir facilement et de façon standard les applications containers.

Technologie objet et objets ActiveX dans FactorySuite de Wonderware Nous avons vu dans les sections précédentes les objets et la technologie ActiveX. Le but de cette section est de montrer comment ces technologies sont optimisées dans FactorySuite de Wonderware pour l'automation industrielle.

5.1 FactorySuite 1000

Wonderware Corporation a introduit la première gamme intégrée de logiciels pour le marché de l'automation industrielle en avril 1997. L'importante intégration des produits composant FactorySuite 1000 a permis d'optimiser de nombreuses technologies orientées objet.

InTouch, l'interface homme-machine (IHM) de FactorySuite, a optimisé la technologie des objets génériques (GOT) pour permettre la communication avec d'autres composants de FactorySuite, y compris InBatch, IndustrialSQL Server et InControl. Le système d'informations de production Intrack expose un serveur d'automatisation OLE qui communique avec la base de données de suivi de production et peut manipuler ses données. Scout VT et les outils client IndustrialSQL Server utilisaient de façon intensive la technologie ActiveX.

Page 8: ActiveX Et Factory Suite

ActivX-fr-intouch.doc 8 14/05/01

L'utilisation de ces technologies orientées objet a permis à Wonderware de commercialiser la première, et toujours unique à ce jour, gamme intégrée de logiciels pour l'automatisation industrielle. Ce virage décisif nous a permis de distancer les autres vendeurs de procédés industriels, qui tentent de trouver une solution intégrée. Il est important de remarquer que toutes ces technologies complexes ont été fournies sous la forme de solutions complètes, faciles à utiliser, qui ont fait la réputation de Wonderware.

5.2 FactorySuite 2000

FactorySuite 2000 introduit d'importantes évolutions en termes d'intégration, tout en s'inscrivant dans la stratégie d'ouverture et de convivialité de Wonderware. Les sections suivantes présentent quelques-unes des nombreuses améliorations dont les utilisateurs peuvent bénéficier avec FactorySuite 2000.

5.2.1 InTouch

Composant chargé du dialogue homme-machine dans FactorySuite 2000, InTouch 7.0 est un container ActiveX. Les utilisateurs pourront utiliser un éventail infini d'objets ActiveX développés par Wonderware et des sociétés indépendantes du monde entier. InTouch continue à supporter la technologie GOT pour une intégration optimale avec les applications InTouch traditionnelles.

5.2.2 InControl

Composant chargé des fonctions réflexes dans FactorySuite 2000, InControl 7.0 est également un container ActiveX. Les utilisateurs peuvent créer ou acheter des objets ActiveX d’automatisme adaptés à leurs besoins et les utiliser dans la stratégie d’automatisme développée avec InControl. InControl 7.0 utilise également DCOM pour le contrôle et la configuration à distance.

InControl 7.0 inclut un certain nombre de contrôles ActiveX, y compris un contrôle PID, un contrôle de type logique floue et une interface de commande d'axe. Cette version inclut également un exemple d'utilisation du contrôle de type logique floue pour régler le contrôle PID de façon automatique. Le contrôle en logique floue est conforme à l'extension Fuzzy Logic du standard CEI 1131-3.

5.2.3 IndustrialSQL Server

Composant chargé de l’historisation des données dans FactorySuite 2000, IndustrialSQL Server 7.0 expose les fonctionnalités des applications clientes au moyen d'objets ActiveX. Ces outils de suivi de tendance et d'analyse pourront être déployés dans InTouch (pour l'interface homme-machine) et dans d'autres containers ActiveX. IndustrialSQL Server est basé sur Microsoft SQL Server de Microsoft. Il est ainsi possible d'accéder aux données de procédé, de traitement par lots et de production en utilisant des outils SQL standard.

5.2.4 InBatch

Composant chargé du pilotage des procédés discontinus dans FactorySuite 2000, InBatch 7.0 fournit des objets ActiveX pour contrôler les procédés batch. InBatch offre également un ActiveX recettes de type Grafcet qui permet à InTouch de surveiller directement le déroulement des opérations batch. InBatch 7.0 utilise également IndustrialSQL Server pour l'historique des batch, offrant une gestion centralisée des données historiques, des données en temps réel et des données de traitement par lots.

5.2.5 InTrack

Composant chargé du pilotage de fabrication dans FactorySuite 2000, InTrack 7.0 se comporte comme un serveur d'automatisation OLE, permettant de consulter et de manipuler les données de suivi de production. InTrack 7.0 fournit également des objets ActiveX qui communiquent avec le moteur d'automatisation OLE. Ces objets ActiveX peuvent être déployés dans InTouch ou dans n'importe quel container ActiveX.

Page 9: ActiveX Et Factory Suite

ActivX-fr-intouch.doc 9 14/05/01

5.2.6 Scout

Composant chargé de l’accès Intranet/Internet dans FactorySuite 2000, Scout 7.0 fournit un certain nombre de composants ActiveX permettant de visualiser des données FactorySuite en temps réel via Internet. Scout 7.0 fournit également un convertisseur de vues de procédé qui convertit les écrans InTouch en objets Java pour permettre un affichage à distance au moyen de navigateurs Web standard.

Résumé La technologie objet permet une conception modulaire des logiciels. Elle réduit de manière significative le temps nécessaire à la mise en oeuvre et à la modification des applications logicielles. Les objets ActiveX sont construits autour de la technologie COM/DCOM de Microsoft, elle-même basée sur OLE, pour permettre à des applications container de dialoguer avec des objets génériques, ouverts et standard. Tous les développeurs peuvent créer des objets ActiveX sans connantre les applications containers.

Wonderware Corporation améliore en permanence ses produits en intégrant différentes technologies objet. FactorySuite 2000 fournit un support robuste des fonctionnalités et ressources des objets ActiveX, des containers ActiveX et du serveur d'automatisation OLE.

En contribuant aux avancées technologiques dans le domaine des logiciels d'automation industrielle sur PC, Wonderware s'est positionné à l'avant-garde des nouvelles technologies logicielles. Grbce aux produits Wonderware, les utilisateurs peuvent bénéficier de puissantes technologies tout en évitant les complexités habituellement associées à ce type de technologies. L'engagement de Wonderware est de fournir des logiciels puissants, hautement intégrés, durables et conviviaux pour les applications d'automation industrielle.

Lectures conseillées • = Chappell, David (1996). Understanding ActiveX and OLE, A Guide For Developers &

Managers. Redmond, WA : Microsoft Press, ISBN : 1-57231-216-5 • = Eddon, Guy & Eddon, Henry (1997). Active Visual Basic 5.0 • = Redmond, WA : Microsoft Press, ISBN : 1-57231-512-1 • = Appleman, Daniel (1997), Dan Appleman’s Developing ActiveX Components With Visual

Basic 5.0. Emeryville, CA : Ziff-Davis Press, ISBN : 1-56276-510-8