Vers l' intégration d'une approche de génération automatique de mod ele de simulation dans un flot de conception de contrôle -commande

HAL Id: hal-01251052

https://hal.inria.fr/hal-01251052

Submitted on 5 Jan 2016

HAL is a multi-disciplinary open access archive for the deposit and dissemination of sci- entific research documents, whether they are pub- lished or not. The documents may come from teaching and research institutions in France or abroad, or from public or private research centers.

L’archive ouverte pluridisciplinaire HAL, est destinée au dépôt et à la diffusion de documents scientifiques de niveau recherche, publiés ou non, émanant des établissements d’enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

Vers l’ intégration d’une approche de génération automatique de mod ele de simulation dans un flot de

conception de contrôle -commande

Sophie Prat, Philippe Rauffet, Alain Bignon, Pascal Berruet

To cite this version:

Sophie Prat, Philippe Rauffet, Alain Bignon, Pascal Berruet. Vers l’ intégration d’une approche de génération automatique de mod ele de simulation dans un flot de conception de contrôle -commande.

JDJN MACS, GDR MACS, Jun 2015, Bourges, France. �hal-01251052�

Vers l’int´egration d’une approche de g´en´eration automatique de mod`ele de simulation dans un flot

de conception de contrˆ ole-commande

Sophie Prat ^1,2 , Philippe Rauffet ¹ , Alain Bignon ² , Pascal Berruet ¹

1 Laboratoire des Sciences et Techniques de l’Information, de la Communication et de la Connaissance, UMR 6285 – Universit´ e de Bretagne-Sud, CNRS, Centre de Recherche, BP 92116

56321 Lorient Cedex, France.

[email protected] ; [email protected] ; [email protected]

2 SEGULA Technologies,

BP 50256, 56602 Lanester Cedex, France.

[email protected]

R´ esum´ e— Dans le cadre d’une d´ emarche outill´ ee d’aide ` a la conception de contrˆ ole-commande, bas´ ee sur l’Ing´ enierie Dirig´ ee par les Mod` eles (IDM), on cherche ` a y int´ egrer des techniques de v´ erification par simulation. L’int´ erˆ et est de pouvoir permettre la g´ en´ eration automatis´ ee du prototype virtuel du syst` eme ` a commander/superviser, et ce d` es le d´ ebut du cycle de conception. Cette d´ emarche de concep- tion de syst` emes sociotechniques permet de g´ en´ erer un pro- gramme de commande et l’interface de supervision associ´ ee, d` es le d´ ebut de la conception du syst` eme. La g´ en´ eration est automatis´ ee grˆ ace ` a l’utilisation des techniques de l’IDM. En vue de l’obtention d’un prototype virtuel d’un proc´ ed´ e de gestion de fluide, une approche de structuration des mod` eles de simulation du proc´ ed´ e est pr´ esent´ ee dans cet article. Les perspectives d’int´ egration au sein du flot de conception de l’outil d’aide ` a la conception Anaxagore sont aussi abord´ ees.

Mots-cl´ es— Simulation, V´ erification, IDM, Aide ` a la concep- tion.

I. Introduction

Dans un contexte de concurrence g´ en´ eralis´ ee, l’am´ e- lioration de la conception de syst` emes sociotechniques (syst` emes complexes en forte interaction avec l’humain) doit faire face aux probl´ ematiques li´ ees ` a la communica- tion au sein d’´ equipes pluridisciplinaires. D’autre part, il est n´ ecessaire de limiter la d´ etection tardive d’erreurs de conception (d´ etect´ ee par exemple, lors de l’impl´ ementation, lorsque le syst` eme physique est fig´ e).

C’est dans ce sens que des travaux ont ´ et´ e initi´ es par Alain Bignon [3], [8], cherchant ` a g´ en´ erer, d` es les premi` eres phases de conception, programmes de commande et inter- faces de supervision associ´ ees. Grˆ ace ` a l’utilisation des tech- niques issues de l’Ing´ enierie Dirig´ ee par les Mod` eles (IDM), en particulier les transformations de mod` eles, la g´ en´ eration est ainsi automatis´ ee. Cependant, ` a ce jour, l’outil ne dis- pose pas de techniques de v´ erifications int´ egr´ ees qui per- mettraient de garantir la qualit´ e des r´ esultats g´ en´ er´ es, tout en y consacrant un minimum de temps. Un int´ erˆ et particu- lier est port´ e sur la simulation qui permet de rendre compte de la dynamique du comportement du proc´ ed´ e r´ eel, et ainsi d’obtenir un prototype virtuel d` es le d´ ebut de la concep- tion.

Toutefois, l’obtention de mod` eles de simulation requiert

des connaissances approfondies du proc´ ed´ e et en simulation [12], et d´ epend aussi de l’objectif de la simulation (c’est-

`

