Soutenance mémoire
Contexte général et positionnement
Les systèmes temps-réels sont décrits avec profusion dans la littérature scientifique. Les sections qui suivent permettent de restreindre le cadre d’application de nos travaux, et ainsi de circonscrire notre périmètre d’exploration.
Contraintes de sûreté de fonctionnement
Un système cyber-physique est défini comme l’intégration de mécanismes calculatoires à des processus interagissant avec un environnement physique [Lee08]. On peut également les qualifier de systèmes réactifs, dans le sens où ils doivent répondre à des commandes extérieures [Loh+19]. Ceux-ci sont parfois contraints par des exigences de cadence et de latence, imposant l’exécution de calculs donnés entre des bornes temporelles ; on parle alors plus généralement de systèmes temps-réels. Quand le non-respect de ces contraintes temporelles contribue à une défaillance du système et qu’une défaillance est susceptible de mener à des conséquences jugées catastrophiques (c.-à-d. : perte de vies humaines, désastre écologique, etc.), ces systèmes sont qualifiés de systèmes temps-réels de sûreté [Kop11]. De nombreuses industries spécialisées, comme l’avionique, le ferroviaire, l’automobile ou le nucléaire civil ont comme mission de concevoir et développer de tels systèmes. Ceux-ci sont régis par des normes internationales strictes, qui veillent au bon respect des contraintes de sûreté de fonctionnement, comme l’ISO 26262 [ISO18], l’IEC 60880 [IEC06] ou la DO178-C [RTC11a].
Positionnement 1 (Domaine avionique). Nos travaux se concentrent particulièrement sur l’étude de systèmes temps-réels de sûreté dans le domaine avionique, c’est-à dire devant se conformer aux critères de certification les plus exigeants de la DO-178C.
Contraintes opérationnelles
Les systèmes temps-réels de sûreté existent depuis plus de cinquante ans : un des plus marquants de l’Histoire étant peut-être le système de guidage d’Apollo 11 [MB68]. Depuis, les générations de systèmes aéroportés se sont succédé, et des standards de développement comme l’IMA (Integrated Modular Avionics) ou l’ARINC-653 [Air15] se sont imposés, indices de la maturité de tels systèmes. Toutefois, les besoins du marché de l’avionique évoluent. Ainsi la taille des programmes embarqués sur les systèmes avioniques croît de manière exponentielle à chaque génération : les nouvelles requièrent pour cela toujours davantage de puissance de calcul que les précédentes [War+13]. De plus, les composants électroniques vieillissent jusqu’à devenir défectueux, ce qui signifie que le matériel des générations précédentes doit être remplacé. L’évolution continue du matériel conduit les fondeurs à privilégier de nouvelles générations de matériel, au détriment des plus anciennes, qui deviennent obsolètes et ne sont plus manufacturées, le coût de maintenance des installations surpassant les gains de vente. Le coût de développement du matériel (en particulier des processeurs) étant considérable (plusieurs centaines de millions de dollars [Bur90 ; Uhl19]), les fondeurs privilégient les marchés de masse plutôt que de cibler des domaines industriels de niche comme l’avionique. Pour ces mêmes raisons économiques, ces niches préfèrent l’achat de composants sur étagère, ou COTS (Component Off-The-Shelf), à l’investissement dans des solutions matérielles particulières, suivant la tendance du « Buy, don’t build » [LRS+94 ; Bak02].
Positionnement 2 (Composants matériels sur étagère). Nos travaux se limitent à l’étude des systèmes temps-réels de sûreté utilisant du matériel industriel sur étagère, c’est-à-dire fourni par une tierce partie, sans possibilité d’intervenir dans sa conception ou de le modifier.
Contraintes liées au processus industriel
Les processus de développement des logiciels temps-réels de sûreté avioniques sont régis par la norme DO-178C. Ceux-ci sont généralement implémentés via des méthodes de développement en « V » ou en spirale [Boe88]. Le constructeur détient la feuille de route qui découpe le système final en de multiples composants, dont des entités parfois multiples sont responsables de leur livraison. Les sous-systèmes critiques (c’est-à-dire hébergeant des applications temps-réelles de sûreté) sont découpés en de multiples briques logicielles, dont la cohérence est assurée par une fonction d’intégrateur. Ces fonctions logicielles sont livrées contractuellement ; le code source original n’est souvent pas disponible et encore moins modifiable. Il incombe à l’intégrateur de s’assurer du respect des exigences temporelles de cet ensemble. Dans cette optique, l’intégrateur réalise en amont une conception temporelle de son système, qui peut être amendée en aval, au fil de l’intégration.
Positionnement 3 (Intégration à la chaîne de production logicielle). Les contraintes temporelles étant particulièrement sensibles au niveau de l’intégration, c’est à ce niveau que nous orientons nos travaux. Nous considérons ainsi que le code fonctionnel dit « métier » est toujours écrit par un tiers et que nous ne pouvons intervenir directement sur son développement.
Concepts de partitionnement temporel
Paradigme « event-triggered »
La plupart des systèmes temps-réels non soumis à des contraintes de sûreté de fonctionnement privilégient une approche dite event-triggered, dans laquelle les événements extérieurs sont immédiatement pris en charge. Celle-ci peut simplement se traduire par la levée d’une interruption matérielle et son acquittement. Les calculs peuvent être traités de manière différée. La figure 2.1 illustre ce principe :
— une tâche (notée α) est élue par l’ordonnanceur ;
— α est préemptée par une interruption levée suite à un événement matériel ;
— la routine d’interruption, ou ISR (Interrupt Service Routine), prend en charge cet événement, qui donne lieu à un traitement ultérieur (tâche β) ;
— la main est rendue à α, qui complète, laissant à son tour la main à l’ordonnanceur;
— ce dernier permet l’élection de la tâche β.
Notons que d’autres stratégies que celle-ci sont possibles. Par exemple, l’ISR aurait pu se conclure par un appel à l’ordonnanceur permettant l’élection immédiate de β.
Cette approche centrée sur la réception d’événements, couplée avec une politique d’ordonnancement adéquate, comme privilégier l’élection des tâches avec la plus proche échéance, c.-à-d. EDF (Earliest Deadline First), permet une implémentation réactive et dynamique. Celle-ci permet d’exploiter le potentiel calculatoire d’un processeur qui est uniquement sollicité en présence d’événements. Toutefois, comme le flot de contrôle de l’exécution est piloté par des événements extérieurs dont les occurrences ne peuvent être prédites, il est ardu de prouver que de tels systèmes soient sûrs. C’est-à-dire que le bon fonctionnement du système n’est pas assuré quels que soient les événements reçus par le système.
Paradigme « time-triggered »
Le paradigme time-triggered s’oppose à l’event-triggered vu en section 2.2.1 en ne considérant qu’un seul type d’événement : l’écoulement du temps. Au vu des considérations physiques des systèmes étudiés, on peut raisonnablement considérer que le temps s’écoule de manière monotone et uniforme au sein d’un système donné. Dans ces travaux, nous distinguons le temps logique du temps physique. Le temps logique est produit par une horloge de Lamport, qui garantit un ordre total entre tous les événements (ou tics) produits par cette horloge, chaque tic produisant une estampille unique [Lam78]. Ce sont ces horloges logiques qui cadencent l’écoulement des événements temporels. Si le temps logique peut être uniquement conceptuel, le temps physique est toujours exprimé en unités de temps (c.-à-d. en secondes, selon le système international des unités) et capture le temps qui s’écoule dans le monde physique. Si leurs unités de temps ne sont pas nécessairement les mêmes, dans la pratique celles-ci sont fortement corrélées. D’autres travaux, comme le modèle des réacteurs [Loh+19], différencient également le temps logique du temps physique.
|
Table des matières
1 Introduction
1.1 Contexte
1.2 Contributions
1.3 Méthodologie
1.4 Plan
2 Systèmes temps-réels de sûreté
2.1 Contexte général et positionnement
2.1.1 Contraintes de sûreté de fonctionnement .
2.1.2 Contraintes opérationnelles
2.1.3 Contraintes liées au processus industriel
2.2 Concepts de partitionnement temporel
2.2.1 Paradigme « event-triggered »
2.2.2 Paradigme « time-triggered »
2.2.3 Multiplexage temporel statique
2.3 Problématique de provision de temps d’exécution
2.3.1 WCET : temps d’exécution dans le pire cas
2.3.2 Méthodes d’analyse du WCET
2.3.3 Interférences temporelles
2.4 Réduction des interférences temporelles
2.4.1 Utilisation de matériel dédié
2.4.2 Contrôle des caches
2.4.3 Prévention des accès simultanés multicœurs
2.5 Motivations de nos travaux
3 Cadre de travail industriel
3.1 Présentation
3.1.1 Origine d’Asterios
3.1.2 Chaîne outillée et noyau temps-réel
3.2 TCA : automates contraints par le temps
3.3 Modèle de programmation PsyC
3.3.1 Expression des horloges logiques
3.3.2 Utilisation des agents pour décrire des TCA
3.3.3 Communications inter-agents
3.4 Modèle d’exécution d’Asterios
3.4.1 Exécution des agents
3.4.2 Cloisonnement entre tâches
3.5 Étude de la plateforme matérielle de référence
3.6 Conclusion
4 Méthode de partitionnement spatial
4.1 Motivations
4.2 État de l’art du partitionnement spatial statique
4.3 Définition d’une méthode statique et vérifiable
4.3.1 Utilisation de chaînes de compilation qualifiées
4.3.2 Identification des spécificités matérielles
4.3.3 Abstraction de placement mémoire
4.3.4 Génération automatisée d’un binaire partitionné
4.3.5 Stratégie de validation du partitionnement spatial
4.4 Implémentation pour la plateforme MPC5777M
4.4.1 Sélection de la chaîne de compilation
4.4.2 Analyse du matériel de gestion de la mémoire
4.4.3 Génération des descripteurs mémoires
4.5 Implémentation pour la plateforme P2020
4.5.1 Présentation du P2020
4.5.2 Sélection de la chaîne de compilation
4.5.3 Analyse du matériel de gestion de la mémoire
4.5.4 Identification des données nécessaires à l’exécution
4.5.5 Génération des descripteurs mémoires
4.6 Validation expérimentale
4.6.1 Configuration de partitionnement spatial
4.6.2 Génération de l’exécutable final
4.7 Conclusion
5 Conclusion
