Une adaptation d’UML à la modélisation des systèmes hybrides

01/08/2016
Publication e-STA e-STA 2010-2
OAI : oai:www.see.asso.fr:545:2010-2:17192
DOI :

Résumé

Une adaptation d’UML à la modélisation des systèmes hybrides

Métriques

57
8
240.51 Ko
 application/pdf
bitcache://096c53c28a7f9842f5616b620a1e398bc7c56595

Licence

Creative Commons Aucune (Tous droits réservés)
<resource  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                xmlns="http://datacite.org/schema/kernel-4"
                xsi:schemaLocation="http://datacite.org/schema/kernel-4 http://schema.datacite.org/meta/kernel-4/metadata.xsd">
        <identifier identifierType="DOI">10.23723/545:2010-2/17192</identifier><creators><creator><creatorName>Emmanuel Tanyi</creatorName></creator><creator><creatorName>Marcellin Nkenlifack</creatorName></creator></creators><titles>
            <title>Une adaptation d’UML à la modélisation des systèmes hybrides</title></titles>
        <publisher>SEE</publisher>
        <publicationYear>2016</publicationYear>
        <resourceType resourceTypeGeneral="Text">Text</resourceType><dates>
	    <date dateType="Created">Mon 1 Aug 2016</date>
	    <date dateType="Updated">Mon 1 Aug 2016</date>
            <date dateType="Submitted">Sun 16 Sep 2018</date>
	</dates>
        <alternateIdentifiers>
	    <alternateIdentifier alternateIdentifierType="bitstream">096c53c28a7f9842f5616b620a1e398bc7c56595</alternateIdentifier>
	</alternateIdentifiers>
        <formats>
	    <format>application/pdf</format>
	</formats>
	<version>28925</version>
        <descriptions>
            <description descriptionType="Abstract"></description>
        </descriptions>
    </resource>
.