a-dire de ce que l’on souhaite v´ erifier en utilisant la si- mulation). De plus, avant de pouvoir utiliser la simulation pour effectuer des v´ erifications sur la commande ou au ni- veau de l’IHM (Interface Homme-Machine) de supervision, il faut pouvoir en garantir sa qualit´ e. C’est-` a-dire r´ epondre

`

a la question

est-ce que le mod` ele de simulation et son ex´ ecution sont bien fid` eles au comportement du syst` eme physique par rapport ` a l’objectif pr´ ed´ efini ?

.

Dans nos travaux nous consid´ ererons le cas de la concep- tion de syst` emes de gestion de fluide embarqu´ es sur des navires. Afin de pouvoir v´ erifier le bon fonctionnement (ou le respect de sp´ ecifications), il faudra donc ˆ etre en mesure de mod´ eliser le comportement de l’´ evolution du fluide en fonction des commandes impl´ ement´ ees. Du point de vue de l’´ equipage qui exerce sur le syst` eme un pilotage macrosco- pique, le comportement de celui-ci est discret. Par exemple, pour une pompe de r´ egulation de pression, l’op´ erateur en charge de la commande du syst` eme ne g` ere pas directement l’asservissement en vitesse de la pompe, mais simplement son ´ etat (Marche/Arrˆ et) ou son mode de fonctionnement (Manuel/Automatique). Les commandes impl´ ement´ ees sur les automates programmables industriels sont ´ egalement discr` etes. Les quelques asservissements continus n´ ecessaires sont g´ en´ eralement implant´ es dans l’´ equipement qui, ainsi, s’autor´ egule. Pour cela, nous retenons l’utilisation d’une si- mulation ` a ´ ev´ enements discrets (changement d’´ etats ` a des instants pr´ ecis dans le temps [13]) pour notre approche.

En vue de sa g´ en´ eration automatique, une approche de structuration des mod` eles de simulation du proc´ ed´ e est pro- pos´ ee dans cet article. Dans un premier temps l’objectif de la simulation sera d´ efinie, puis l’approche de structuration sera pr´ esent´ ee et illustr´ ee sur un cas d’´ etude.

II. Travaux ant´ erieurs et pistes de recherches

L’Ing´ enierie Dirig´ ee par les mod` eles (IDM) renvoie ` a

l’utilisation syst´ ematique de mod` eles comme artefacts de

conception primaires dans le cycle de vie. L’IDM est un

domaine de l’informatique qui met ` a disposition des ou-

tils, des concepts et des langages pour cr´ eer et transfor-

mer ces mod` eles [15]. L’IDM est fond´ ee sur la notion de mod` ele et sur deux concepts principaux. D’une part l’utili- sation d’autant de langage de mod´ elisation que n´ ecessaire (concept de m´ etamod´ elisation), et d’autre part le concept de transformation de mod` eles afin de rendre les mod` eles op´ erationnels. L’approche MDA (Model Driven Architec- ture ) [11] propose de transformer un mod` ele ind´ ependant de toutes plates-formes d’ex´ ecution (PIM) en un mod` ele sp´ ecifique ` a une plate-forme (PSM). Le PSM obtenu cor- respond ` a un mod` ele op´ erationnel. Se r´ ef´ erer ` a l’´ etat de l’art r´ ealis´ e dans [5] pour plus de pr´ ecisions. Parmi les principaux int´ erˆ ets identifi´ es dans [15], on peut retenir la r´ eutilisation de mod` eles sur ´ etag` eres, l’interop´ erabilit´ e, la portabilit´ e, la r´ e-ing´ enierie.

Dans divers travaux, l’IDM est utilis´ ee pour faire de la g´ en´ eration automatique. Parmi les diff´ erentes applications on peut retenir : l’obtention de programmes de commande, d’IHM, ou encore de mod` eles de simulation. Certaines ap- proches permettent ´ egalement de faire de la g´ en´ eration conjointe.

Dans ce cadre, des travaux ont ´ et´ e men´ es pour cr´ eer un outil d’aide ` a la conception g´ en´ erant conjointement pro- gramme de commande et interface de supervision. Cet outil [3], [8], nomm´ e Anaxagore, utilise les techniques de transformations de mod` eles de l’IDM pour g´ en´ erer la com- mande et l’interface de supervision ` a partir d’un mod` ele m´ etier (fourni par un m´ ecanicien) et d’une biblioth` eque d’´ el´ ements. Le mod` ele m´ etier est un sch´ ema P&ID (Pi- ping & Instrumentation Diagram) d´ ecrivant le syst` eme physique. Un ´ el´ ement est d´ efini comme l’unit´ e constitutive du proc´ ed´ e du syst` eme. Il peut ˆ etre relatif ` a du mat´ eriel (vanne, pompe ...) ou ` a des fonctionnalit´ es du syst` eme.

Chaque ´ el´ ement de la biblioth` eque contient plusieurs vues.

Le concept de vue est ici une extension de celui utilis´ e par Lallican [9], il correspond aux diff´ erents points de vues des concepteurs.

D’autres travaux concernent la g´ en´ eration conjointe de code de commande et de mod` eles de simulation. On peut citer ` a ce sujet les travaux de Lallican [9] sur les syst` emes transitiques, puis ´ etendus par B´ evan [2] aux syst` emes transitiques reconfigurables. La g´ en´ eration se fait ` a par- tir d’une description du syst` eme, exprim´ ee dans un lan- gage sp´ ecifique au domaine (DSL) et d’une biblioth` eque de composants (au sens de Lallican). Les vues parties op´ eratives des composants sont utilis´ ees pour obtenir, par transformation de mod` ele, le mod` ele de simulation de la partie op´ erative du syst` eme transitique. Ce dernier est ex´ ecutable sur le simulateur SimSED. A noter que la simu- lation conjointe de la commande et de la partie op´ erative est utilis´ ee pour v´ erifier le code de commande g´ en´ er´ e.

Adam, dans ses travaux [1], g´ en` ere un observateur bas´ e sur un simulateur ` a ´ ev´ enement discret. Cet observateur a pour but de fournir, au syst` eme d’Aide ` a la D´ ecision, l’´ etat du syst` eme de production. A partir d’un mˆ eme mod` ele du syst` eme, est g´ en´ er´ e conjointement la commande et l’ob- servateur. Dans le cadre de la g´ en´ eration automatique de mod` eles de simulation, il est fait ´ etat que la g´ en´ eration passe g´ en´ eralement par l’utilisation d’une biblioth` eque de mod` eles de simulation ´ el´ ementaires [1] qui sont ensuite ins- tanci´ es et param´ etr´ es. L’avantage est que la g´ en´ eration s’en trouve facilit´ ee et cela permet une capitalisation de

la connaissance, et la r´ eutilisation. De plus, les donn´ ees d’entr´ ees sont le plus souvent sous forme de mod` eles UML transform´ es ensuite en mod` ele de simulation. Dans les tra- vaux de El Haouzi [6], l’impl´ ementation d’une plate-forme de simulation g´ en´ erique est faite ` a partir d’un mod` ele de connaissance en UML. Une instanciation de la plate-forme g´ en´ erique permet d’obtenir la plate-forme de simulation pour un syst` eme particulier. Le logiciel ARENA est utilis´ e pour la simulation. On peut aussi avoir des mod` eles SysML.

Comme par exemple dans [7] o` u le diagramme d’activit´ e est transform´ e en R´ eseau de Petri puis transform´ e en VHDL- AMS pour ˆ etre ex´ ecut´ e sur le logiciel System Vision. Dans le domaine de l’´ electronique, on peut citer les travaux de Sarmento [16] o` u il est g´ en´ er´ e le mod` ele de simulation glo- bal d’un syst` eme h´ et´ erog` ene embarqu´ e afin de valider le syst` eme. Pour ce faire la co-simulation est utilis´ ee.

De fa¸ con g´ en´ erale, on distingue dans les m´ ethodes de mod´ elisation pour la simulation bas´ ee sur l’IDM, deux ap- proches : l’une bas´ ee sur un langage unifi´ e, l’autre sur un langage sp´ ecifique au domaine [10]. Cependant, l’utilisa- tion d’un mod` ele UML (ou SysML) ne semble pas per- tinent dans le cadre de l’outil Anaxagore. Cela deman- derait aux experts de d´ evelopper un nouveau mod` ele du syst` eme. Il semble plus judicieux de r´ eutiliser les mod` eles m´ etiers r´ ealis´ es pour la conception du syst` eme, sans rajou- ter une charge de travail suppl´ ementaire aux concepteurs.

De plus, comme dans les travaux de B´ evan et d’Adam, la biblioth` eque utilis´ ee est bas´ ee sur le concept de vue. De ce fait, il apparaˆıt envisageable de rajouter ` a la g´ en´ eration conjointe de la commande et de l’IHM de supervision, celles des mod` eles de simulation.

L’int´ erˆ et de notre d´ emarche (Fig.1) est d’enrichir le flot d´ ej` a existant de l’outil Anaxagore en y int´ egrant la g´ en´ eration des mod` eles de simulation. La simulation per- mettra d’effectuer des v´ erifications au plus tˆ ot. C’est-` a-dire que l’on cherche ` a utiliser la simulation non seulement sur les mod` eles de sorties, mais aussi sur leurs mod` eles in- term´ ediaires.

Fig. 1. Place de la simulation dans le flot de conception

Contrairement aux syst` emes de production, les syst` emes

de gestion de fluide embarqu´ es n´ ecessitent de mod´ eliser non

seulement le comportement de la partie op´ erative, mais

aussi celle du fluide. En vue d’obtenir des repr´ esentations

g´ en´ eriques, il semble judicieux de dissocier ces deux mod´ eli-

sations, notamment par rapport ` a la r´ eutilisation des

mod` eles [16]. En effet, le comportement d’un ´ el´ ement de la

partie op´ erative n’est pas d´ ependant du fluide. Par contre

les effets de la partie op´ erative sur le fluide sont li´ es ` a sa nature. Comme il convient de simuler ` a la fois le compor- tement de la partie op´ erative et celle du fluide, il faudra structurer les mod` eles de simulation associ´ es ` a la partie op´ erative et au fluide.

III. Approche retenue en vue d’une g´ en´ eration automatique de mod` eles de simulation L’int´ erˆ et de simuler le comportement du proc´ ed´ e est de pouvoir effectuer des v´ erifications dynamiques. Les diff´ erentes interactions entre l’IHM de supervision, la partie de contrˆ ole/commande et la simulation sont sch´ ematis´ ees sur la Fig.2.

Des v´ erifications peuvent concerner l’aide ` a la d´ ecision et la surveillance. Par exemple, on peut chercher ` a ´ evaluer au niveau de l’IHM, si les informations disponibles sont n´ ecessaires et suffisantes, ou bien s’int´ eresser au syst` eme d’alarmes (au niveau du contrˆ ole/commande ou de l’IHM).

En effet, des alarmes peuvent ˆ etre distinctes lorsqu’elles sont transmises ` a l’IHM de supervision, mais ne pas ˆ etre affich´ ees comme telle sur l’IHM. De plus, il ne faut pas que des alarmes contradictoires puissent ˆ etre actives en mˆ eme temps. D’autres v´ erifications peuvent concerner l’adapta- tion du syst` eme face aux al´ eas, ou encore s’int´ eresser aux commandes de haut niveau.

Fig. 2. Sch´ ema des interactions

Cette v´ erification d’exigences fonctionnelles n´ ecessite de mod´ eliser le comportement de la partie op´ erative d’une part, et l’´ evolution du comportement du fluide d’autre part.

Cependant, notre approche est utilis´ ee en tout d´ ebut de conception (le syst` eme physique n’est donc pas encore fig´ e).

