Interactions entre applications, entités et éléments physiques . 77

5.3 Démarche d’invention des entités . . . . 81

5.3.1 Éléments des modèles d’entités contrôlables . . . . 81

5.3.2 Indépendance vis-à-vis des capteurs . . . . 85

5.3.3 Abstraction de plusieurs éléments physiques . . . . 86

5.4 Principes de représentation des entités par des automates. 89

5.4.1 Structure particulière des automates . . . . 89

5.4.2 Extension de la notion d’états par des variables . . . . 92

5.5 Correspondances entre entités et ressources REST . . . . . 93

5.5.1 Liens entre les modèles d’entités et le critère HATEOAS . . . 93

5.5.2 Transformation des modèles d’entités en ressources . . . . 94

5.5.3 Annotations sémantiques des ressources . . . . 101

5.6 Conclusion . . . 101

5.1 Abstraction des éléments physiques par des entités

5.1.1 Les éléments physiques comme point commun de la ville

Une ville se compose d’un ensemble d’éléments physiques que nous définissons

comme étant des équipements : lampadaires, plots rétractables, feux tricolores, etc. ;

ou des zones géographiques : segments de routes, places de parking, carrefours, etc.

Chaque instance de la ville possède ses propres spécificités (géographiques,

ins-titutionnelles, etc.), mais chacune d’entre elles est composée des mêmes éléments

physiques. Par exemple, l’exemple conducteur (cf. section 4.2) est composé

d’élé-ments physiques tels que les lampadaires L₁ à L₇, les segments de route SR_1.1,

SR1.2, les routes R1 et R2, etc. que toute instance de ville possède. Les éléments

physiques sont ainsi le point commun à toutes les instances de ville.

Afin de rendre la ville intelligente, ces éléments physiques intègrent des capteurs

et actionneurs. Un équipement tel que le plot rétractableP Rintègre des actionneurs

permettant de lever ou monter celui-ci. Les équipements peuvent également être

pourvus de capteurs, tel que le capteur présent dans le plot rétractable P R pour

connaître sa hauteur.

Les zones géographiques sont également pourvues de capteurs : le segment de

route SR1.1 possède des capteurs magnétiques à chaque extrémité, les places de

parking P P₁, P P₂ possèdent des capteurs de présence sous le bitume. Les zones

géographiques ne sont pas actionnables directement, mais les effets qu’engendrent

des actions sur les équipements à proximité de ces zones géographiques influencent

les valeurs des capteurs présents sur ces zones : mettre un feu tricolore au rouge

aura une influence sur le taux d’occupation de la route se situant à proximité.

5.1.2 Définition des entités

Nous proposons de représenter les éléments physiques de la ville intelligente par

ce qu’on appelle des entités. Une entité est une abstraction d’un ou plusieurs

élé-ments physiques de la ville comportant des capteurs et actionneurs. On parle d’entité

contrôlable lorsqu’une entité est associée à un ou plusieurs éléments physiques qui

sont pourvus d’au moins un actionneur.

Par exemple, une entité associée à un plot rétractable est considérée comme

contrôlable puisque des actionneurs sont présents au sein du plot pour le faire monter

ou descendre. A l’inverse, l’entité qui est associée à un segment de route n’est pas

contrôlable puisque seuls des capteurs de passage sont présents sur celui-ci.

La figure5.1illustre le diagramme de cas d’utilisation des entités où les

applica-tions utilisent les entités à la fois pour pouvoir superviser mais également contrôler

les éléments physiques de la ville intelligente. Le contrôle des éléments physiques

s’ef-fectue par l’intermédiaire de commandes envoyées aux actionneurs présents sur les

équipements. Tels que montrés sur cette figure, les modèles des entités peuvent être

modifiés en fonction des données des capteurs et des ordres envoyés aux actionneurs.

Nous verrons plus en détails la nature de ces interactions entre les entités et les

différents acteurs en sous-section5.2.2.

elements

monitor physical

Applications ^{update entities}_models

control physical

elements

«Subsystem »Entities

Sensors

Actuators

Figure ^{5.1 – Cas d’utilisation montrant les fonctions remplies par les entités}

5.1.3 Motivations de l’abstraction proposée

5.1.3.1 Les entités comme généralisation de la ville

L’abstraction que nous proposons par le biais des entités a pour objectif d’être

