Interface et Paramètres d’Interface

Définition 2:

L’Interface d’une Entité Composable est ce qui lui permet de se lier à d’autres Entités Composables. Il s’agit d’un 3-uplet : Int = (N e, P r, IS). On notera l’Interface d’une Entité Composable e : Int(e).

Définition 3:

N e est l’ensemble des Besoins (Needs). Il s’agit des connaissances requises par l’Entité Composable. On notera les Besoins d’une Entité Composable e : N e(e).

Définition 4:

P r est l’ensemble des Produits (Products). Il s’agit des connaissances générées par l’Entité Composable. On notera les Produits d’une Entité Composable e : P r(e).

Définition 5:

IS est l’ensemble des Stockages Internes (Internal Storages). Il s’agit des connaissances stockées par l’Entité Composable (pour réaliser une intégration ou dans le cadre d’his- torisation de données par exemple) et potentiellement accessibles depuis l’extérieur de l’Entité Composable. On notera les Stockages Internes d’une Entité Composable e : IS(e). Définition 6:

Un Elément d’Interface, i, est un élément appartenant à l’Interface d’une Entité Com- posable. i est donc un Elément d’Interface de l’Entité Composable e si et seulement si i ∈ N e(e) ∪ P r(e) ∪ IS(e).

Un Elément d’Interface est décrit comme le couple i = (Nom, D) où Nom est son nom et D l’ensemble des informations le caractérisant.

Définition 7:

L’ensemble des informations caractérisant un Elément d’Interface i est appelé un Data- type et sera noté D(i). Il s’agit d’un 3-uplet D = (T ype, F rame, Axis)

Gardant à l’esprit notre objectif de rendre l’Interface autosuffisante, il faut que le Datatype contienne toutes les informations pertinentes pour pouvoir comprendre ce que représentent les différents éléments de l’Interface et vérifier la cohérence des liaisons entre nos Entités Composables.

Définition 8:

Le Type désigne la grandeur représentée qu’il s’agisse d’une grandeur avec unité (Force, Accélération, Vitesse par exemple) ou sans unité (Booléen, Entier non signé par exemple). L’ensemble des Types définis sera noté T y.

On a T y = T ysi∪ T yco∪ T yar. Le Type d’un Datatype D sera noté D.T ype.

Définition 9:

T ysi est l’ensemble des Types simples. Ceux-ci ne contiennent qu’une seule grandeur.

Définition 10:

T yco est l’ensemble des Types complexes. Ceux-ci correspondent à une agrégation de

4.2. Concepts et Définitions

Définition 11:

T yar est l’ensemble des Types Array (tableaux). Ceux-ci représentent une collection

d’éléments de même Type. Ces Types sont caractérisés par une information de taille (i.e. la taille du tableau). Ainsi, size(T a) désignera la taille d’un Type Array T a.

Il est important de noter que la taille des tableaux peut être dynamique suivant les besoins de l’application.

L’information de Type est-elle suffisante dans notre contexte pour caractériser précisément les éléments de l’Interface ?

Considérons l’exemple d’évitement de parois présenté section 4.1.2. Le sonar profilomé- trique effectue des mesures qu’il exprime dans un repère qui lui est propre. Il faut donc se demander dans quel repère est effectué le contrôle. Plusieurs hypothèses sont possibles, on peut par exemple envisager :

– Le contrôle est effectué dans l’espace sonar

– Le contrôle est effectué dans le repère robot et les mesures du sonar sont passées dans le repère robot au sein de l’entité sonar.

– Le contrôle est effectué dans le repère robot et les mesures du sonar sont passées dans le repère robot au sein de l’entité effectuant le calcul des intrusions.

– Le sonar est monté de telle manière que le repère sonar et le repère robot coïncident retirant la nécessité d’une conversion.

Sans connaissance du contenu des différentes entités, il nous est impossible de savoir laquelle de ces hypothèses est valide et donc de pouvoir correctement réutiliser la loi de commande décrite dans une autre application robotique. D’autant plus qu’ici nous n’avons considéré que la relation entre deux entités. La même problématique est soulevée pour chaque lien entre des entités. Comme souligné dans le cadre de ROS (voir Section 2.4.1 et [Foo13]), il s’agit là d’une problématique importante qui est fréquemment source d’erreurs dans le développement d’une architecture de contrôle.