Il en r´ esulte un manque consid´ erable de donn´ ees quanti- tatives, ne permettant pas de mod´ eliser finement le com- portement du fluide. Par exemple, les dimensions r´ eelles des canalisations sont inconnues. De ce fait, il n’apparaˆıt pas pertinent de s’int´ eresser ` a des exigences quantitatives telle que la qualit´ e de service. L’objectif de la simulation est donc de v´ erifier qualitativement des exigences fonction- nelles sur des proc´ ed´ es de gestion de fluide.

A. Structuration des mod` eles de Simulation

On propose de structurer les mod` eles de simulation en trois niveaux (Fig.3). Le Niveau Composant correspond

`

a la mod´ elisation du comportement des ´ el´ ements com- mand´ es (partie op´ erative) et de l’instrumentation. Le Ni- veau Contextualisation correspond ` a la contextualisation

des effets des op´ erations sur le fluide. Enfin, un Niveau Syst` eme, contient les r` egles d’´ evolution de l’environnement.

Fig. 3. Sch´ ema des interactions entre IHM, Commande et Simulation du proc´ ed´ e

Les ´ echanges d’informations entre partie commande et partie simulation se font entre le Niveau El´ ´ ementaire de la partie commande et le Niveau Composant de la partie simulation.

Les ´ echanges d’informations internes ` a la partie simula- tion sont multiples. En effet le Niveau syst` eme, en fonc- tion de l’´ etat de la partie op´ erative (Niveau Composant ) et du fluide (Niveau contextualisation), fait une mise ` a jour des informations du Niveau Contextualisation. Ces infor- mations concernent essentiellement les r` egles de propaga- tion de l’´ evolution du fluide. Le Niveau Contextualisation, quant ` a lui, renvoie des informations destin´ ees ` a l’instru- mentation au Niveau Composant. Enfin, le Niveau Compo- sant retourne les informations sur les capteurs et les me- sures ` a la partie commande.

