Ouvert
com(x)? | not(x)!
x=100
ferm:= x
Fermé
not(x)!
x=100
ferm:=x
com(x)? | note(x)
x<100
ferm := x
not(x)!
x<100
ferm:=x
not(x)!
x=100
ferm:=100
not(x)!
x<100
ferm := 100
com(x)? | not(x)
x=100
ferm := x
com(x)? | not(x)!
x<100
ferm := x
Figure 5.5 – Représentation graphique du type de volet avec raccourcie de
nota-tion
5.2.5 Raccourci de représentation
Comme nous l’avons vu précédemment, la représentation graphique d’une
ac-tion d’entrée fait intervenir une localité virtuelle, une notificaac-tion de retour et une
action interne. Ce schéma est systématique, et il peut être abrégé par une notation
indiquant l’action d’entrée et l’action de sortie. La représentation du volet avec le
raccourci de représentation est illustrée par la figure5.5.
La première ligne de l’étiquette d’un raccourci de notation indique la commande
que doit recevoir un dispositif et la notification qu’il émet en retour. Lorsqu’il y a
des paramètres, ils sont indiqués avec les mêmes symboles dans la commande que
dans les notifications. Lors de l’écriture non raccourcie, ces symboles indiquent
la présence de variables temporaires qui permettent de garder en mémoire les
paramètres de commandes et les comparer avec les notifications de retour.
De même, les nuances de gris facilitent la lecture du graphique. Les flèches
noires indiquent une transition de sortie. Les flèches grises indiquent un raccourci
de notation, nous les nommons des transitions d’entrée-sortie.
5.3 Règles de comportements
La modélisation du comportement répond à la question : « Quelle est la
notifica-tion et l’état de réponse d’un dispositif lors de la récepnotifica-tion d’une commande ? » Un
système possède des fonctionnalités, ces dernières permettent de réaliser des tâches
particulières. Et afin d’utiliser ces fonctionnalités, un système doit être contrôlé en
lui envoyant les bonnes commandes permettant d’obtenir un comportement désiré.
Ici l’objectif est de créer le contrôle de dispositifs.
Les automates IOSTS permettent de modéliser un comportement. À cet égard,
nous avons vu comment modéliser le comportement d’un dispositif. La
modélisa-tion du comportement permet de connaître quelles sont les commandes à envoyer
à un dispositif afin d’obtenir un état. Dans le même ordre d’idée, les IOSTS
per-mettent de modéliser le comportement d’un ensemble de dispositifs. Ces dispositifs
peuvent dépendre les uns des autres ou non.
– L’exemple d’un comportement de dispositifs ne dépendant pas les uns des
autres pourrait être le comportement d’une chambre disposant d’une lampe
de plafond, d’une lampe de chevet et d’un volet.
– L’exemple d’un comportement de dispositif dépendant les uns des autres
pourrait être le comportement d’une télévision reliée à un décodeur
satellite.
L’objectif est de créer un mécanisme qui permet le contrôle de dispositifs.
L’ensemble des états possibles d’un sous-ensemble de dispositifs d’une installation
domotique est le produit cartésien de tous les états possibles de ses dispositifs.
Il n’est pas envisageable d’énumérer tous les états souhaités afin de définir le
contrôleur de dispositifs. En revanche, il est possible de décrire un contrôleur au
moyen de règles de réactions à des évènements ou des règles de contraintes. Les
règles de réactions à des évènements consistent à exprimer une ou des actions à
entreprendre lorsqu’un évènement apparaît et que le système est dans un certain
état. Nous nommons ces règles : Évènement Condition Changement (ECC). Les
règles de contraintes se présentent sous forme d’expressions booléennes.
Le comportement standard d’un système « dispositif – télécommande » est de
réagir à chaque appui sur un bouton en effectuant une action. Dans ce cas, l’appui
sur un bouton est un évènement traduit par la réception d’un signal pour le
dis-positif. La réaction réalisée par le dispositif lors de la réception d’un évènement est
inscrite dans un programme. Dans un même ordre d’idées, les règles ECC
perme-ttent de programmer la réaction du système lors de la réception d’un évènement.
Les règles de contraintes permettent de matérialiser un ensemble d’états
au-torisés ou interdits d’un système.
À partir de ces deux types de règles, un contrôleur sera synthétisé afin de limiter
le comportement du système.
5.3.1 Comportement sur évènements
Le comportement sur évènements est défini par des règlesÉvènement Condition
Changement(ECC). Les ECC sont utilisées pour commander un systèmeS2 depuis
5.3 Règles de comportements 93
un autreS1. Cette approche est flexible et permet à un système de commander un
ou plusieurs autres systèmes, mais aussi d’être commandé par plusieurs systèmes.
Les ECC sont la généralisation des règles classiquesÉvènement Condition
Ac-tion introduites dans le domaine des bases de données. Une ECC exprime un
changement à entreprendre lorsqu’un évènement apparaît et que le système est
dans un certain état. Plus exactement, lorsque l’évènement E apparaît et que la
condition C est satisfaite, le changement C doit être entrepris.
Il existe deux types de changement :
– Le changement par action correspond à l’émission d’une action d’entrée
d’un système, c’est-à-dire à l’émission par le contrôleur d’une commande à
destination d’un dispositif. Ce type de règle se nomme Évènement
Condition Action (ECA).
– Le changement par but correspond à un changement de l’état d’un système
afin qu’il atteigne le but. Le but est un état du système. Dans ce cas, la
série d’actions n’est pas énoncée afin d’atteindre l’état, c’est un calcul qui
définit les actions à envoyer au dispositif. Ce type de règle se nomme
Évènement Condition But (ECB).
Ce type de règle permet de décrire des comportements que les règles de
con-trainte ne peuvent pas exprimer. C’est notamment le cas pour les réactions aux
évènements. En effet, les règles de contrainte permettent de gérer les états, mais
pas les évènements. Par exemple, il est impossible de créer un comportement avec
un bouton poussoir émettant un seul type d’évènement : « le bouton a été appuyé »
en n’utilisant qu’un système de contraintes.
Une règleÉvènement Condition Actionest définie par un tuple :eca=hλ
!, c , α
?i,
où λ
!∈Σ
!est une action de sortie du système S1 (Σ
!∈ S1), c est une condition
booléenne sur les variables du système S2 et α
?∈ Σ
?est une action d’entrée du
système S2 (Σ
?∈ S2).
Une règle Évènement Condition But est définie par un tuple :ecb=hλ
!, c, γi,
où λ
!∈ Σ
!appartient à l’automate de comportement du système S1, c est une
condition booléenne sur les variables du système S2, et γ ∈ S est un état du
système S2. Un état est défini par une localitél ∈L et les valeurs de chacune des
variables de V.
5.3.2 Règles de contraintes
Les contraintes sont utilisées pour restreindre le comportement d’un système.
L’expression d’une contrainte est écrite au moyen d’un langage logique. Nous
limi-tons l’étude aux contraintes de comparaison entre les variablesv
id’un système et
des constantes. L’expression des contraintes est écrite en utilisant les opérateurs
de comparaison (<, >,≤,≥, =,6=) et les opérateurs de l’algèbre booléenne (∧,∨,
¬). Une contraintec
1s’écrit sous forme d’une série de disjonctions et conjonctions
de comparaisons comme par exemple :
c
1=v
1<cst
1∧v
2≥cst
2∧. . .
Rappelons qu’un système peut-être commandé par différents points de
com-mande qui ne sont pas contrôlables. C’est le cas d’une télécomcom-mande d’une
télévi-sion qui ne peut pas être bridée puisqu’un utilisateur a toujours la possibilité de
l’utiliser. C’est pourquoi un système peut violer une contrainte imposée. Dans ce
cas, le contrôleur doit corriger l’état du système afin de garantir la contrainte.
L’automate IOSTS du contrôleur est synthétisé à partir de l’automate de
com-portement du dispositif et de la règle de contrainte.
De la même manière que l’utilisateur peut, par un système de commande
ex-terne, violer une contrainte qui a été définie, le système peut démarrer dans un
état qui viole cette contrainte. Dans ce cas, il n’y a pas d’état stable antérieur à
l’état courant dans lequel le contrôleur pourrait ramener le système. Ansi, pour
chaque contrainte, un état de secours est défini. Il correspond à l’état dans lequel
le contrôleur doit amener le système si ce dernier démarre dans un état violant la
contrainte.
Dans le document
Modélisation de l'interopérabilité d'objets communicants et de leur coopération : application à la domotique
(Page 108-111)