Résumé— Nous présentons une extension de UML pour faciliter la modélisation des systèmes hybrides. L’extension est motivée par notre expérience sur l’utilisation de UML dans la conception d’une plate forme de simulation de systèmes hybrides. Le métamodèle que nous proposons s’articule autour de trois aspects : - Modification du diagramme d’activité pour intégrer les signaux discrets et continus sous forme d’entrée/sortie. - Incorporation des structures pour la spécification des relations de causes à effet. - Définition des règles de conversion entre les modèles proposés et un langage de l’automatique (GRAFCET). - Définition des règles de conversion entre les modèles proposés et les diagrammes UML classiques. Cette proposition est une contribution à l’objectif des automaticiens d’arriver à un langage unifié (à l’instar de UML) spécifiquement adapté aux concepts du Génie Automatique. Mots clés—UML, Control System, Hybrid System, Activity Diagram, Continuous system, GRAFCET, Modeling. I. INTRODUCTION Le dossier d’un automatisme industriel incorpore de nombreux détails concernant les programmes d’automates, les schémas électriques, les procédés industriels, les matériels incorporés à la fourniture, etc. Mais il manque une vue de synthèse permettant d’appréhender les principes de fonctionnement. Or, tous les auteurs préconisent l’établissement d’un modèle de référence pendant les phases pré-technologiques, ainsi que son maintien et sa mise à jour au cours des étapes ultérieures [1] [2] [3] [4] [5] [6]. Les automaticiens se sont vite rendu compte de l’intérêt d’utiliser les méthodes et outils du Génie logiciel dans le Génie automatique [7] [8] [9], [3] [10], [11], [12], [13], [14], [2], [15]. Or, UML est un langage qui couvre le cycle de vie, et donc les étapes de modélisation, réalisation et programmation. En attendant la venue d’un langage unifié de modélisation des systèmes automatiques, un modèle créé avec un langage de spécification du Génie automatique (GRAFCET [16],…) devrait avoir la possibilité de “migrer” vers UML qui est plus ouvert. L’existence de passerelles est donc une nécessité. Le point de départ pour utiliser UML en Génie automatique est de considérer que UML ne dispose pas d’outil pour modéliser les relations de causes à effet. Plusieurs travaux ont permis de constater cette affirmation [17] [12], [1] [18] [3]. Nous pensons que cet aspect important peut être complété avec un langage approprié tel que MSMC (Modélisation et Simulation des Machines Cybernétiques) proposé dans [19]. Un code objet pourra être généré, mais pour se faire, nous transformerons les “phénomènes” de MSMC en classes d’objets, avant de les adapter à notre modèle. Si les cas d’utilisation permettent de spécifier les relations entretenues entre un utilisateur et la chose commandée, les diagrammes d’activité quant à eux permettent de décrire l’organisation des activités, supportant à la fois les comportements conditionnels et les comportements parallèles. Toutes les fonctionnalités des machines d’état (exemple: StateCharts) peuvent être utilisées dans un modèle d’activité. Etant donné que les diagrammes d’activité pourraient être une solution pour améliorer la structuration des spécifications d’automatismes industriels, nous pensons donc qu’il est indiqué d’étendre ce formalisme aux systèmes hybrides. Nous apportons ces aménagements pour permettre à l’environnement UML de pouvoir jouer un rôle encore plus important dans le cycle de conception (en Génie automatique), depuis les cas d’utilisation jusqu’au déploiement. Le métamodèle qui en découle a reçu le nom de HAD (Hybrid Activity Diagram) dans le cadre de ce travail. Cet article commence par une brève présentation des systèmes hybrides, suivie par la description de l’extension proposée. Après avoir illustré le métagraphe sur l’exemple d’une machine à souder et sa compatibilité avec le GRAFCET et les diagrammes UML classiques, nous appliquerons le métamodèle HAD à la modélisation d’un système hybride type: le Laminoir, tout en mettant en évidence les règles de convertibilité. II. LES SYSTEMES DE CONTROLE INDUSTRIELS HYBRIDES Les recherches sur systèmes industriels automatiques s’attellent à résoudre les questions suivantes [2] : - La modélisation : Il s’agit d’avoir recours à une approche système structurant les différents objets en tenant compte du sens physique et de la causalité de leurs interactions. - L’analyse : Elle suppose le développement d’outils de validation et de vérification des Systèmes Dynamiques Hybrides (SDH), puis la maîtrise de la complexité de cette analyse et l’interprétation physique de certaines propriétés à analyser telles que la stabilité globale du système à travers ses phases consécutives de fonctionnement. - La Simulation : Les recherches actuelles concernant les méthodes et outils formels relatifs à l’analyse du Une Adaptation d’UML à la Modélisation des Systèmes Hybrides Emmanuel TANYI1 , Marcellin NKENLIFACK2 2 LAIA, INSTITUTE OF TECHNOLOGY, UNIVERSITY OF DSCHANG, PO BOX 134 BANDJOUN, CAMEROON 1NATIONAL POLYTECHNIC, UNIVERSITY OF YAOUNDE 1, CAMEROON 2 marcellin.nkenlifack@gmail.com, 1 emmantanyi@yahoo.com e-STA copyright 2010 by see Volume 7, N°2, pp 46-57 comportement des SDH et à la synthèse des lois de commande en sont encore à leurs débuts [19]. La simulation reste donc un passage obligé lorsqu’il faut : - Aider à la réalisation d’une installation, - Valider le modèle élaboré (dans un but de prévision) pour une installation existante, - Valider la commande conçue pour une installation. Les différentes méthodes et outils (spécification, analyse, simulation) sont nombreux aussi bien sur le plan mathématique qu’en Génie automatique et Génie logiciel. Quelques approches et outils mathématiques de base qui peuvent être mis en jeu sont les suivants [27] [28] [29] [2] [1] : Théorie du contrôle, Commande hiérarchisée, Algèbre booléenne, Théorie des graphes, Réseaux de Pétri, Machine aux états finis ou automates (on y retrouve les machines de Moore et de Mealy). A. Les approches de description des systèmes automatiques • Les Systèmes à Evénements Discrets (SED) Ils regroupent un ensemble de procédés qui sont mis en jeu de façon discrète. Les modèles de SED seront généralement élaborés à l’aide des automates à états finis, des GRAFCETs, des Réseaux de Pétri, etc. Le GRAFCET (Graphe Fonctionnel de Commande Etape Transition) est un diagramme fonctionnel dont le but est de décrire graphiquement les différents comportements d’un automatisme séquentiel [30] [16]. • Les Systèmes Continus et Echantillonnés (SCE) [31] [32] : Ils regroupent des automatisations qui traitent des procédés continus portant sur des produits, matières, matériaux ou flux d’énergie continus et caractérisés par des grandeurs continues. On y retrouve : - Les systèmes à boucle ouverte (non asservis) dans lesquels ni la sortie, ni aucune autre variable du système n'a d'effet sur le contrôle de la sortie. - Les systèmes à boucle fermée (asservis) qui possèdent une rétroaction de la sortie sur l’entrée. Pour une meilleure analyse lors de l’étude des systèmes asservis, un certain nombre de propriétés sont explorées. Il s’agit de la stabilité, la rapidité et la précision, etc. • Les Systèmes Hybrides (SH). Ce sont les systèmes dans lesquels : - L’état d’un système dynamique peut être décrit par une combinaison de variables continues, discrètes ou symboliques (exemple de système symbolique : un actionneur peut être ouvert, fermé ou en panne). - La variable utilisée pour décrire le temps peut être de type : continu (décrit par des équations algébro-différentielles), discret (exemple, échantillonnage de signaux décrivant l’évolution des variables, chaque échantillon restant porteur de sa date), symbolique (différents événements ne sont plus rattachés à un instant déterminé et ne peuvent plus être utilisés comme date). - Le procédé aussi peut être continu et événementiel. Cas des installations de production continue avec les étapes finales de conditionnement discontinues ou encore les productions batch, dans lesquelles la matière est caractérisée par des variables continues et est traitée étape par étape. Comme particularité des Automatismes Hybrides on a les Interactions (action mutuelle entre parties du Système Hybride). Les Interactions séquentiel-continu se matérialisent au niveau des actions (étapes du GRAFCET). On parle alors d'action-interaction. Les Interactions continu-séquentiel retrouvées au niveau des réceptivités liées aux transitions. On parle alors de réceptivité-interaction. Nous avons à la figure 1 un exemple de mini GRAFCET hybride. Il est extrait de [11]. Figure 1 Exemple de mini GRAFCET hybride En observant le GRAFCET (figure 1), on peut noter que : - l’action 1 : “Start Induction Motor” déclenche une interaction depuis l’étape 1 du GRAFCET et qui s’applique au moteur d’induction (partie continue). Il s’agit là d’un exemple d’action-interaction de type séquentiel-continu ; - la réceptivité (1) : “motor speed = 18 revs/s” invoque une interaction qui émane du moteur d’induction et agit sur la suite du GRAFCET. Il s’agit là d’une réceptivité- interaction, interaction de type continu-sequentiel. B. La modélisation des systèmes hybrides Une modélisation minimale des Systèmes Hybrides est présentée à la figure 2 [2] : Figure 2 Canevas de modélisation des systèmes hybrides -L’état évolue dans X=Xc×Xd, où Xc ⊆ ℜ n et Xd ⊆ Ν. -Les entrées du système sont des fonctions de commandes U=Uc×Ud. -Le Système Hybride peut alors être structuré autour des parties suivantes : - un système dynamique continu Sc dont l’évolution est décrite par une fonction de transition continue ϕc qui dépend de la valeur de xd : xc(t) = ϕc (t, t0, xc(t0), xd, uc) ; - un système à événements discrets Sd dont l’évolution est décrite par une fonction de transition discrète ϕd : xd (t+ ) = ϕd (t, xc, xc(t), ud) ; - un ensemble de liaisons entre ces deux systèmes. Start induction motor1 Set roll gap to maximum Motor speed = 18 revs/ s 2 (1) Système dynamique hybride uc∈Uc ud∈Ud xc∈Xc xd∈Xd e-STA copyright 2010 by see Volume 7, N°2, pp 46-57 La modélisation des Systèmes Dynamiques Hybrides peut être effectuée à l’aide de divers formalismes, parmi lesquels nous pouvons citer : - Automates Hybrides - Statecharts Hybrides - GRAFCET Hybride - Réseaux de Pétri Mixtes - Hybrid - Hybrid machines - Bond graph à commutations - Réseaux de Pétri Colorés - Réseaux de Pétri Hybrides - Réseaux de Pétri Prédicat Transition Différentiel Pour une description détaillée de ces différents formalismes, le lecteur pourra consulter les articles [16] [31] [2] [32] [5] [4]. Toutefois, il faut dire que les approches et formalismes de représentation des SDH ci-dessus bien qu'intéressants, ne fournissent pas la modularité et l’extensibilité requise pour la représentation de systèmes complexes. D’autre part, ces outils ont étés plus développés pour des travaux de recherche théoriques et ne sont pas toujours nécessairement adaptés à la représentation précise de systèmes physiques. D’ou l’intérêt que nous portons à l’égard de la modélisation objet dans de ce travail, qui apporte [33] : - modularité, - modèle déclaratif, - structuration sous forme de classes et d’objets, - héritage (structuration hiérarchique), - abstraction (encapsulation), - parallélisme et communication par messages, - réduction du temps de développement du modèle (construction, modification, utilisation), Cependant, les outils orientés objets bien qu’étant performants sont pour la plupart adaptés à des applications précises. Ces outils ne sont pas tout à fait dans l’industrie (à quelques exceptions), cela est plus dû au fait que l’on ne dispose pas encore de bibliothèques de paquetages ouvertes ou généralisées disponibles. III. LE MÉTAMODÈLE HAD : HYBRID ACTIVITY DIAGRAM Nous proposons le métamodèle HAD (Hybrid Activity Diagram), comme solution pour la modélisation objet des systèmes hybrides. Ce métamodèle prend en compte les relations de causes à effet et a l’avantage de pouvoir être compatible avec des langages de spécification des automatismes industriels (GRAFCET, MSMC), tout en restant compatible avec les diagrammes UML classiques [34] [35]. A. Pourquoi s’intéresser au diagramme d’activité ? Les diagrammes d’activité d’UML montrent bien l’organisation séquentielle globale des activités de plusieurs objets et dans plusieurs cas d’utilisation d’un système. Contrairement aux “StateCharts” qui eux sont limités à montrer comment un seul objet se comporte dans plusieurs cas d’utilisation [36]. En plus, un diagramme d’activité (tout comme le GRAFCET), met en évidence le parallélisme par le biais de pseudo-états de type convergence et divergence. Les diagrammes d’activité se familiarisent donc mieux avec le GRAFCET, et plus généralement avec les outils de spécification des automatismes industriels. Le choix du diagramme d’activité se justifie également par le fait qu’il est adapté au développement d’applications “multithreading”, ce qui est un très grand avantage dans le cadre du développement de simulateurs d’automatismes industriels hybrides [10] [11] [21] [24]. B. Intégration des relations de causes à effet La causalité est une notion fondamentale pour la compréhension des systèmes physiques car elle permet de comprendre comment un système atteint un état donné à partir de l’étude des interactions entre variables [4]. Il s’agit d’une notion très liée aux conditions de fonctionnement du système. Ces conditions étant en effet définies, les interactions traduisent les relations de causes à effet entre les variables du système, c’est à dire le mécanisme par lequel elles influent les unes sur les autres. Le concept de causalité peut être interprété suivant deux points de vue principaux : – l’approche bond-graph ; – l’approche temporelle. Vous trouverez une description détaillée de ces deux modèles dans [37] [4]. La base logique des applications du Génie automatique étant une logique de relations de causes à effet, ces relations devraient pouvoir bénéficier d’une expression graphique. HAD intégrera beaucoup plus des métagraphes respectant un formalisme et une syntaxe bien précises. 1) Concept de “Activity Class” La notion de classe activité que nous introduisons ici constitue un organe de causes à effet. Les influences qu’il subit sont des causes. L’influence qu’il exerce correspond à l’effet. Une ActivityClass est caractérisée par un mécanisme qui, pour une combinaison donnée de causes, produit un effet déterminé. Une ActivityClass est une unité logique structurée par trois caractéristiques fondamentales : – le type d’influence exercée – la nature de son comportement – le mécanisme de fonctionnement Nous avons illustré cette structure à la figure 3. Figure 3 Caractéristiques générales d’une ActivityClass La notion d’ActivityClass est comparable à peu près au concept de “phénomène” du langage MSMC dont la description est faite dans [19]. 2) Concept de “Activity Module” Un ActivityModule représente un module d’influence. Il est constitué d’un ensemble de classes activité internes. Les instances qui n’appartiennent pas à l’application mais qui CAUSES Mécanismes Influences subies Influences exercéesEffet e-STA copyright 2010 by see Volume 7, N°2, pp 46-57 l’influencent de l’extérieur sont appelées ActivityCause. Virtuellement, n’importe quelle instance de la classe activité peut exercer son influence à l’extérieur (du module). La figure 4 présente quelques composants qu’on peut retrouver dans un Module. Les instances d’un module qui n’exercent aucune influence sont appelées ActivityNoEffect. Figure 4 Composants d’un ActivityModule Le concept central au niveau d’un HAD est donc celui d’instance ActivityClass. Un diagramme HAD pourra faire intervenir plusieurs instances de la classe ActivityClass et un ou plusieurs modules d’activités. Les “états d’activité” que nous connaissons dans les diagrammes d’activité classiques d’UML seront modifiés pour devenir des instances d’ActivityClass, encapsulant un état, un comportement et des interactions. Chaque instance ActivityClass sera capable de recevoir en entrée un message ou un signal (discret ou continu), d’effectuer éventuellement des activités (actions) et d’envoyer à son tour un ou plusieurs messages d’influence en sortie. Ainsi, on pourrait avoir comme attributs d’un message : – les champs numériques : données se rapportant aux valeurs des signaux à intensité variable – les champs lexicaux : qui permettent de désigner les signaux discrets – les champs de nombres cardinaux : utilisés dans les problèmes de comptage. 3) Métagraphe Plus généralement, le tableau 1 présente le formalisme du métagraphe HAD, avec les différents domaines, types d’attributs et représentations. 4) Prise en compte du parallélisme et des comportements conditionnels Dans les diagrammes d’activité classiques d’UML, les “branchements” sont des pseudo-états à une transition entrante et plusieurs transitions sortantes gardées. Seule l’une des transitions sortantes peut être empruntée. Une “fusion” marque la fin d’un comportement conditionnel initialisé par un branchement [36]. Le comportement parallèle dans les diagrammes classiques est décrit par les “débranchements” et les “jonctions”. Nous proposons de représenter les branchements, fusions, débranchements et jonctions par des objets particuliers que nous appellerons “ActivitySelectON”, “ActivitySelectOFF”, “ActivityThreadON” et “ActivityThreadOFF”. Ceci pour bien mettre en évidence le fait que les processus déclenchés par un débranchement tournent en parallèle sous forme de « thread » [38] [20]. Ces objets particuliers ne peuvent pas envoyer de message à l’extérieur du module courant. Le tableau 2 présente les composants du métagraphe de HAD intégrant ces objets pour la prise en compte du parallélisme et des actions conditionnelles. 5) Bloc fonctionnel du Métamodèle Le schéma de la figure 5 permet une meilleure compréhension de la dynamique d’entrée/sortie du métamodèle et sa décomposition fonctionnelle sous la forme : y1 = f (x1, x2, x3, …) ; y2 = g (x1, x2, x3, …) ; y3 = h (x1, x2, x3, …) ; etc. Figure 5 Bloc fonctionnel d’entrée / sortie d’un système de contrôle Il faut noter que chaque fois, l’envoi de messages en sortie s’effectue lorsqu’on a une certaine configuration du vecteur d’entrée. L’utilisation de ce schéma est illustrée plus loin, dans le cas de la modélisation d’une machine à souder. C. Exemple de modèle pour un système séquentiel simple Nous présentons un exemple de diagramme d’activité classique. Il s’agit de celui de la machine à souder. Cet exemple est tiré de [14]. Nous considérons une machine qui soude une pièce A avec une pièce B. Les pièces arrivent sur la machine par des voies séparées. Quand elles sont positionnées, l’opération de soudage est effectuée. Ensuite, la pièce soudée est éjectée et le cycle peut recommencer. Nous présentons dans un premier temps le diagramme d’activité classique UML à la figure 6, exactement tel qu’il se présente dans [14], puis nous allons relever quelques-unes de ses limites. La figure 6 nous montre effectivement les activités de notre machine à souder. Pour chaque état action, on voit apparaître l’activité correspondante. Le déclenchement de chaque transition de sortie est provoqué par la fin de l’exécution de la tâche à laquelle cet état est associé. ActivityClass ActivityCause ActivityEffect ActivityNoEffect VECTEUR D’ENTRÉE x1 x2 x3 - - - VECTEUR DE SORTIE y1 y2 y3 - - - VARIABLES D’ENTRÉE X1 X2 X3 . VARIABLES DE SORTIE Y1 Y2 Y3 . Bloc fonction nel e-STA copyright 2010 by see Volume 7, N°2, pp 46-57 Eléments du Domaine Type Représentation (Metagraphe) Attributs Objet d’initialisation (Begin) Sommet - identifiant : BE (Begin) par défaut * envoi du message “OK” en sortie - Objet Activité à influence interne dans le module - Objet Activité n’exerçant aucune influence Sommet - Identifiant d’objet - Pile des instances de messages reçus en entrée - Variable synchronisant les messages en entrée * Opérations internes au module * Messages envoyés, destinataire, et [conditions d’envoi] Objet Activité externe ou influençant l’extérieur Sommet - Identifiant de l’objet - Pile des instances de messages reçus en entrée - Variable synchronisant les messages en entrée * Opérations internes au module * Messages envoyés, destinataire, et [conditions d’envoi] Objet terminal (End) Sommet - identifiant: EN (End) par défaut - Pile de messages reçus Liaison Objet – Objet Arc (orienté par défaut) Ligne verticale (par défaut) Liaison Extérieur – Objet Arc (orienté par défaut) Ligne horizontale en traits interrompus Liaison Objet – Extérieur Arc (orienté par défaut) Ligne horizontale en traits interrompus Messages reçus en entrée (INput) Numériques, Lexicaux ou Cardinaux IN: <1<7< 3, 4> “StartMotor”>5>7> “Message” >instances destinatrices du message> Opérations effectuées Fonctions OP : Démarrer ( ) Figure 6 Composants de base du métagraphe simple de HAD Eléments du Domaine Type Représentation (Metagraphe) Attributs ActivityThreadON (ex. cas de deux processus déclenchés en sortie) Sommet - identifiant - Pile des instances de messages reçus en entrée - Variable de synchronisation logique des messages en entrée * envoi du message "OK" à toutes les sorties ActivityThreadOFF (ex. fin des deux processus paralleles en entrée) Sommet - identifiant - Pile des instances de messages reçus en entrée - Variable de synchronisation logique des messages en entrée * envoi du message "OK" à la sortie ActivitySelectON (ex. sélection conditionnelle à trois alternatives) Sommet - identifiant - Pile des instances de messages reçus en entrée - Variable de synchronisation logique des messages en entrée - Condition logique pour la sélection de la sortie * envoi du message "OK" à la sortie correspondante ActivitySelectOFF (ex. sélection conditionnelle à trois alternatives) Sommet - identifiant - Pile des instances de messages reçus en entrée - Variable de synchronisation logique des messages en entrée * envoi du message "OK" à la sortie Combinaison de deux processus alternatifs en entrée et deux processus déclenchés en sortie Sommet - identifiant - Pile des instances de messages reçus en entrée - Variable de synchronisation logique des messages en entrée * envoi du message "OK" à toutes les sorties Figure 7 Composants du métagraphe de HAD avec parallélisme et actions conditionnelles 1 1 E T T S S T e-STA copyright 2010 by see Volume 7, N°2, pp 46-57 Figure 8 Diagramme d’activité UML standard de la machine à souder Limites du diagramme classique : On reste limité ici, car il n’est prévu aucune vue pouvant représenter les échanges que cette machine entretient avec l’extérieur. Il est par conséquent difficile de modéliser les relations à l’aide de blocs fonctionnels comme celui présenté plus haut à la figure 5. Dans tous les cas, aucune règle ne permet d’aboutir à des modèles qui correspondent à de véritables décompositions fonctionnelles du genre : Y = f (x1, x2, x3, …). Le constat qui se dégage à l’évidence est donc que le diagramme d’activité UML classique présenté sous cette forme est très peu conforme au Génie automatique et ses langages. D’ou la nécessité de lui apporter quelques aménagements pour qu’il puisse répondre aux attentes. 1) Modèle HAD de la machine à souder Les modèles que nous présentons sont conformes aux règles d’influence que doivent respecter les langages du Génie automatique. Le système de contrôle ici est vu comme un réseau d’instances s’influençant les unes des autres. Ces influences s’exercent à l’aide de messages et de signaux. L’application de notre métagraphe à la machine à souder donne le résultat de la figure 7. Quelques commentaires sur la figure 7 : Les instances numérotées de 1 à 10 font partie du module principal, également les instances T1, T2 et S1. Par contre, les instances de E1 à E5 sont externes au module, mais peuvent l’influencer. Elles font partie de la commande. Pour faciliter la lecture de l’ensemble, nous donnons ici quelques explications concernant les attributs de l’instance numéro 9 de la figure 7 : - IN: S1> ; est le message envoyé (après les opérations) à l’instance numero S1 2) Bloc fonctionnel du modèle de la machine à souder La figure 8 présente les entrées/sorties correspondant à l’exemple précédent. Dans cette figure, on voit bien que la contrainte des systèmes de contrôle basée sur la relation de causes à effet devient évidente ici. Du modèle présenté, on pourrait pratiquement déduire tout un réseau d’influence. La description ainsi faite montre que nos modèles sont conformes aux principes du Génie automatique, notamment à MSMC et au GRAFCET (vu le caractère séquentiel de la représentation). Notons ici que nous préférons utiliser à chaque fois le terme « influence » plutôt que celui de « DataFlow » plus utilisé dans les systèmes d’information. Justement, dans le cas des systèmes de contrôle, l’image qui vient plus à l’esprit est celle de signaux échangés entre entités. C’est pour cela que nous avons préféré garder ce terme comme dans [19]. Figure 9 Entrées/Sorties du modèle de la machine à souder 3) Conversion du diagramme HAD en GRAFCET Règles de passage Il nous suffit de considérer que les instances du modèle HAD deviennent des étapes du GRAFCET. Les influences subies (internes ou externes) se transforment en réceptivités des transitions et les opérations et influences exercées par chaque instance deviennent les actions de l’étape correspondante dans le GRAFCET. Les instances non influentes deviennent des transitions avec réceptivité égale à 1. Notons ici que la réceptivité d’une transition est obtenue en faisant un produit logique des réceptivités correspondant aux différentes influences subies par l’instance. Quant aux instances particulières permettant de supporter le parallélisme et les actions conditionnelles, elles se transforment en liaisons séquences multiples et perdent leur identifiant. Débranchement Jonction Mise en service SOUDAGE EJECTION ATTENTE A AVANCE A AVANCE B ATTENTE B Marche Avance Switch A Switch B Stop Démarrage Soudage Arrêt Start Avancer A, B Souder Ejecter Arrêter Système de contrôle : (MACHINE A SOUDER) e-STA copyright 2010 by see Volume 7, N°2, pp 46-57 Figure 10 Diagramme HAD modélisant la machine à souder ActivityThreadON et ActivitySelectON deviennent donc des sommets de divergence du GRAFCET. ActivityThreadOF et ActivitySelectOF deviennent des sommets de convergence du GRAFCET. L’instance recevant le message venant directement de l’objet d’initialisation se transforme en étape initiale du GRAFCET. En appliquant ces règles nous arrivons au GRAFCET de la figure 9. 1 2 4 6 8 IN: 6> 3 5 7 IN: 5> 9 IN: 2> IN: <1T1> IN: <23,4> IN: <48> IN: <6T2> IN: <37> IN: <5T2> OU: “Marche”>2> OU: “Avance”.“Switch A”>5> “Avance”.“Switch B”>6> OU: ”Stop A”>7> “Stop B”>8> 10 IN: <7<8< S: <79> IN: S1> IN: <9< S: <9< OP: Ejecter() OU: “Fin éjection”>T1> [Redémarrer] “ Fin éjection ”>10> [Arrêter] IN: EN> IN: <10< OU: “Demarrer Soudage”>9> OU: “Arrêt”>10> S1 T1 T2 E4 E5 E3 E2 E1 OU: “OK”>1> e-STA copyright 2010 by see Volume 7, N°2, pp 46-57 Figure 11 GRAFCET déduit du diagramme HAD modélisant la machine à souder B. Compatibilité avec le diagramme d’état transition UML classique Notre modèle non seulement présente des avantages par rapport au Génie automatique, mais en plus il reste compatible avec les diagrammes UML classiques en Génie logiciel. Voici les règles permettant de passer de notre diagramme HAD au diagramme classique UML : - toutes les instances internes deviennent des états d’activité classiques d’UML ; - toutes les instances et influences externes sont supprimées ; - les instances de type "T" se transforment en débranchement ou en jonction (l’appelation est « Joint » en UML) ; - les instances de type "S" se transforment en branchement ou en fusion (l’appelation en UML est « Fork ») ; - les liaisons internes (avec ou sans message) deviennent des transitions du diagramme classique ; - les objets initialisation et terminal deviennent respectivement les états initial et final du diagramme d’activité UML classique; - les opérations internes au module deviennent les méthodes exécutées dans l’état d’activité du diagramme classique. Dans ces conditions, le diagramme d’activité classique d’UML se comporte donc comme un “cas particulier” de notre diagramme HAD dans lequel on a que des objets internes ne subissant aucune influence et n’exerçant aucune influence. La figure 10 présente l’application de ces règles à notre modèle HAD, qui reconstitue ainsi le diagramme d’activité classique UML de la machine à souder. Figure 12 Diagramme d’activité UML classique obtenu par conversion de notre modèle HAD de la machine à souder, en appliquant les règles définies plus haut Note : Enrichissement d’UML en général Notre métamodèle est utile aussi bien en Génie automatique qu’en Génie logiciel, notamment dans la modélisation des systèmes d’information [39] [40] [41]. En effet, les diagrammes d’activité classiques d’UML ne ressortent pas les interactions avec l’extérieur au cours des différentes opérations, puisque les activités montrent ce qui doit être réalisé, mais ne montrent pas tout à fait qui les réalise. En terme de programmation, cela veut dire que le diagramme n’indique pas quelle classe est responsable de chaque activité. Le métamodèle HAD basé sur les notions de classes et d’interactions avec l’extérieur permet donc d’ouvrir une nouvelle voie pour pouvoir remédier à cette situation. C. Les diagrammes hybrides HAD 1) Présentation Un diagramme d’activité hybride pour nous sera vu comme un diagramme d’activité tel que présenté ci-dessus, auquel on associe (aux différentes instances ActivityClass) un ensemble de variables d’états continues et pour lequel un système d’équations algébro-différentielles portant sur un sous- ensemble de ces variables peut être associé à chaque état. De façon globale, l’ensemble des instances actives définit à chaque moment la situation, et l’ensemble des systèmes 3 5 7 Avance A Vérifier A prête Avance.Switch A Stop A 4 6 8 Ejecter Souder Fin soudage Fin éjection Démarrer soudage 9 10 1 Début Marche Marcher2 Poste soudure OK Stop Arrêter11 Attente signal Avance B Stop B Attente signal Avance.Switch B Vérifier B prête Mise en marche Souder Ejecter Avance A Avance B Vérifier si A prête Vérifier si B prête Arrêter Attente Signal Attente Signal e-STA copyright 2010 by see Volume 7, N°2, pp 46-57 d’équations associées à ces instances définit l’activité de cette situation. Des instances externes peuvent également agir sur les variables d’état continues. 2) Limites des approches semblables Il faut noter que d’autres approches semblables de modélisation de systèmes hybrides existent : - les « StateCharts hybrides » [13] qui conservent malheureusement tous les inconvénients des StateCharts présentés au début de cet article (voir III-A). - les « Réseaux de Petri hybrides » présentés dans [2] qui restent très complexes à manipuler pour de gros systèmes, et ne sont pas directement compatibles avec les diagrammes UML classiques. - OMHS (Object Oriented Methodology for Hybrid System) basée sur OMT. Cette méthode n’est pas adaptée aux modèles génériques d’un SDH et ne prend pas en compte le parallélisme. 3) Application à la modélisation d’un automatisme hybride: Le Laminoir L’exemple est tiré de [11]. Il s’agit du laminoir (Rolling Mill), présenté à la figure 11, un exemple type de système automatique hybride. Le système convertit les blocs métalliques en tôles. Le processus de laminage invoque une séquence d’opérations : le métal est chauffé à une température précise; l’ouverture entre les rouleaux (Rolls) est ajustée pour permettre au métal de pénétrer; le bloc est inséré dans les rouleaux; le moteur d’induction (induction motor) déplace les rouleaux à une vitesse constante jusqu’à ce que l’ouverture soit stabilisée à une certaine valeur assez faible; les tôles produites sont éjectées des rouleaux et la séquence est reprise. Les séquences d’opérations sont modélisées sous la forme d’un GRAFCET. Un extrait du GRAFCET du laminoir a été présenté à la figure 1. La logique (séquence) d’opérations, définie par le GRAFCET est implémentée dans l’automate programmable (Programmable Logic Controller), qui constitue ainsi la partie séquentielle du système hybrid. Les autres composants du système (Servomoteur, contrôleur d’ouverture -Roll gap controller-, moteur d’induction - induction motor-, rouleaux -rolls-, et contrôleur de température -temperature controller-) constituent la partie continue du système. Ils sont modélisés par un ensemble d’équations différentielles et algébriques. Par exemple, l’ouverture de roulements étant donnée en considérant la position "x" du servomoteur, on a l’équation différentielle (servomoteur) suivante : Le Laminoir utilise un ensemble de capteurs (sensors) pour obtenir des informations sur le processus : - Le capteur P (roll gap potentiometer) : permet de mesurer l’ouverture entre les roulements. - Le capteur S (Speed sensor) : permet de déterminer la vitesse de roulement. - Le capteur L (Load cell) : détermine la présence d’une charge entre les rouleaux. - Le capteur T (Thermocouple) : détermine la température du métal dans le four. Figure 13 Le Laminoir (Rolling Mill) Vitesse du servomoteur = dx / dt : (1) f est le coefficient de friction X est la valeur instantanée de l’ouverture refX est la valeur de référence de l’ouverture K est le gain du servomoteur J est le moment d’inertie des rouleaux. La température du métal est donnée par la relation : Tm = Tf * Exp (-τ*t) (2) Tm=température recherchée du métal, Tf=température du four, τ=constante de refroidissement et t=temps Le lecteur pourra se référer à l’article [11] pour plus de détails sur le fonctionnement du laminoir. Nous présentons à la figure 12, le modèle hybride du diagramme d’activité utilisant le métagraphe proposé. Il s’agit de la modélisation type d’un système hybride basée sur HAD. Les modèles hybrides HAD ont l’avantage de modéliser les systèmes industriels hybrides à l’aide d’un formalisme restant compatible avec les diagrammes classiques UML. En plus, on pourra facilement passer de ce modèle au GRAFCET ou à MSMC, puis à la simulation.Nous avons donc un outil qui serait très utile aux acteurs du Génie automatique (confrontés aujourd’hui à des systèmes de plus en plus complexes), mais également aux acteurs du génie informatique. Rolls S T Oven Servomotor Induction Motor Temperature controller Roll-gap controller Programmable Logic Controller (PLC) Sensor P L S dt dX f dt Xd JXXK ref +=− 2 2 )( e-STA copyright 2010 by see Volume 7, N°2, pp 46-57 Figure 14 Diagramme d’activité hybride (HAD) modélisant le laminoir IV. CONCLUSION Nous avons proposé une extension d’UML pour les automatismes industriels hybrides. Notre métamodèle (HAD) prend en compte les relations de causes à effet et la modélisation des systèmes hybrides. La compatibilité avec les langages de spécification d’automatismes existants permet de passer facilement d’un modèle HAD vers le GRAFCET. La compatibilité avec UML classique permet de bénéficier des avantages de UML dans la couverture du cycle de développement. HAD vient palier à un inconvénient du diagramme d’activité classique UML à savoir qu’il ressemble beaucoup plus à une approche fonctionnelle qu’à une approche orientée objet. Cette ambiguïté pourrait être levée en prenant HAD comme contribution à une normalisation plus complète des diagrammes d’activité, ceci afin de permettre aux développeurs de construire sur de bases plus stables des outils servant à exécuter et tester ces diagrammes en Génie logiciel. Enfin, nous pensons poser à travers cet article les jalons pour la mise sur pied (comme souhaité par [14] [17]…) d’un langage unifié propre au Génie automatique. S1 1 S3 2 IN: 2> IN: <13> OU: “Process Data Ready”>2> OU: “Ready for Next Roll”>S1> IN: <9EN> IN: 4> 4 IN: <3< S: <3< OP: SetSpeed () dt dX f dt Xd J)XX(K 2 2 ref +=− OU: “OK”>S1> IN: <45> [Continuous] “OK”>6> [Reversible] E2 5 IN: 7> IN: S2> 7 IN: <5< S: <5< OP: FirstRoll(); ReInsertMetal () OU: “OK”>8> 8 IN: <79> IN: <6< S: <6< OP: Roll () OU: “OK”>10> [Count<S3> [Count == Max] 10 IN: 6> S2 OU: “Specimen In Position>8> E4 OU: “MillReverse”>6> E3 9 IN: <8< S: <8< OP: SecondRoll() OU: “OK”>S3> 6 OU: “OK”>1> e-STA copyright 2010 by see Volume 7, N°2, pp 46-57 Le travail présenté ici se poursuit encore et ouvre d’ailleurs beaucoup de perspectives: Nous envisageons dans un proche avenir développer dans l’environnement de simulation de systèmes automatiques un module qui devrait permettre la conversion automatique des modèles HAD en GRAFCET ou en diagrammes classiques UML avant de passer à la simulation du système. REFERENCES [1] Brenier H., Métamodèle UML, Les spécifications fonctionnelles des automatismes industriels et temps réel, 303–362, Dunod, Paris, 2001. [2] Zaytoon J., Systèmes Dynamiques Hybrides, Traité Systèmes automatisés, Information Commande et Communication, Hermes, Paris, 2001. [3] Soriano T., Langage de Modélisation Unifié et Systèmes Dynamiques Hybrides : une approche, 3ème Conférence Internationale sur l’Automatisation des Processus Mixtes (ADPM’98), Mars 1998, Reims, France [4] Traoré S., Une Approche Orientée Objet dans la Simulation des Systèmes Dynamiques Semi-Continus, Thèse de Doctorat de l’Université de Rennes I, Supelec, Rennes, France, 1994. [5] Thevenon L., Représentation des systèmes Hybrides Complexes par Flux de Données : Développement d’un outil de Modélisation et de Simulation des procédés Batch, Thèse de Doctorat de l’Institut National Polytechnique de Grenoble, Grenoble, France, 2000. [6] Perret J., Hetreux G. et Le Lann J. M., Object hybrid formalism for modeling and simulation of chemical processes, Proc. of IFAC Conf. on Analysis and Design of Hybrid Systems, (ADHS), June 16-18, 2003, Saint-Malo, France [7] Tanyi E., Tsochounie J., Nkenlifack M. et Noulamo T., “An Internet- Based Distributed Real-time Control System for the Cameroon Power Network”, IEEE Proc Int. Conf. on Signal & Image Technology and Internet-based Systems, Yde-Cameroon, 2005, ISBN: 2-9525435-0. [8] Tanyi E., Noulamo T., Nkenlifack M. et Tsochounie J., A Multi-Agent Design and Implementation of An Internet Based Platform for the Remote Monitoring and Control of the Cameroon Power Network, Special Issue on Advances in Information Engineering, Engineering Letters, 13:2_18, ISSN: 1816-0948 (online version); 1816-093X (print version), http://www.engineeringletters.com/issues_v13/issue_2/index.html [9] Noulamo T., Tanyi E., Nkenlifack M. et Lienou J., Modèle métier et architectures génériques pour la commande et la surveillance des systèmes dynamiques, Proc. Of CIFA 2008, Conf. Int. Francophone d’Automatique, Bucarest, Roumanie, 3-5 septembre 2008. [10] Iung C. et Zanne C., Simulation des systèmes hybrides, Systèmes Dynamiques Hybrides, Traité Systèmes automatisés, Information commande et communication, 195–210, Hermes, Paris, 2001. [11] Tanyi E. et Linkens D., A G2 based Hybrid Modeling and simulation strategy and its Application to a Rolling Mill, Control Engineering Practice, London, 1998. [12] Tanyi E. et Nkenlifack M., An object oriented simulation platform for hybrid control systems, Analysis and Design of Hybrid Systems (ADHS) 2003, Proc. of the IFAC International Conference, St Malo, France, June 16-18 2003, Edited by S. Engell, H. Gueguen & J. Zaytoon, ISBN 0-08- 044094-0 [13] Gueguen H., Roubinet C., Pascal J.C., Soriano T. et Pingaud H., Modèles mixtes et structuration de modèles complexes, Systèmes Dynamiques Hybrides, Traité Systèmes automatisés, Information commande et communication, 179-183, Hermes, Paris, 2001. [14] Brenier H., Métamodèle UML, Les spécifications fonctionnelles des automatismes industriels et temps réel, 303–362, Dunod, Paris, 2001. [15] Quenec’hdu Y. et Zaytoon J., Sur la modélisation des systèmes hybrides, Systèmes Dynamiques Hybrides, Traité Systèmes automatisés, Information commande et communication, 87–92, Hermes, Paris, 2001. [16] David R. et Alla H., Du Grafcet aux réseaux de pétri, Hermès, France, 1997. [17] Hien N., Une méthode Industrielle de Conception de Commande par Automate Hybride Développée en Objets, Thèse de Doctorat de l’Université de Droit, d’Economie et des Sciences d’AIX-Marseille, Toulon, France, 2001 [18] Mosterman P., An Overview of Hybrid Simulation phenomena and their support by Simulation Packages, in F.W. Vaandrager & J. H. van Schuppen (Eds.), Hybrid Systems: Computation and Control, Lecture Notes in Computer Science 1569, pp 165-177, 1999 [19] Brenier H., Métamodèle MSMC (Modélisation et Simulation des Machines Cybernétiques), Les spécifications fonctionnelles des automatismes industriels et temps réel, 194–248, Dunod, Paris, 2001. [20] Nkenlifack M., Modélisation objet et développement d’un atelier de simulation des automatismes industriels hybrides, Thèse de Doctorat de l’Ecole Polytechnique (Université de Yaoundé 1), Cameroun, 2004. [21] Tanyi E. et Nkenlifack M., Application of UML to the Modeling and Simulation of Hybrid Control, in Masoud Mohammadian (Ed.), Proc. of the International Conference on Computational Intelligence for Modeling, Control and Automation (CIMCA’2003), Vienna - Austria, 12-14 February 2003, pp. 619 - 628, ISBN 17-408806-92 [22] Tanyi E. et Nkenlifack M., A UML-Based model for the simulation of Hybrid Control Systems, Proc. of the International Conference on Computer Science, Software Engineering, Information Technology, e- Business, and Applications (CSITeA’03), June 5-7, 2003, Rio de Janeiro, Brazil, ISBN 0-9742059-0-7 [23] Tanyi E. et Nkenlifack M., An extended UML for the modeling of hybrid control systems, in Burnham K. J., Haas O. C. L. (Editors), Proc. of the sixteenth International Conference on Systems Engineering (ICSE2003), Coventry, UK, 9-11 September 2003, Vol. 2, pp. 681 - 686, ISBN 0- 905949-91 [24] Tanyi E. et Nkenlifack M., An object-oriented simulation environment for hybrid control systems, in Satyadas, A. and Dascalu, S. M. (editors), Proceedings of the 12th Intl. Conf. on Intelligent and Adaptive Systems and Software Engineering (IASSE-2003), July 2003, San Francisco, CA, USA, ISBN 1-880843-47-1 [25] Nkenlifack M. et Tanyi E., HAD: Extending UML for the Modeling of Hybrid Control Systems, Poster in ECOOP, 17th European Conference on Object-Oriented Programming, July 21-25, 2003, Darmstadt University of Technology, Germany, http://www.st.informatik.tu- darmstadt.de:8080/ecoop/posters/index.phtml [26] Noulamo T., Tanyi E., Nkenlifack M. et Lienou J. P., Domain specific, Model and generic architectures for control and monitoring of dynamic system, Journal: ADVANCES IN COMPUTER SCIENCE ANDENGINEERING, PUSHPA PUBLISHING HOUSE, ISSN 0973- 6999, INDIA, 2009. e-STA copyright 2010 by see Volume 7, N°2, pp 46-57 [27] Lipschutz S., Mathématiques pour informaticiens : Cours et problèmes, série Schaum, McGraw-Hill Inc., New York, 1983. [28] //www.sciences.univ-nantes.fr/physique/perso/aloui/index.htm, Cours sur les méthodes numériques de résolution des équations différentielles linéaires et non linéaires, juin 2001. [29] Ayres F., Théorie et applications du calcul différentiel et intégral, Schaum, McGraw-Hill Inc., New York, 1979. [30] CEI-IEC (Commission Electrotechnique Internationale), GRAFCET specification language for sequential function charts, Norme Internationale IEC 60848, 2002. [31] Gueguen H. et Lefebvre M., A comparison of mixed specification formalisms, 4ème Conférence Internationale sur l’Automatisation des Processus Mixtes (ADPM’00), 2000, Dortmund, Allemagne. [32] Gueguen H., Valentin-R C., Pascal J., Soriano T. et Pingaud H., Modèles mixtes et structuration des modèles complexes, in Systèmes Dynamiques Hybrides, Traité Systèmes automatisés, Information commande et communication, Hermes, Paris, 2001, pp. 157-187. [33] Urquia H. et Dormido S., Object Oriented Design of Reusable Model Libraries of Hybrid Dynamic Systems – Part Two: A Case study, Mathematical and Computer Modeling of Dynamical Systems, Vol.9, N°1, pp 91-118, 2003. [34] //www.omg.org, Site Web de l’OMG contenant le manuel de référence UML 2.0, 2005. [35] Rumbaugh J., Jacobson I. et Booch G., The Unified Modelling Language Reference Manual, Addison-Wesley, 1999. [36] Flower M., UML Distilled, Second edition, Addison-Wesley Longman, Inc, 2000. [37] Buisson J., Bond graphs à commutations, in Systèmes Dynamiques Hybrides, traité Systèmes automatisés, Information Commande et Communication, Hermès, Paris, 2001, pp. 93-117 [38] Delannoy C., Programmer en Java, Eyrolles, France, 2001 [39] Printz J., Génie logiciel, Les techniques de l’ingénieur, Doc H3208. [40] Roques P. et Vallee F., UML en action, Eyrolles, France, 2001 [41] Schach S., Practical Software Engineering, IRWIN, Boston, 1992. e-STA copyright 2010 by see Volume 7, N°2, pp 46-57