B. Illustration sur un cas d’´ etude

Le cas d’´ etude retenu a ´ et´ e simplifi´ e ici pour des rai- sons de place, mais reste n´ eanmoins repr´ esentatif des effets existant sur un syst` eme auxiliaire global.

Le syst` eme pr´ esent´ e sur la Fig.4 est constitu´ e de deux soutes (St1 et St2) s´ epar´ ees par une vanne motoris´ ee ` a deux voies (VM1). La soute St2 est reli´ ee ` a une vanne motoris´ ee (VM2). Chaque vanne est constitu´ ee d’un capteur de fin de course d’ouverture (FcO) et de fermeture (FcF).

Fig. 4. Sch´ ema du cas d’´ etude

L’illustration se fera en utilisant les mod` eles de simula- tion ex´ ecutables, exprim´ es avec des langages de program- mation de la norme IEC 61131-3. Ainsi les Niveaux Com- posant et Contextualisation sont r´ ealis´ es en langage FBD (Function Block Diagram), le Niveau Syst` eme quant ` a lui est en langage ST (Structured Text).

Le Niveau 1 (Fig.5), dit de Composant, correspond ` a la

mod´ elisation du comportement des deux vannes (VM1 et

VM2 ). Les entr´ ees Def FcO et Def FcF du bloc fonction-