généralisable à toute instance de ville. Ainsi, les applications utilisent les entités

pour superviser ou contrôler la ville ce qui amène à ce que les applications ne soient

plus conçues au cas par cas suivant les spécificités de chaque ville.

Une entité associée au segment de route SR1.1 doit être généralisable à tout

segment de route de la ville intelligente, et non d’une ville en particulier.

De plus, différents types de capteurs peuvent servir à mesurer la même

informa-tion. Par exemple, le taux d’occupation des véhicules présents sur une route peut

être mesuré par différents types de capteurs : capteurs magnétiques (comme c’est

le cas pour le segment SR_1.1), boucles à induction, capteurs ultrasons ou encore

caméras (Pan Tilt Zoom, par exemple). Le type de capteur utilisé est donc

spéci-fique à une instance de ville et afin d’être généralisable, les entités doivent pouvoir

s’abstraire de la nature des capteurs.

5.1.3.2 Les entités comme granularité des éléments physiques

Les entités doivent abstraire les éléments physiques qu’elles représentent à

dif-férents niveaux de granularité pour permettre aux applications qui les utilisent de

superviser et contrôler plus facilement la ville.

Par exemple, une entité peut être associée à l’ensemble des lampadaires se

trou-vant le long d’une rue, et permettre aux applications de contrôler les lampadaires de

cette rue de manière groupée. Le contrôle des lampadaires d’une rue peut consister à

tous les allumer, en allumer un sur deux ou encore tous les mettre en veille. Comme

évoqué en sous-section 5.1.3.1, cette entité peut se généraliser à n’importe quelle

instance de ville puisqu’elle est indépendante de la configuration d’une rue et de son

nombre de lampadaires.

Sur la base de notre exemple conducteur (cf. section 4.2.1), une application

d’éclairage public doit pouvoir allumer ou éteindre l’ensemble des lampadaires d’une

rue, les lampadairesL₁àL₇. Ici, une entitée_iassociée à chaque lampadaireL_iserait

fastidieuse à utiliser par cette application d’où l’avantage d’une entité regroupant

les lampadaires.

Similairement, une abstraction de plus forte granularité doit permettre aux

applications de superviser plus facilement un ensemble d’éléments physiques. Par

exemple, une entité pourrait être associée à un ensemble de places de parking en

fournissant une abstraction de la disponibilité de celles-ci, à savoir si elles sont toutes

occupées, toutes libres ou à moitié libres par exemple.

5.1.3.3 Les entités comme moyen de protéger les équipements

Les équipements ne doivent pas pouvoir être contrôlés de manière incohérente par

les applications. Une utilisation inconsistante résulte d’un état inconsistant d’un ou

plusieurs équipements, c’est-à-dire provoquant un fonctionnement anormal de

ceux-ci. Par exemple, une utilisation inconsistante d’un feu rouge est de le faire passer

au feu vert alors qu’il est à l’orange. Similairement, lorsqu’il s’agit de plusieurs

équipements, ici l’ensemble des feux d’un carrefour, une utilisation inconsistante

produisant un état inconsistant est de les mettre tous au feu vert en même temps.

Cette notion de consistance est largement présente dans les bases de données, où

l’état d’un élément du système est dit consistant lorsque les contraintes de

consis-tance qui lui sont associées sont satisfaites [47]. Par exemple, une transaction

im-pliquant deux comptes bancaires est dite consistante si, à la fin de la transaction,

la contrainte de consistance suivante est respectée : la somme débitée est égale à la

somme créditée.

Ainsi, en nous inspirant de cette notion de consistance, les entités

contrô-lables doivent intégrer des contraintes de consistance. Ces contraintes de consistance

doivent permettre d’assurer que l’état des équipements ne soient pas inconsistants

résultant d’un fonctionnement anormal de ceux-ci.

5.2 Représentation et utilisation des entités

5.2.1 Choix de représentation des entités

Nous avons choisi de représenter les entités par des automates discrets à états

finis, puisqu’il s’agit de modèles particulièrement utilisés dans les systèmes réactifs

(cf. section 2.2.1).

Notre système est similaire à un système réactif : l’ensemble des entités constitue

notre système interagissant avec l’environnement à savoir l’ensemble des éléments

physiques formant l’environnement de la ville intelligente (cf. section 5.1.1). Notre

