L'isolation des systèmes temps réel est une nécessité pour garantir la fiabilité et la sécurité en limitant ou en empêchant certaines interactions entre les différents composants d'un système. Dans les systèmes temps réel, les composants à isoler les uns des autres sont généralement les différentes tâches exécutées sur le système et les ressources spatiales et temporelles que celles-ci utilisent. Les ressources spatiales comprennent les différents types de mémoires présents dans le système : mémoire cache, mémoire vive, etc. Les ressources temporelles correspondent au temps pendant lequel une tâche a accès au processeur en comprenant le temps d'accès aux ressources. Selon le type d'isolation recherchée (spatiale, temporelle, consommation d'énergie, etc.), différentes solutions peuvent être mises en place. Ces différentes solutions peuvent passer par la virtualisation ou par le partitionnement des ressources, c'est-à-dire limiter l'accès aux ressources de certaines tâches pour améliorer le temps d'accès à ces ressources. Ces pratiques de partitionnement sont notamment très répandues dans les systèmes systèmes temps réel qui possèdent un processeur multi-cœur car cela permet une meilleure isolation temporelle entre les tâches exécutées sur les différents cœurs en rendant le temps d'accès aux ressources partagées plus déterministe. Les systèmes à criticité mixte sont un type de système temps réel qui doivent fournir certaines garanties quant à leur capacité à faire cohabiter les tâches à criticités élevées et faibles. Dans un système à criticité mixte il y a au minimum deux niveaux de criticité, critique et non-critique, et plus le niveau de criticité d'une tâche est élevé, plus les contraintes sur cette tâche seront fortes.

Systèmes à criticité mixte

Définition Les systèmes à criticité mixte (Mixted Criticality Systems en anglais ou MCS) désigne des systèmes temps réel sur lesquels des applications avec des niveaux de criticité différents cohabitent et peuvent échanger des ressources sans qu'il soit nécessaire de prévoir les cas particuliers. À chaque processus est associé un niveau de criticité qui correspond à un palier d'importance prédéfini dans le système. Un système à criticité mixte a au moins deux niveaux de criticité distincts. Ces groupes de criticité assurent un niveau de confiance hétérogène permettant d'éviter la propagation des erreurs. À chaque processus est attribué un niveau de criticité qui correspond un niveau de confiance que ce processus se doit de respecter : plus le niveau de criticité de ce processus sera élevé, plus cela signifie que la confiance que l'on attribue à ce processus est forte et plus il doit être isolé des autres processus et moins il doit avoir de chance d'être corrompu par les erreurs des autres processus. Un processus dans un système à criticité mixte se distingue des autres systèmes par des paramètres spécifiques tels que le temps d'exécution pire-cas ( en anglais ou WCET), une deadline, une période et un niveau de criticité. Le WCET, la période et la deadline dépendent du niveau de criticité de la tâche. Un niveau de criticité élevé entraîne une majoration importante du WCET pour une application.

Problématiques Les systèmes à criticité mixte doivent apporter un certain nombre de garanties quant à la capacité qu'ils ont à exécuter en harmonie sans que les tâches critiques ne dépassent leur échéance. D'après Burns et Davis, cela implique de trouver un compromis entre le partitionnement des ressources pour assurer un certain niveau de sécurité des tâches et le partage des ressources de manière efficace pour assurer la sûreté du système. Une bonne gestion des ressources implique également d'apporter au système des solutions d'accès déterministe aux ressources.

Partage & partitionnement La problématique principale des systèmes à criticité mixte réside dans le bon équilibre entre partitionnement et partage des ressources. La gestion des ressources partagées est cruciale pour assurer des performances suffisantes pour accueillir des tâches temps réel. L'allocation de ces ressources est notamment un des points critiques à aborder dans un système temps réel. Par exemple, le temps d'accès à la mémoire partagée peut varier selon que la page à laquelle la tâche souhaite accéder n'a pas été utilisée depuis longtemps par le processus propriétaire de la page. Le partitionnement des ressources est une problématique importante dans les systèmes à criticité mixte. La répartition du temps d'utilisation du processeur, par exemple, peut permettre de réduire l'impact d'une attaque par déni de service (Denial of Service en anglais) visant à utiliser la totalité du temps de calcul du processeur ou encore en ayant une utilisation intensive des ressources partagées.

Délai d'accès aux ressources Pour respecter ces garanties, les systèmes à criticité mixte se doivent de pouvoir accéder aux ressources sans qu'une tâche ne puisse interférer avec le temps d'exécution des autres tâches. Le temps d'exécution d'une tâche étant intimement lié au délai d'accès aux ressources comme la mémoire ou le cache, il est important de disposer de mécanisme permettant de rendre déterministe le délai lié d'accès à une ressource.

Sûreté

La sûreté sera abordé sous l'angle de la fiabilité du système temps réel. C'est donc naturellement que le thème de l'isolation temporelle sera plus abordé car l'isolation temporelle permet d'assurer directement la fiabilité du système en faisant en sorte que chaque tâche respecte ses échéances. L'isolation temporelle est directement reliée à la fiabilité du système dans le sens où une tâche isolée temporellement des autres tâches s'exécutera comme si elle était seule à être exécutée sur le système ce qui évitera des variations de temps d'exécution. L'isolation spatiale permet, de son côté, d'assurer une partie de la fiabilité du système en empêchant une erreur de programmation d'affecter d'autres tâches que celle qui a provoqué l'erreur.

Isolation temporelle Un processus est isolé temporellement s'il s'exécute indépendamment de la charge de travail des autres processus ; son temps d'exécution n'est pas influencé par l'exécution d'autres processus sur le système.

Systèmes à criticité mixte et isolation temporelle L'exécution de fonctionnalités critiques doit être protégée des interférences générées par des processus non critiques. Une première approche consiste à partager le temps du processeur entre les tâches de manière la plus proche de l'optimale possible. Le calcul du (WCET) est une borne haute utilisée pour répartir le temps de calcul du processeur entre les tâches. Il s'agit d'une garantie de temps de réponse pour les applications en cours d'exécution. Le modèle courant utilisé dans les systèmes à criticité mixte pour assurer l'isolation temporelle est basé sur ces caractéristiques : les tâches T sont définies par une période défini par l'intervalle de temps qui sépare deux activations de la tâche, une limite D, le temps d'exécution C et un niveau de criticité L.

Response Time Analysis Response Time Analysis (RTA) est une méthode consistant à évaluer le temps de réponse pour déterminer le temps d'exécution d'une tâche et ainsi prévenir le dépassement de temps alloué pour ce processus. L'intérêt est d'approcher la valeur optimale d'utilisation des ressources. Dans l'article écrit par Baruah une première possibilité (pour l'implémentation de RTA) est de ranger les tâches par niveau de criticité puis d'utiliser l'algorithme de Audsley sur chaque niveau de criticité pour assigner les priorités aux tâches en les ordonnant de la plus basse à la plus haute. Le test d'ordonnancement des tâches se fait en parcourant par ordre croissant de priorité le niveau de criticité basse puis le niveau de criticité haute. L'approche de Vestal prend en compte deux types de criticité : haute et basse. Les tâches peuvent être interrompues pendant leur traitement quel que soit leur niveau de criticité et toutes les tâches doivent être exécutées comme si elles avaient le plus haut niveau de criticité. Elle se distingue de la méthode précédente dans l'article de Baruah parce qu'elle ne définit pas les priorités par deadline monotonic. En effet Vestal a démontré que le "deadline monotonic prority assignment" n'était pas optimal pour les tâches qui ont plus d'un WCET ().

Slack Scheduling D'autres méthodes existent, comme le Slack Scheduling qui consiste à utiliser le temps non utilisé par les tâches critiques pour les tâches non critiques. Least Slack Time First (LST) est une implémentation pour laquelle un slack time court privilégie une tâche en augmentant sa priorité.

Cette équation mesure le taux d'utilisation du processeur.

D représente la limite de temps relative pour cette tâche, e le temps d'exécution alloué à la tâche pour chaque période. u représente la somme du rapport entre e et D pour chaque tâche, il s'agit d'un coefficient. + Exemple avec 3 tâches Tasks D eT1123T263T341 Les tâches suivantes devraient s'exécuter de manière optimale : sans que le processeur soit dans une situation où il n'ait rien à exécuter. On voit que , il n'y a pas de temps mort.

Period Transformation Il est également possible de faire coexister des applications critiques et non critiques en transformant la période des tâches (Period Transformation). Le principe est de diviser les tâches critiques, ainsi la période et le temps d'exécution de ces sous tâches est inférieure ce qui augmente leur priorité d'exécution par rapport aux tâches non critiques. La contrepartie de cette solution est l'accroissement du temps d'exécution d'ordonnancement dû à l'augmentation du nombre de tâches.

Exception temporelle La programmation orientée objet offre la possibilité d'attribuer une contrainte à une suite d'instructions. Si l'une des instructions ne se respecte pas la contrainte, un événement, aussi appelé exception, vient interrompre l'exécution normale du programme. Appliquée aux systèmes temps réel, une exception générée après un temps donné est un moyen efficace d'isoler temporellement les processus en les empêchant de dépasser le temps qui leur a été attribué. Les méthodes utilisant des délais est courant dans les systèmes tolérants aux pannes : l'expiration de ce délai met en évidence une anomalie dans l'exécution du processus. Une fois l'anomalie détectée, il devient possible de la gérer par l'arrêt du processus, par exemple.

Multicœurs et isolation temporelle Dans le contexte d'une plateforme multi-cœurs d'autres pistes ont été abordées comme l'exécution exclusive des tâches critiques sur les cœurs disponibles pendant un intervalle de temps avant que les applications non critiques puissent prendre la main. AMC () s'appuie sur une segmentation en deux groupes d'applications distinctes : critiques et non critiques. En l'absence de nécessité d'exécuter des tâches critiques alors les tâches non critiques peuvent être prises en considération, à l'inverse se sont toujours les tâches critiques qui ont la main.

Cache partagé Le cache partagé étant une des ressources les plus sollicitées, le temps d'accès à celle-ci peut être très variable même lorsque chaque cœur possède sa partition dédiée de cache. Cette ressource pouvant faire varier le temps d'exécution pire-cas d'une tâche (Worst Case Execution Time en anglais ou WCET), rendre plus prévisible le temps d'accès à celle-ci permettrait donc d'améliorer le temps d'exécution pire-cas d'une tâche.

Ordonnancement Memory-Centric