nel Simu VM permettent l’introduction de d´ efauts sur les

capteurs de fin de course. Les commandes d’ouverture et

de fermeture sont CmdO et CmdF. Les sorties Ouverte et

Fermee correspondent ` a la position de la vanne (ouverte

ou ferm´ ee). Enfin FcO et FcF correspondent aux valeurs des capteurs de fin de course qui sont envoy´ ees ` a la partie commande. Lorsqu’il n’y a pas d’introduction de d´ efauts, FcO (respectivement FcF) a la mˆ eme valeur que Ouverte (respectivement Fermee).

Fig. 5. Impl´ ementation du Niveau composant en FBD

L’´ evolution des changements de positions de la vanne (et par cons´ equent, l’´ evolution des valeurs des variables Ouverte et Fermee) peut ˆ etre mod´ elis´ ee par R´ eseau de Pe- tri (Fig.6).

Fig. 6. RdP mod´ elisant le comportement de la vanne

L’hypoth` ese a ´ et´ e faite que la prise en compte d’une com- mande d’ouverture ou fermeture se fait uniquement lorsque la vanne est en position ferm´ ee ou ouverte. Le marquage du R´ eseau de Petri sur la Fig.6, signifie que la vanne est dans la position ferm´ ee. La transition t1 est sensibilis´ ee d` es lors que la place p3 est marqu´ ee. La condition associ´ ee au franchissement de cette transition est donc toujours vraie (il en va de mˆ eme pour la transition t9). Une fois cette transition franchie, la place p0 devient marqu´ ee. La vanne est alors en attente d’une commande d’ouverture ou fer- meture. Lors d’une commande de fermeture, la transition t0 est franchie. La place p1 re¸ coit le jeton de la place p0.

La vanne ´ etant d´ ej` a en position ferm´ ee, les transitions t4 puis t1 sont franchies. La place p0 est ` a nouveau marqu´ ee.

Lors d’une commande d’ouverture, la transition t5 est fran- chie. La vanne n’´ etant pas d´ ej` a ouverte, la transition t6 est franchie. La place p5 devient alors marqu´ ee. La vanne commen¸ cant sa phase d’ouverture, elle quitte sa position ferm´ ee. A la fin du temps de manoeuvre, elle se retrouve en position ouverte, la place p6 devient ainsi marqu´ ee.

Le Niveau 2 (Fig.8), dit de Contextualisation, pr´ esente la mod´ elisation des effets de l’´ etat des vannes sur le fluide, ainsi que la mod´ elisation du fluide (ici de l’eau) dans les

soutes. En d’autres termes, on mod´ elise le fait qu’une vanne laisse passer ou non le d´ ebit de fluide (bloc fonctionnel Eau VM), et l’´ evolution du niveau de fluide dans les soutes (bloc fonctionnel Eau St).

En s’inspirant de la mod´ elisation sous forme d’activit´ e des travaux de [4], on peut mod´ eliser les effets sur le fluide (Fig.7). Par exemple, une vanne pourrait avoir deux acti- vit´ es : laissez passer le fluide et empˆ echer le fluide de passer.

Fig. 7. Mod´ elisation sous forme d’activit´ e, application pour l’activit´ e laisser passer le fluide d’une vanne

Pour qu’une activit´ e d´ ebute, il faut que toutes les condi- tions n´ ecessaires soient remplies. Par cons´ equent, une fois que toutes les places correspondant ` a ces conditions sont marqu´ ees, la transition Td est franchie, l’activit´ e com- mence. La transition Tf sera franchie, lorsque les conditions pour effectuer l’activit´ e ne sont plus remplies, ce sera donc la fin de l’activit´ e.

Fig. 8. Impl´ ementation du Niveau2 de simulation en FBD

Les entr´ ees du bloc fonctionnel Eau VM sont :

Debit Entrant et VM ouverte. Le premier correspond

au d´ ebit de fluide entrant dans la vanne, et le second

au fait que la vanne est ouverte. La sortie du bloc

