Détection d'erreur au plus tôt dans les systèmes temps-réel : une ...

4.3. ÉVALUATION DU COÛT DU DÉTECTEUR 119liées par τ-transitions sous forme d’arbre au lieu d’une liste. De plus, une implémentationde la fonction de vérification dans l’espace noyau permettrait de gagner 1,5 microsecondesur chaque appel système, c’est à dire 4,5 micro secondes au total. Ceci représente entre10 et 20% du temps d’exécution du détecteur.ConclusionA la fin du chapitre 3, nous étions en possession d’un algorithme de haut niveau permettantde mettre en place un service de détection au plus tôt pour une spécification définievia un automate temporisé. Cet algorithme était «désincarné» puisqu’il supposait uneexécution indépendante de l’algorithme de vérification et de l’application. En pratique lecode de vérification doit se prémunir des différentes suspensions d’activités déclenchéespar l’ordonnanceur. Nous avons proposé dans ce chapitre une implémentation de cet algorithmesur la plate-forme de développement et d’exécution d’applications temps réelXenomai.Le prototype proposé permet d’intercepter les événements non autorisés par la spécificationet de déclencher le processus de recouvrement. Cela se fait par exemple, enbloquant la progression de l’exécution de l’application et en déclenchant le réveil d’unetâche de recouvrement. Le recouvrement des erreurs dues à un dépassement d’échéance sefait lui aussi avec a priori une latence de l’ordre d’un changement de contexte, au mieux.La description du prototype couvre les aspects liés à l’architecture logicielle assurantun bon contrôle de l’exécution de l’application surveillée, et les algorithmes et structuresde données concrètement utilisés pour réaliser la vérification. La conception du détecteurà partir d’un modèle nous a permis de bien séparer le code qui peut être réutilisé de celuiqui doit être régénéré pour chaque application. Cette séparation nous a permis de mettreen place un processus automatique pour générer le code complet du détecteur, et l’intégrerà une application donnée. L’outil est distribué librement 4 bien qu’il ne soit qu’à l’état deprototype.Ce chapitre de description du prototype est clos par une étude du coût du détecteuren terme de code ajouté à l’application, d’empreinte mémoire, et de temps processeurconsommé. Le détail des algorithmes et structures utilisés dans les différentes étapes duprocessus de détection, nous a permis de déterminer l’accroissement de l’empreinte mémoireet temporelle du détecteur. En effet, ces deux aspects du coût d’intégration du détecteurvarient en fonction de paramètres représentatifs de la complexité de la spécificationvérifiée. Les résultats de cette étude ont pu être complétés par des résultats expérimentaux.4 http://www.laas.fr/~trobert/RTRV/