IMOCA : une architecture à base de modes de fonctionnement pour une application de contrôle dans un environnement incertain

HAL Id: hal-01102659

https://hal.univ-brest.fr/hal-01102659

Submitted on 13 Jan 2015

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.

IMOCA : une architecture à base de modes de fonctionnement pour une application de contrôle dans

un environnement incertain

Goulven Guillou, Jean-Philippe Babau

To cite this version:

Goulven Guillou, Jean-Philippe Babau. IMOCA : une architecture à base de modes de fonctionnement

pour une application de contrôle dans un environnement incertain. CAL 2013. 7ième conférence

francophone sur les architectures logicielles., May 2013, Toulouse, France. �hal-01102659�

IMOCA : une architecture à base de modes de

fonctionnement pour une application de contrôle dans un environnement incertain

G. Guillou

Lab-STICC/UMR 6285, UBO, UEB 20 Avenue Le Gorgeu

29200 Brest, France

goulven.guillou@univ-brest.fr

J.P. Babau

Lab-STICC/UMR 6285, UBO, UEB 20 Avenue Le Gorgeu

29200 Brest, France

jean-philippe.babau@univ-brest.fr

Résumé

Les syst` emes de contrˆ ole de processus par r´ egulation font intervenir plusieurs modes de fonctionnement (lois de com- mandes) en fonction du contexte. Dans un environnement naturel fortement perturb´ e, il est alors n´ ecessaire de r´ e- pondre aux trois questions suivantes vis-` a-vis des modes de fonctionnement :

1. Quels sont les modes de fonctionnement pertinents ? 2. Comment enchaˆıner plusieurs modes ?

3. Comment param´ etrer les modes ?

Pour r´ epondre ` a ces questions, l’approche propos´ ee s’appuie sur une architecture logicielle et une m´ ethodologie ´ epaul´ ees par des outils de simulation et de mise au point incr´ emen- tale par essais/corrections. Le choix des modes de fonction- nement, la mani` ere de les enchaˆıner et de les param´ etrer reposent sur une expertise. Les diff´ erents modes (lois de commande) sont associ´ es ` a des contextes c’est-` a-dire ` a des

´ etats de l’environnement. L’enchaˆınement des lois de com- mande s’effectue par commutation et est g´ er´ e par un auto- mate. Enfin les diff´ erents param` etres des modes d´ ependent du contexte et sont tabul´ es. L’architecture pr´ esent´ ee est ind´ ependante des technologies des capteurs et des action- neurs (interaction avec l’environnement). La partie contrˆ ole est compos´ ee de trois contrˆ oleurs dits r´ eactif, expert et adaptatif fonctionnant de mani` ere parall` ele et asynchrone.

Le contrˆ oleur r´ eactif est charg´ e de l’application temps r´ eel d’une loi de commande choisie par le contrˆ oleur expert et param´ etr´ ee par le contrˆ oleur adaptatif.

L’approche est valid´ ee sur le pilotage automatique d’un voi- lier en s’appuyant sur un environnement virtuel pour la si- mulation.

Mots Clef

Architecture, contrˆ ole, adaptation, contexte, modes

1. INTRODUCTION

Les syst` emes de contrˆ ole de processus sont de plus en plus utilis´ es pour assister l’activit´ e humaine, y compris dans des environnements incertains. Dans ce contexte, disposer d’ou- tils d’aide au d´ eveloppement et de simulation devient cru- cial. Un syst` eme de contrˆ ole utilise des capteurs pour obtenir des informations sur le processus ` a contrˆ oler ainsi que sur son environnement physique (voir figure 1). D’autre part, des actionneurs permettent d’appliquer les commandes d´ e- termin´ ees par le syst` eme de contrˆ ole. De tels syst` emes sont souvent sp´ ecifiques ` a chaque domaine, voire ` a chaque pro- cessus ` a cause des contraintes li´ ees ` a l’environnement ainsi que celles li´ ees aux mat´ eriels eux-mˆ emes. Ils sont donc sou- vent d´ evelopp´ es au cas par cas, ce qui pose des probl` emes de mise au point et au final de d´ eploiement. Les m´ ethodes

Processus à contrôler Environnement

physique

Actionneurs Commandes

Données

Contrôleur Capteurs

Environnement Cible Contrôle

Figure 1: Syst` eme de contrˆ ole

orient´ ees objets et, plus r´ ecemment, l’ing´ enierie dirig´ ee par les mod` eles (IDM [2, 20]) offrent un cadre pour la maˆıtrise du d´ eveloppement de ce type d’applications. En particulier, l’architecture dirig´ ee par les mod` eles (MDA pour Model Dri- ven Architecture [17]) se concentre plus particuli` erement sur la s´ eparation des probl` emes en proposant trois mod` eles ap- pel´ es PIM

, PM

et PSM

. Par la suite on appellera en- vironnement le processus ainsi que son environnement phy- sique.

Dans ce contexte, l’architecture IMOCA (pour archItecture for MOde Control Adaptation) se focalise sur les syst` emes de contrˆ ole de processus dans un environnement naturel per- turb´ e o` u l’int´ egrit´ e physique du processus peut ˆ etre remise en cause. Les avions, les engins spatiaux, les v´ ehicules ter- restres ou lunaires, les bateaux ou encore les drones sont des exemples typiques de cette cat´ egorie de processus.

1. Platform Independent Model 2. Platform Model

3. Platform Specific Model