fonctionnel, Debit Sortant, correspond au d´ ebit sortant

de la vanne. Ainsi lorsque VM ouverte = TRUE, le d´ ebit

en sortie de la vanne est le mˆ eme que celui en entr´ ee

(si l’on n´ eglige la perte de charge). Au contraire, si

VM ouverte = FALSE alors le d´ ebit sortant de la vanne

sera nul (Debit sortant = 0). Les entr´ ees du bloc fonc- tionnel Eau St sont : Debit entrant et debit sortie. Le premier correspond au d´ ebit de fluide arrivant dans la soute, et le second au fait qu’il y ait un d´ ebit sortant de la soute ou non. En effet, la pr´ esence ou non d’un d´ ebit sor- tant de la soute est li´ e, en plus du niveau de fluide stock´ e,

`

a l’architecture du syst` eme. Les sorties du bloc fonctionnel sont Debit sortant et Niveau St. Le premier correspond au d´ ebit qui sort de la soute, et le second au niveau de fluide dans la soute. Ainsi la soute se remplira (augmen- tation du niveau du fluide) lorsqu’il y a uniquement un d´ ebit en entr´ ee de la soute (c’est-` a-dire que debit sortie aura pour valeur FALSE et Debit entrant aura une valeur non nulle). La soute se videra lorsqu’il y a uniquement un d´ ebit sortant de la soute (et que le niveau de fluide est suffisant). C’est-` a-dire quand Debit entrant aura une va- leur nulle et debit sortie aura la valeur TRUE. Dans le cas o` u la soute serait remplie et vid´ ee en mˆ eme temps (bras- sage d’une soute), alors Debit entrant aura une valeur non nulle et debit sortie aura la valeur TRUE. Le niveau dans la soute sera constant si le d´ ebit de remplissage est le mˆ eme que celui de vidage.

Le Niveau 3 (Fig.9), dit syst` eme, repr´ esente les r` egles de propagations du comportement du fluide. En effet, c’est ` a ce niveau que les liens entre les diff´ erents blocs fonction- nels du Niveau contextualisation seront effectu´ es. Dans cet exemple, les ´ echanges d’informations entre les diff´ erents ni- veaux de simulation, sont r´ ealis´ es ` a l’aide de variables glo- bales.

Fig. 9. Exemple d’impl´ ementation du Niveau syst` eme en ST

On consid` ere dans cet exemple, qu’une vanne est ouverte, d` es lors qu’elle n’est pas en position ferm´ ee. Ceci donnera lieu ` a une premi` ere r` egle de simulation.

R` egle 1 :

Affectation des valeurs d’entr´ ee du param` etre VM ouverte des instances des blocs fonctionnels Eau VM.

Ainsi, il est n´ ecessaire de connaˆıtre et de r´ ecup´ erer les in- formations concernant la position d’ouverture des vannes (obtenues dans le Niveau Composant). Elles sont dispo- nibles ` a travers les variables VM1 posOuverte (pour la vanne VM1) et VM2 posOuverte (pour VM2). L’affecta- tion des valeurs d’entr´ ee du param` etre VM ouverte (dans le Niveau Contextualisation) se fait ` a l’aide des variables VM1 ouverte et VM2 ouverte, qui prennent ici la valeur des variables VM1 posOuverte et VM2 posOuverte.

Au vu de l’architecture du proc´ ed´ e, il va falloir prendre en compte le ph´ enom` ene des vases communicants (le ni- veau dans les soutes tendant naturellement ` a s’´ equilibrer).

Ainsi la pr´ esence ou non d’un d´ ebit sortant de la soute St1 est non seulement li´ ee ` a l’´ etat de la vanne VM1 mais aussi au niveau d’eau dans les deux soutes. En effet, mˆ eme si la vanne VM1 est ouverte, lorsque la soute St2 se sera rem- plie au mˆ eme niveau que la soute St1 alors le d´ ebit sortant de celle-ci sera nul. Ce qui donne lieu ` a une deuxi` eme r` egle de simulation.

R` egle 2 :

Affectation de la valeur d’entr´ ee de debit sortie de l’ins- tance St1 du bloc fonctionnel Eau St.

Ainsi, debit sortie vaut True lorsque la vanne VM1 est ouverte (d’apr` es la r` egle 1) et que le niveau dans la soute (Niveau St) est sup´ erieur ` a celui de la soute St2.

Dans le cas contraire debit sortie vaut False. L’infor- mation concernant le niveau dans les soutes est fait par l’interm´ ediaire des variables St1 niveau et St2 niveau.

L’affectation de la valeur d’entr´ ee debit sortie de l’ins- tance St1 (Niveau Contextualisation), se fait par la variable St1 PresDebitS. Concernant la soute St2, la pr´ esence ou non d’un d´ ebit sortant de la soute est directement li´ ee au fait que la vanne VM2 soit ouverte ou non, et qu’il reste ou non de l’eau dans cette soute. On aura donc une troisi` eme r` egle de simulation.