système interagit avec l’environnement via des sorties qui sont des commandes

en-voyées aux actionneurs pour contrôler les éléments physiques. A l’inverse, notre

système reçoit de l’environnement des entrées qui sont des données provenant des

capteurs.

Par ailleurs, nous avons choisi d’utiliser des automates puisque ceux-ci

per-mettent de rendre notre modélisation générique : peu importe les éléments physiques

associés aux entités, le modèle d’une entité est toujours un automate composé

d’en-trées, de sorties, de variables, de transitions et d’états. L’utilisation du langage Argos

nous permet l’utilisation de profiter d’un vocabulaire étendue pour la description de

ces automates. Puisque le modèle est le même quelle que soit l’entité, cela rend plus

aisé le développement d’applications. Comme nous le verrons en section5.5,

l’inter-face uniforme issue des principes REST permet également de satisfaire ce critère.

Enfin, le choix de représenter les entités par des automates est motivé par le

fait que les automates comportent des transitions qui peuvent être restreintes afin

de protéger les équipements contre des utilisations incorrectes. Les automates

com-portent également des états qui peuvent être de granularité plus ou moins fine. Nous

reviendrons plus en détails sur ces deux points dans la section5.4.

5.2.2 Interactions entre applications, entités et éléments physiques

5.2.2.1 Vue d’ensemble

Nous définissons un exemple qui est généralisable, afin d’illustrer nos propos

concernant les interactions existantes entre applications, entités et éléments.

Celui-ci est composé des deux applications : App1 supervise le segment de route SR1.1

via l’entité E₁ qui lui est associée, App₂ contrôle le feu de travaux F T₂ au travers

de l’entité qui le représente. La figure 5.2 et la figure 5.3 sont des diagrammes de

séquence qui décrivent exhaustivement ces interactions.

Comme montré dans les deux figures, les applications interagissent avec les

enti-tés au moyen d’états qui leur sont exposés pour superviser et contrôler la ville. Les

applications peuvent observer mais également modifier l’état courant des entités.

Nous avons fait le choix d’exposer les états des modèles d’entités aux applications

que nous appelons plus simplement les états des entités. La notion d’état est facile à

appréhender pour des néophytes qui ne possèdent pas de connaissances techniques

liées aux automates discrets à états finis que nous utilisons. Ainsi, il est rendu

plus facile aux développeurs d’applications d’utiliser les entités pour contrôler et

superviser la ville. Comme nous le verrons en section 5.4.1, le choix d’exposer des

états aux applications a une influence sur la structure des automates.

ack

updated

state

updated

state

ack

ack

send sensors data

get current state

subscribe current state

send sensors data

Road segmentSR

1.1

App

1

EntityE

1

send sensors data

notify state

ack + state

ack + state

Figure ^{5.2 – Interaction entre l’application}App₁ et le segment de routeSR_1.1 via

son entitéE1.App1 lit l’état courant deE1 qui change d’état en fonction des valeurs

de capteurs reçues.App₁souscrit également à une notification de changement d’état

de E₁.

Supervision de la ville au travers des entités Les applications supervisent les

éléments physiques de la ville via des requêtes envoyées aux entités pour connaître

leur état courant. En effet, une entité qui reçoit une requête de supervision

ren-voie en retour son état courant, qui correspond à l’état courant de l’automate. Le

choix de renvoyer l’état courant est pertinent puisqu’il correspond à l’état de

l’en-tité à l’instant où la requête est reçue. La figure 5.2montre que l’application App1

supervise le segment de route SR1.1 via une requête qui est envoyée à son entité,

l’application recevra en retour la valeur de l’état courant.

Les états des entités sont issus de la consolidation des données de capteurs.

L’entité du segment de routeSR_1.1 reçoit les données des capteurs magnétiques (cf.

section 4.2.1) consolidées sous forme de taux d’occupation. Par exemple, l’entité

de SR_1.1 aurait des états (LOW TRAFFIC, MEDIUM TRAFFIC, HIGH TRAFFIC)

correspondant aux différents taux d’occupation du segment de route. Nous verrons

en sous-section5.3.2plus en détail l’entité du segment SR1.1 et son modèle associé,

qui nous permet de mettre en avant l’indépendance des entités vis-à-vis des types

de capteurs présents dans la ville.

Enfin, afin de pouvoir superviser les éléments physiques dans un mode

