›› État des lieux

L'adaptation au contexte d'exécution devient une préoccupation majeure avec l'avènement des systèmes répartis ou des calculs sur des grilles ou des grappes d'ordinateurs. Un système (ou logiciel) auto-adaptatif évalue continuellement son comportement. Il change son mode d'exécution ou se reconfigure si son auto-évaluation indique que l'objectif poursuivi n'est plus satisfaisant ou que de meilleures performances sont réalisables. Pour chaque tâche qu'un tel système doit accomplir plusieurs modules sont disponibles. De plus le système possède des connaissances sur les propriétés de ces modules afin de constituer la chaîne de traitement semblant la plus pertinente au vu du contexte de l'exécution et d'activer et de paramétrer les modules appropriés. Ces dernières années, l'étude des systèmes auto-adaptatifs a connu un engouement notable dans plusieurs domaines de recherche : logiciels numériques pour environnements dynamiques (grilles, réseaux), systèmes de monitoring reconfigurables, "pervasive computing" ou informatique omniprésente nécessitant des logiciels et machines ayant des capacités de composition et de reconfiguration, services web, etc.

›› Contribution : pilotage du diagnostic

Les systèmes de monitorage, tels que Calicot, doivent souvent faire face à des signaux de qualité variable. Tirer parti du contexte permet généralement de faciliter le traitement du signal et d'améliorer les résultats qui sont ensuite exploités par la partie diagnostic. Nous étudions la manière d'adapter de tels systèmes de monitorage au contexte courant de leur exécution. Par exemple, pour le traitement de signal il s'agit de choisir et d'adapter  les algorithmes de traitement à une analyse du contexte courant. Ce dernier peut indiquer le type de bruit présent sur les signaux, une estimation de l'information présente, les fautes actuelles ou encore les hypothèses de maladies prédites par le diagnostic.

Les étages de raisonnement, tels que le diagnostic, peuvent aussi être adaptés, par exemple en prenant en compte le niveau de connaissance que les étages de traitement du signal sont en mesure d'extraire ou, encore, le niveau de connaissance suffisant pour parvenir à une conclusion. À cette fin, nous avons proposé d'utiliser un module appelé « pilote » qui opère à trois niveaux :

1. Il choisit et paramètre les algorithmes qui analysent les signaux en entrée. Des règles spécialisées sont utilisées par le pilote pour choisir l'algorithme le plus pertinent et le meilleur règlage selon le contexte courant.
2. Il active ou désactive les tâches de traitement dédiées à l'extraction d'événements spécifiques des signaux en entrée.
3. Il adapte le diagnostic à la résolution actuelle de l'analyse des signaux.

Dans notre approche, le diagnostic est effectué par reconnaissance de chroniques. Les chroniques sont organisées dans une hiérarchie de bases de chroniques : les chroniques les plus abstraites comportent moins d'événements (à détecter sur les signaux) et moins d'attributs; les chroniques les plus spécifiques comportent plus de détails. La base de chroniques courante est choisie selon le niveau d'abstraction imposée par la tâche de reconnaissance de chroniques ou par la tâche de traitement de signal : d'une part, une base de chroniques plus abstraite nécessite moins de ressources de calcul qu'une base de chroniques plus raffinée, d'autre part, les événements les plus abstraits sont plus faciles à calculer sur des signaux bruités. L'utilisation de cette hiérarchie de bases de chroniques permet une utilisation plus intelligente des ressources et permet de focaliser le diagnostic sur les informations les plus sûres.