R` egle 3 :

Affectation de la valeur d’entr´ ee de debit sortie de l’ins- tance St2 du bloc fonctionnel Eau St. debit sortie vaut True lorsque la vanne VM2 est ouverte (d’apr` es la r` egle 1), et que le niveau dans la soute (Niveau St) est non nul.

Enfin, il reste ` a connecter les d´ ebits sortant et entrant des diff´ erentes instances des blocs fonctionnels Eau VM et Eau St pour mod´ eliser l’´ ecoulement du fluide.

R` egle 4 :

Propagation des d´ ebits entre les diff´ erents composants.

Ainsi, le d´ ebit sortant de la soute St1 (variable St1 debitS) ´ etant reli´ e au d´ ebit entrant dans la vanne VM1, la variable VM1 debitE sera affect´ ee de la valeur de St1 debitS. Le d´ ebit sortant de cette mˆ eme vanne est reli´ e au d´ ebit entrant dans la soute St2. La variable St2 debitE sera donc affect´ ee par la valeur de VM1 debitS. Enfin, le d´ ebit sortant de la soute St2 ´ etant reli´ e au d´ ebit entrant dans la vanne VM2, VM1 debitE sera donc affect´ ee par la valeur de St2 debitS.

Les interactions entre les diff´ erents niveaux de simula- tion sont illustr´ ees en partie sur la Fig.10. On y voit la r´ ecup´ eration de l’´ etat du proc´ ed´ e (partie op´ erative et du fluide) par le Niveau Syst` eme, qui apr` es ´ evaluation des r` egles de simulation, met ` a jour les variables du niveau Contextualisation. Pour plus de clart´ e, seule la soute St1 et la vanne VM1 ont ´ et´ e repr´ esent´ ees. Pour la mˆ eme raison, l’ordre potentiel d’´ evaluation des r` egles de simulation, et la synchronisation des mises ` a jour des variables d’entr´ ee d’un mˆ eme bloc n’ont pas ´ et´ e repr´ esent´ es. De mˆ eme, l’instru- mentation ne figurant pas dans le cas d’´ etude, la transmis- sion des informations du Niveau Contextualisation destin´ ee

`

a l’instrumentation n’est pas repr´ esent´ ee.

Fig. 10. Illustration des interactions entre les niveaux de simulation

IV. Discussion : Perspective d’int´ egration dans le flot de conception de l’outil Anaxagore En reprenant le concept de biblioth` eque de simulation, la biblioth` eque d’´ el´ ements standards de l’outil Anaxagore pourrait ˆ etre enrichie par une vue de simulation. Cette vue de simulation contiendrait les mod` eles des Niveau Com- posant et Contextualisation (Niveau 1 et 2). Cela permet- trait ainsi de pouvoir g´ en´ erer, pour ces niveaux, les mod` eles de simulation du proc´ ed´ e. Un param´ etrage sera cependant n´ ecessaire. Le Niveau 3 paraˆıt quant-` a-lui, pour l’instant, difficilement enti` erement automatisable en l’´ etat. En effet, les donn´ ees (ou informations) n´ ecessaires ne sont que tr` es peu formalis´ ees.

Au vu du principal objectif de l’outil cherchant ` a li- miter le temps pass´ e ` a faire des sp´ ecifications, il n’est pas forc´ ement judicieux de chercher ` a formaliser toute la connaissance du syst` eme que poss` edent les experts. Une alternative, pour faciliter l’impl´ ementation du Niveau 3, consisterait ` a fournir une biblioth` eque de r` egles de simula- tion. L’expert choisirait les r` egles de simulation n´ ecessaire pour le proc´ ed´ e ` a simuler, qu’il param´ etrerait ensuite, ainsi que leur ordre d’´ evaluation.

Toutefois certaines r` egles sont automatisables, comme celle concernant la propagation des d´ ebits. Les informations n´ ecessaires sont d´ ej` a formalis´ ees. Elles sont d’ailleurs uti- lis´ ees pour g´ en´ erer les animations de propagation du fluide sur l’IHM de supervision.

V. Conclusion

Cette proposition de structuration apporte une m´ ethode de construction des mod` eles de simulation, en vue de la g´ en´ eration automatique d’un prototype virtuel de proc´ ed´ e de gestion de fluide. La dissociation de la partie op´ erative et du comportement de fluide permet une mod´ elisation modu- laire, avec diff´ erents niveaux d’abstraction possibles. Ainsi, en fonction du besoin, on peut affiner la finesse de reproduc- tion du comportement du fluide, sans pour autant devoir modifier celle de la partie op´ erative (et r´ eciproquement).