Cela contrevient donc à notre volonté d’avoir une Interface autosuffisante pour les utilisa- teurs. Il nous faut donc ajouter des informations supplémentaires dans notre description du Datatype.

Nous avons ainsi ajouté deux champs supplémentaires permettant de caractériser un Elé- ment d’Interface.

Définition 12:

F rame est un champ désignant le repère (frame) dans lequel est exprimé l’Elément d’Interface. L’ensemble des repères existants sera noté F r. Le Frame d’un Datatype D sera noté D.F rame.

Différentes valeurs sont possibles pour ce champ. Trois valeurs sont obligatoirement défi- nies :

– NOF RAME : la donnée n’appartient à aucun repère particulier. – W ORLD : la donnée appartient au repère monde.

– Une valeur est définie par robot. Dans notre cas, nous n’utiliserons qu’un seul engin. Nous noterons donc cette valeur ROBOT . La donnée est alors exprimée dans le repère robot.

Il est également nécessaire de définir des repères pour chaque capteur donnant des mesures relatives à une position ou à l’un de ses dérivés (vitesse, accélération). Par exemple, un repère sera défini pour le sonar profilométrique, le Loch Doppler ou encore la centrale inertielle.

Nous définirons également des repères pour le système d’actionnement, dans notre cas un repère par moteur. Enfin, des repères spécifiques pour chaque tâche peuvent aussi être définis par l’utilisateur.

Définition 13:

Axis est un champ désignant l’axe ou le plan dans lequel est exprimé l’Elément d’In- terface. L’ensemble des axes existants sera noté Ax. L’Axis d’un Datatype D sera noté D.Axis.

Nous avons défini 7 valeurs possibles pour ce champ :

– NOAXIS : la donnée n’est pas exprimée dans un axe particulier. – x : la donnée évolue suivant l’axe x.

– y : la donnée évolue suivant l’axe y. – z : la donnée évolue suivant l’axe z. – xy : la donnée évolue dans le plan xy. – yz : la donnée évolue dans le plan yz. – xz : la donnée évolue dans le plan xz. Définition 14:

Deux Datatypes, D1 et D2, seront définis comme identiques, noté D1 = D2, si et seule-

ment si D1.T ype = D2.T ype et D1.F rame = D2.F rame et D1.Axis = D2.Axis

4.2. Concepts et Définitions

Dans certains cas, il est également intéressant de pouvoir adapter l’Interface d’une Entité Composable à l’utilisation qui en est faite. Considérons l’exemple de la connaissance d’annu- lation de force (Figure 4.5, blocs G et H). Les équations (4.5) et (4.6) sont identiques à la différence près de l’axe sur lequel nous souhaitons annuler la force. Nous pourrions faire deux Entités Composables, une par axe mais ce ne serait pas une solution judicieuse notamment car elle est potentiellement source d’erreurs.

Il nous faut donc pouvoir indiquer suivant quel axe sont exprimés les différents Besoins et Produits. Nous allons utiliser pour cela des Paramètres d’Interface.

Définition 15:

Les Paramètres d’Interface représentent l’ensemble des modifications possibles à l’Interface d’une Entité Composable en fonction de l’utilisation qui en sera faite. L’en- semble des Paramètres d’Interface d’une Entité Composable e, noté IntP ar(e), est défini comme :

IntP ar(e) = {ipi, i ∈ [1 ... Dim(IntP ar(e))] / ipi ∈ F r ∪ Ax}

Si les Paramètres d’Interface permettent d’adapter repères ou axes, nous n’autorisons pas dans notre approche l’utilisation de Paramètres d’Interface portant sur les Types. En effet, nous souhaitons toujours conserver la signification physique des différents modèles. Or une trop grande généricité au niveau des Types rendrait les modèles trop abstraits puisque leur véritable signification ne serait apparente qu’à l’utilisation de l’Entité Composable.