Évaluation de l’heuristique pour des problèmes quelconques

Le second aspect que nous pouvons analyser porte sur l’efficacité de l’algorithme heuristique que nous utilisons pour la résolution du problème demapping de tâche : le gain en temps d’exécution et le décalage entre les solutions approchées et les solutions optimales.

Pour illustrer l’efficacité duparcours epsilon, nous avons analysé le comportement de l’algorithme avec quatre types de parcours : (i) des sources vers les puits, (ii) des puits vers les sources, (iii) aléatoire (les services continus sont analysés dans n’importe quel ordre) et (iv) parcours epsilon. Pour ce faire, nous générons automatiquement des problèmes quelconques, notésA × B, consistant à rechercher une configuration de déploiement étant donné un graphe logique deA services continus et un réseau de B objets.

Concrètement, le processus de génération sélectionneA services continus, numéro-tés de1 à A, depuis un ensemble prédéfini de services continus de complexité variable (constante, linéaire, polynomiale, etc.). Des contraintes sont alors générées aléatoirement pour chaque service continu, à partir d’ensembles prédéfinis de propriétés (zones, fonction-nalités matérielles et logicielles requises, etc.). Enfin, des arêtes sont construites entres les services continus, les cycles étant évités en suivant la règle suivante :∀(i, j) ∈ EL, i < j. Les objetsB sont eux aussi construits aléatoirement, à partir d’un ensemble de profils prédéfinis (motes, systèmes embarqués, smartphones) correspondant à des quantités de ressource bien spécifiques et du même ensemble de propriétés que les contraintes (position, fonctionnalités disponibles, etc.) de façon à s’assurer que le problème puisse être résolu. Les fonctionsnpwri

0^,ncpui

0^,nmemi

0 ^etndski

0^{, qui modélisent la charge courante,} sont elles aussi sélectionnées depuis un ensemble de fonctions usuelles (constante, linéaire, polynomiale, etc.).

Les différents problèmes A × B générés pour cette expérience sont non triviaux, c’est-à-dire qu’il est impossible de déployer l’ensemble desA services continus sur un

seul objet. En d’autres termes, la consommation globale du graphe logique, hors coût de communication, est au minimumx fois plus élevée que la quantité d’énergie, de mémoire et d’instructions par seconde disponible sur le plus puissant des appareils.

Les problèmesA × B générés sont ensuite utilisés en tant que scénario pour le calcul d’une configuration de déploiement. Pour chaque problème, on cherche à calculer :

— une configuration optimale, en résolvant le problème d’optimisation linéaire en nombres binaires que nous avons présenté dans la section précédente ;

— une configuration sous-optimale, en appliquant notre algorithme de résolution heuristique ;

— la plus mauvaise configuration possible (c.-à-d. celle qui consomme le plus d’énergie possible tout en restant déployable), en transformant le problème d’optimisation en une maximisation du coût au lieu d’une minimisation, ce pour mesurer la qualité des solutions sous-optimales vis-à-vis de l’optimal et du pire cas.

Pour le calcul des solutions optimales et des pires solutions, nous utilisons un solveur open source appelélp_solve 5.5.2.0⁸, exécuté sur une machine de bureau classique (dual-core 3.2GHz, 4GB memory). Le calcul des solutions sous-optimales est effectué lui aussi sur cette machine, mais aussi sur le smartphone Galaxy Nexus que nous avons utilisé pour notre précédente expérience, dans le but de mesurer l’efficacité de l’algorithme sur ce type d’appareil. Enfin, nous mesurons aussi le nombre de faux négatifs, c’est-à-dire les cas où l’algorithme heuristique ne trouve aucune solution alors que le solveur en trouve une.

La Table 5.3 présente le surcoût moyen de la solution sous-optimale par rapport à l’optimale, ce pour les différents problèmesA × B que nous avons générés (une centaine de chaque type). Ce surcoût est calculé comme un pourcentage de la valeur de la fonction objectifG pour la solution optimale :

G(sous-optimal) − G(optimal)

G(optimal) × 100

La taille des problèmes est volontairement limitée, du fait du temps de calcul des solutions optimales qui croît démesurément avec la taille ; par exemple, trouver une solution optimale à un problème 50×50 nécessite jusqu’à 5 jours de calculs. Aussi, au-delà des problèmes 15×5 nous ne possédons pas de mesures fiables sur la valeur des solutions optimales. En ce qui concerne le temps d’exécution de l’algorithme heuristique, même pour des problèmes de taille plus élevée, la Table 5.4 présente le temps nécessaire pour la recherche des configurations sous-optimales et, lorsque cela est possible, optimales.

On remarque que, dans la plupart des cas, le parcours des puits vers les sources et le parcours epsilon obtiennent les meilleurs résultats, aussi bien en ce qui concerne les valeurs moyennes que les extremums. Cette efficacité est notamment due au fait que, dans le contexte de la communication sans fil, les coûts d’émissions sont plus élevés

Source vers les puits Puits vers les sources

Surcoût Surcoût min/max Faux négatifs Surcoût Surcoût min/max Faux négatifs 5×5 18.26 [0, 44.52] 0 8.38 [0, 33.34] 0 5×10 12.66 [0, 39.17] 0 5.51 [0, 21.7] 0 10×5 17.61 [5.55, 56.12] 7 14.05 [0, 42.39] 0 10×10 16.93 [3.38, 37.3] 13 9.82 [0, 25.29] 0 15×5 17.86 [4.94, 51.83] 23 13.47 [0, 39.06] 0 Epsilon Aléatoire