événe-mentiel, les applications peuvent demander à être notifiées lors des changements

d’états des entités.

updated

state

updated

state

updated

state

updated

state

wait

Traffic LightF T

2

App

2

EntityE

₂

ack + intermediary state

modify current state

ack + intermediate state

subscribe last request

result

ack

get sensors data

modify current state

ack

ack + target state

ack + target state

ack

send actuator

command

send actuator

command

Figure ^{5.3 – Interaction entre l’application} App₂ et le feu de travauxF T₂ via son

entitéE₂.App₂ modifie l’état courant deE₂. Lorsque l’état voulu par App₂ ne peut

pas être atteint tout de suite, E2 notifieApp2 qu’un état intermédiaire existe.

Contrôle de la ville au travers des entités Les applications peuvent également

contrôler les entités en envoyant des requêtes pour changer l’état courant de celles-ci,

comme illustré par le diagramme de séquence de la figure5.3où l’application App2

change la couleur du feu de travaux F T2 par l’intermédiaire de l’entité E2 qui lui

est associée.

L’application App₂ modifie l’état courant de l’entité, puisque les automates ont

des entrées spécifiques qui le permettent (cf. section 5.3.1.1). Suite à la réception

d’une requête de changement d’état, une entité contrôlable envoie des requêtes aux

actionneurs pour atteindre l’état demandé puis reçoit en retour des acquittements,

comme illustrés par les communications entre l’entité E₂ et le feu tricolore F T₂.

Enfin, l’entité contrôlable retourne un acquittement à l’application pour lui notifier le

résultat. Pour cela nos automates comportent des sorties qui sont des acquittements

positifs ou négatifs (cf. section 5.3.1.3).

Comme le montre ce diagramme de séquence, avant d’atteindre l’état souhaité

par l’application, l’entité peut atteindre un état dit intermédiaire dont nous donnons

plus de détails en sous-section5.3.1.2. Par exemple, si l’application App2 demande à

passer le feuF T₂ rouge, via l’entitéE₂, celui-ci sera orange avant d’être rouge. Pour

être informée que l’état voulu est atteint, l’application doit indiquer à l’entité qu’elle

souhaite être notifiée. Une fois l’état cible atteint, après avoir été provisoirement

dans l’état orange pour l’entité E₂, une notification est envoyée à l’application, ici

informantApp2 que l’état du feu est rouge.

Enfin, les entités peuvent interroger les capteurs des équipements. Ici un

cap-teur est présent dans le feu F T2 permettant de savoir si une panne de courant est

survenue. En l’interrogeant l’entité E₂ peut mettre à jour son état. Nous illustrons

l’automate de cette entité dans la figure 5.4qui est décrite en section 5.3.1.

5.2.2.2 Déploiement de code

Code relatif à l’implémentation des entités Le code qui décrit

l’implémenta-tion des entités sous forme d’automates doit être deployé au plus proche des éléments

physiques qu’elles représentent. Cela permet de limiter la latence de communication,

en communiquant directement avec les capteurs et actionneurs des éléments

phy-siques, et ainsi de garantir que les états des entités changent en un temps compatible

avec le contrôle temps réel.

Nous verrons en section 7.4 que le code décrivant l’implémentation des entités

vise à être déployé sur les plateformes edges de la plateforme FIWARE qui

corres-pondent au matériel le plus proche des éléments physiques. Cela constitue un choix

idéal pour satisfaire nos exigences de temps-réel (cf. section4.3) et permet d’assurer

une meilleure tolérance aux pannes.

Code relatif aux applications utilisant des entités Les applications peuvent,

suivant leurs besoins, avoir des contraintes temps-réel alors que d’autres non. Pour

satisfaire les critères temps-réel de certaines applications, les communications

ré-seaux doivent être réduites. Par conséquent les applications doivent s’exécuter au

plus proche des entités qu’elles utilisent. Cela permet d’assurer également un

fonc-tionnement autonome lorsque d’éventuelles pannes de matériels ou du réseau

sur-viennent.

Nous verrons en détail en section 7.4où doit s’exécuter le code des applications

suivant leurs besoins respectifs.

5.3 Démarche d’invention des entités

Dans le document Modèles partagés et infrastructures ouverte pour l'internet des objets de la ville Intelligente (Page 84-91)