Dans ces syst` emes, les lois de contrˆ ole font intervenir plu- sieurs modes de fonctionnement ou lois de commande soit parce que plusieurs actionneurs sont pr´ esents (pour mou- voir un bras articul´ e et entraˆıner des roues par exemple) soit parce qu’il est important de pouvoir agir de diff´ erentes mani` eres sur un mˆ eme actionneur (ne serait-ce que pour passer d’un ´ etat de marche ` a un ´ etat d’arrˆ et par exemple).

Dans la pratique peu d’entre eux s’av` erent utilisables, ce qui n´ ecessite de r´ epondre aux trois questions suivantes :

1. Quels sont les modes de fonctionnement pertinents ? 2. Comment enchaˆıner plusieurs modes ?

3. Comment param´ etrer les modes ?

Ce document pr´ esente comment int´ egrer, dans une approche MDA avec l’architecture IMOCA, les sp´ ecificit´ es d’un sys- t` eme de contrˆ ole tout en r´ epondant ` a ces trois questions.

L’architecture IMOCA, parce qu’il est important de s´ eparer l’application de contrˆ ole du processus lui-mˆ eme, est bas´ ee sur trois couches appel´ ees cible, interpr´ etation et contrˆ ole.

Le contrˆ oleur est lui-mˆ eme compos´ e de trois contrˆ oleurs dits r´ eactif, expert et adaptatif fonctionnant de mani` ere pa- rall` ele et asynchrone. Le contrˆ oleur r´ eactif est charg´ e de l’ap- plication temps r´ eel d’une loi de commande choisie par le contrˆ oleur expert et param` etr´ ee par le contrˆ oleur adaptatif.

La suite de ce document est organis´ ee comme suit : apr` es une pr´ esentation de l’´ etat de l’art, l’architecture IMOCA est d´ ecrite en d´ etail puis une m´ ethodologie destin´ ee ` a aider le concepteur du syst` eme de contrˆ ole ` a choisir, combiner et param´ etrer les modes est fournie. Enfin, en guise de valida- tion, une solution pour le cas du pilotage automatique des voiliers est d´ evelopp´ ee conform´ ement ` a la m´ ethodologie et ` a l’architecture pr´ esent´ ees.

2. ETAT DE L’ART

IMOCA est une architecture [5] pour d´ ecomposer un sys- t` eme en sous-syst` emes en offrant des outils conceptuels pour la maˆıtrise (mise au point) de chaque partie. De ce fait, IMOCA int` egre divers paradigmes existants, vus comme des briques de base conceptuelles pour l’architecture. D’abord, une s´ eparation claire est propos´ ee entre la plateforme (la cible qui correspond ` a la plateforme r´ eelle) et l’application (le contrˆ ole qui s’appuie sur une plateforme abstraite). On reprend ici le paradigme MDA [17, 7] et plus pr´ ecis´ ement le style architectural SAIA [8] o` u les entr´ ees/sorties de haut- niveau (les donn´ ees du contrˆ ole) sont s´ epar´ ees des donn´ ees de bas niveau (le monde vu au travers des capteurs/ action- neurs) [16]. Cette derni` ere vue correspond ` a une plateforme abstraite explicite [14]. Au niveau du contrˆ ole, IMOCA in- troduit plusieurs niveaux ` a travers divers contrˆ oleurs [13]

pour permettre une adaptation au contexte. La politique d’adaptation est de type Model Reference Adaptive Control [4] en s’appuyant sur une observation de l’environnement et une expertise du contrˆ ole pour assurer une robustesse dans le comportement adaptatif. Le contrˆ ole s’appuie lui sur des modes de fonctionnement param´ etrables. Les modes de fonctionnement sont classiques dans les applications de contrˆ ole [18, 9]. Ils permettent via des automates (le contrˆ o- leur expert) de d´ efinir une politique d’adaptation en fonc- tion d’´ ev´ enements (ici des ´ ev´ enements externes ou des chan- gements d´ etect´ es dans l’environnement). IMOCA introduit une autre capacit´ e d’adaptation via l’adaptation des para- m` etres des politiques de contrˆ ole. Cette adaptation est li´ ee

au contexte et est pr´ e-tabul´ ee comme dans de nombreux sys- t` emes embarqu´ es via des look-up tables [10], essentiellement pour des raisons de performance et de pr´ edictibilit´ e. Il existe beaucoup de travaux concernant les modes dans les architec- tures, par exemple dans AADL. Ces travaux apportent soit des outils de formalisation ` a base d’automates, par exemple des r´ eseaux de Petri temporis´ es, pour la validation du com- portement (absence de deadlock, comportement temporel) des syst` emes comme dans [1] ; soit des outils de gestion de la reconfiguration des modes ` a l’ex´ ecution comme dans [3].

Pour sa part, IMOCA s’int´ eresse ` a l’aide ` a la mise en place (choix et mise au point) des modes en se concentrant sur l’aspect applicatif (qualit´ e de contrˆ ole). IMOCA est com- pl´ ementaire de ces approches. L’originalit´ e d’IMOCA est de proposer un composant de mise au point des tables pour le contrˆ ole [15] par simulation via une interface d´ edi´ ee. En- fin, l’utilisation de mod` eles [20] permet de se concentrer sur les donn´ ees du probl` eme pour g´ en´ erer l’application et son environnement de mise au point.

3. ARCHITECTURE IMOCA

3.1 Principes de l’architecture IMOCA

L’architecture IMOCA est bas´ ee sur SAIA [7] qui est elle- mˆ eme une approche MDA pour permettre le d´ eveloppement d’un syst` eme de contrˆ ole de processus ind´ ependamment d’une technologie de capteurs et d’actionneurs. Cette ind´ ependance est primordiale pour limiter l’impact sur l’application d’un changement de capteur ou d’actionneur. En effet, dans un environnement fortement perturb´ e, c’est-` a-dire soumis ` a de rapides et importantes variations (temp´ erature, pression, ac- c´ el´ eration ...) les pannes peuvent ˆ etre courantes. De plus, dans un contexte ´ economique concurrentiel, les optimisa- tions de mat´ eriel sont incessantes. L’architecture IMOCA pr´ esent´ ee figure 2 est constitu´ ee de trois couches dites Cible, Interpr´ etation et Contr^ ole. La cible est un mod` ele de la plateforme mat´ erielle et le contr^ ole utilise une vue id´ eale de l’environnement, les donn´ ees, pour prendre des d´ ecisions appel´ ees commandes qui sont transmises aux actionneurs.

L’adaptation entre la cible et le contr^ ole est r´ ealis´ ee par la couche d’interpr´ etation qui se charge de faire le lien entre capteurs et actionneurs d’un cˆ ot´ e, et donn´ ees et commandes de l’autre cˆ ot´ e. Cette configuration assure l’ind´ e- pendance de la partie contrˆ ole vis-` a-vis de la plateforme ma- t´ erielle. Des ´ ev´ enements externes peuvent intervenir (panne de capteur, changement de consigne par exemple). Ils in- fluencent directement le contrˆ ole. Enfin, un composant de

Données

Cible Interprétation Contrôle

ou réel

simulé

Contrôleur Capteurs

Evénements externes

Interpréteur données Interpréteur

de

de

Interpréteur commandes Actionneurs

de simulation

et de réglage

Environnement Composant

d’évènements Evénements

Commandes

Les cadres repr´esentent des composants, les fl`eches d´ecrivent des flux d’information

Figure 2: Principes de l’architecture IMOCA

simulation et de r´ eglage est ajout´ e fournissant les outils n´ e-

cessaires ` a la mise au point de l’application de contrˆ ole. Il est

apte ` a prendre la main sur cette derni` ere afin de permettre ` a

un expert de tester diff´ erentes lois de commande, de valider leurs enchaˆınements et de r` egler leurs param` etres.

Les principaux composants de l’architecture IMOCA sont d´ etaill´ es ci-apr` es.

3.2 Données

Pour pouvoir choisir et param´ etrer la bonne loi de com- mande, l’application de contrˆ ole a besoin de se faire une image de l’environnement appel´ ee ´ egalement contexte. La construction du contexte se fait en deux ´ etapes. Dans la premi` ere, l’environnement est mesur´ e ` a l’aide de capteurs.

Les donn´ ees issues de ces capteurs sont ensuite transfor- m´ ees en donn´ ees de haut-niveau. Au sein de la cible, le capteur se r´ eduit ` a des sp´ ecifications purement techniques masquant les aspects bas-niveau. Un capteur se caract´ e- rise par (voir figure 3 o` u un capteur est d´ enot´ e Sensor) un nom sensorName, une valeur courante value de type double, une fr´ equence frequency. Des m´ ethodes set_data et get_data de mise ` a jour et de lecture de la valeur du capteur existent pour chaque classe. Ces m´ ethodes n’appa- raissent pas dans le m´ etamod` ele car leur signature et com- portement par d´ efaut sont g´ en´ er´ ees automatiquement. Le comportement est compl´ et´ e par la suite en fonction de l’ex- pertise m´ etier. Les capteurs d´ elivrent des donn´ ees brutes qu’il va falloir interpr´ eter pour obtenir des donn´ ees de haut- niveau. L’ensemble des donn´ ees est d´ etermin´ e par exper- tise du domaine d’application en r´ epondant ` a la question

”Quelles sont les donn´ ees qui permettent de prendre des d´ e- cisions par rapport au contrˆ ole ?”. Il s’agit de donn´ ees de haut-niveau qui ne comportent aucun d´ etail sur la mani` ere de les obtenir. Les donn´ ees ou data figure 3 sont caract´ e- ris´ ees par un nom dataName, un type, une valeur value, une fr´ equence frequency ainsi que des op´ erations de mise ` a jour et de lecture. Deux grandes cat´ egories de donn´ ees sont distingu´ ees, les donn´ ees continues ContinuousData pouvant prendre toute valeur entre deux bornes minimalBound et maximalBound et les donn´ ees de type ´ enum´ er´ e EnumeratedData ne pouvant prendre qu’un nombre fini de valeurs. Certaines donn´ ees, pour indiquer une modification de l’environnement, peuvent g´ en´ erer un ´ ev´ enement.

L’interpr´ eteur de donn´ ees est charg´ e de faire le lien entre les capteurs et les donn´ ees (figure 4). Les donn´ ees issues des capteurs sont filtr´ ees, on peut choisir par exemple de ne prendre qu’une donn´ ee sur trois ou d’effectuer une moyenne sur fenˆ etre glissante ou encore d’utiliser un filtre de Kalman.

Ensuite la valeur obtenue est format´ ee c’est-` a-dire convertie dans une unit´ e du Syst` eme International. Cela comporte un d´ ecalage d’offset ainsi qu’une mise ` a l’´ echelle par multiplica- tion par un coefficient de calibration. Ensuite la valeur est stock´ ee dans un buffer circulaire permettant des traitements d’ordre statistique : moyenne, ´ ecart type, pente de la droite de r´ egression... Enfin une phase de combinaison permet de fournir une donn´ ee ` a la couche de contrˆ ole. Cette phase peut ˆ etre r´ eduite ` a la transmission de la valeur filtr´ ee et format´ ee si la donn´ ee n´ ecessaire au contrˆ ole correspond ` a la donn´ ee d´ elivr´ ee par le capteur.

A partir des donn´ ees, le contrˆ ole agit pour produire les com- mandes. La couche de contrˆ ole est maintenant d´ etaill´ ee.

Combinaison Stockage

Stockage Filtrage

Filtrage

Filtrage

Formatage Formatage

Formatage Stockage Capteur_1

Capteur_n Capteur_2

Donnée

Figure 4: La couche d’interpr´ etation pour une don- n´ ee

3.3 Contrôle 3.3.1 Principes

Le contrˆ ole s’effectue ` a l’aide de lois de commande ou modes de fonctionnement. L’application doit toujours ˆ etre capable d’appliquer un mode dit courant. D’autre part, il est connu que les lois de commande sont tr` es sensibles aux variations de l’environnement. Il s’av` ere donc n´ ecessaire soit de chan- ger de mode courant (pour r´ epondre ` a la question 2 de l’introduction ”Comment enchaˆıner plusieurs modes ?”), soit de modifier ses param` etres (pour r´ epondre ` a la question 3 de l’introduction ”Comment param´ etrer les modes ?”). Pour cela, l’application de contrˆ ole est elle-mˆ eme compos´ ee de trois entit´ es fonctionnant en parall` ele et de mani` ere asyn- chrone (figure 5). La premi` ere dite r´ eactiveController est charg´ ee ` a haute fr´ equence (fr´ equence du capteur le plus ra- pide, environ 100Hz) du contrˆ ole temps r´ eel du syst` eme, elle utilise des donn´ ees qui correspondent directement ` a celles des capteurs (filtre ´ el´ ementaire sans phase de combinaison dans la couche d’interpr´ etation) pour calculer les commandes

`

a appliquer ` a partir du mode impos´ e par l’expertController.

Ce dernier est contrˆ ol´ e par un automate (liste de Transition) qui change d’´ etat sur un trigger (´ ev´ enement) (figure 6). En- fin, l’adaptativeController ajuste, ` a basse fr´ equence (de l’ordre de 0.1Hz), les diff´ erents param` etres de la loi de com- mande afin de la rendre plus performante par rapport ` a l’en- vironnement mesur´ e.

3.3.2 Contrôleur réactif et modes

Les Modes (voir figures 5 et 6) se caract´ erisent par un nom

modeName, un ensemble de param` etres configuration, un

ensemble de consignes setpoints et une loi de commande

control. Le contrˆ oleur r´ eactif effectue une boucle de type

perception/action qui consiste ` a lire un certain nombre de

donn´ ees pour nourrir un mode impos´ e par le contrˆ oleur ex-

pert et d´ elivrer une commande. La loi de commande est une

fonction qui d´ epend ` a la fois de param` etres, de donn´ ees di-

rectement interpr´ etables et de consignes qui proviennent du

contrˆ oleur expert. Par exemple, pour une r´ egulation de type

PID de vitesse d’un v´ ehicule, les param` etres sont les coeffi-

cients P, I et D (voir figure 5), les donn´ ees la vitesse du v´ e-

hicule et la consigne est fournie par le conducteur. Des data

sont d´ edi´ ees ` a la surveillance de donn´ ees capteurs (temps

r´ eel) qui sont sens´ ees rester dans un certain intervalle de

valeurs afin d’assurer une utilisation robuste de la loi de

commande. En cas de d´ epassement un ´ ev` enement est g´ e-

n´ er´ e. Dans le cas par exemple du pilotage d’un voilier, si la

r´ egulation se fait sur l’angle de gˆıte, il est important de sur-

veiller le cap du bateau pour ´ eviter de gros ´ ecarts de route

[11]. Cette surveillance doit se faire sur des donn´ ees temps

r´ eel pour obtenir une bonne r´ eactivit´ e car un changement

de contexte est par essence lent ` a rep´ erer. Pour une donn´ ee

issue d’un capteur, sortir de l’intervalle sp´ ecifi´ e signifie que

la loi de commande n’est plus adapt´ ee. Le contrˆ oleur expert

Figure 3: M´ etamod` ele simplifi´ e des donn´ ees, commandes, capteurs, actionneurs et ´ ev` enements

Figure 5: Les diff´ erents ´ el´ ements du contrˆ oleur

Figure 6: Contrˆ ole et modes

commute alors sur une autre loi. Cette nouvelle loi peut ˆ etre pr´ evue dans l’enchaˆınement normal des lois pour l’accom- plissement d’une tˆ ache donn´ ee, ou ˆ etre une loi par d´ efaut dans le cas o` u le comportement observ´ e n’est pas conforme

`

a l’expertise effectu´ ee. Il est donc important de disposer d’au moins une loi robuste ` a la plupart des contextes pour pou- voir s’y r´ efugier en cas de n´ ecessit´ e.

Pour prendre en compte les ´ evolutions de l’environnement, il faut ˆ etre capable d’adapter les param` etres des modes afin de maintenir un bon niveau de performance dans le nou- veau contexte. En effet, plutˆ ot que de changer de mode, il se peut qu’un changement de param´ etre soit plus pertinent.

Par exemple, dans le cadre de la r´ egulation en cap d’un voi- lier, l’augmentation de l’amplitude des angles de barre peut suffire pour r´ epondre ` a l’augmentation de celle des vagues.

C’est le contrˆ oleur adaptatif pr´ esent´ e dans la partie suivante qui est charg´ e de cette adaptation.

3.3.3 Contrôleur adaptatif et table des paramètres

Le contrˆ oleur adaptatif rep` ere les caract´ eristiques basses fr´ e- quences de son environnement pour param´ etrer les modes.

Il utilise pour cela (figure 5) une table Adaptation donnant pour chaque mode et chaque contexte identifi´ e (une Data) une configuration, c’est-` a-dire les valeurs des diff´ erents pa- ram` etres intervenant dans le mode. La table est construite par expertise ` a l’aide notamment du composant de simula- tion et de mise au point. Un exemple de table des param` etres est la table 2 pr´ esent´ ee dans la section 5.

Afin de garantir une utilisation coh´ erente de la table des param` etres il est n´ ecessaire que deux contextes distincts ne puissent ˆ etre valides simultan´ ement. Enfin si aucun contexte

propos´ e ne correspond au contexte courant il est important de pr´ evoir des param` etres par d´ efaut.

Le contrˆ oleur expert, pr´ esent´ e maintenant, se charge de l’en- chaˆınement des modes qui d´ ependent ` a la fois du type d’ac- tionneur command´ e, des objectifs ` a atteindre mais ´ egale- ment de l’environnement.

3.3.4 Contrôleur expert et automate

Le contrˆ oleur expert s´ electionne la loi de commande et les consignes ` a appliquer. C’est un automate fini d´ eterministe Transition (figure 5) muni d’un ´ etat initial o` u chaque ´ etat est associ´ e ` a une loi de commande. Ses transitions sont ´ eti- quet´ ees par des ´ ev´ enements et lors d’un changement d’´ etat (trigger) les consignes setPoint sont ´ evalu´ ees afin de pou- voir effectuer la commutation de modes. Ces consignes sont d´ efinies par expertise. Un exemple simple de comportement pour le contrˆ oleur expert est mod´ elis´ e figure 7 ` a l’aide de r´ eseaux de Petri interpr´ et´ es [6]. Bien qu’il n’y ait pas ici de parall´ elisme sous-jacent, nous utilisons ce formalisme car il est couramment employ´ e pour la mod´ elisation des sys- t` emes ` a ´ ev´ enements discrets [12]. Une place correspond ` a un

´

etat et est associ´ ee ` a un mode. Nous avons ici un comporte- ment simple bas´ e sur deux modes. Le jeton indique le mode courant. Les transitions sont ´ etiquet´ ees par un ´ ev´ enement evt_i et une fonction c_i servant ` a calculer les consignes.

Lorsqu’un ´ ev´ enement arrive et qu’une transition valid´ ee est

´

etiquet´ ee par cet ´ ev´ enement, la fonction c_i est ex´ ecut´ ee et la transition tir´ ee.

3.3.5 Evènements

Les ´ ev´ enements sont soit externes (mise en route du syst` eme

ou changement de consigne par exemple), soit g´ en´ er´ es par

evt_1

evt_2

Mode_1 Mode_2

c_1

c_2

Figure 7: Exemple de comportement simple pour le contrˆ oleur expert

certaines data. Ils indiquent un changement de contexte qui n´ ecessite une r´ e-´ evaluation du mode courant, qui peut ne plus ˆ etre appropri´ e. Les ´ ev´ enements provoquent l’´ evaluation de la fonction de transition de l’automate, la r´ ecup´ eration des param` etres associ´ es au mode obtenu et l’´ evaluation des consignes.

3.3.6 Modèles et code

Une fois les mod` eles d´ ecrits, le d´ eveloppeur peut s’appuyer sur un certain nombre de librairies m´ etiers fournies aussi bien pour la couche interpr´ etation (conversions usuelles, calibration, offset, outils statistiques, filtres ...), que pour la couche contr^ ole (contextes, automates, tables ...) ou en- core pour le composant de simulation et de r´ eglage (widgets, IHM ...). Ainsi, une fois l’architecture sp´ ecifi´ ee, le squelette du code est obtenu par g´ en´ eration de code, puis le code fi- nal est obtenu par int´ egration et adaptation des librairies propos´ ees. Pour des raisons de place, cette partie, bas´ ee sur des transformations de mod` eles, n’est pas d´ etaill´ ee dans cet article.

4. MÉTHODOLOGIE

L’utilisation d’IMOCA ne garantit pas en soi que l’applica- tion de lois de contrˆ ole r´ eponde aux trois questions pos´ ees en introduction :

1. Quels sont les modes de fonctionnement pertinents ? 2. Comment enchaˆıner plusieurs modes ?

3. Comment param´ etrer les modes ?

Le choix des modes de fonctionnement (question 1) possibles est d’autant plus difficile que de nombreuses donn´ ees sont disponibles et combinables. Cependant, toute loi de com- mande n’est pas bonne, encore faut-il qu’elle ait un sens (on ne peut d´ ecemment contrˆ oler la vitesse d’une voiture en fonction de la temp´ erature ext´ erieure par exemple), et qu’elle soit r´ eellement efficace, c’est-` a-dire, que le contrˆ ole r´ esultant soit de bonne qualit´ e. La mesure de la qualit´ e d’un contrˆ ole est ´ egalement un probl` eme difficile car de nombreux crit` eres, parfois qualitatifs plutˆ ot que quantitatifs peuvent intervenir : robustesse, sˆ uret´ e, s´ ecurit´ e, consommation, r´ e- ponse ` a un ´ echelon, conformit´ e ` a une expertise effectu´ ee de l’activit´ e concern´ ee... Le probl` eme de l’enchaˆınement des lois de commande (question 2) est ´ egalement tr` es difficile car d´ ependant de l’environnement, de la tˆ ache ` a effectuer et de crit` eres parfois difficilement quantifiables comme ”avoir une belle trajectoire”. Pour r´ epondre ` a ce probl` eme, la m´ e- thodologie propos´ ee repose sur une expertise pour le choix des modes de fonctionnement (question 1), la mani` ere de

les enchaˆıner (question 2) et de les param` etrer (question 3).

L’expert est aid´ e lui-mˆ eme par des outils de simulation et de mise au point incr´ ementaux par essais/corrections via le composant de simulation et de r´ eglage. La m´ ethodologie comporte 4 ´ etapes :

Etape 1 mise ` a disposition d’un environnement r´ eel ou si- mul´ e, construction de la couche cible et du contr^ oleur r´ eactif.

Etape 2 construction de la biblioth` eque de lois de com- mande et de la table des param` etres

Etape 3 caract´ erisation des donn´ ees ou contextes en fonc- tion des capteurs

Etape 4 construction de l’automate et d´ efinition des ´ ev` e- nements

La premi` ere ´ etape a pour but de pouvoir jouer avec le pro- cessus ` a contrˆ oler. Le coˆ ut des plateformes r´ eelles ainsi que les contraintes et les risques li´ es ` a leur utilisation font qu’il est avantageux de simuler le processus ainsi que son envi- ronnement pour permettre le rejeu et ainsi tester diff´ erentes configurations. L’expert est d’autant mieux ´ epaul´ e que la si- mulation est r´ ealiste. Dans ce cadre, la r´ ealit´ e virtuelle par son cˆ ot´ e immersif est particuli` erement int´ eressante. Une fois cet environnement disponible la couche cible peut ˆ etre d´ e- velopp´ ee ainsi que le contrˆ oleur r´ eactif qui peut ˆ etre en lien direct avec les capteurs dans un premier temps.

Ensuite la construction d’une interface permettant de choisir et construire diff´ erentes lois de commande permet ` a un ex- pert de s´ electionner celles qui semblent les plus pertinentes.

Cette interface prend en lieu et place le rˆ ole du contr^ oleur expert et permet de d´ efinir les donn´ ees n´ ecessaires aux lois de commande s´ electionn´ ees. L’expert teste les lois dans dif- f´ erentes conditions et d´ efinit les param` etres qui paraissent les plus adapt´ es. L’´ etablissement des param` etres conduit ` a la d´ efinition des contextes dans lesquels ils op` erent efficace- ment et ` a la construction du contr^ oleur adaptatif.

Dans une troisi` eme ´ etape, les contextes doivent ˆ etre carac- t´ eris´ es en fonction des capteurs ce qui entraˆıne la d´ efinition de la couche d’interpr´ etation de l’architecture.

On peut ensuite s’int´ eresser ` a la construction de l’automate, c’est-` a-dire ` a la construction du contr^ oleur expert, pour lequel, l’intervention d’un expert est primordiale. En effet, l’enchaˆınement des modes d´ epend des tˆ aches ` a effectuer (al- ler chercher un objet n´ ecessite de se d´ eplacer puis de mani- puler un bras et enfin de revenir par exemple), de contraintes m´ ecaniques (s’arrˆ eter avant de pouvoir reculer par exemple et pour s’arrˆ eter il peut ˆ etre n´ ecessaire de freiner avant) ou encore d’une analyse m´ etier de comment il faut faire.

L’´ elaboration de l’automate am` ene ` a d´ efinir les diff´ erents

´

ev´ enements qui vont permettre de changer d’´ etat. Ces ´ ev´ e- nements sont li´ es d’une part ` a des changements de contexte et, d’autre part, ` a la surveillance temps r´ eel de certains cap- teurs. Il est alors souvent n´ ecessaire de d´ efinir de nouvelles donn´ ees et de les relier aux capteurs.

5. UNE ÉTUDE DE CAS : LE PILOTAGE AUTOMATIQUE DES VOILIERS

Dans cette section l’architecture IMOCA et la m´ ethodolo-

gie propos´ ee pr´ ec´ edemment sont mises en oeuvre dans le

but de d´ evelopper un pilote automatique de voilier. C’est

un probl` eme crucial que d’affranchir le marin d’une tˆ ache

Figure 8: Le bateau (en vert) et son clone (en mauve)

r´ ep´ etitive et fastidieuse tout en veillant ` a sa s´ ecurit´ e et en pr´ eservant une conduite performante le tout dans un envi- ronnement, mer, vent, voilier, par essence tr` es perturb´ e. Les lois de commande choisies sont de type PID. La validation repose sur l’utilisation d’un environnement virtuel offrant une excellente qualit´ e d’exp´ erience et permettant de compa- rer diff´ erents types de pilotage.

5.1 Position du problème

En course ` a la voile au large et en solitaire le skipper pour pouvoir manœuvrer, r´ egler, manger ou tout simplement dor- mir utilise un pilote automatique. Les pilotes automatiques commerciaux utilis´ es sont de simples r´ egulateurs de cap et d’allure qui n’agissent que sur la barre via un unique ac- tionneur. Ils sont peu performants et conduisent parfois ` a des situations critiques entraˆınant des d´ egats irr´ eversibles comme des d´ emˆ atages ou des chavirages. L’am´ elioration de ces pilotes est une demande forte des coureurs ainsi que des industriels les concevant.

5.2 Construction du pilote

5.2.1 Etape 1 : mise à disposition d’un environne- ment réel ou simulé, construction de la couche cible et du barreur réactif

Pour la mer et le vent le mod` ele IPAS [19] pour Interactive Phenomenological Animation of the Sea impl´ ement´ e dans le langage AR´ eVi

est utilis´ e. Un mod` ele de voilier, bas´ e sur la dynamique des syst` emes mat´ eriels, a ´ et´ e d´ evelopp´ e ; sa g´ eo- m´ etrie est d´ efinie via un fichier VRML qui permet un rendu de qualit´ e. Par d´ efaut, le bateau est muni d’un pilote de type commercial, c’est-` a-dire un r´ egulateur de cap. L’environne- ment offre la possibilit´ e de cloner le bateau pour effectuer des comparaisons de performance sur la loi de contrˆ ole. On peut voir figure 8 le bateau (en vert) dans son environnement physique avec son clone (en mauve).

Le bateau est ´ equip´ e de tous les capteurs Sensor habituels : an´ emom` etre, girouette, speedom` etre, GPS, compas, sondeur, angle de barre, plus quelques uns plus sp´ ecifiques comme 4. AR´ eVi (Atelier de R´ ealit´ e Virtuelle) est une biblio- th` eque de simulation et de rendu 3D.

une centrale inertielle ou des jauges de contrainte

. Un ac- tionneur Actuator, un v´ erin lin´ eaire agissant sur les safrans

`

a une vitesse constante, est ´ egalement d´ efini ainsi qu’une interface qui permet au skipper de notifier la consigne de cap ExternalEvent ` a suivre et de la modifier (` a l’image des boˆıtiers de commande disponibles dans le commerce). L’en- vironnement virtuel offre la possibilit´ e ` a l’utilisateur d’agir

`

a sa guise sur le vent, l’´ etat de la mer et sur les r´ eglages du voilier.

La d´ efinition des capteurs, de l’actionneur et des ´ ev` enements externes, li´ es aux actions effectu´ ees sur l’interface pilote, de la couche cible est ici directe.

5.2.2 Etape 2 : construction de la bibliothèque de lois de commande et de la table des paramètres

Au niveau du contrˆ ole, le seul actionneur ` a commander est le v´ erin. Mais, les nombreux capteurs autorisent de multiples r´ egulations. L’expertise a permis d’opter pour de la r´ egu- lation de type PID car il s’agit d’une solution industrielle

´

eprouv´ ee et ses avantages et inconv´ enients sont bien connus par les marins donc exploitables. Pour autant, il existe de nombreuses impl´ ementations (PPIDD, PDD, ...) de cette loi.

Par exemple, le mode cap est une r´ egulation de type PDD qui tient compte du roulis ` a cause de son importance pour l’anticipation :

θ_barre=K_c(K_cap(cap−consCap)+K_lacetlacet+am.K_roulisroulis)

θ

est l’angle de barre absolu, cap la data donnant le cap magn´ etique du bateau, consCap la consigne de cap ` a respec- ter, lacet la vitesse de rotation en degr´ es par seconde du bateau par rapport ` a un axe vertical (li´ e ` a la centrale iner- tielle) et roulis la vitesse de rotation par rapport ` a l’axe du bateau (dirig´ e de l’arri` ere vers l’avant). K

, K

, K

et le gain K

sont ajust´ es en fonction de l’environnement par le barreur adaptatif. Le terme am devant K

vaut ±1 en fonction de l’amure du bateau. Pour d´ eterminer les bonnes lois et les param´ etrer, une table de mixage (cf. figure 9) est cr´ e´ ee. C’est l’interface du composant de mise au point. En s´ e- lectionnant le bouton correspondant, le mode de fonctionne- ment courant est choisi (les modes sont ici appel´ es Cap, G^ ıte, Vitesse, Vent, G^ ıte rel et Vitesse rel sur la figure). Et les diff´ erents param` etres ou coefficients (indiqu´ es ici avec ` a leur gauche les modes dans lesquels ils interviennent) sont r´ eglables ` a l’aide de scroll bar. Les 6 modes de barre retenus sont d´ etaill´ es dans la table 1.

Une partie de la table des param` etres choisis est donn´ ee en aper¸ cu dans la table 2.

5.2.3 Etape 3 : caractérisation des données en fonc- tion des capteurs

De nombreuses donn´ ees sont presque directement d´ efinis- sables ` a partir des capteurs au formatage pr` es. C’est le cas de la vitesse, de la position, du cap, de la force et de la direc- tion du vent apparent... D’autres donn´ ees sont plus d´ elicates

`

a obtenir. Par exemple la direction et la force du vent r´ eel

sont issues d’un calcul faisant intervenir vitesse, cap du ba-

teau et angle et vitesse du vent r´ eel. Le r´ esultat peut ˆ etre

5. Les jauges de contraintes servent ` a mesurer les d´ efor-

mations des mat´ eriaux sur lesquels elles sont fix´ ees.

MODES DE BARRE Mode cap :

θ

= K

(K

(cap − consCap) + K

lacet + am.K

roulis) Mode cap relatif :

θ

= K

(K

(cap − consCap) + K

lacet + am.K

roulis) + θ

Mode vent r´ eel :

θ

= K

(K

(T W A − consT W A) + K

lacet + am.K

roulis) Mode gˆıte :

θ

= sgn.K

(K

(gite − consGite) + am.K

roulis+

K

(sensabarre − consSB) + K

(

dt

))

Mode gˆıte relatif :

θ

= sgn.K

(K

(gite − consGite) + am.K

roulis+

K

(sensabarre − consSB) + K

(

dt

)) + θ

Mode gain :

θ

= −K

(K

(gite − consGite) + am.K

roulis+

K

(sensabarre − consSB) + K

(

dt

)) + θ

Table 1: La biblioth` eque du barreur r´ eactif

Pr` es Mer Calme

Largue

Mer Calme ... Pr` es

Mer Agit´ ee default

Mode cap

K

= 1 K

= 5 K

= 10 K

= 0

K

= 1 K

= 5 K

= 15 K

= 10

...

K

= 2 K

= 5 K

= 10 K

= 5

K

= 1.25 K

= 5 K

= 10 K

= 0

Mode vent r´ eel

K

= 1 K

= 5 K

= 20 K

= 0

K

= 1.2 K

= 5 K

= 20 K

= 20

...

K

= 2 K

= 5 K

= 10 K

= 0

K

= 1.25 K

= 5 K

= 20 K

= 0

Table 2: Extrait de la table des param` etres

Figure 9: Table de mixage employ´ ee pour le r´ eglage des PID

affin´ e en exploitant la centrale inertielle pour tenir compte de l’attitude du bateau.

De plus,un certain nombre de contextes tel que Largue et Mer Calme sont n´ ecessaires ` a l’adaptation des modes. Un contexte combine plusieurs informations. Pour Largue et Mer Calme, la premi` ere concerne les allures et la deuxi` eme les ´ etats de mer. Chaque contexte correspond au final ` a une donn´ ee de type ´ enum´ er´ e. Certaines comme l’´ etat de mer sont bas´ ees sur une analyse fr´ equentielle des mouvements du ba- teau et sur une double int´ egration sur des acc´ el´ erations four- nies par la centrale inertielle pour estimer la hauteur des vagues. Ensuite l’´ echelle de Douglas

sert de r´ ef´ erence pour qualifier les diff´ erents ´ etats de mer. D’autres comme les al- lures du bateau sont bas´ ees sur l’angle au vent r´ eel moyenn´ e sur une dizaine de secondes.

Les donn´ ees n´ ecessaires sont au final tr` es nombreuses. Outre les donn´ ees continues qui donnent des valeurs de type cap- teurs, celles de type ´ enum´ er´ e peuvent se classer en 5 grandes cat´ egories en fonction de ce qu’elles permettent de caract´ e- riser : le bateau, la mer, le vent, la route du bateau et les contextes pour les modes de barre. Cette classification est relative au m´ etier et non int´ egr´ ee ` a l’architecture. Elle ap- parait dans les librairies de mod` ele et de code sp´ ecifique.

5.2.4 Etape 4 : construction de l’automate et défini- tion des événements

La derni` ere ´ etape porte sur la construction de l’automate, c’est-` a-dire le barreur expert. La figure 10 en donne une version simplifi´ ee sous la forme d’un r´ eseau de Petri inter- pr´ et´ e. Dans cette vue, les transitions ne sont pas ´ etiquet´ ees.

Cette ´ etape oblige ` a d´ efinir les derniers ´ ev´ enements n´ eces- saires et donc quelques nouvelles donn´ ees. Par exemple le passage entre le mode cap et le mode vent r´ eel peut se faire 6. L’´ echelle de Douglas est celle mondialement utilis´ ee dans les bulletins m´ et´ eorologiques.

p2 p

3

p4

p5

p6

p7

p₈

p9 p

10 p₁₁

p1

Figure 10: Automate contrˆ olant le barreur expert

sur une notion de stabilit´ e li´ ee ` a la fois au vent, ` a la mer, aux mouvements de la barre et ` a l’allure du bateau. Les consignes se calculent elles directement ` a partir des donn´ ees.

Cette mise au point incr´ ementale justifie pleinement l’utili- sation de l’architectural, de la librairie m´ etier et de l’envi- ronnement de mise au point. Le d´ eveloppement devient alors un assemblage format´ e et adaptable de composants logiciels m´ etier.

5.3 Expérimentation

L’environnement virtuel permet de tester le pilote dans des

conditions de mer et de vent vari´ ees. Diff´ erents ´ el´ ements

du bateau sont r´ eglables comme les voiles, la quille ou la

position du skipper. Cependant, tester la qualit´ e d’un pilo-

tage est difficile car il s’agit toujours d’un compromis entre

plusieurs crit` eres comme performance, s´ ecurit´ e, consomma-

tion ´ energ´ etique et trajectoire. Aussi le bateau est clon´ e

pour pouvoir comparer le pilote construit selon l’architecture

IMOCA, appel´ e barreur virtuel, avec un simple r´ egulateur de

cap proche d’un pilote commercial, appel´ e PID. Un certain

nombre de cas (rafale, d´ epart en surf, clapot ...) connus pour

prendre en d´ efaut ces pilotes commerciaux servent pour la

comparaison. La figure 11 pr´ esente la trajectoire du clone

ainsi que du barreur virtuel. Les deux voiliers naviguent tra-

vers au vent dans 20 noeuds de vent par mer calme lorsque

survient une rafale ` a 23 noeuds qui dure une quarantaine de

secondes avant que le vent ne reprenne sa force initiale. Au

d´ epart (` a gauche sur la figure) les deux voiliers sont quasi-

ment superpos´ es. Quand la rafale arrive ils abattent l´ eg` ere-

ment pour essayer de contrecarrer le surcroˆıt de puissance

mais ils finissent par partir au lof, c’est-` a-dire par se tourner

brutalement vers le vent. Le barreur virtuel passe en mode

gˆıte et accompagne cette aulof´ ee alors que le PID cherche ` a

lutter contre l’´ ecart ` a la consigne en donnant beaucoup de

barre (voir la figure 12). Lorsque la rafale se termine le bar-

reur virtuel repasse en mode cap et le clone finit par venir

s’aligner ` a l’arri` ere de l’autre voilier.

barreur virtuel PID

Figure 11: Trajectoires des deux voiliers lors d’une rafale

−30

−25

−20

−15

−10

−5 0 5 10 15

940 950 960 970 980 990 1000 1010

Angle de barre (deg)

Temps (s)

barreur virtuel PID

Figure 12: Angles de barre

Les courbes des figures 12 et 13 donnent une explication de ce qui se passe en donnant les angles de barre et les vitesses des deux bateaux.

Alors que le barreur virtuel change de mode (les change- ments de mode apparaissent avec des croix en X) et parvient ainsi ` a conserver une bonne vitesse, le PID cherche ` a com- penser la d´ eviation de trajectoire en donnant beaucoup de barre ce qui freine le bateau.

6. CONCLUSION

Ce document pr´ esente l’architecture IMOCA et une m´ etho- dologie d´ edi´ es aux syst` emes de contrˆ ole de processus par r´ egulation en environnement perturb´ e. Le principe est d’ef- fectuer de la commutation de modes en fonction des ´ evolu- tions de l’environnement ; les modes, leurs param` etres, leur enchaˆınement ´ etant d´ etermin´ es par expertise du domaine

7 7.5 8 8.5 9 9.5 10 10.5 11 11.5 12

940 950 960 970 980 990 1000 1010

Vitesse (noeuds)

Temps (s)

barreur virtuel PID

Figure 13: Vitesses

d’application.

IMOCA offre des mod` eles et des outils pour la mise au point incr´ ementale des donn´ ees et des param` etres du syst` eme de contrˆ ole. Cette architecture et cette m´ ethodologie ont ´ et´ e appliqu´ ees au cas du d´ eveloppement d’un pilote automatique pour voiliers et donnent un r´ esultat op´ erationnel apportant un gain ` a la fois en performance mais ´ egalement en s´ ecurit´ e.

Dans les perspectives, nous visons la mise en place d’un code op´ erationnel embarquable, adaptable et reconfigurable sur voilier r´ eel. Nous pensons aussi augmenter les librairies dis- ponibles pour viser d’autres domaines d’application.

7. REFERENCES

[1] D. Bertrand, A.-M. D´ eplanche, S. Faucou, and O. H.

Roux. A study of the AADL mode change protocol. In Proceedings of the IEEE International Conference on Engineering Complex Computer Systems - ICECCS 2008, page 288, Belfast, Ireland, 2008. IEEE Computer Society.

[2] J. B´ ezivin. In Search of a Basic Principle for Model Driven Engineering. The European Journal for the Informatics Professional, 2 :21–24, 2004.

[3] E. Borde, G. Haik, and L. Pautet. Mode-based reconfiguration of critical software component architectures. In Design, Automation Test in Europe Conference Exhibition, 2009. DATE ’09., pages 1160–1165, 2009.

[4] Y. Brun, G. Marzo Serugendo, C. Gacek, H. Giese, H. Kienle, M. Litoiu, H. M¨ uller, M. Pezz` e, and M. Shaw. Software Engineering for Self-Adaptive Systems. chapter Engineering Self-Adaptive Systems through Feedback Loops, pages 48–70. 2009.

[5] R. A. D. Garlan and J. Ockerbloom. Exploiting style in architectural design environments. In Proceedings of the 2nd ACM SIGSOFT symposium on Foundations of software engineering, page 175–188, New York, NY, USA, 1994.

[6] R. David and H. Alla. Du Grafcet aux R´ eseaux de Petri. Herm` es, 1992.

[7] J. Deantoni and J.-P. Babau. A MDA-based approach for real time embedded systems simulation. In Proceedings of the 9th IEEE International Symposium on Distributed Simulation and Real-Time

Applications, pages 257–264, Montreal, 2005. IEEE Computer Society.

[8] J. Deantoni and J.-P. Babau. SAIA : safe deployment of sensors based real time application. In Workshop on Models and Analysis for Automotive Systems (held in conjunction with RTSS), Rio de Janeiro, Br´ esil, Dec.

2006.

[9] G. H. E. Borde and L. Pautet. Mode-Based Reconfiguration of Critical Sofware Component Architectures. In Design, Automation Test in Europe Conference Exhibition, pages 20–24, 2009.

[10] V. A. F Maker, R. Amirtharajah. MELOADES : Methodology for Long-term Online Adaptation of Embedded Software for Heterogeneous Devices.

Technical Report CSE-2013-69, UC Davis, Computer Science, 2012.

[11] G. Guillou. Architecture multi-agents pour le pilotage

automatique des voiliers de comp´ etition et Extensions alg´ ebriques des r´ eseaux de Petri. PhD thesis,

Universit´ e de Bretagne Occidentale, 2010.

[12] L. Holloway, B. Krogh, and A. Giua. A Survey of Petri Net Methods for Controlled Discrete Event Systems.

Discrete Event Dynamic Systems, 7(2) :151–190, 1997.

[13] P. Horn. Autonomic Computing : IBM’s Perspective on the State of Information Technology, 2001.

[14] M. v. S. J.P. Almeida, R. Dijkman and L. Pires. On the notion of abstract platform in MDA development.

In Proceedings of the eighth IEEE International Enterprise Distributed Object Computing Conference, pages 253–263, 2004.

[15] Y. Li, K. H. Ang, and G. C. Y. Chong. PID control system analysis and design. IEEE Control Systems Magazine, 26(1) :32–41, 2006.

[16] L. M.Agrawal, S.Cooper and V. Thomas. An open software architecture for high-integrity and

high-availability avionics. In Proceedings of DASC04, Digital avionics Systems Conference, 2004.

[17] OMG. Model driven architecture guide v1.0.1, 2003.

[18] S. V. P. H. Feiler, B. Lewis and E. Colbert. An overview of the SAE Architecture & Design Language (AADL) Standard : A Basis for Model Based

Architecture-Driven Embedded Systems Engineering.

In Architecture Description Language, workshop at IFIP World Computer Congress, 2004.

[19] M. Parentho¨ en. Animation ph´ enom` enologique de la mer : une approche ´ enactive. PhD thesis, Universit´ e de Bretagne Occidentale, 2004.

[20] F. Terrier and S. G´ erard. MDE benefits for

didtributed, real time and embedded systems, 2006.