La mod´ elisation sous forme de RdP semble ˆ etre une piste

int´ eressante pour introduire la validation et la v´ erification des mod` eles de simulation.

L’utilisation de la simulation, en fin du flot de concep- tion, devrait permettre d’effectuer les v´ erifications sur le syst` eme complet et de valider l’interface de supervision aupr` es du client. En allant plus loin, cela permettrait de r´ ealiser des tests utilisateurs ou encore de former les futurs utilisateurs du syst` eme.

Une mise en pratique de cette approche est en cours de r´ ealisation, sur le mˆ eme principe que le cas d’´ etude pr´ esent´ e, afin de r´ ealiser un prototypage rapide d’un syst` eme de production, stockage, et distribution d’eau douce embarqu´ e sur un navire.

R´ ef´ erences

[1] Adam M., Cardin O., Berruet P., et Castagna P. Proposal of an Approach to Automate the Generation of a Transitic System’s Observer and Decision Support using Model Driven Engineering.

IFAC World Congress, Milan, Italie, 28 Aoˆ ut au 2 Septembre 2011.

[2] B´ evan R. Approche composant pour la commande multi-versions des syst` emes transitiques reconfigurables. Th` ese de doctorat de l’Universit´ e de Bretagne-Sud, 9 D´ ecembre 2013.

[3] Bignon A., Rossi A. et Berruet P. An integrated design flow for the joint generation of control and interfaces from a business model. Computer in Industry, vol. 64, n

6, pp 634–649, 2013.

[4] Combacau M., Courvoisier M. Process failures diagnosis in FMS real-time control : an approach combining rule-based systems and Petri nets. The Second Annual Conference on AI, Simulation and Planing in High Autonomy Systems, Cocoa Beach, FL, Etat- Unis. 1–2 Avril 1991.

[5] Combemale B. Ing´ enierie Dirig´ ee par les Mod` eles (IDM) – ´ Etat de l’art. 2008.

[6] El Haouzi H., Pannequin R., Thomas A. G´ en´ eration automa- tique de plateformes de simulation pour des syst` emes organis´ es en flux tir´ es. 7e Congr` es International de G´ enie Industriel, Trois Rivi` eres, Canada, 5–8 juin 2007.

[7] Foures D., Albert V., Pascal J-C. et Nketsa A. Automation of SysML activity diagram simulation with model-driven enginee- ring approach. Symposium on Theory of Modeling and Simula- tion - DEVS Integrative M&S Symposium, Orlando, FL, Etat- Unis, 26–29 Mars 2012.

[8] Goubali O., Bignon A., Berruet P., Girard P. et Guittet L.

Anaxagore, an exemple of model-driven engineering for indus- trial supervision. Ergonomie et Informatique Avanc´ ee Confe- rence, Ergo’IA, Fance, 15–17 octobre 2014.

[9] Lallican J. L. Proposition d’une approche composant pour la conception de la commande des syst` emes transitiques. Th` ese de doctorat de l’Universit´ e de Bretagne-Sud, 12 D´ ecembre 2007.

[10] Li X., Lei Y., Wang W., Wang W. et Zhu Y. A DSM-based multi-paradigm simulation modeling approach for complex sys- tems. 2013 Winter Simulation Conference, Washington, DC., Etat-Unis, 8–11 D´ ecembre 2013.

[11] Kennedy A, Carter K., Frank W., et Architects D. MDA Guide Version 1.0, 2003.

[12] Pritsker A.A.B., Henriksen J.O, Fishwick P.A. et Clark G.M.

Principles of modeling. 1991 Winter Simulation Conference, Phoenix, AZ, Etat-Unis, 8–11 D´ ecembre 1991.

[13] Ray C. ATLAS, une plate-forme pour la mod´ elisation et la simu- lation de syst` eme d´ esagr´ eg´ es. Th` ese de doctorat de l’Universit´ e de Rennes I, 19 Septembre 2003.

[14] Robinson S., Nance R.E., Paul R.J., Pidd M. et Taylor S.J.E.

Simulation model reuse : definitions, benefits and obstacles. Si- mulation Model Practice Theory, vol. 12, n

7–8, pp.479–494, 2004.

[15] Rochet S. Formalisation des Processus de l’Ing´ enierie Syst` eme : Proposition d’une m´ ethode d’adaptation des processus g´ en´ eriques ` a diff´ erents contextes d’application. Th` ese de doctorat de l’Universit´ e de Paul Sabatier – Toulouse III, 26 Novembre 2007

[16] Sarmento A. G´ en´ eration Automatique de Mod` eles de Simulation

pour la Validation de Syst` emes H´ et´ erog` enes Embarqu´ e. Th` ese

de doctorat de l’Universit´ e Joseph Fournier – Grenoble I, 28

Octobre 2005.