Soutenance mémoire
Les systèmes temps réel
Définition
Les systèmes temps réel sont tous ces systèmes informatiques pour lesquels la contrainte d’exactitude de la réponse à un stimuli externe s’étend au domaine temporel en plus du domaine logique. En d’autres termes, une réponse sera considérée comme correcte, du point de vue d’un système temps réel, si le calcul effectué est correct et, surtout, si la réponse est obtenue dans le laps de temps imparti, souvent avant l’expiration d’une limite temporelle, ou échéance (Martin, 1965 ; Shin & Ramanathan, 1994). Ces systèmes, qui procurent ces garanties sur les aspects temporels de leur exécution, sont utilisés dans de nombreux domaines, tels que l’aéronautique, l’automobile, la production et la distribution d’énergie, les télécommunications, la robotique, etc. La plupart des systèmes embarqués, présents dans nombre de ces domaines, sont d’ailleurs soumis à de telles contraintes temps réelles. Les systèmes embarqués sont les systèmes dont le fonctionnement est compris dans celui de systèmes plus larges. Il s’agit la plupart du temps de systèmes informatiques contrôlant des systèmes physiques et/ou électroniques. Ces systèmes sont soumis à des contraintes importantes, du point de vue du volume, des ressources disponibles (mémoire, capacité de calcul), et dans certains domaines de la criticité des fonctions auxquelles ils contribuent.
Temps réel dur vs souple
Le monde des systèmes temps réel est scindé la plupart du temps en deux catégories : le temps réel dur (ou strict), et le temps réel souple. Cette distinction vise à séparer les systèmes selon l’impact du non respect de l’échéance. Pour le temps réel dur, l’impact est catastrophique si le résultat est obtenu après l’échéance (y compris dans une marge extrêmement faible après l’échéance). On peut imaginer l’impact sur la trajectoire d’une fusée d’un système de contrôle ne réussissant pas à répondre dans les temps. Pour le temps réel souple, cet impact est faible et souvent lié à la qualité de service. On peut par exemple se permettre dans une application de télécommunication de perdre des paquets sans engendrer d’échec catastrophique. L’impact sera uniquement sur la qualité de la communication. Une troisième catégorie que l’on peut rencontrer est celle du temps réel ferme : l’impact n’est pas catastrophique si le calcul n’est pas effectué dans les temps, mais le résultat est inutile. Considérons par exemple un système de prédiction (temps, résultats d’une compétition) : le résultat est inutile si l’évènement se produit avant la fin du calcul. Dans ce travail de thèse, nous nous intéressons au domaine des systèmes embarqués temps réel. Les contraintes sur lesquelles nous nous concentrons sont des contraintes strictes : la réponse du système se doit d’être produite dans une fenêtre temporelle précise.
Le test logiciel
Définition
Afin de pouvoir mesurer l’adéquation des systèmes informatiques à leurs spécifications, il est nécessaire de les tester. Le test logiciel consiste à exécuter le logiciel testé en lui fournissant des entrées et en observant ses sorties. Les sorties obtenues sont comparées avec des sorties attendues, et un verdict est rendu pour le test concerné. Contrairement à la vérification qui analyse le modèle pour garantir des propriétés du système, le test ne permet pas de prouver qu’un système est conforme à sa spécification. Il est cependant utile pour pouvoir détecter un maximum d’erreurs de l’implémentation, dans des situations où la vérification complète du logiciel n’est pas faisable.
Le test logiciel permet de vérifier différentes propriétés d’un logiciel. On peut s’intéresser à la robustesse, vérifiant ainsi que le comportement de l’implémentation reste adéquat en présence de conditions extrêmes, d’entrées invalides, de pannes, etc. On peut d’autre part s’intéresser à la performance, mesurant le temps de réponse en fonction de la sollicitation du logiciel afin de connaître ses caractéristiques sous une charge lourde. On peut aussi s’intéresser au test des fonctionnalités d’un logiciel, permettant de valider l’implémentation des exigences spécifiées dans le cahier des charges. Le test logiciel est intégré aux différentes méthodologies de développement logiciel à différents niveaux. Dans une démarche de développement guidé par les tests (Test-Driven Development, TDD), le test est présent avant même l’implémentation du programme à tester. L’ingénieur commence par programmer et automatiser des tests unitaires de manière à guider le développement (Janzen & Saiedian, 2005). on retrouve le test à tous les niveaux de développement. Les tests unitaires des éléments du programme servent à valider l’implémentation de la conception détaillée, les tests d’intégration l’architecture, les tests de validation système l’adéquation aux spécifications.
Boîte noire et boîte blanche
Une classification fréquemment rencontrée en ce qui concerne le test logiciel est la distinction entre boîte noire et boîte blanche. Dans le test boîte noire, le logiciel est vu, comme le nom de la catégorie l’indique, comme une boîte noire. Les seuls éléments manipulés et observés sont ses entrées et ses sorties, sans se soucier des éléments internes qui le composent. Le test boîte noire vise le plus souvent à garantir la conformité entre l’exécution du logiciel et ce que ses spécifications définissent. Sur le cycle en V, le test de validation est le plus souvent du test boîte noire. Le test boîte blanche vise au contraire à ouvrir le logiciel et à venir valider son fonctionnement en ayant la connaissance de ses composants internes. Le test unitaire, par exemple, s’intéresse au fonctionnement d’une « unité » du programme, qu’il s’agisse d’une fonction ou d’une classe (pour de la programmation orientée objet) et est le plus souvent réalisé en boîte blanche. Contrairement au test boîte noire, le test boîte blanche se base sur une connaissance d’un modèle du fonctionnement du programme testé qui est le plus souvent une représentation du code source (graphe de flot de contrôle, formalismes tels que les automates ou les réseaux de Petri. . . ). Cette connaissance de la structure du programme permet de le tester en garantissant des critères de couverture tels que tous les arcs, tous les sommets ou tous les chemins du graphe de flot de contrôle.
Processus de test
Un processus de test boîte noire vise à confirmer l’adéquation d’un système à ses spécifications en le soumettant à un ensemble de données d’entrée/sortie définies, et en comparant des sorties aux sorties attendues dans les spécifications. Cet ensemble de donnés d’entrées (qui peut inclure un aspect temporel) est ce que l’on appelle le cas de test.On peut y voir que le cas de test (test case) est obtenu à partir de l’objectif de test (test purpose), puis sert à nourrir le testeur afin de permettre d’effectuer le test. L’objectif de test est la propriété du système à tester. Il décrit les conditions du test ainsi que le résultat attendu. Lorsqu’il est formalisé, c’est la spécification du cas de test. Afin de pouvoir donner un verdict quant à l’adéquation du système à ses spécifications (ou à quantifier son (in)adéquation), le test doit être effectué sur une exécution du système. Il s’agit alors d’un test dynamique et non statique. L’approche statique pourrait inclure de la relecture de code, ou une exécution symbolique (King, 1976 ; Khurshid, Păsăreanu & Visser, 2003). Pour cela, il faut donc que le système s’exécute sur une plateforme, qui peut être réelle ou simulée, et qu’il communique avec un environnement qui là encore peut être réel ou simulé. Le testeur procure les entrées du système conformément au cas de test, puis compare les sorties obtenues avec celles qui sont attendues dans le cas de test. Il peut ensuite rendre un verdict sur l’inadéquation du système à ses spécifications.
|
Table des matières
Introduction
Contexte & Motivations
Contributions
Organisation du manuscrit
I Contexte et état de l’art
1 Contexte
1.1 Les systèmes temps réel
1.1.1 Définition
1.1.2 Temps réel dur vs souple
1.2 Le test logiciel
1.2.1 Définition
1.2.2 Boîte noire et boîte blanche
1.2.3 Processus de test
1.3 Le forçage en ligne
1.3.1 Vérification en ligne
1.3.2 Forçage en ligne
1.4 Positionnement
2 État de l’art
2.1 Test des systèmes temps réel
2.1.1 Test basé sur les modèles
2.1.2 Génération des cas de tests
2.2 Injection de fautes dans les systèmes temps réel
2.3 Forçage en ligne des systèmes temps réel
2.4 Positionnement
II Forçage en ligne des systèmes temps réel paramétrés
3 Présentation de la démarche
3.1 Démarche pour le forçage en ligne
3.1.1 Objectif de la démarche
3.1.2 Test des systèmes temps réel
3.1.3 Présentation du processus
3.2 Présentation détaillée de la démarche
4 Model checking paramétré
4.1 Choix de la technique et du formalisme
4.1.1 Synthèse de paramètres
4.1.2 Capacités d’analyse et décidabilité
4.1.3 Principe
4.2 Réseaux de Petri
4.2.1 Définition et sémantique des réseaux de Petri
4.2.2 Définition et sémantique des réseaux de Petri temporels
4.2.3 Définition et sémantique des réseaux de Petri temporels à arcs inhibiteurs temporisés
4.2.4 Définition et sémantique des réseaux de Petri temporels paramétrés
à arcs inhibiteurs
4.2.5 Restriction des piTPNs
4.3 Analyse paramétrique
4.3.1 Algorithmes
4.3.2 Exemple
5 Construction du modèle d’analyse
5.1 Systèmes de transition à durée
5.1.1 Définition et sémantique des systèmes de transition à durée
5.1.2 Définition et sémantique des systèmes de transition à durée paramétrés
5.2 Modèles des tâches du système
5.2.1 Démarche IDM
5.2.2 Modèles de tâches (p)DTS
5.3 Transformation et composition des modèles d’entrée
5.3.1 Transformation de pDTS vers piTPN
5.3.2 Composition
6 Principe de mise en œuvre
6.1 Analyse hors-ligne du modèle du système
6.1.1 Analyse paramétrique
6.1.2 Choix du point
6.2 Génération des modèles embarqués
6.2.1 Principe
6.2.2 Injection des valeurs de paramètres
6.2.3 Epsilon-réduction
6.3 Principe de l’implémentation dans un RTOS
6.3.1 Principe général
6.3.2 Architecture
6.3.3 Structures de données
6.3.4 Algorithme de contrôle
6.3.5 Précision de l’implémentation
III Mise en œuvre
7 Implémentation du forçage en ligne dans Trampoline RTOS
7.1 Trampoline RTOS
7.1.1 AUTOSAR
7.1.2 Implémentation dans trampoline RTOS
7.2 Plateforme d’exécution
7.3 Implémentation dans trampoline RTOS
7.3.1 Contrôleur
7.3.2 Modèle du système
7.3.3 Démarrage des tâches
7.3.4 Wrapper d’appels systèmes
7.4 Résultats
7.4.1 Overhead
8 Application à un exemple
8.1 Exemple
8.1.1 Protection temporelle AUTOSAR OS
8.1.2 Objectif de test
8.2 Expérimentation
8.2.1 Modélisation du système
8.2.2 Analyse hors ligne du système et obtention de la stratégie de test
8.2.3 Configuration du forçage en ligne
8.2.4 Exécution du test
Conclusion