Surcoût Surcoût min/max Faux négatifs Surcoût Surcoût min/max Faux négatifs 5×5 8.19 [0, 28.06] 0 25.96 [0, 34.52] 0 5×10 5.42 [0, 21.7] 0 21.87 [0, 24.5] 0 10×5 12.87 [0, 42.39] 0 25.57 [5.01, 45.63] 2 10×10 9.74 [0, 24.77] 0 22.18 [3.61, 23.98] 6 15×5 13.47 [0, 35.27] 0 24.77 [5.27, 36.34] 14

Table 5.3 – Surcoût en pourcentage de l’optimal et nombre de faux négatifs.

5×5 5×10 10×5 10×10 15×5 20×20 50×50 100×100 1000×1000 Optimal 63ms 1s 8s 60s 483s >20mn >20mn >20mn >20mn Heuristique (PC) <1ms <1ms <1ms 1ms 2ms 3ms 6ms 12ms 680ms Heuristique (smartphone) <1ms 1ms 2ms 3ms 28ms 101ms 630ms 1s 10s

Table 5.4 – Temps de calcul.

que les coûts de réception. Ainsi, étant donné que le parcours des puits vers les sources déploie les services continus en partant de la fin du graphe logique, l’incertitude est naturellement réduite lorsque le coût du déploiement d’unvl_i sur unn_j est estimé ; en effet, la plupart des successeurs devl_i sont déjà associés à un objet.

La Table 5.3 présente, en outre, le nombre de faux négatifs pour chaque méthode de parcours. On constate, ici aussi, que le parcours des puits vers les sources et le parcours epsilon obtiennent de meilleurs résultats en se montrant significativement moins sujets aux faux négatifs. Cela s’explique, de façon similaire, par la réduction implicite (parcours des puits vers les sources) et explicite (parcours epsilon) de l’incertitude. En effet, à chaque étape, ces parcours orientent l’algorithme vers des choix à faible incertitude qui ont donc moins de chance d’être des voies sans issues par la suite.

Spécifiquement, nous pouvons observer que, si les résultats sont proches de l’optimal, il existe toutefois un surcoût qui tend à croître avec la complexité des problèmes, ici

V al eu r d e la fo n c o n o b je c f (G ) 200 700 0 20 40 60 80 100

Solu on op male Parcours epsilon Parcours aléatoire Pire solu on

Figure 5.7 – Valeurs de la fonction objectif pour 100 instances d’un problème non trivial (15 opérateurs à placer sur 5 appareils).

traduite par des valeurs deA supérieures à B. Ceci s’observe particulièrement sur la Fi-gure 5.7, qui présente les mesures effectuées lors de la recherche d’une configuration pour les 100 problèmes 15×5 que nous avons générés aléatoirement lors de notre expérience : les valeurs de la fonction objectif pour la solution optimale, la solution sous-optimale obtenue pour le parcours epsilon et le parcours aléatoire et la pire solution possible. Concrètement, ce surcoût est induit par le comportement de l’algorithme heuristique, qui associe graduellement les services continus aux appareils et n’effectue pas de mo-difications à posteriori. En effet, une fois unvl_i associée à un appareiln_j, l’algorithme ne revient jamais survl_i et, de fait, s’oriente très tôt vers une solution dans l’espace de recherche. En conséquence, du fait des forts coûts de communication, la probabilité d’associer un prédécesseurvl_k devl_i (c.-à-d.s_ki ∈ ISi_{) sur l’appareil}n_j est fortement accrue lorsquevl_i a déjà été associée àn_j. D’où l’influence du parcours sur la qualité des résultats.

Le surcoût des solutions sous-optimales produites par notre algorithme heuristique est cependant à relativiser, car plutôt bas : entre 10 et 20 % en moyenne. De plus, l’algorithme n’est jamais bloqué dans une solution sous-optimale irréalisable (aucun faux négatif ) et demeure globalement éloigné de la pire des solutions possibles. Par ailleurs, ce surcoût est à mettre en perspective avec la réduction significative du temps de calcul, même pour des problèmes de taille conséquente (p. ex. 1000×1000) qui seraient impossible à résoudre de manière optimale. Enfin, du fait de la complexité raisonnable de l’algorithme et sa faible consommation d’espace mémoire, celui-ci peut être déployé directement sur un simple smartphone, comme montré dans la Table 5.4. Ainsi, le calcul d’une configuration n’est pas tributaire d’une infrastructure centralisée et peut être réalisé directement sur un appareil courant et massivement répandu dans l’Internet des objets.

t1 t2 AVG tpref Tpref M

MIN ^tmin MAX

tmin tmax tmax ≥ tmax ≥ tmin < tmax < tmin HVAC t-off t+ h1 h2 AVG

...

M : Système de contrôle central.

t+, t-, off: Evénements (chauffer, refroidir, arrêter). ^Ttpref^pref : Préférences locales. ^{: Politiques globales.}

Figure 5.8 – Exemple de graphe logique, pour un bureau contenant deux capteurs de température et deux capteurs d’humidité.