Soutenance mémoire
De manière historique, la notion d’application temps-réel est associée au contrôle de systèmes physiques et à l’acquisition de données à partir de capteurs matériels. La prise en charge de l’acquisition de données et de leur traitement par des applications logicielles se généralise et devient presque une règle. Les domaines d’application de ce type de logiciel se sont élargis et approfondis. L’évolution du logiciel dans l’automobile en est un exemple criant. Les systèmes d’aide à la conduite, ou même de gestion de la direction électronique ont évolué. Historiquement leur réalisation se faisait à l’aide de puces dédiées. Ces fonctions sont désormais assurées par un logiciel qui pilote en temps-réel le système physique. Désormais, les voitures contiennent des calculateurs puissants combinés avec des systèmes d’exploitation permettant de déployer des applications logicielles relativement complexes. Le standard AUTOSAR illustre les efforts de rationalisation des architectures logicielles embarquées dans les véhicules pour permettre le déploiement d’applications de plus en plus complexes.
Ces logiciels ont souvent pour objectif de synchroniser l’évolution d’un système physique avec son environnement. Pour que le système puisse contrôler ou réagir aux modifications de son environnement, il doit être capable de respecter des contraintes temporelles variées : échéances, et définition de fréquences minimales ou maximales d’activations. Le service délivré par l’application se décrit en terme de comportement temps-réel. Or ce comportement doit être sûr de fonctionnement. Cela signifie que le logiciel doit satisfaire un certain nombre d’exigences liées à son comportement en opération : la précision et la correction de ses calculs, sa disponibilité, sa réactivité… Une grande partie des travaux réalisés en recherche dans les sciences et techniques de l’ingénierie du logiciel a été consacrée au développement de méthodes de conception, et de mécanismes destinés à assurer le bon fonctionnement du logiciel selon ces critères. Les systèmes pour lesquels les conséquences d’un dysfonctionnement sont inacceptables sont qualifiés de systèmes critiques.
Enjeux de la conception d’un système temps-réel critique
Lorsque l’on doit définir le comportement d’une application, il est important de comprendre la façon dont l’environnement et l’application interagissent. La nature des interactions entre ces deux entités et le rôle associé à chacune influencent énormément la façon dont elle est conçue et réalisée.
Etat et comportement d’une application
Un exemple typique d’application «temps-réel» consiste à capturer et traiter en tempsréel des mesures de divers capteurs afin de contrôler un système physique. La fonction de l’application est de «réagir» aux variations de l’environnement. La première étape de la description des interactions entre l’environnement et l’application revient à décider qui doit mener la danse : l’application ou l’environnement. Par exemple, si l’on considère un outil de calcul numérique haute précision permettant de calculer l’inverse de matrices de grande taille, alors la précision numérique du résultat est la qualité requise principale pour ce type d’application. L’utilisateur ou l’environnement de cette application déclenche l’exécution de l’application mais va attendre aussi longtemps que nécessaire le résultat du calcul. Ce type d’application sera désigné sous le terme d’application conversationnelle puisque l’utilisateur ou l’environnement attend volontairement que l’application délivre sa fonction. En revanche, si l’on considère l’exemple d’un service de signalisation des trains s’arrêtant aux différents quais d’une gare, ce système est dépendant de l’activité de son environnement. Un affichage qui ne prend pas en compte suffisamment vite l’arrivée et le départ des trains n’est pas satisfaisant du point de vue d’un voyageur .
Les systèmes réactifs voient leur activité guidée par leur environnement. Leur comportement se définit du coup sous la forme de règles ou équations qui associent un stimuli à une réaction instantanée, [Ber89]. Ceci constitue le modèle le plus simple d’un système réactif. D’un point de vue réaliste, le système peut avoir une dynamique relativement complexe entre un stimuli et la réaction désirée. Les applications temps-réel sont une classe particulière de systèmes réactifs pour lesquels la réaction à un stimuli doit être fournie dans une plage temporelle précise. Toute application temps-réel réaliste contient une partie «réactive» et une partie «conversationnelle». La description de la fonction de l’application peut alors se faire en décrivant son comportement. Ceci requiert la définition de l’état du système et de sa dynamique.
État et comportement d’une application temps-réel
L’état de l’application représente l’ensemble de l’information caractérisant l’application en un instant de son exécution. La variation de cette information au cours du temps constitue le comportement de l’application. Suivant la nature de l’état du système, il existe divers moyens pour décrire l’enchaînement des états. Dans le cas de l’état d’une application logicielle, la variation de l’état est discontinue par nature. Chaque fois que l’état de l’application varie la fonction représentant l’état du système en fonction du temps fait un «saut». Ainsi, l’état du système peut être représenté au cours du temps par une fonction constante par morceaux. De manière plus classique, la dynamique du système est vue comme une succession d’un certain nombre d’étapes où l’état du système est stable puis change de manière instantanée de valeur. Chaque discontinuité représente un changement d’état et sera appelée transition. Un événement peut être vu comme la cause ou la manifestation d’une telle transition. Plus généralement, un événement est un moyen simple pour identifier un instant, un point de passage dans l’exécution de l’application. La notion d’événement permet de nommer et dater les transitions lors de l’exécution de l’application.
Interactions environnement/application
L’implémentation de l’application définit un ensemble d’états de départ et les actions à réaliser pour obtenir une séquence de transitions permettant d’obtenir la fonction désirée en collaboration et/ou en dépit de l’environnement. L’interaction entre l’environnement et l’application fait partie intégrante de la conception de l’application. En effet, l’environnement est régi par des lois qui permettent d’utiliser le comportement attendu de l’environnement pour s’assurer que l’application délivre correctement son service. Ainsi, l’interaction entre l’application et l’environnement est bidirectionnelle et se fait à travers une interface. Cette interface caractérise la fraction commune de leurs états respectifs. Puisque les définitions que nous considérons sont centrées autour de l’application, cette fraction d’état partagée entre l’environnement et l’application sera appelée «état externe» de l’application. Les échanges de données entre l’environnement et l’application se font grâce aux valeurs prises par cet état externe au cours du temps. La réalisation de l’implémentation repose sur des hypothèses concernant les comportements raisonnables de l’environnement (vitesse d’évolution, lois physiques, phénomènes vraisemblables…). Ces hypothèses permettent de définir la nature des transitions que l’environnement peut provoquer sur l’état externe de l’application. Ces changements d’états constituent le comportement normal de l’environnement. Par exemple, l’effet de la gravité ou des frottements de l’air sur la carlingue de l’avion constituent des influences normales de l’environnement sur l’avion. En revanche, l’impact d’un éclair sur sa carlingue ne fait pas partie des influences «normales» de l’environnement. Cette séparation ne signifie pas que la seconde interaction entre l’environnement et le système ne sera jamais étudiée mais qu’elle n’entre pas directement en ligne de compte pour assurer la fonction de l’avion. Cette notion d’interactions normales nous permet d’être plus précis lors de la définition d’un état correct d’une implémentation de l’application [ALRL04].
Etats corrects et application zéro défauts
La conception du système est correcte du point de vue fonctionnel, lorsque l’application peut toujours assurer sa fonction lorsqu’elle est exécutée dans un environnement «normal». Cela revient à définir un contexte d’utilisation idéalisé, et à s’assurer que dans ce contexte la fonction sera toujours satisfaite. Nous dirons alors que l’application est bien conçue (du point de vue fonctionnel). Tout le problème réside dans la sélection des interactions normales. Supposons que l’on ait une application bien conçue. Lorsqu’une application bien conçue du point de vue fonctionnel est exécuté dans un environnement «normal», alors tous les états occupés par l’application durant une telle exécution sont dits corrects. La propriété principale d’un état correct est que l’implémentation de l’application peut poursuivre son exécution à partir de cet état et assurer sa fonction. Cette vision d’une application et de sa conception peut sembler utopique mais correspond à ce que l’on pourrait appeler le logiciel zéro-défaut. En effet cette vision suppose que tout a été prévu, et correctement pris en compte. Ce type de conception repose aussi sur une perception souvent tronquée de l’environnement où l’on ne considère qu’une portion de ses interactions possibles avec l’application. La conséquence directe est que si l’environnement peut «agresser» l’application en la plaçant dans un état qui ne soit pas correct, alors tout peut arriver et en particulier le pire. La vision zéro défaut est souvent utilisée dans un contexte où l’environnement d’utilisation de l’application est aménagé, «dompté», pour s’assurer qu’il se comportera tel que prévu lors de la conception de l’application.
|
Table des matières
Introduction
1 Contexte et Problématique
1.1 Enjeux de la conception d’un système temps-réel critique
1.1.1 Etat et comportement d’une application
1.1.2 Contraintes comportementales temps-réel
1.1.3 Plate-forme d’exécution et prédictibilité
1.1.4 La sûreté de fonctionnement du logiciel
1.1.5 Applications temps-réel tolérantes aux fautes
1.2 Vérification à l’exécution
1.2.1 Principe de la vérification à l’exécution
1.2.2 Traces et signaux : les modèles d’exécution
1.2.3 Catégories de vérifieurs en-ligne
1.3 Observation et analyse
1.3.1 De l’exécution d’un code vers les événements
1.3.2 Etat du bloc d’analyse et synchronisation avec l’application
1.4 Position de l’étude
1.4.1 Attributs orientés «détection» d’un vérifieur en-ligne
1.4.2 Synthèse de la démarche suivie
2 Critère de Détection au plus tôt
2.1 Rappels sur les traces et leurs opérations
2.2 Historique d’une exécution et processus d’observation
2.2.1 Approche de modélisation suivie
2.2.2 Historique d’une exécution en cours
2.2.3 État du processus d’observation
2.2.4 Monotonie des observations
2.2.5 «Latence» et exactitude du processus d’observation
2.3 Symptômes d’erreur et apparition de l’erreur
2.3.1 Symptômes d’erreur associés à Spec
2.3.2 Date d’apparition de l’erreur
2.4 Latence de détection et détection au plus tôt
2.4.1 Contribution à la latence de détection
2.4.2 Détection causale, «au plus tôt»
3 Synthèse d’un détecteur au plus tôt
3.1 Automates temporisés et traces temporisées
3.1.1 Rappel sur les automates finis non temporisés
3.1.2 Les automates temporisés
3.1.3 Interprétation des automates temporisés
3.2 Synthèse du détecteur au plus tôt
3.2.1 Des symptômes vers l’analyse d’accessibilité
3.2.2 Etude du comportement en-ligne
3.2.3 Test de validité d’un événement
3.2.4 Calcul des échéances à partir de l’abstraction temporelle
4 Prototypage et évaluation du détecteur
4.1 Les enjeux de l’implémentation
4.1.1 Analyse du comportement attendu
4.1.2 L’environnement Xenomai
4.1.3 Conditionnement des données
4.2 Réalisation et intégration du prototype
4.2.1 Analyse des structures de contrôle de Xenomai
4.2.2 Analyse algorithmique et description du prototype
4.3 Évaluation du coût du détecteur
4.3.1 Occupation de la mémoire
4.3.2 Temps d’exécution
Conclusion générale
