3.2 Modèle des applications IoT
3.2.1 Représentation de l’application
3.3 Modèle de l’infrastructure Fog . . . . 80
3.3.1 Les noeuds de l’infrastructure . . . . 82 3.3.2 Les liens réseau . . . . 83
3.4 Formulation du problème de placement de services . . . . . 85
3.4.1 La consommation énergétique . . . . 85 3.4.2 Violations des délais . . . . 86 3.4.3 Fonction objectif . . . . 87
3.5 Approches de résolution . . . . 87
3.5.1 Optimisation Discrète par essaims particulaires (DPSO) . . . 87 3.5.2 Algorithme Génétique (GA) . . . . 98
3.6 Résultats . . . 100
3.6.1 Test du DPSO et des heuristiques pour le placement de services101 3.6.2 Test du DPSO et des méta-heuristiques pour le placement
sta-tique . . . . 107
3.7 Bilan des expérimentations et amélioration des approches
de placement . . . 115
3.8 Synthèse . . . 118
3.1 Introduction
Considérer un problème de placement de services dans un environnement statique (sans mobilité de noeuds) est une approche qui a pour avantage d’an-ticiper ou d’estimer les besoins en calculs et en communications d’une zone Fog donnée. Cette approche se fait dans le cadre des études pour le dimen-sionnement des infrastructures. Les gestionnaires d’infrastructures réseau et de calculs doivent effectuer cette étude pour minimiser leurs coûts d’inves-tissement et d’opération tout en estimant les éventuels besoins utilisateurs.
Dans ce chapitre nous posons le modèle mathématique de notre système Fog-IoT dans un environnement statique, la représentation de l’infrastructure Fog, des applications IoT ainsi que le modèle de consommation énergétique et la métrique représentant la qualité de service (QoS) d’une application. Nous for-mulons ensuite le problème de placement hors ligne des services IoT dans l’infrastructure Fog avec pour objectif de minimiser la consommation énergé-tique de l’infrastructure et les violations des délais de réponse des applications IoT.
3.2 Modèle des applications IoT
On considère des applications IoT multi-services faisant partie de la caté-gorie de workflow de services déterministes définis dans la section 1.5.1 du cha-pitre 2. La topologie d’une application est représentée par un graphe orienté de services qui s’échangent des données. Cette représentation est utilisée dans plusieurs travaux sur l’IoT dont [Buyya 2019], [Giang 2015] et [Hilman 2020]. La figure 3.1 donne un exemple de topologie.
3.2.1 Représentation de l’application
Une application ai est composée d’un nombre ni de services. Les interac-tions entre les services et leurs dépendances sont représentées par un graphe orienté Gi = (Si, Ei). Les noeuds de l’ensemble Si représentent les services de l’application et les arcs du graphe de l’ensemble Ei représentent la dépen-dance de données entre les différents services. Le service initial ou la source du graphe est une abstraction du capteur de l’application si
0 et le dernier service
sini+1 représente l’actionneur de l’application.
3.2.1.1 Les services
Une application IoT reçoit des données de l’environnement extérieur par l’intermédiaire de capteurs. Ces données transitent dans le réseau et sont trai-tées par un ensemble de services virtuels. Par la suite, des instructions sont transmises vers les actionneurs. À partir de la définition précédente, nous pou-vons décomposer les services d’une application IoT en plusieurs catégories.
Un service si
j ∈ Si peut faire partie de l’une des catégories suivantes :
(1) Service source de génération de données (capteur)
Nous considérons un service fictif source si
0 qui représente le capteur de l’équipement utilisateur de l’application. Ce dernier sera chargé d’envoyer les données avec une certaine fréquence freqi
0 suivant un modèle ou une distri-bution de probabilité adéquate.
(2) Service destination/puis (actionneur)
Le service destination si
ni+1 est un service fictif représentant le capteur du noeud utilisateur, qui va recevoir des instructions.
(3) Service de traitement flux
Un service de traitement de flux est un service faisant partie de l’ensemble des services qui traitent les données transitant du capteur vers l’actionneur.
(4) Service d’analyse
Un service d’analyse est un service qui ne fait pas partie de l’ensemble des services à traitement de flux. C’est-à-dire qu’il ne se trouve pas dans un chemin de données (chemin dit critique) allant d’un capteur vers son actionneur. Les services d’analyse n’interagissent pas (ou interagissent très rarement) avec l’utilisateur (noeud IoT) et sont utilisés à des fin d’analyses à long terme des performances de l’application et du comportement des noeuds utilisateurs.
Un service si
j de traitement de flux ou d’analyse est l’abstraction d’une entité de calcul virtuelle telle qu’une machine virtuelle ou des containers, ils sont définis par les caractéristiques suivantes :
— teci
j : représente la technologie de déploiement du service : machine virtuelle (VM), container (CT) ou Bundles OSGi etc.
— insti
j représente la quantité d’instructions CPU, en Millions d’instruc-tions (MI) que devra traiter le service à la réception de chaque flux de données.
— rami
j : représente les besoins en mémoire vive en MB. — di
j : représente le délai d’exécution maximal du service si
j en secondes. — predi
j : représente l’ensemble des services prédécesseurs de si
j dans le graphe.
— succi
j : représente l’ensemble des services successeurs du services si
j dans
le graphe.
3.2.1.2 Liens et dépendances entre les services IoT
Chaque arc orienté ei
jj0 ∈ Ei, allant du service si
j au service si
j0 représente une dépendance de données entre eux. L’arc ei
jj0 est défini par les informations suivantes :
— datai
jj0 : représente le volume de données en kB, échangés entre si
j et
si
j0 et qui traverse le réseau à chaque communication. — di
jj0 : représente le délai de communication maximal entre si j et si
j0 en secondes.
Figure 3.1 – Représentation de la topologie d’une application mettant en évidence les chemins critiques et les différentes catégories de services définies dans cette section.
3.2.1.3 Ensemble de chemins critiques CPi
Une application IoT peut être composée de plusieurs types de services. Les chemins critiques sont définis par les développeurs de l’application et déterminent un ensemble de services de traitement de flux et d’arcs allant du capteur à l’actionneur.
Une application possède au moins un chemin critique. Un chemin critique
cpi
q ∈ CPi est une séquence simple (les arcs ne se répètent pas) et finie d’arcs orientés dans la même direction appartenant à l’ensemble Ei qui lient un ensemble de services d’un traitement de flux de Si et qui démarre d’un service capteur et se termine par un service actionneur [Williamson ].