i
ContextAA : plateforme sensible au Contexte pour aborder le problème
de l’espace intelligent ouvert
par
Patrice Roy
Thèse présentée au Département d'informatique en vue de l'obtention de docteur ès sciences (Ph.D.)
FACULTÉ DES SCIENCES UNIVERSITÉ DE SHERBROOKE
ii
Le 30 juillet 2019
le jury a accepté le mémoire de Monsieur Patrice Roy dans sa version finale.
Membres du jury
Professeur Bessam Abdulrazak, Directeur de recherche Département d'informatique
Yacine Belala Codirecteur de recherche Ingénieur logiciel principal Teksystems Global Services
Professeur Gabriel Girard Membre interne Département d'informatique
Abdenour Bouzouane Professeur titulaire en informatique
Membre externe
Département d'informatique et de mathématique Université du Québec à Chicoutimi
Professeur Richard Egli Président-rapporteur Département d'informatique
iii
Sommaire
Les environnements intelligents traditionnels sont des espaces délimités à l’intérieur desquels il est possible d’offrir un soutien spécialisé à des individus. Bien que ces espaces aient fait la démonstration de leur utilité, l’avènement des technologies mobiles et le gain de mobilité qui en découle pour les individus profitant d’environnements intelligents complique le maintien d’une continuité de service pour ceux-ci. Pourtant, les besoins des individus ne s’estompent pas lorsqu’ils franchissent le pas de la porte de leur logis.
C’est pour cette raison que nous avons conçu ContextAA, une plateforme visant à résoudre le problème de la continuité de service dans un contexte d’usagers mobiles à travers un environnement hétérogène où la qualité de la connectivité peut varier. ContextAA se veut une solution générale au problème de l’espace intelligent ouvert, concept qui inclut à la fois les espaces intelligents classiques et celui, plus large et sans frontières prédéterminées, dans lequel tout individu et tout agent est présumé capable de mobilité. En ce sens, ContextAA fait le choix de supporter des variations dans la qualité de service, en fonction de la richesse offerte dans l’environnement immédiat, privilégiant en retour une continuité de service.
Les éléments clés de ContextAA sont une architecture répartie reposant sur des composants Hôtes, à l’intérieur desquels logent des Agents standards, participant à l’offre de services de leur Hôte, et des Agents du domaine, chargés d’une mission et opérant sur la base d’une perspective individuée sur le Contexte, que nous nommons le Contexte-selon. Chaque Agent du domaine s’inscrit dans un cycle de vie, et plus spécifiquement dans un cycle opératoire, et peut migrer d’un Hôte à l’autre si cela lui permet de poursuivre sa mission.
Au cœur de ContextAA se trouve le Contexte, qui est à la fois langage et objet de langage, données, métadonnées et opérations sur le Contexte. De par le langage du Contexte et de par son architecture où les opérations sont basées sur le Contexte, ContextAA se présente comme une architecture capable d’accommoder des nœuds à faibles ressources, comme on en trouve par exemple dans le monde de l’Internet des objets, et où les Agents sont susceptibles de pouvoir poursuivre leur mission malgré la mobilité de leur Hôte, même lorsque cet Hôte se trouve en situation de connectivité limitée.
ContextAA est utilisé sur des projets concrets, comme base sur laquelle sont maintenant construits des outils de plus haut niveau, et permet à la fois de mieux profiter des espaces intelligents traditionnels et d’aborder les problèmes spécifiques à l’espace intelligent ouvert.
iv
Remerciements
Ce fut une longue route, incluant un divorce, un mariage, une naissance, quelques décès, quelques années de syndicalisme actif, une grève étudiante d’une ampleur inattendue. Une vie familiale spectaculaire. Une carrière qui a beaucoup bouillonné. Une vie pleine de surprises.
Merci à Bessam Abdulrazak et à Yacine Belala. Je ne suis pas un étudiant facile à diriger, je sais, mais j’ai apprécié votre soutien et j’ai beaucoup de respect pour vous. Vous avez fait du bon travail, et je vous en remercie.
Merci particulier aux collègues Charles Gouin-Vallerand, qui a suggéré l’idée de visibilité du Contexte, et Benoit Fraikin pour son aide dans la sélection d’une notation pour la représentation des fonctions. De manière générale, les échanges informels avec les membres du DOMUS ont été féconds pour élaborer certaines des métaphores que vous rencontrerez dans ces pages. Merci à mon amie Martine Drapeau pour avoir suggéré le nom Agent du domaine. Merci à Björn Fahller pour une intuition pour la représentation des valeurs dans une sous-expression 𝑒𝑣𝑎𝑙. Merci spécial à Victor Manuel Ponce Diaz pour sa collaboration et ses questions au cours des dernières années. Merci à mes parents Lucille et Réal, à mes beaux-parents Jacqueline, Danielle et Jocelyn, de même qu’à mon ex beau-père Alain, qui m’ont tous soutenus ou aidés à leur manière pendant cette longue aventure. Je vous dois beaucoup et je vous aime.
Merci à mes collègues et ami(e)s, de même qu’à mes ami(e)s tout court. Vous êtes nombreuses et nombreux, et vous êtes importantes et importants pour moi. Je n’ai pas été aussi présent pour vous que j’aurais dû l’être, je le sais, mais je n’ai eu de vous que du soutien et de l’affection. Je suis reconnaissant. J’apprécie particulièrement vos critiques, vos commentaires, et cet irritant « pis, ton doctorat, ça avance? » qui grattait le bobo en ajoutant à l’envie de terminer au plus vite.
Merci au Collège Lionel-Groulx et à l’Université de Sherbrooke, pour vos encouragements et votre tolérance envers moi pendant cette aventure. En particulier, merci à mes étudiant(e)s, pour avoir stimulé mes neurones, mais surtout pour leur patience et (encore une fois) leur tolérance. Je sais que vous êtes conscients que je ne vous ai pas donné ce que je vous aurais donné en temps normal, et j’apprécie que vous ayez accepté de cheminer avec moi malgré tout.
À mes enfants. Mes quatre grandes filles : Marguerite, Calypso, Amandine et Vayda. À mon garçon Ludo, arrivé dans ma vie pendant ma rédaction. Je sais ce que vous avez enduré ces dernières années. Je vous entends. Je vous adore.
Surtout, à Za, Isabelle pour les moins intimes. Mon amour, ma belle. C’est beaucoup grâce à toi que j’y suis arrivé. Que nous y sommes arrivés, vraiment. La vie est plus belle parce que tu es là.
v
Table des matières
Sommaire ... iii
Remerciements ... iv
Table des matières ... v
Liste des abréviations ... xiii
Liste des figures ... xv
Liste des tableaux ... xvi
Chapitre 1 ContextAA – Introduction et motivation ... 1
1.1 Problématique ... 1
1.2 Proposition d’ensemble ... 2
1.3 Survol de ContextAA ... 3
1.4 Survol des principales orientations ... 3
1.5 Justification des choix architecturaux ... 4
1.5.1 Diversification et hétérogénéité des espaces intelligents ... 4
1.5.2 Connectivité imparfaite et exigence d’autonomie ... 5
1.5.3 Simplification des mécanismes de raisonnement et de déploiement ... 6
1.5.4 Intégration à l’existant ... 6
1.6 Motivations d’une démarche novatrice ... 7
Chapitre 2 État des connaissances ... 10
2.1 Environnements intelligents ... 10 2.2 Contexte ... 21 2.2.1 Définitions ... 23 2.2.2 Modélisation ... 28 2.2.3 Profil ... 29 2.3 Agents ... 30 2.3.1 Contextualisation (Context-awareness) ... 33 2.3.2 Raisonnement réparti ... 38 2.4 Architecture ... 38 2.4.1 Modalités architecturales ... 39 2.4.2 Systèmes multi-agents ... 42 2.4.3 Modalités de communication ... 45 2.4.4 Ontologie ... 47
vi
Chapitre 3 ContextAA – Conception ... 49
3.1 Pourquoi ContextAA – Les besoins ... 49
3.1.1 Sur le plan des environnements intelligents ... 49
3.1.2 Sur le plan du Contexte ... 50
3.1.3 Sur le plan des Agents ... 50
3.1.4 Sur le plan de la contextualisation ... 51
3.1.5 Sur le plan de la perspective sur le Contexte ... 52
3.1.6 Sur le plan architectural ... 52
3.1.7 Sur le plan de l’ontologie ... 53
3.2 Espace intelligent ouvert ... 53
3.2.1 Conséquences ... 54 3.3 Contexte ... 55 3.3.1 Contexte-selon ... 56 3.3.2 Modélisation ... 57 3.3.3 Profil ... 58 3.3.4 Contexte partiel ... 59 3.4 Agent ... 59 3.4.1 Mobilité ... 60 3.4.2 Services ... 61 3.4.3 Mission ... 62 3.4.4 Espace contextuel ... 62 3.4.4.1 Visibilité du Contexte ... 63 3.4.5 Cadre ontique ... 64 3.4.6 Contextualisation ... 65 3.5 ContextAA – Architecture ... 66 3.5.1 Hôte ... 67 3.5.2 Voisinage réseau ... 67 3.5.3 Nœuds mobiles ... 68 3.5.4 Architecture détaillée ... 68 3.5.5 Objet autonome ... 69 3.5.6 Canal de Contexte ... 70
vii
3.6 Dynamique de contextualisation... 71
3.6.1 Gestion du Contexte ... 71
3.6.2 « Contexte-selon », ou évaluation subjective de la qualité du Contexte ... 72
Chapitre 4 ContextAA – Modèle théorique ... 74
4.1 Vocabulaire de base ... 74
4.1.1 Invariants, préconditions et postconditions ... 74
4.1.2 Opération primitive ... 75 4.2 Conventions et notation... 75 4.2.1 Considérations générales ... 75 4.2.2 Appartenance à un type ... 76 4.2.3 Types de fonctions ... 76 4.2.4 Foncteurs et expressions λ ... 76 4.2.5 Chaînes de caractères ... 77 4.2.6 Ensembles ... 77 4.2.7 Listes ... 78 4.2.8 Fonctions ... 78 4.2.9 Fermetures ... 79
4.2.10 Transformer un ensemble en liste ... 80
4.2.11 Gestion des erreurs ... 80
4.2.12 Fonctions sur des listes ... 80
4.2.13 Fonctions et notations étendues... 81
4.2.14 Opérateurs ... 82 4.2.15 Notation en extension ... 82 4.2.16 Paires et uplets ... 82 4.2.17 Contexte ... 83 4.2.18 Agent ... 83 4.2.19 Hôte ... 83 4.2.20 Espace contextuel ... 84 4.2.21 Nom de Contexte ... 84 4.3 Contexte ... 84
4.3.1 Contextes bruts et synthétiques ... 84
viii
4.3.3 Nom et valeur d’un Contexte ... 85
4.3.4 Équivalence entre Contextes ... 85
4.3.5 Forme canonique et forme compacte ... 86
4.3.6 Sous-Contextes ... 86
4.3.7 Taille d’un Contexte ... 86
4.3.8 Contexte terminal ... 87
4.3.9 Autres identités ... 87
4.3.10 Contexte bien formé et malformé ... 87
4.3.11 Représentations alternatives ... 88
4.3.12 Profondeur d’un Contexte ... 88
4.3.13 Fusion de Contextes ... 89
4.4 Noms de Contextes ... 89
4.4.1 Vocabulaire ... 89
4.4.2 Noms composites ... 90
4.4.3 Éléments d’un nom ... 91
4.4.3.1 Nombre d’éléments ... 91
4.4.3.2 Nom vide ... 91
4.4.3.3 Accès à un élément ... 91
4.4.3.4 Équivalence entre éléments ... 91
4.4.3.5 Subsomption ... 92
4.4.4 Noms en tant que texte ... 92
4.4.5 Concaténation ... 92
4.4.6 Comparaison entre deux noms ... 93
4.4.6.1 Égalité de deux noms ... 93
4.4.6.2 Différence entre deux noms ... 93
4.4.6.3 Équivalence entre éléments de noms ... 93
4.4.6.4 Équivalence entre noms ... 94
4.4.6.5 Disparité opératoire entre formes compacte et canonique ... 94
4.4.6.6 Distance entre deux noms ... 95
4.4.7 Reconnaissance de modèles ... 95
4.4.7.1 Jeton ∗ (match any) ... 96
ix
4.4.7.3 Jeton ? (match auto) ... 97
4.4.7.4 Jeton ? = (named element) ... 97
4.4.7.5 Jeton 𝒂𝒍𝒍 ... 97
4.4.7.6 Jeton # (échappement) ... 97
4.4.7.7 Échappement et ordonnancement des valeurs ... 98
4.4.8 Qualifications d’accès au Contexte ... 98
4.4.9 Dictionnaire de modèles ... 98
4.4.9.1 Jeton 𝒄𝒐𝒎𝒎𝒊𝒕... 99
4.4.9.2 Fonction 𝒕𝒓𝒚𝑴𝒂𝒕𝒄𝒉 ... 99
4.5 Opérations sur le Contexte ... 100
4.5.1 Prédicats sous forme de Contexte ... 100
4.5.2 Critères standards ... 100
4.5.3 Transformations standards ... 101
4.5.3.1 Apprentissage et oubli ... 101
4.5.3.2 Équivalence par transformation de Contexte (𝝉-équivalence) ... 102
4.5.4 Algorithmes standards ... 102
4.5.5 Relation entre algorithmes et critères ... 104
4.5.6 Composition d’opérations ... 104
4.5.7 Exemples d’applications ... 105
4.5.8 Évaluation d’expressions ... 106
4.5.8.1 Expressions 𝒄𝒐𝒎𝒎𝒊𝒕 ... 108
4.6 Similitudes entre Contextes ... 108
4.6.1 Distance sémantique – discussion informelle ... 110
4.6.2 Distance structurelle ... 113
4.6.2.1 Équivalence structurelle – discussion informelle ... 114
4.6.3 Distance de contenu ... 114
4.6.3.1 Équivalence de contenu – discussion informelle ... 115
4.6.4 Interpréter la distance structurelle ... 115
4.6.5 Interpréter la distance de contenu ... 115
4.6.6 Discussion ... 116
4.6.7 Rapprocher les Contextes ... 119
x
4.6.7.2 Abstraction de racine ... 121
4.6.7.3 Permutation de Contexte ... 123
4.6.7.4 Rapprochement de Contextes par transformations ... 124
4.6.8 Distance sémantique ... 125
4.6.9 Interpréter la distance sémantique ... 125
4.6.10 Méta-Contextes ... 126
4.7 Agents ... 126
4.7.1 Modèle général (survol) ... 127
4.7.2 Agent du domaine ... 129
4.7.3 Atteinte d’une mission ... 131
4.7.4 Continuité de service ... 131
4.7.5 Espace contextuel ... 132
4.7.5.1 Contenu et gestion d’un espace contextuel ... 132
4.7.5.2 Oublier le Contexte ... 132
4.7.6 Agent standard ... 133
4.7.6.1 Interactions avec le matériel ... 134
4.7.6.2 Interactions avec les objets autonomes et le voisinage ... 134
4.7.6.3 Gestion et entretien du Contexte ... 135
4.7.6.4 Services essentiels généraux ... 136
4.7.6.5 Agents de soutien ... 136
4.8 Cadre ontique ... 136
4.8.1 Formalisme ... 137
4.8.2 Adéquation et vérité ... 137
4.8.3 Avantages et inconvénients du cadre ontique ... 138
Chapitre 5 ContextAA – Considérations architecturales ... 139
5.1 Hôte ... 139
5.1.1 Caractéristiques d’un Hôte ... 140
5.2 Objets autonomes ... 141
5.2.1 Canaux de Contexte ... 142
5.2.2 Canaux de Contexte et isolement des Agents ... 142
5.2.3 Gestionnaire d’Agents ... 143
xi
5.2.4.1 Découvreur ... 143
5.2.4.2 Émetteur ... 144
5.2.4.3 Récepteur ... 144
5.2.5 Interaction avec des composants tiers ... 144
Cycle de vie d’un Agent ... 145
5.3 Cycle d’opération d’un Agent ... 146
5.4 Concordance entre Contexte requis et Contexte offert ... 146
5.4.1 Équivalence entre Contextes ... 146
5.4.2 Mise en correspondance avec un modèle ... 147
5.4.2.1 Impact des qualifications d’accès au Contexte ... 148
5.4.2.2 Critères de Contextes ... 149
5.4.2.3 Transformations de Contextes ... 149
5.4.2.4 Autres opérations de Contexte ... 150
5.4.3 Fournisseur d’équivalences ... 151
5.5 Interaction avec capteurs et actuateurs ... 152
5.6 Interaction entre Hôtes ... 153
5.6.1 Déploiement d’un Agent ... 153
5.6.1.1 Ressources minimales d’un Agent ... 153
5.6.2 Migration d’un Agent ... 154
5.6.3 Mécanismes d’isolation ... 155
5.6.4 Actions différées ... 155
5.6.5 Mobilité et gestion de conflits ... 158
5.7 Temps ... 159
5.7.1 Moments d’un Agent ... 159
5.7.2 Ordonnancement chronologique global ... 160
5.7.3 Ordonnancement chronologique local ... 161
5.7.4 Ordonnancement chronologique entre Hôtes ... 161
5.8 Modèle de programmation ... 162
5.9 Spécifications techniques de ContextAA ... 162
Chapitre 6 Validation ... 164
6.1 Frugalité ... 164
xii
6.2.1 Distance structurelle ... 167
6.2.2 Distance de contenu ... 168
6.2.3 Autres constats empiriques ... 169
6.3 Scénarios de tests ... 170
6.3.1 Scénario – Ajustement des paramètres de confort ... 170
6.3.2 Scénario -- Continuité de service par voie de migration ... 171
6.3.3 Construction d’un modèle d’activité ... 173
6.3.4 Construire des domaines sémantiques dynamiques ... 174
6.4 Discussion ... 175
Conclusion ... 176
Annexe A Vocabulaire des noms de Contextes ... 180
Annexe B Expressions 𝒆𝒗𝒂𝒍 ... 182
Annexe C Critères de Contexte ... 183
Annexe D Transformations de Contexte ... 184
Annexe E Autres opérations de Contexte ... 185
Annexe F Principaux Agents standards ... 186
Annexe G Distance structurelle pour un ensemble de cas de tests ... 188
Annexe H Distance de contenu pour un ensemble de cas de tests ... 196
Annexe I Modèles de Contexte et mécanique de prise en charge ... 211
Requête ... 211
Réponse ... 211
Requêtes prises en charge ... 211
Transmission d’une requête publique – RequesterAgent ... 212
Prise en charge d’une requête locale – ResolverAgent ... 212
Annexe J Traduire de XML à Contexte et inversement ... 213
Annexe K Traduire de Contexte à JSON et inversement ... 215
Annexe L Automatiser l’interface avec des services tiers ... 217
Annexe M Implémentation de 𝝈 et de 𝝔 ... 218
xiii
Liste des abréviations
API Application Programming InterfaceBDI Belief-Desire-Intention
COM Component Object Model
CORBA Common Object Request Broker Architecture DCE Distributed Computing Environment
EBNF Extended Backus-Naur Form
FIPA Foundation for Intelligent Physical Agents
ICE Internet Communications Engine
IdO Internet des objets (Internet of Things)
IEEE Institute of Electrical and Electronics Engineers
IETF Internet Engineering Task Force
IIOP Internet Inter-ORB Protocol
ISO International Standards Organization
JADE Java Agent Development Framework
JCAF Java Context-Aware Framework
JSON JavaScript Object Notation
JVM Java Virtual Machine
MQTT Message Queue Telemetry Transport NAT Network Address Translation
OMG Object Management Group
OSGi Open Services Gateway initiative
OWL Web Ontology Language
PARC Palo Alto Research Center
ReST Representational State Transfer
RFID Radio-Frequency Identification
RMI Remote Method Invocation
RPC Remote Procedure Call
SOAP Simple Object Access Protocol
STL Stepanov and Lee (mieux connu sous le nom – erronné – de Standard Template Library)
URL Uniform Resource Locator
xiv UUID Universally Unique Identifier
WSDL Web Services Definition Language XDR eXternal Data Representation
xv
Liste des figures
Figure 1 - Isolation d'un Agent du réseau ... 4
Figure 2 - Interaction avec une technologie tierce ... 7
Figure 3 Architecture générale d'un système de gestion du contexte (reproduit de [101]) ... 39
Figure 4 - DOMUS, espace intelligent de la Faculté des sciences, Université de Sherbrooke ... 54
Figure 5 - Architecture globale soutenant à l'origine ContextAA ... 66
Figure 6 - Vue par strates d'un composant Hôte ... 69
Figure 7 - Contexte et forme arborescente ... 88
Figure 8 - Forme composite ou canonique ... 91
Figure 9 - Exemples d'équivalence entre noms ... 94
Figure 10 - Agent du domaine (forme générale) ... 128
Figure 11 - Chemin de 𝑺𝒂 à 𝑵𝒉 ... 135
Figure 12 - Composant Hôte (vue aérienne) ... 139
Figure 13 - Communication entre objet autonome et Agent standard (vue aérienne) ... 142
Figure 14 - Cycle de vie des Agents (vue générale) ... 145
Figure 15 - Cycle d'opération d'un Agent 𝒂 ... 146
Figure 16 - Vision arborescente d’un Agent ... 147
Figure 17 - Vision arborescente d'un Agent (section réponse) ... 148
Figure 18 - Non-condordance du Contexte local avec la « réalité physique » ... 156
Figure 19 Croissance de la consommation de mémoire vive en fonction du nombre d'Agents du domaine ... 165
Figure 20 - Similitudes entre 𝒄𝟎 et 𝒄𝟏𝟏, de même qu’entre 𝒄𝟑 et 𝒄𝟒 ... 168
Figure 21 - Agent requérant (maintien du confort) ... 171
Figure 22 - Agent migrateur ... 172
Figure 23 Types valeurs basés sur le Contexte selon [82] ... 174
Figure 24 - Traduction de XML à Contexte et inversement ... 213
xvi
Liste des tableaux
Table 1 - Exemples de tailles de Contextes ... 87
Table 2 - Exemples d'évaluation d'expressions par 𝒆𝒗𝒂𝒍 ... 107
Table 3 - Échantillon de test, évaluation de la distance sémantique ... 166
Table 4 - Vocabulaire de noms de Contextes ... 180
Table 5 - Expressions 𝒆𝒗𝒂𝒍 ... 182
Table 6 - Critères de Contexte ... 183
Table 7 - Transformations de Contexte ... 184
Table 8 - Autres opérations de Contexte ... 185
Table 9 - Distance structurelle (cas de tests) ... 188
Table 10 - Distance de contenu (cas de tests) ... 197 s
1
Chapitre 1
ContextAA – Introduction et motivation
« Il n'y a qu'une façon d'échouer, c'est d'abandonner avant d'avoir réussi ! » (Olivier Lockert / Hypnose)
L’informatique diffuse, suivant la vision énoncée par Mark Weiser [113], est cette tendance à faire en sorte que l’informatique se fonde dans le décor de la vie des individus. Plusieurs manifestations de cette vision existent au moment d’écrire ces lignes, allant des vêtements intelligents à la domotique; en même temps, le tout convergeant avec une démocratisation des ordinateurs prenant des formes de plus en plus conviviales (téléphones, tablettes et autres).
Un créneau important de la domotique est celui des espaces intelligents, enceintes capables d’offrir une gamme riche de services aux individus qui s’y trouvent. Les composants logiciels qui opèrent dans ces espaces sont en mesure de collaborer pour tirer profit de leurs forces mutuelles, partager de l’information et construire un contexte : une représentation logique de l’individu, de son milieu et de leur interaction.
Un espace intelligent est traditionnellement un environnement immersif aux frontières fixes : une chambre, un appartement, une maison. Le cas type de l’environnement intelligent est un domicile adapté aux besoins spécifiques d’un habitant déterminé, qu’il s’agisse de difficultés motrices, d’une forme de démence, de problèmes reliés au vieillissement, p. ex. : risques de chute menant à des blessures, et besoin de réagir rapidement si un tel événement survient. Dans un espace intelligent adapté à ses besoins, l’individu est accompagné, suivi et, en quelque sorte, protégé.
Lorsqu’un individu quitte un tel espace, toutefois, les services associés à l’espace ne peuvent plus lui être offerts. Ceci entraîne une discontinuité de service, sans qu’il n’y ait eu en contrepartie une discontinuité des besoins. Pour assurer la continuité des services dont dépend l’individu, il importe de faire en sorte que ces services ne soient pas liés à un lieu fixe, et soient plutôt en mesure d’accompagner l’individu dans ses déplacements.
Une convergence de technologies contemporaines ouvre des portes en ce sens : la connectivité accrue des appareils, qui tend vers ce que l’on nomme aujourd’hui l’Internet des objets (IdO); le fait que des ordinateurs grand public mais de format convivial soient désormais fortement répandus; la disponibilité de plus en plus grande de réseaux WiFi; etc. Assurer la continuité de services offerts à un individu mobile, à l’intérieur comme à l’extérieur des espaces intelligents traditionnels, devient véritablement possible.
1.1 Problématique
L’offre matérielle et logicielle existante dans le domaine des espaces intelligents tend à viser la résolution de problèmes concrets, comme la détection de chutes chez les personnes âgées, l’adaptation d’un lieu aux paramètres favorisant le confort d’un individu, ou encore la mise en place d’un suivi de prise de médicaments. Cette offre tend à être circonscrite dans l’espace : on parle typiquement de maisons intelligentes, par exemple, ou d’appartements intelligents.
2
La réalité contemporaine des individus ayant des besoins particuliers ne se limite toutefois pas à leur logis. Plusieurs se déplacent, vaquent à diverses occupations, travaillent à temps partiel, ont des loisirs. Les besoins des individus sont vastes, diversifiés, et ne s’estompent pas lorsqu’ils franchissent le pas de la porte de leur logis.
C’est pour cette raison que nous avons conçu ContextAA, que nous décrivons par la présente. Tirant son nom des Agents contextualisés (Context-Aware Agents) qui y opèrent, ContextAA vise à résoudre le problème de la continuité de service dans un contexte d’usagers mobiles à travers un environnement hétérogène où la qualité de la connectivité peut varier.
1.2 Proposition d’ensemble
Nous proposons donc par le présent document ContextAA, une solution qui se veut générale au problème de l’intelligence ambiante. Par intelligence ambiante, nous entendons d’abord un espace intelligent classique : une enceinte offrant des services aux individus qui s’y trouvent. Nous dénoterons parfois ces environnements par le vocable « espace classique ». Nous enrichissons cette acception classique des espaces intelligents pour en faire un espace sans frontières prédéterminées, dans lequel tout individu et tout agent est présumé capable de mobilité. Nous donnons à cet espace le nom d’espace intelligent ouvert, ou simplement « espace ouvert ».
Réaliser l’espace ouvert est une entreprise ambitieuse, nous le savons, puisqu’elle combine à la fois les défis des espaces intelligents classiques, ceux de la mobilité, et demande de faire certains choix, certains compromis dont nous discutons plus loin. Notre proposition pour réaliser cet objectif repose sur des Agents disséminés dans l’environnement, où chaque Agent doit accomplir une mission. Les Agents et ce sur quoi ils opèrent sont décrits dans un langage commun : le Contexte. L’emploi de majuscules est volontaire pour Contexte et Agent, et distingue l’acception technique de ces termes pour nos travaux du sens plus général généralement accordé à ces termes. Notre démarche est motivée de prime abord par un constat : bien qu’il soit possible de construire des environnements intelligents capables de prêter assistance de manière très spécialisée à des individus en fonction de leurs besoins, ces espaces sont typiquement délimités, et il se trouve que les besoins d’un individu bénéficiant d’un environnement intelligent ne deviennent pas caducs lorsque l’individu se déplace au-delà des frontières de cet environnement.
L’incapacité d’agents liés à un lieu spécifique d’offrir leurs services à un individu hors de ce lieu entraîne une discontinuité de services pour le bénéficiaire. Nous sommes d’avis qu’il est important, au moins pour certains services, de mettre en place les mécanismes nécessaires pour prévenir cette discontinuité. Pour cette raison, nous mettons de l’avant une démarche maximisant la continuité de service (§4.7.4), que nous quantifions à partir de la capacité qu’a un Agent d’accomplir pleinement sa mission (§3.4.3). En contrepartie, conscients que ce ne sont pas tous les environnements qui pourront offrir à l’usager une gamme de services aussi riche que celle offerte dans un espace intelligent, nous sommes disposés à accepter une fluctuation de la qualité de service à travers le temps et l’espace. Privilégier la continuité de service plutôt que la qualité de service est un compromis que nous acceptons de faire.
Certains services requièrent le support d’un environnement intelligent riche. Pour cette raison, nous positionnons les espaces intelligents classiques comme des zones incluses dans l’espace intelligent ouvert. Nous préconisons qu’un Agent puisse utiliser les services d’un espace intelligent classique lorsque ceux-ci sont disponibles.
3
1.3 Survol de ContextAA
Nous appuyons notre proposition d’ensemble (§1.2) d’une architecture logicielle conçue pour rencontrer les défis de l’espace intelligent ouvert (§3.5) :
nous supposons que l’environnement contient des nœuds, qu’il s’agisse d’appareils mobiles, d’ordinateurs fixes, de composants matériels dédiés, … Les technologies et les ressources de ces nœuds sont présumées hétérogènes, en quantité comme en qualité, mais les nœuds participant à notre démarche doivent pouvoir communiquer entre eux. Notez que nous ne supposons pas une connectivité universelle, avec tout nœud et en tout temps; il nous suffit en principe que la connectivité avec chaque nœud soit possible;
nous déployons sur chaque nœud participant à notre architecture un composant Hôte (§3.5.1), adapté aux ressources qui y sont disponibles;
des Agents (§3.4) sont déployés sur chaque Hôte. Un Hôte prend en charge les Agents qui y sont déployés et assure la présence d’une gamme minimale de services pour ceux-ci, en particulier l’interaction avec des entités sur d’autres nœuds, incluant des composants de technologies tierces (§1.5.4);
chaque Agent cherche à accomplir une mission (§3.4). Un Agent connaît les contraintes, matérielles ou autres, auxquelles il est assujetti, et est en mesure de les communiquer à travers les services offerts par son Hôte. Chaque Agent est porteur d’un cadre ontique (§4.8); informellement, le cadre ontique d’un Agent constitue la vision subjective de ce qu’est un Contexte pertinent pour lui, donc de ce que sont les Contextes qui lui importent et les relations entre ces derniers;
un Agent est porteur des opérations qu’il doit réaliser pour accomplir sa mission. L’Agent est pour nous une entité autonome et dynamique, capable de s’adapter à son environnement, mais capable aussi de s’associer à d’autres au besoin dans la poursuite de sa mission. Un Agent peut migrer d’un Hôte à l’autre si cela lui permet de mieux poursuivre sa mission;
des entités satellites, nommées objets autonomes, gravitent autour d’un Hôte et réalisent les tâches qui ne s’inscrivent pas naturellement dans son cycle d’opérations, par exemple les entrées/sorties bloquantes;
le Contexte est le langage qui sous-tend notre proposition. Par le Contexte, nous décrivons les états de la réalité enrichie, les comportements des Agents, leur mission, leur cadre ontique, leurs besoins et contraintes en termes de ressources… Le Contexte, jouant à la fois les rôles de langage et de métalangage, se trouve au cœur de notre démarche.
1.4 Survol des principales orientations
Pour tenir compte des réalités matérielles des nœuds, dont les ressources sont susceptibles d’être limitées, la plateforme répartie faite de nos composants Hôtes est légère : presque tout s’y décrit dans un seul langage simple, et chaque Agent y opère selon une perspective locale, dans l’optique de favoriser une action autonomique (au sens de Kephart et Chess [58]) si nécessaire.
4
la première est d’encourager la continuité de service (§4.7.4). Tel que mentionné dans §1.5.2, nous acceptons de ne pas pouvoir garantir en tout temps un niveau de qualité de service analogue à celui possible dans un espace classique. Nous privilégions en retour une adaptation des Agents à l’environnement : les services riches d’un environnement intelligent classique peuvent être utilisés par nos Agents lorsque cela s’avère possible. En l’absence de tels services, notre optique est qu’un Agent doit d’abord assurer la continuité de ses services, quitte à réduire la gamme de services offerts à l’ensemble de ceux qui peuvent être assurés dans un espace aux ressources plus limitées;
la seconde est de préférer un cadre ontique subjectif et une syntaxe commune à une ontologie partagée. Nous supportons d’office des Agents autonomes et mobiles. Par autonomes, nous n’entendons pas solitaires ou isolés, mais bien capables d’action indépendante des autres Agents, et agissant d’abord en fonction de leur propre mission et de leur propre « savoir ». Nous mettons l’accent sur la capacité d’un Agent à demeurer opérationnel même s’il se trouve isolé des autres. Plutôt que d’imposer une ontologie commune aux Agents et de présumer la disponibilité de tiers pour soutenir l’Agent dans son raisonnement, nous amenons une approche subjective, le « Contexte-selon » (§3.6.2).
De par cette seconde orientation, l’Agent devient porteur d’une perspective propre, parfois même singulière, sur le Contexte. Le passage d’une ontologie partagée à un cadre ontique individuel influence notre définition d’un Agent. Pour éviter une cacophonie de perspectives sur le Contexte, nous automatisons la mise en correspondance des besoins d’un Agent, exprimés sous la forme de Contexte, avec le Contexte disponible pour cet Agent (§5.4).
1.5 Justification des choix architecturaux
Notre proposition tient compte de notre compréhension de certains mouvements technologiques contemporains majeurs, et met en relief les solutions que nous apportons à certains problèmes clés de l’espace ouvert tel que nous le concevons.
1.5.1 Diversification et hétérogénéité des espaces intelligents
Les espaces ubiquitaires sont de plus en plus diversifiés, de moins en moins homogènes. En milieu urbain, la variété de marques d’appareils, de technologies, de formats de données, etc. est en croissance soutenue, ce qui s’accompagne de l’émergence de recherches dans ce qu’on nomme les espaces ubiquitaires urbains [120], capables d’appréhender cette nouvelle réalité.
Nous abordons cette diversité et cette hétérogénéité en mettant en place des mécanismes pour maximiser l’adaptation des Agents à leur environnement. Comme le montre la figure 1, un Agent 𝑎 est isolé du voisinage réseau par son Hôte ℎ (§3.5.2), et ne connaît de l’espace ouvert que le contenu de son propre espace contextuel 𝑆𝑎 (§3.4.4). Un Hôte, quant à lui, transige avec les autres Hôtes et avec les entités tierces (§1.5.4) à travers des objets autonomes 𝑂𝑏𝑗 (§3.5.5); chacun des objets autonomes chargé d’interagir avec une entité tierce joue un rôle d’intermédiaire entre la technologie tierce en question et le monde pur Contexte que nous proposons.
h Sh a Sa h' a' Sa Obj Obj
5
La diversification des nœuds s’accompagne d’une connectivité croissante avec une multitude d’appareils de la vie courante, ce qui laisse envisager une nouvelle réalité, souvent nommée Internet des objets (Internet of Things1), que nous abrégerons par IdO : un espace ubiquitaire constitué
d’une vaste quantité d’appareils capables de communication. Ces nœuds, aux ressources souvent limitées, sont autant de possibilités pour déployer des Hôtes et loger d’éventuels Agents cherchant à accompagner un individu mobile. Pour être en mesure de profiter même des nœuds aux ressources limitées, notre proposition vise à être peu coûteuse en termes de ressources, comme en font foi nos choix technologiques et notre approche axée sur le seul langage du Contexte.
La croissance de la diversité des nœuds et de leur potentiel de connectivité ne garantit pas qu’un Agent soit en tout temps capable d’interagir avec son environnement. Nous estimons probable qu’un Agent se trouve occasionnellement dans des lieux où la connectivité et imparfaite ou nulle, ou encore là où les nœuds avoisinants ne correspondent pas à ses besoins, peu importe la raison. Conséquemment, la capacité pour un Agent d’agir de manière autonome nous semble être une caractéristique importante d’une conception pour l’espace intelligent ouvert. Notre approche pour la gestion de la discontinuité de connectivité passe par un mécanisme d’isolation, décrit à §5.6.3, à partir duquel la connectivité n’est pas un phénomène directement observable par les Agents. Même entre Hôtes, donc entre entités opérant sur la base de Contexte, nous préconisons de réduire au minimum les exigences de conformité. Le choix d’appliquer un cadre ontique subjectif à chaque Agent plutôt que d’imposer une ontologie commune à tous les Agents, tout comme le fait de faire reposer l’interopérabilité des Agents sur la syntaxe du Contexte plutôt que sur sa sémantique, découlent de notre acceptation du caractère limité de ce que connaît a priori un Agent ou un Hôte : nous mettons l’accent sur la capacité d’apprendre, et d’oublier, du Contexte, de même que sur l’évaluation de la proximité (ou de la distance) sémantique entre deux Contextes.
1.5.2 Connectivité imparfaite et exigence d’autonomie
Un Agent capable de s’adapter à son environnement est, à notre avis, mieux équipé pour faire face à la diversité décrite ci-dessus et en tirer profit. C’est pourquoi nous mettons de l’avant une exigence d’autonomie chez les Agents, exigence que sous-tend notre proposition architecturale dans son ensemble. Dans notre approche, faire en sorte que l’Agent du domaine n’interagisse qu’avec son espace contextuel isole cet Agent des fluctuations du voisinage réseau et permet un raisonnement ne reposant que sur du connu pour cet Agent.
Déplacer le raisonnement vers l’espace contextuel de l’Agent permet de restreindre les impacts d’une connectivité imparfaite. Techniquement, même si son Hôte est incapable d’entrer en communication avec d’autres Hôtes ou avec des entités tierces, l’Agent demeure actif sur la base de son connu jusqu’alors.
6
Ce choix architectural met en relief l’équilibre entre continuité de service et qualité de service : sur la base des choix que nous avons faits, en particulier celui d’isoler l’Agent du voisinage réseau, un Agent ayant pour mission d’assurer un environnement adéquat à un individu ne cesserait pas de travailler en ce sens s’il est coupé des capteurs lui décrivant l’état « actuel » de l’environnement de cet individu; l’Agent poursuivrait au contraire sa mission, et chercherait à guider les actuateurs en fonction des objectifs visés, tout comme l’Agent sur chaque actuateur chercherait à répondre aux demandes reçues tout en s’assurant que ses paramètres de sécurité soient respectés. Le Contexte-selon et la poursuite par chaque Agent d’une mission qui est la sienne peuvent mener à des conflits, ce dont tient compte notre proposition.
1.5.3 Simplification des mécanismes de raisonnement et de déploiement
Nous faisons le choix de représenter les Agents du domaine, les données et les opérations sur des données par un seul et même format, soit le Contexte. Ceci permet entre autres de raisonner sur le Contexte et de gérer les Agents à partir d’un seul et même moteur, tout comme cela permet de faire migrer un Agent entre deux Hôtes aussi simplement qu’en faisant migrer son espace contextuel. Cette façon de faire est pour nous une simplification des mécanismes de raisonnement et de déploiement. Nous disons du raisonnement qu’il est simplifié car il ne repose que sur un seul format de données, le Contexte, et ne nécessite pas de cas particuliers pour les données, les Agents, les opérations, etc. Ceci ouvre la porte à une réduction de la taille du processus Hôte dans son ensemble, et au déploiement d’un Hôte sur un nœud aux ressources limitées.
Nous disons du déploiement des Agents qu’il est simplifié du fait qu’outre l’encadrement du processus, qui implique entre autres de détecter les conditions propices à la migration d’un Agent, de repérer une destination adéquate pour ce dernier et de s’assurer que l’Hôte destinataire est disposé à l’accueillir, le transfert en soi de l’Agent est un transfert de Contexte, un problème « réglé » dans notre architecture parce que nécessaire a priori à son bon fonctionnement.
1.5.4 Intégration à l’existant
La plupart des cadriciels d’agents répartis et d’entités contextualisées répertoriés à la section §2.4 proposent des infrastructures stratifiées et procèdent par offre et consommation de services, comme le montrent entre autres [29, 42, 101]. En ce sens, notre approche « pur Contexte », qui repose sur l’automatisation de la circulation de Contexte en fonction de la mise en correspondance de Contextes publiés par divers Agents, est un peu hors-normes.
Bien qu’étant hors-normes, notre proposition se doit de permettre l’interaction avec l’existant, avec les technologies tierces qui adressent des problèmes connexes à ceux qui nous intéressent.
En pratique, hors de son propre écosystème pur Contexte, un Hôte est susceptible d’interagir avec : des infrastructures existantes, telles que Jade, Jini ou des composants OSGi pour n’en nommer
que quelques-unes;
la plateforme sous-jacente, donc le nœud en tant que tel, typiquement à travers son système d’exploitation. Ceci inclut entre autres l’interaction des Agents avec des capteurs et des actuateurs. Nous en faisons mention ici du fait que les modalités pour permettre l’interaction entre le nœud et les Agents sont semblables à celles permettant l’interaction entre l’Hôte et les technologies tierces; et
7
des formats de données, par exemple XML ou JSON, et des protocoles spécialisés tels que FIPA ou Java RMI.
La plupart des technologies permettent aux agents d’exposer et de consommer des services. Les interfaces de ces services sont typiquement compréhensibles par le consommateur, que ce soit par réflexivité ou par analyse d’un descriptif d’interface, WSDL ou autre. Pour assurer une interaction avec les composants de technologies tierces, il faut à tout le moins que notre proposition puisse découvrir des services, assurer l’interopérabilité avec ceux-ci, de même que consommer et produire des données dans des formats autres que le Contexte.
Le Contexte tel que nous le définissons peut en grande partie être converti de manière automatique dans des formats tels que XML ou JSON, et il est souvent possible de faire la transformation inverse (annexe J). Pour que les Agents dans notre modèle demeurent « pur Contexte », et assurer l’homogénéité opératoire de notre modèle, nous réalisons la jonction entre le fonctionnement « pur Contexte » et les technologies tierces en périphérie d’un Hôte, par l’interaction de deux mécanismes :
h Sh a Sa a' Sa’ O
Figure 2 - Interaction avec une technologie tierce
les Agents standards, par exemple 𝑎′ dans la figure 2, implémentent les actions qui peuvent se
faire sans nuire au cycle d’opération des Agents. Dans ce cas, l’Agent prend sur lui de représenter par du Contexte les états pertinents du nœud sous-jacent et les actions qu’il est possible d’y effectuer, et accepte sous forme de Contexte des demandes d’actions à poser qu’il pourra réaliser par la suite; et
les objets autonomes, par exemple 𝑂 dans la figure 2, dans le cas où l’interaction se fait avec un nœud ou un service externe à l’Hôte et au nœud sous-jacent, ou encore lorsque l’interaction demande d’entreprendre des actions qui nuiraient au cycle d’opération des Agents.
Bien que l’automatisation de la génération des interfaces avec des services tiers soit possible, ce volet de ContextAA fait partie de travaux en cours et sera réalisé dans un projet à part entière. Voir l’annexe L pour quelques avenues à explorer en ce sens.
1.6 Motivations d’une démarche novatrice
L’impulsion derrière nos travaux tient à la réalité d’espaces intelligents existants, où nous faisons déjà face au problème de discontinuité de service pour les usagers mobiles et où nous avons noté l’absence de solution générale à ce problème.
De prime abord, nous avons fait le constat que bien qu’il soit possible d’accompagner des individus dans un espace délimité tel qu’un environnement intelligent classique, la mobilité des individus leur permet de ne pas demeurer confinés à un tel espace.
Conscients du fait que les besoins individuels couverts par un environnement intelligent ne disparaissent pas nécessairement chez un individu qui quitte un tel espace, nous avons réfléchi à une solution basée sur des agents mobiles, capables d’accompagner l’individu dans ses déplacements. Nous souhaitions une approche peu coûteuse en termes de ressources, pour exploiter un maximum de nœuds possibles, tout comme nous souhaitions une solution qui ne soit pas rattachée à un seul langage de programmation ou à une seule plateforme.
8
Un examen des solutions existantes, fait à la section §2.4, a permis de constater qu’il serait préférable de mettre au point notre propre infrastructure, du fait que les plus populaires des infrastructures existantes (en particulier [5, 54]) reposaient sur une machine virtuelle commerciale (la JVM de Java), ce qui est avantageux sur le plan des services offerts a priori mais trop coûteux en termes de ressources pour certains des nœuds sur lesquels nous pouvions envisager déployer nos composants. Nous avons plutôt fait le choix de développer un composant Hôte, qui jouera le rôle d’une machine virtuelle sans en être une, et de le faire dans un langage qui donnerait un contrôle plus complet sur la gestion des ressources.
Notre perspective sur ce qui deviendrait l’espace intelligent ouvert impliquait plusieurs a priori architecturaux : la connectivité non-garantie et l’accent que nous avons choisis de mettre sur la continuité de services ont permis de mettre de l’avant l’intérêt d’avoir des agents autonomes, peu ou pas dépendants en pratique de tiers spécialisés ou de nœuds clés (§3.4). La continuité de service suggérait aussi l’intérêt pour un Agent d’être en mesure de poursuivre sa mission, donc de migrer d’un substrat à l’autre si les ressources venaient à manquer. L’objectif d’autonomie pour les agents, joint à celui d’une infrastructure peu coûteuse en termes de ressources, nous a amenés à envisager ce qui deviendrait le cadre ontique, sorte d’ontologie propre à un agent, donnant naissance au Contexte-selon qui sous-tend notre démarche.
L’un des aspects où nous estimions pouvoir innover, réduire la consommation de ressources et gagner en flexibilité fut le choix d’un langage spécifiquement pensé pour le Contexte (§4.3). Suite à un examen des catégories traditionnelles du Contexte (temps, lieu, environnement, usager, etc.), et au constat dans la littérature existante de nombreuses applications utilisant des formats spécialisés (§2.2), nous avons fait le choix d’un format minimaliste permettant de maximiser la capacité de représentation du contexte, tout en restant dissocié de la sémantique applicative de cas d’espèces existants. Les travaux sur ce format nous ont permis de constater que la dissociation du langage et de sa sémantique facilitait l’expression d’opérations fécondes, comme la mise en correspondance structurelle et sémantique de Contextes sur la seule base d’une syntaxe commune, ou encore l’automatisation du calcul de la distance entre deux Contextes. Éventuellement, il est devenu clair que le Contexte permettait même de représenter les Agents et leurs opérations, et qu’une conséquence directe de ce constat était que faire migrer un Agent d’un Hôte vers un autre était devenu l’équivalent technique de transmettre un Contexte entre eux.
Les fondements théoriques de nos travaux (chapitre 4) ont évolué côte à côte avec la conception d’un composant Hôte (§3.5.1), lieu où sont déployés les Agents. Nous avons fait progresser les volets conceptuel et technique main dans la main, validant nos idées de manière concrète et assurant du même coup que notre démarche demeurait pragmatique, même pour des systèmes embarqués et aux ressources restreintes.
Une partie de notre proposition nait de réflexions quant au caractère multidisciplinaire de la conception des espaces intelligents. Certains éléments architecturaux tels que les objets autonomes (§3.5.5) et les canaux de Contexte (§3.5.6) visent en partie à simplifier le raisonnement quant au comportement d’un Agent, sans compromettre les caractéristiques opératoires d’un Hôte. Isoler les Agents du réseau et des problèmes associés à la concurrence évacue ces questions de l’élaboration des tâches que les Agents doivent accomplir, ce qui vise à faciliter la mise à contribution de spécialistes non-informaticiens dans la conception d’un Agent.
9
le chapitre 2 met en relief l’état des connaissances dans quelques-uns des créneaux connexes à nos travaux dans l’espace intelligent ouvert;
les chapitres 3, 4 et 5 visent à décrire ce qu’on pourrait qualifier du « cœur » de ContextAA : le chapitre 3 établit l’usage que nous faisons de certains termes clés, en particulier dans
l’acception spécifique et technique que leur confèrent nos travaux. Ainsi, ce chapitre montre comment ContextAA permet d’adresser les problèmes de l’espace intelligent ouvert;
le chapitre 4 décrit le modèle théorique qui sous-tend notre démarche. Y sont entre autres décrits le langage qu’est le Contexte, les opérations sur le Contexte, la mise en correspondance de Contextes et les Agents de ContextAA;
le chapitre 5 détaille les éléments architecturaux par lesquels nous avons réalisé ce modèle, incluant les composants Hôtes, les objets autonomes et les interactions entre Hôtes;
le chapitre 6 fait état de la démarche de validation en cours pour ContextAA;
enfin, une conclusion permet de faire le point sur l’état de nos travaux et de décrire les directions vers lesquelles nous sommes engagés pour le proche futur.
10
Chapitre 2
État des connaissances
« Les grandes connaissances engendrent les grands doutes » (Aristote / Les entretiens – IVe s. av. J.-C.)
Ce chapitre a pour objectif de situer l’état des connaissances dans les domaines ayant trait aux points d’intérêt de nos travaux, soit les systèmes répartis, les systèmes multi-agents, le Contexte et la contextualisation, de même que les espaces intelligents. Chacun de ces sujets étant vaste, nous limitons notre survol aux parties de ces champs d’étude qui convergent dans une direction connexe à la nôtre, touchant au passage certains créneaux proches du nôtre mais que nous avons choisi de ne pas explorer.
Il deviendra rapidement clair que les environnements intelligents existants offrent des services riches aux individus qui les habitent, mais ont des défauts conséquents avec leurs qualités, c’est-à-dire que la richesse de leur offre de services tient à leur situation, soit celle d’un lieu délimité dans l’espace et dans lequel les outils disponibles sont de grande qualité. Les systèmes pensés pour ces environnements profitent de leurs forces mais ont une portée délimitée par les limites de ces environnements.
Dans cette section, tout en décrivant l’état des connaissances, nous prenons soin de cibler là où nous pensons offrir, par un changement de perspective et une approche technologique différente, des outils qui permettront de transcender les limites des espaces existants pour enrichir l’offre de services qu’ils rendent disponible, tout en poursuivant la collaboration avec leurs services lorsque cela s’avère opportun. Les constats que nous ferons serviront d’assise pour la conception de ContextAA telle que décrit au Chapitre 3.
2.1 Environnements intelligents
Les postes de travail virtuels, mieux connus sous le nom d’ordinateurs personnels aujourd’hui et depuis l’époque où ils furent pensés au Palo Alto Research Center (PARC) comme depuis la commercialisation du premier appareil Macintosh d’Apple, en 1984, proposent aux usagers une représentation interactive d’entités logicielles à travers des métaphores du « monde réel » : des dossiers, qui contiennent des fichiers; une corbeille à recyclage; une interaction basée sur le principe du pointage et de la sélection par un ou plusieurs clics; le glissement d’un document d’un « endroit » à l’autre en le glissant à l’écran… Cette métaphore est d’ailleurs amenée plus loin encore avec les écrans tactiles contemporains qu’on retrouve sur plusieurs appareils contemporains tels que les téléphones intelligents et les tablettes.
Nous utilisons informellement le vocable espace physique pour faire référence à l’espace dans lequel vivent les humains. Nous nommons tout aussi informellement espace logique ce dans quoi s’exécutent les composants logiciels. Nous ne considérons pas l’un ou l’autre de ces espaces comme « plus réel » que l’autre; en effet, les interactions entre l’espace logique et l’espace physique sont si nombreuses que ces deux espaces sont devenus interdépendants.
11
Il est possible de voir l’interface entre les humains et la machine comme une entité jouant un double rôle, soit celui de représenter et filtrer l’information d’une part et celui de valider les entrées de données et les opérations entreprises d’autre part. Offrir une métaphore qui adapte le logiciel aux attentes des humains, tout en formalisant les deux extrémités de cette interface, eut un impact considérable sur l’acceptation de la machine par les humains, de même que sur l’avènement de l’ère de l’information [15].
Malgré ce rapprochement, l’espace physique et l’espace logique sont longtemps demeurés séparés, distincts, chacun de son côté de l’interface décrite par les périphériques d’entrée/ sortie que sont la souris, l’écran, les haut-parleurs, etc. Un impact de leur intégration graduelle fut d’accroître fortement la productivité des individus et l’interactivité entre composants de ces deux espaces [27]. Suivant [93], nous nommons espace intelligent, ou réalité enrichie, l’espace synthétique résultant de la jonction des espaces physique et logique et de leur interaction.
Si la métaphore du bureau de travail virtuel a transformé l’ordinateur en commodité courante accessible aux non-spécialistes, et si les téléphones intelligents, tablettes et autres appareils contemporains ont accéléré ce processus d’acceptation sociale de la technologie, l’informatique ubiquitaire (Ubiquitous Computing) et les espaces intelligents poussent plus loin encore la métaphore en cherchant à intégrer les réalités physique et logique sous un angle différent. Plutôt que de proposer une interface à travers des appareils spécialisés comme des ordinateurs, l’informatique ubiquitaire passe plutôt par de nombreux (et souvent petits) appareils disséminés dans l’espace physique, appareils qui ne ressemblent pas nécessairement à des ordinateurs.
Depuis ses débuts, l’un des principaux objectifs de l’informatique ubiquitaire est de faire en sorte que les interfaces manifestes entre les espaces logique et physique disparaissent, se fondent en quelque sorte dans le décor, là où elles demeureront utiles sans par ailleurs perturber les humains dans leurs activités, pour dépasser la métaphore du bureau de travail virtuel [113].
La vision mise de l’avant par Weiser [113] se rapproche de celle de la réalité augmentée : plutôt que de chercher à intégrer les humains dans un espace logique, cette vision préconise d’intégrer les composants du monde logique dans l’espace physique, de manière à les rendre essentiellement invisibles pour les humains qui l’habitent.
Puisque les espaces logique et physique sont distincts mais interdépendants, ceux-ci interagissent à travers une interface. En informatique ubiquitaire, cette interface est constituée d’un ensemble d’appareils, chacun existant en quelque sorte à la fois dans l’espace logique, interagissant avec les autres appareils, et dans l’espace physique, participant à l’environnement des humains. Les capteurs saisissent l’information de l’espace physique et l’exposent au monde logique dans un format susceptible d’y être utile, alors que les actuateurs transforment des requêtes provenant du monde logique en actions sur le monde physique.
Certains prétendent que dans un monde idéal, cette interface entre les mondes physique et logique ne devrait pas être perceptible par des humains, sauf peut-être dans le cas de composants conçus expressément dans cette optique : « The most profound technologies are those that disappear. They
weave themselves into the fabric of everyday life until they are indistinguishable from it. »2 [113].
En ce sens, l’informatique ubiquitaire est parfois aussi qualifiée de « technologie calme ».
12
« Technologies encalm as they empower our periphery. This happens in two
ways. First, […] a calming technology may be one that easily moves from center to periphery and back. Second, a technology may enhance our peripheral reach by bringing more details into the periphery. […] The result of calm technology is to put us at home, in a familiar place. »3 [114]
La vision proposée par Weiser est empreinte de défis, et a donné une impulsion à quantité de recherches en informatique ubiquitaire, en particulier dans les créneaux des systèmes intelligents prêtant assistance aux humains de manière réactive ou proactive. Cette vision a bien sûr ses critiques, en particulier ceux qui, à la manière de Chmiel et al. [23], suggèrent que la recherche soit orientée vers l’amplification de l’intelligence humaine plutôt que vers l’intelligence artificielle. À titre d’exemple, selon Rogers [89] :
« [some argue] for a significant shift from proactive computing to proactive
people; where UbiComp technologies are designed not to do things for people but to […] enable people to do what they want […]. Instead of embedding pervasive computing everywhere in the environment it considers how UbiComp technologies can be created as ensembles or ecologies of resources, that can be mobile and/or fixed, to serve specific purposes and be situated in particular places. »4 [89]
En résumé, l’informatique ubiquitaire peut être perçue comme une manière non-intrusive de fondre les espaces physique et logique de manière à ce que l’espace résultant soit une réalité enrichie, accroissant par le fait-même le potentiel de chacun.
La mouvance de l’IdO, devenue populaire pendant que nos travaux sur ContextAA suivaient leur cours, préconise la dissémination dans l’environnement d’objets connectés et chargés d’une forme d’intelligence. Cette mouvance suppose une connectivité pleine et entière des objets, et permet à ces derniers de participer aux tâches quotidiennes des humains : un réfrigérateur qui supervise les dates de péremption des aliments qui y sont entreposés et propose une liste d’épicerie adaptée en conséquence, tenant compte des rabais à l’épicerie de prédilection de ses propriétaires, est un exemple d’un tel objet.
3 Les technologies calment quand elles enrichissent la périphérie de notre environnement, que ce soit parce qu’elles se
déplacent aisément entre le centre et la périphérie ou parce qu’elles étendent notre portée en accroissant le détail de la périphérie. Une technologie calme évite les bris de familiarité. (Traduction libre)
4 Certains préconisent un changement de perspective, passant de l’informatique proactive aux humains proactifs, où
les technologies ubiquitaires seraient conçues non pas en fonction de faire des choses pour les gens mais bien en fonction d’aider les gens à faire ce qu’ils souhaitent faire. Plutôt que d’intégrer les composants ubiquitaires partout dans l’environnement, ceux-ci estiment que les technologies ubiquitaires devraient constituer un ensemble de ressources, mobiles ou fixes, jouant des rôles définis et placés à des endroits précis. (Traduction libre)
13 Dans un survol de l’IdO, Rose [90] relate :
« The term “Internet of Things” (IoT) was first used in 1999 by British
technology pioneer Kevin Ashton to describe a system in which objects in the physical world could be connected to the Internet by sensors. Ashton coined the term to illustrate the power of connecting Radio-Frequency Identification (RFID) tags used in corporate supply chains to the Internet in order to count and track goods without the need for human intervention. Today, the Internet of Things has become a popular term for describing scenarios in which Internet connectivity and computing capability extend to a variety of objects, devices, sensors, and everyday Items »5 [90]
L’IdO est typiquement pensée comme un enrichissement de l’environnement immédiat des humains, et s’inscrit donc dans la conception d’espaces intelligents traditionnels, mais dans une optique de démocratisation de ces espaces : la production accrue d’appareils capables de participer à l’IdO a un impact sur les prix, de telle sorte qu’il est possible de faire l’acquisition d’appareils participant à cette mouvance en ligne ou dans des commerces conventionnels [3]. Comme le mettent de l’avant les travaux de Tao et al. [108], l’IdO est aussi une approche visant à faciliter l’interopérabilité d’appareils a priori hétérogènes :
« IoT does not refer to a single technology but, instead, to a new paradigm
characterized by the pervasive presence around us of a variety of objects (referred as‘things’) participating into the domestic activities […] connected (sic.) each other [and] able to interact and cooperate in order to achieve common home-related goals »6 [108]
Cette démocratisation des espaces intelligents rejoint certains objectifs de ContextAA, qui facilite par design la détection des participants à l’espace intelligent et fait passer les échanges avec ceux-ci par le langage du Contexte. Contrairement à l’IdO, toutefois, ContextAA ne suppose pas une connectivité pleine et entière, et met l’accent sur l’adaptation du système à l’environnement plutôt que sur l’adaptation de l’environnement aux besoins d’un individu. En ce sens, les deux approches sont complémentaires.
5 La paternité du terme “Internet of Things” (Internet des objets, IdO) est attribuée à Kevin Ashton en 1999 et visait à
décrire un système où les objets du monde physique pourraient être connectés à Internet par voie de capteurs. Ashton utilisait le terme pour illustrer la puissance des étiquettes RFID pour tracer des objets de consommation par Internet sans intervention humaine. Aujourd’hui, IdO est un terme populaire pour décrire des scénarios où la connectivité avec Internet s’étend à une vaste gamme d’objets de la vie courante. (Traduction libre)
6 L’IdO n’est pas une technologie spécifique mais bien un nouveau paradigme charactérisé par la présence autour de
nous d’une variété d’objets (de ‘choses’) participant aux activités domestiques, interconnectées et capables de collaboration dans la poursuite d’un objectif commun. (Traduction libre)
14
Une autre mouvance connexe à ContextAA et à l’IdO est celle des environnements ubiquitaires urbains, où la caractéristique première est la diversité technologique et protocolaire [99]. À titre d’exemple de tels environnements, certaines villes se disent désormais « intelligentes », bien que ce qualificatif ait un sens variant fortement selon les lieux [79]. Pour plusieurs villes, cette intelligence vise surtout l’offre de services pour identifier les lieux où il est possible de garer un véhicule ou un signalement aux intéressés de retards possibles dans le réseau de transport en commun. Généralement, les villes intelligentes accroissent l’offre de réseaux sans fils pour accroître la connectivité des individus et faciliter l’accès aux services offerts. S’ajoutent à cela des capteurs pour améliorer la fluidité des déplacements des gens (indications juste-à-temps du trafic, feux de circulation adaptatifs et autres), de la luminosité intelligente dans les rues, une meilleure détection de l’amoncellement de déchets, etc.
Constat 1 : un environnement ubiquitaire urbain se présente comme une offre diversifiée (certains diraient disparate) de services. L’évolution des villes qui se veulent de plus en plus intelligentes annonce un accroissement de la présence de ces environnements. Les espaces intelligents traditionnels sont typiquement des environnements riches en services mais délimités dans l’espace : « Intelligent Space […] denotes an environment containing a set of
interacting Context providers and consumers »7 [93]. La richesse de leur offre de services fait de
ces espaces un milieu privilégié d’expérimentation et de développement de solutions visant en particulier l’amélioration des conditions de vie des individus. Ils ne sont toutefois pas les seuls types d’environnements intelligents possibles en pratique.
Des études ont été faites sur les espaces intelligents nomadiques, ensembles fédérés d’espaces intelligents entre lesquels se déplace un usager, et ont de ce fait abordé la question du transfert de données d’un espace intelligent à l’autre. Yang [117] offre un plaidoyer pour assurer une continuité de services pour des usagers mobiles, et soutenant cette approche :
« As people get used to new technology, they come to expect its availability, and
dependency on the technology grows. This is especially true of smart spaces because their goal is to embed technology into living environments, which can greatly impact many daily activity routines. Consider an elder person with early-stage Alzheimer, whose independent living depends on a cognitive assistance service that cues her to finish tasks she has started. When she leaves her apartment to go to the grocery store, she still counts on receiving the same kind of help. This is why we must have nomadic pervasive computing, so that critical services are not lost just because the user leaves her home space »8 [117]
7 L’espace intelligent identifie un environnement contenant un ensemble de producteurs et de consommateurs de
Contexte en interaction les uns avec les autres (Traduction libre)
8 En s’habituant aux nouvelles technologies, les gens en viennent à dépendre de leur disponibilité. Ceci est
particulièrement vrai des espaces intelligents, ce qui impacte plusieurs activités du quotidien. Prenons pour exemple une personne souffrant de la maladie d’Alzheimer, qui dépend de l’assistance de son environnement pour terminer les tâches qu’elle entreprend; cette personne a encore besoin d’aide lorsqu’elle fait son épicerie. C’est ce qui explique le besoin d’espaces intelligents nomadiques (Traduction libre)
![Figure 3 Architecture générale d'un système de gestion du contexte (reproduit de [101])](https://thumb-eu.123doks.com/thumbv2/123doknet/2878707.72797/55.918.268.652.378.747/figure-architecture-générale-système-gestion-contexte-reproduit.webp)
