Approches par logiciel déterministe

Les approches de type logiciel déterministe se basent sur un domaine d’usage dans lequel le processeur est prédictible. Le logiciel est en charge de respecter ce domaine d’usage. On distingue dans les approches existantes celles où le logiciel est conçu pour respecter de lui-même le domaine d’usage –on parle de logiciel auto-contenu–, et celles pour lesquelles un logiciel dédié, que nous appelons logiciel de contrôle dans la suite de ce manuscrit, force le reste du logiciel à respecter le domaine d’usage.

Approche par logiciel auto-contenu

Dans les approches que l’on peut rencontrer dans la première catégorie, le logiciel est décomposé en phases d’exécution interne depuis une mémoire locale, et en phases de communication, lors desquelles il effectue les lectures et écritures sur les entrées/sorties et d’éventuels transferts de mémoire. Le logiciel est configuré pour ne pas communiquer sur l’interconnexion lors des phases d’exécution, si bien qu’il ne peut générer aucune interférence durant cette phase. Un ordonnancement statique garantit qu’il y a toujours au plus un cœur qui se trouve dans une phase de communication.

Chapitre 3. Évaluation du WCET dans les processeurs multi-cœurs

Pipel

in

e

MMU Cache interne

In ter fac e ver s l'int er con ne xio n Logiciel utile Logiciel de contrôle

Cœur

Figure 3.3 – Vue d’ensemble de la configuration d’un cœur dans l’approche par logiciel de contrôle de Jegu [54]

Un exemple d’implémentation de ce concept, appelé AER (Acquisition, Execution, Restitution) a été développé par Durrieu et al. [34] et expérimenté sur un Flight Mana- gement System déployé sur un processeur COTS. Cet exemple montre que les principes d’isolation temporelle des phases de communication permettent d’utiliser un processeur COTS dans un domaine d’usage où il est prédictible.

Approche par logiciel de contrôle

Jegu et al. proposent, dans un brevet déposé par Airbus [54], une approche reprenant les principes exposés ci-dessus. Ces principes sont implémentés dans un logiciel dédié, que nous appelons “logiciel de contrôle”. Ce logiciel, qui est déployé sur tous les cœurs, va réaliser lui-même les phases de communication pour le compte du logiciel qu’il contrôle, que nous appellerons “logiciel utile” par la suite.

Le logiciel utile est conçu en une succession de phases de communication (fetch, flush) et d’exécution (execute). L’activité des phases de communication est décrite dans une table de données que le logiciel de contrôle lit pour réaliser les communications à proprement parler à des dates maîtrisées. Il s’occupe également de charger les données et instructions nécessaires à la phase d’exécution, de telle sorte que cette dernière ait lieu depuis une mémoire cache privée. Enfin, comme illustré sur la figure 3.3, il garantit que le logiciel utile ne peut émettre d’accès durant sa phase d’exécution en configurant la MMU pour ne rendre accessible que des données présentes dans le cache.

Ce brevet s’accompagne d’une publication [26] expliquant comment construire les tables de données pour le logiciel de contrôle à partir d’une application décrite comme une séquence de traitements, comme peut l’être un modèle synchrone. Cette approche semble la plus prometteuse parmi celles que nous avons recensées, dans la mesure où elle vise les processeurs COTS, puis se place dans un domaine d’usage qui reprend les

3.4. Synthèse principes d’isolation temporels validés dans les approches à processeurs déterministes. Elle s’accompagne toutefois des limitations suivantes :

• Le logiciel doit être développé selon un modèle d’exécution contraint, puis analysé pour obtenir les tables de configuration du logiciel de contrôle. Cela empêche toute réutilisation du logiciel existant.

• À notre connaissance, aucune implémentation de cette approche n’a été réalisée. Nous ne connaissons pas l’impact sur le temps d’exécution du logiciel.

Nous revenons sur cette approche dans le chapitre 4, où nous définissons notre pro- blématique de thèse.

3.4

Synthèse

Nous avons donné une vue d’ensemble des méthodes d’évaluation du WCET, et de leur application potentielle dans un contexte d’utilisation d’un processeur multi-cœurs. La principale difficulté, qui fait consensus dans les communautés industrielles et scienti- fiques, porte sur l’évaluation des perturbations engendrées sur une tâche par les tâches concurrentes exécutées sur les autres cœurs. Ces perturbations résultent de la présence d’interférences entre les activités électroniques concurrentes, qui surviennent lorsque les cœurs accèdent à des ressources matérielles communes. On cherche à borner ces pertur- bations en appliquant des pénalités d’interférences.

Le problème vient du fait qu’on ne connaît pas aujourd’hui de méthode pour éva- luer une pénalité d’interférences sur un processeur COTS sans connaître l’intégralité des tâches embarquées, ou sans poser des restrictions sur l’utilisation des ressources com- munes par les cœurs. Or, les méthodes mono-cœurs n’abordent pas ces questions.

Nous nous sommes donc intéressés à des méthodes alternatives, qui étendent les méthodes mono-cœurs pour traiter la question des interférences. Ces approches visent soit à obtenir une pénalité d’interférences globale à partir du profil d’utilisation des res- sources communes par toutes les tâches embarquées, soit à éliminer par construction les interférences en posant des restrictions sur l’usage des ressources communes par les cœurs.

Les approches par pénalité globale sont intéressantes, mais inapplicables dans notre contexte car elles invalident la propriété de partitionnement robuste, contrairement aux approches par élimination des interférences. Ces dernières mettent en œuvre des principes d’isolation temporelle des activités concurrentes émises par les différents cœurs. Dans la plupart des approches, ces principes sont implémentés dans le matériel, ce qui a abouti à des prototypes de processeurs adaptés pour le calcul du WCET. Ces approches ne sont à l’heure actuelle pas suivies par les fabricants de processeurs. D’autres approches, par logiciel déterministe, s’intéressent à la manière d’organiser le logiciel embarqué pour que l’activité qu’il génère s’insère dans des fenêtres temporelles disjointes. Ces approches sont au cœur de notre problématique de thèse, que nous développons dans le chapitre suivant.

Troisième partie

Démarche scientifique

Chapitre 4

Problématique

Sommaire

4.1 Problème général . . . . 53