David Decotigny Projet ACES

Présentation au sujet: "David Decotigny Projet ACES"— Transcription de la présentation:

1 David Decotigny Projet ACES
Une infrastructure modulaire de simulation pour l’évaluation de performances de systèmes temps-réel David Decotigny Projet ACES

2 Plan de l’exposé Contexte et problématique
Critères et méthodes d’évaluation Infrastructure extensible pour l’évaluation de systèmes temps-réel Une extension : famille d’ordonnanceurs personnalisable Expérimentations : mesure de l’influence de la perception du temps Conclusions et perspectives Famille d’ordonnanceurs => permet de montrer en quoi et comment on peut étendre et personnaliser le système simulé Prise en compte => comment on peut mener une série d’expériences et les résultats qu’on peut exploiter Une infrastructure de simulation pour l’évaluation de performances de systèmes temps-réel

3 Introduction (1/3) Systèmes temps-réel
Correction fonctionnelle Respect des contraintes temporelles Temps = donnée physique mesurable Contraintes de temps Échéances temporelles, retard au démarrage maximal, … Types de systèmes temps-réel Temps-réel strict : garanties strictes Temps-réel souple : garanties relatives (probabilistes) Tout d’abord, intro au domaine => permet de definir certains points de terminologie Une infrastructure de simulation pour l’évaluation de performances de systèmes temps-réel

4 Introduction (2/3) Modèle de système
Niveau logiciel Application Plusieurs tâches Support d’exécution Gestion de ressources Interaction avec l’environnement Niveau matériel Processeur Environnement Réseau Il existe d’autres formalismes (logiques, algebres, methodes structurelles [RdPt, reactif synchrone] : le temps pour nous est physique ! Preciser les attrbuts temporels (echeance, gigue…) Une infrastructure de simulation pour l’évaluation de performances de systèmes temps-réel

5 Introduction (3/3) Notions d’ordonnancement temps-réel
Déroulement de l’exécution de l’application Décisions d’arbitrage du processeur Ordonnancement Défini hors-ligne Défini en-ligne À plan dynamique À priorité statique (RM/DM), dynamique (EDF, LLF) Repose sur un modèle de tâche Caractéristiques : loi d’activation, temps d’exécution pire-cas Contraintes de temps Entrelacement des exec : parler explicitement de multitache Ordonnancement = arbitrage des demandes en processeur pour respect des contraintes tempo. Règles et algorithmes pour le partage du processeur afin de respecter les contraintes temporelles Ordo HL => dit « cyclique » ou « par plans » Necessite d’evaluer => en particulier lorsque une partie non caracterisee Nécessité d’évaluer le comportement et les garanties offertes Une infrastructure de simulation pour l’évaluation de performances de systèmes temps-réel

6 Plan de l’exposé Contexte et problématique
Critères et méthodes d’évaluation Infrastructure extensible pour l’évaluation de systèmes temps-réel Une extension : famille d’ordonnanceurs personnalisable Expérimentations : mesure de l’influence de la perception du temps Conclusions et perspectives Famille d’ordonnanceurs => permet de montrer en quoi et comment on peut étendre et personnaliser le système simulé Prise en compte => comment on peut mener une série d’expériences et les résultats qu’on peut exploiter Une infrastructure de simulation pour l’évaluation de performances de systèmes temps-réel

7 Critères d’évaluation
Verdict d’ordonnançabilité : existence et détermination d’un ordonnancement faisable Temps-réel strict Mesures quantitatives sur le comportement effectif Temps-réel souple ou strict Taux de respect des contraintes temporelles Distribution des retards au démarrage Une infrastructure de simulation pour l’évaluation de performances de systèmes temps-réel

8 Méthodes d’évaluation (1/3)
Méthodes analytiques Principe En entrée : modèle abstrait + formalisme associé Identifier les configuration(s) possible(s) Objectif Verdict d’ordonnançabilité Caractéristiques stochastiques Intérêts Tôt dans le processus de développement Sûreté Limitations Données en entrée toutes connues sûres Modèles simples : risque de non représentativité Expliquer modele abstrait/concret TR strict => pires configs possibles + analyse déterministe TR souple => les configs moyennes + analyse stochastique Donnees en entree sures => a tous les niveaux : WCET (pb HW), interactions environnement (=> pessimisme obligatoire), … Surete du verdict : sous reserve que les conditions nominales de fonctionnement sont respectées Modeles simples a cause complexite d’analyse (NP-complet) Une infrastructure de simulation pour l’évaluation de performances de systèmes temps-réel

9 Méthodes d’évaluation (2/3)
Exécution réelle instrumentée Principe En entrée : implantation complète Mesures quantitatives à l’aide de sondes Objectifs Confronter les mesures aux spécifications Intérêt Représentativité des mesures Limitations Tard dans le processus de développement Résultats non sûrs Sonde : « Effet sonde » Sonde matérielle : surcoût inutile à la fabrication Extraire mesures => peut servir pour comparer les perfs de 2 systemes « Résultats non sûrs » : sauf si couverture complète => parler de /couverture/ Effet sonde => « trop » de coûts d’execution pris en compte Une infrastructure de simulation pour l’évaluation de performances de systèmes temps-réel

10 Méthodes d’évaluation (3/3)
Simulation Principe En entrée : modèle abstrait ou concret du système Mesures quantitatives Objectifs Confronter les mesures aux spécifications Intérêts Tôt ou tard dans le preocessus de développement Pas d’effet sonde Limitation Résultats non sûrs Précautions à prendre Pertinence de la simulation sur les modèles concrets Pas d’effet sonde => instrumentation fait partie du simu, pas du systeme simule Pertinence => prise en compte de tous les couts (y compris systeme déxploitation) Une infrastructure de simulation pour l’évaluation de performances de systèmes temps-réel

11 Objectifs Évaluer le comportement temporel de systèmes complexes
Permettre les évaluations tout au long du processus de développement Modèles abstraits Modèles concrets / réutilisation de code Choix de la méthode d’évaluation par simulation Précaution : assurer un haut degré de pertinence Eval comportement syst complexes => modeles analytiques dépasses car trop simplistes, ou syst non totalement caracterises, ou modeles trop pessimistes Extraires mesures => y compris pour completer les methodes sures d’analyse statiques d’ordo Une infrastructure de simulation pour l’évaluation de performances de systèmes temps-réel

12 Plan de l’exposé Contexte et problématique
Critères et méthodes d’évaluation Infrastructure extensible pour l’évaluation de systèmes temps-réel Une extension : famille d’ordonnanceurs personnalisable Expérimentations : mesure de l’influence de la perception du temps Conclusions et perspectives Famille d’ordonnanceurs => permet de montrer en quoi et comment on peut étendre et personnaliser le système simulé Prise en compte => comment on peut mener une série d’expériences et les résultats qu’on peut exploiter Une infrastructure de simulation pour l’évaluation de performances de systèmes temps-réel

13 Ce qu’on attend d’un simulateur
Capacités de personnalisation les tâches de l’application les services du support d’exécution l’ordonnanceur et le modèle de tâches associé Pertinence du comportement temporel simulé Prise en compte des durées d’exécution des éléments du système Perso taches => reutilisation de code Prise en compte des durées d’exécution des éléments du système Application, Support d’exécution (dont l’ordonnanceur) Une infrastructure de simulation pour l’évaluation de performances de systèmes temps-réel

14 Limitations des simulateurs existants
Simulateurs à événements discrets généraux Difficulté d’assurer la pertinence du comportement temporel simulé Simulation adaptée à un domaine différent Simulateurs d’ordonnancement Capacités de personnalisation limitées Pertinence du comportement temporel simulé limitée Simulateurs de systèmes complets Priorité aux problèmes de synchronisation Problèmes d’efficacité Simu taches abstraites : , Difficile de réutiliser du code d’applications déjà existantes Systemes complets => parler des simulateurs niveau instr (tout Ok sauf perfs) Pb efficacite => simulateurs niveau instruction Une infrastructure de simulation pour l’évaluation de performances de systèmes temps-réel

15 Vue d’ensemble du simulateur réalisé (1/3)
Artisst is a Real-Time System Simulation Tool Infrastructure modulaire Module central : simulation de système temps-réel Capacités de personnalisation à tous niveaux Fidélité des comportements temporels simulés Précision temporelle de simulation indépendante de la perception du temps par le système Efficacité de simulation Simulation de systèmes distribués Simulation des pertes et altérations de messages sur le réseau Reproduction des dérives d’horloges Modulaire => notion de circuit de simu. Faculté de personnalisation : interface et code du support d’exécution, ordonnanceur, modèles de tâches, application (réutilisation de code) Fidélité des comportements temporels : prise en compte des coûts d’exécution du support d’exécution, de l’ordonnanceur, de l’application Granularité temporelle de simulation indépendante de la résolution d’horloge système Efficacité de simulation Structure extensible avec boîte à outils par défaut (nombreux ordonnanceurs paramétrables/modèles de tâches) Granularite indep resolution Sys Clk : pas obliges de prendre des occupations de cpu multiples d’un quanta grossier. Possibilite de mesurer l’effet des derives ou des irregularites d’horloge Extensible/boite a outils : ordonnanceurs dispo Une infrastructure de simulation pour l’évaluation de performances de systèmes temps-réel

16 Vue d’ensemble du simulateur (2/3)
Lecteur de traces INTERRUPT_RAISED 0 INTERRUPT_RAISED 0 INTERRUPT_RAISED 0 INTERRUPT_RAISED 0 INTERRUPT_RAISED 0 INTERRUPT_RAISED 0 INTERRUPT_RAISED 1 INTERRUPT_RAISED 2 INTERRUPT_RAISED 3 Générateur d'événements Environnement Analyse statistique Chronogramme Enregistreur de traces INTERRUPT_RAISED 0 SUSPEND_TASK_EXECUTION 0 INTERRUPT_ENTER 0 INTERRUPT_LEAVE 0 RESUME_TASK_EXECUTION 0 INTERRUPT_RAISED 0 SUSPEND_TASK_EXECUTION 0 INTERRUPT_ENTER 0 Observations Système à évaluer Dire qu’il s’agit d’une bibliotheque Insister sur la notion de circuit de simulation Insister sur les modules de simu de lénvt d’une part, et d’exploitation d’autre part Insister sur la notion de modules et les différents modules disponibles + en définir et ajouter d’autres Une infrastructure de simulation pour l’évaluation de performances de systèmes temps-réel

17 Vue d’ensemble du simulateur (3/3)
Traitants d’interruptions Tâches Tâche Clock ISR Insister sur la réutilisation de code + parametre quelconque au hold_cpu (evalue en-ligne) Support d’exécution Ordonnanceur Interruptions Une infrastructure de simulation pour l’évaluation de performances de systèmes temps-réel

18 Propriétés du simulateur (1/4) Modularité
Chronogramme Circuit personnalisable Analyse statistique Enregistreur de traces INTERRUPT_RAISED 0 SUSPEND_TASK_EXECUTION 0 INTERRUPT_ENTER 0 INTERRUPT_LEAVE 0 RESUME_TASK_EXECUTION 0 INTERRUPT_RAISED 0 SUSPEND_TASK_EXECUTION 0 INTERRUPT_ENTER 0 Modules par défaut personnalisables Messages Environnement Autres modules possibles Générateur d'événements Système à évaluer Dire qu’il s’agit d’une bibliotheque Insister sur la notion de circuit de simulation Insister sur les modules de simu de lénvt d’une part, et d’exploitation d’autre part Insister sur la notion de modules et les différents modules disponibles + en définir et ajouter d’autres Une infrastructure de simulation pour l’évaluation de performances de systèmes temps-réel

19 Propriétés du simulateur (2/4) Modularité
Possibilité de connecter les systèmes simulés en réseau Diffusion totale sans perte ni délai par un module central Simulation du routage et des pertes/délais à chaque nœud Une infrastructure de simulation pour l’évaluation de performances de systèmes temps-réel

20 Propriétés du simulateur (3/4) Personnalisation du système simulé
Traitants d’interruptions Modèle de tâche Tâches compute_fft(data1, result1); t = spawn_task(task_entry); compute_fft(data2, result2); ... change_date(); activate_task(); ... Tâche 0 Clock ISR ... cur_task = next_task; Ordonnanceur Take_resource res->ref++; API OS Perso Insister sur la réutilisation de code + parametre quelconque au hold_cpu (evalue en-ligne) spawn_task cancel_task get_date change_date OS basique Interruptions Une infrastructure de simulation pour l’évaluation de performances de systèmes temps-réel

21 Traitants d’interruptions
Propriétés du simulateur (4/4) Fidélité des comportements temporels simulés spawn_task cancel_task get_date change_date OS basique Interruptions Take_resource res->ref++; API OS Perso Tâches Traitants d’interruptions Tâche 0 Clock ISR change_date(); activate_task(); ... cur_task = next_task; Ordonnanceur compute_fft(data1, result1); t = spawn_task(task_entry); compute_fft(data2, result2); hold_cpu(sec(3)); hold_cpu(sec(2)); hold_cpu(sec(4)); hold_cpu(ms(2)); hold_cpu(ms(2)); hold_cpu(ms(30)); Insister sur la réutilisation de code + parametre quelconque au hold_cpu (evalue en-ligne) Une infrastructure de simulation pour l’évaluation de performances de systèmes temps-réel

22 Plan de l’exposé Contexte et problématique
Critères et méthodes d’évaluation Infrastructure extensible pour l’évaluation de systèmes temps-réel Une extension : famille d’ordonnanceurs personnalisable Expérimentations : mesure de l’influence de la perception du temps Conclusions et perspectives Famille d’ordonnanceurs => permet de montrer en quoi et comment on peut étendre et personnaliser le système simulé Prise en compte => comment on peut mener une série d’expériences et les résultats qu’on peut exploiter Une infrastructure de simulation pour l’évaluation de performances de systèmes temps-réel

23 Famille d’ordonnanceurs dynamiques (1/3) Introduction
Principe général des ordonnanceurs dynamiques Test d’acceptation Sélectionner les tâches à intégrer au système, refuser les autres Ordonnancement Garantir le respect des échéances des tâches acceptées Contexte Aucune tâche garantie hors-ligne Tâches activées Indépendantes Aucune hypothèse sur les lois d’activation Loi d’activation => discours = « rythme ou fréquence » Chaque tâche possède une contrainte d’échéance On connaît le temps d’exécution au pire (WCET) de chaque tâche  Une infrastructure de simulation pour l’évaluation de performances de systèmes temps-réel

24 Famille d’ordonnanceurs dynamiques (2/3) Principe
Principe du test d’acceptation Suppose un ordonnancement à priorité Repose sur le calcul du temps processeur disponible pour chaque tâche ???? Priorités Acceptée Refusée Refusée Hypotheses fortes verifiee sur la grande majorite des ordo classiques : EDF, RM/DM et meme fifo. Seule exception notable : LLF. Observation : 2 propriétés sur les priorités suffisent Priorités relatives indépendantes du temps Priorités relatives indépendantes de l’insertion et de la suppression de tâches Une infrastructure de simulation pour l’évaluation de performances de systèmes temps-réel

25 Famille d’ordonnanceurs dynamiques (3/3) Propriétés de l’approche
Unifie une grande partie des algorithmes de garantie à priorité classiques (DM, RM, EDF, … et même Fifo) Généralise une approche systématique pour : Test d’ordonnancement Ordonnancement avec repêchage Ordonnancement avec politiques de rejet Famille d’ordonnanceurs génériques spécialisable par 1, 2 ou 3 fonctions de comparaison des priorités Une infrastructure de simulation pour l’évaluation de performances de systèmes temps-réel

26 Plan de l’exposé Contexte et problématique
Critères et méthodes d’évaluation Infrastructure extensible pour l’évaluation de systèmes temps-réel Une extension : famille d’ordonnanceurs personnalisable Expérimentations : mesure de l’influence de la perception du temps Conclusions et perspectives Famille d’ordonnanceurs => permet de montrer en quoi et comment on peut étendre et personnaliser le système simulé Prise en compte => comment on peut mener une série d’expériences et les résultats qu’on peut exploiter Une infrastructure de simulation pour l’évaluation de performances de systèmes temps-réel

27 Hypothèses classiques en ordonnancement
Prise en compte de la granularité d’horloge (1/4) Problématique : perception du temps Hypothèses classiques en ordonnancement Mesures exactes des dates et durées Dans les systèmes réels, deux échelles de temps : Dates temps-réel Difficilement accessibles par le système Temps-réel Temps mesuré Dates « temps-système » internes au système Approximation locale discontinue du temps-réel Possibilité d’étudier l’influence de la granularité ou de l’irrégularité de l’horloge système Adapté à la simulation de systèmes distribués Résolution de la simulation plus fine que la durée d’un tick d’horloge => possibilite d’étudier l’influence de la ClockRes sur le comportement du systeme Possibilité de simuler des dérives ou des irrégularités d’horloges => Adapté à la simulation de systèmes distribués Prendre cette approximation en compte dans les décisions liées au temps Une infrastructure de simulation pour l’évaluation de performances de systèmes temps-réel

28 Objectif Grandeurs affectées
Prise en compte de la granularité d’horloge (2/4) Règles de prise en compte définies Objectif Conserver la sûreté des tests d’acceptation Se placer dans les cas pessimistes Grandeurs affectées Dates Date de fin de tâche pessimiste Date d’échéance dans l’échelle de temps système Durées Temps d’exécution pire cas restant à exécuter par une tâche Temps non utilisé par une tâche Grandeurs affectées => dans tous les algo d’acceptation dynamique Tps non utilise => recup de ressources Une infrastructure de simulation pour l’évaluation de performances de systèmes temps-réel

29 Simulation avec Artisst
Prise en compte de la granularité d’horloge (3/4) Évaluation de l’impact : dispositif expérimental Simulation avec Artisst Utilisation des ordonnanceurs dynamiques de la famille présentée Charge synthétique avec durée d’exécution des tâches variable Mesure du taux d’acceptation en fonction de la granularité d’horloge système des paramètres de la charge Charge individuelle moyenne : ratio WCET / échéance relative Facteur de recouvrement : ratio échéance relative / délai d’inter-arrivée moyen Sans ou avec coûts système : traitant d’interruption, ordonnanceur, activation de tâche (distribution uniforme sur [0, 0.5ms]) 1200 simulations, chacune représentant 7 jours en temps-réel simulé 10 machines fonctionnant chaque nuit pendant environ 2,5 mois De 5 minutes à 3 jours par simulation (suivant la résolution d’horloge) Une infrastructure de simulation pour l’évaluation de performances de systèmes temps-réel

30 Prise en compte de la granularité d’horloge (4/4) Évaluation de l’impact : résultats
EDF 0.1 0.4 0.7 0.9 charge 10 50 100 granularité (ms) Taux de garantie (%) EDF 0.1 0.4 0.7 0.9 charge 10 50 100 granularité (ms) 40 Taux de garantie (%) Taux de garantie (%) EDF 50 40 30 20 0.1 0.4 100 charge 0.7 50 0.9 10 granularité (ms) Recouvrement = 1 Sans coûts OS Recouvrement = 3 Sans coûts OS Recouvrement = 3 Avec coûts OS Impact d’autant plus fort que la charge individuelle moyenne est élevée Influence de la charge individuelle moyenne prépondérante Impact d’autant plus faible que la charge globale augmente Coûts OS négligeables à grosse granularité prépondérants quand ils sont comparables à la granularité d’horloge Chaque campagne = 1 figure comme ca (16 a 20 pts), pour 4 affectations des priorites de la famille JFP => 4x4 graphiques comme ca + 2 autres ordos (2 autres figs) => tout ca repete 2 fois (2 facteurs de recouvrement) Impact tres fort : jusqu’à 50% ! Une infrastructure de simulation pour l’évaluation de performances de systèmes temps-réel

31 Plan de l’exposé Contexte et problématique
Critères et méthodes d’évaluation Infrastructure extensible pour l’évaluation de systèmes temps-réel Une extension : famille d’ordonnanceurs personnalisable Expérimentations : mesure de l’influence de la perception du temps Conclusions et perspectives Famille d’ordonnanceurs => permet de montrer en quoi et comment on peut étendre et personnaliser le système simulé Prise en compte => comment on peut mener une série d’expériences et les résultats qu’on peut exploiter Une infrastructure de simulation pour l’évaluation de performances de systèmes temps-réel

32 Conclusions et perspectives (1/3)
Bilan Infrastructure de simulation Modulaire, personnalisable et extensible Fidélité de prise en compte des coûts d’exécution Décorrélation des échelles de temps-réel et système Famille d’ordonnanceurs à acceptation dynamique Unification des affectations de priorités classiques Algorithmes généraux indépendants des affectations de priorité Règles de prise en compte de la granularité d’horloge système Intégrées dans les ordonnanceurs fournis Impact évalué sur 3 séries de 18 configurations avec Artisst Une infrastructure de simulation pour l’évaluation de performances de systèmes temps-réel

33 Conclusions et perspectives (2/3)
Disponibilité d’Artisst : licence LGPL 3 types de modules en entrée, 4 types de modules en sortie Module de simulation de systèmes temps-réel bien éprouvé 9 types d’ordonnanceurs temps-réel fournis Validation sur des systèmes centralisés et distribués avec ou sans partage de ressources (aucun protocole d’accès) (temporaire) Une infrastructure de simulation pour l’évaluation de performances de systèmes temps-réel

34 Conclusions et perspectives (3/3)
Inclure le support des tâches dépendantes en centralisé et distribué Proposer un mécanisme de composition d’ordonnanceurs Approche déjà entamée dans Artisst Évaluer l’influence de l’interface de programmation de différents OS Services de réveil de tâches, … Couvrir tout le processus de développement Récupération automatique du paramètre de hold_cpu() Interet integration avec analyse statique => obtenir mesures quantitatives Eval taches depend + syst distribues => ajouter mecanismes d’ordo Pourquoi composition d’ordo => systemes ouverts Compo d’ordo = idem boite a outils ~ STL en algo Influence API OS : ex : programmation des dates de reveil (relatif, absolu, …) Une infrastructure de simulation pour l’évaluation de performances de systèmes temps-réel

35 Une infrastructure de simulation pour l’évaluation de performances de systèmes temps-réel

36 Introduction (4/4) Problématique
Quand tous les comportements temporels Du système (exécution des tâches, support d’exécution, …) et De ses interactions avec l’environnement (lois d’activations, …) sont totalement caractérisés Il peut exister des conditions de faisabilité associées à un ordonnancement Exemples : (EDF, LLF), (RM) Sinon : Moins de contraintes  moins de garanties Nécessité d’ TR strict => on connaît tout => preuves « formelles » possibles Totalement caractérisé => parler de données en entrée = loi d’activation (Pi), WCET (Ci) Conditions de faisabilite : condition necessaire (maths) d’existence d’un ordo faisable : preuve que tout se passera bien. évaluer le comportement et les garanties offertes Une infrastructure de simulation pour l’évaluation de performances de systèmes temps-réel

37 Motivations et objectifs (2/2)
Proposition d’une infrastructure de simulation Extensible et personnalisable Accent mis sur la pertinence des comportements de l’environnement et du système reproduits Validation de sa faculté de personnalisation Intégration de plusieurs ordonnanceurs / modèles de tâches Proposition d’une famille générique d’ordonnanceurs Utilisation du simulateur pour l’étude de l’influence de la précision de perception du temps sur les décisions d’ordonnancement Établissement de règles analytiques pour sa prise en compte dans les ordonnanceurs réalisés Mesures sur les comportements résultants Famille générique => unification de l’existant Une infrastructure de simulation pour l’évaluation de performances de systèmes temps-réel

38 Ce qu’on attend d’un simulateur (1/2)
Pertinence de la simulation de l’environnement Pouvoir faire interagir le système avec une grande variété de composantes de l’environnement simulé Pertinence de l’évaluation du système Pertinence du modèle simulé Abstrait & concret : facilité de personnalisation des éléments du système Modèles de tâches, Services du support d’exécution (dont l’ordonnanceur) Concret : rester le plus proche possible de l’implantation concrète Réutilisation du code de l’implantation Pertinence du comportement temporel simulé Prise en compte des durées d’exécution des éléments du système Prise en compte des durées d’exécution des éléments du système Application, Support d’exécution (dont l’ordonnanceur) Une infrastructure de simulation pour l’évaluation de performances de systèmes temps-réel

39 Ce qu’on attend d’un simulateur (2/2)
Pertinence de simulation par réutilisation de code Tâche T compute_fft(data1, result1); t = spawn_task(task_entry); compute_fft(data2, result2); ... Simulation d’un temps d’occupation du CPU Simulation d’un temps d’occupation du CPU Simulation d’un temps d’occupation du CPU Le processeur est une ressource préemptible : La simulation d’occupation du temps CPU doit tenir compte des préemptions Tâche T Tâche U Une infrastructure de simulation pour l’évaluation de performances de systèmes temps-réel

40 Simulateurs existants (1/2) Grandes classes de simulateurs
À temps continu Résolution d’équations différentielles À événements discrets Temps simulé Wait(3) 1 2 4 5 On a represente une simu DES orientee processus (il en existe orientee evt) Une infrastructure de simulation pour l’évaluation de performances de systèmes temps-réel

41 Simulateurs existants (2/2) Limitations
Limitation des simulateurs à événements discrets généraux [Csim,ADEVS,OMNET++,Hyperformix workbench,OPNet,QNap] Difficulté à assurer la pertinence du comportement temporel simulé Simulation adaptée à un domaine différent (files d’attentes, …) Limitations des simulateurs d’ordonnancement [PERTS,Simulateur ULB, Retis RTSim/Ghost,Timewiz] Difficulté à assurer la pertinence du modèle simulé Simulation par quanta de temps Limitations des simulateurs de systèmes complets [Rialto,TAPS,OSE Softkernel,VxSim,Carbonkernel,CMU Sew] S’attachent davantage aux problèmes de synchronisation qu’au comportement temporel Problèmes d’efficacité Systemes complets => parler des simulateurs niveau instr (tout Ok sauf perfs) Pb efficacite => simulateurs niveau instr Limitation des simulateurs à événements discrets généraux [Csim,ADEVS,OMNET++,Hyperformix workbench,OPNet,QNap] Simuler « occupation du CPU pendant t secondes en tenant compte des préemptions » revient à refaire la gestion des événements Simulation adaptée à un domaine différent (files d’attentes, …) Limitations des simulateurs d’ordonnancement [PERTS,Simulateur ULB, Retis RTSim/Ghost,Timewiz] Panoplie non extensible d’ordonnanceurs et de modèles de tâches Tâches « abstraites » : temps d’occupation du CPU de bout en bout, Difficile de réutiliser du code d’applications déjà existantes Simulation par quanta de temps Limitations des simulateurs de systèmes complets [Rialto,TAPS,OSE Softkernel,VxSim,Carbonkernel,CMU Sew] Panoplie non extensible d’ordonnanceurs API OS associée à un OS précis S’attachent davantage aux problèmes de synchronisation qu’au comportement temporel Problèmes d’efficacité Une infrastructure de simulation pour l’évaluation de performances de systèmes temps-réel

42 Gestion des interruptions
Caractéristiques du simulateur proposé (4/7) Comportement du matériel et de l’OS basique Gestion des interruptions Notion de priorité Masquage possible : Temporaire, local à la tâche Définitif, global au système simulé Par défaut, le système d’exploitation simulé & l’ordonnanceur sont totalement préemptibles Une infrastructure de simulation pour l’évaluation de performances de systèmes temps-réel

43 Caractéristiques du simulateur proposé (3/5) Capacités de personnalisation
Temps simulé occupé Ressources utilisées Personnalisable Extensible Caractéristiques courantes : Loi d’activation de la tâche, paramètres temporels (WCET) Tâche Statut d’exécution * Contexte d’exécution Modèle de tâche 1 RTOS Ordonnanceur Une infrastructure de simulation pour l’évaluation de performances de systèmes temps-réel

44 9 familles d’ordonnanceurs par défaut Ordonnanceurs à priorité
Caractéristiques du simulateur proposé (4/5) Ordonnanceurs fournis par défaut 9 familles d’ordonnanceurs par défaut Ordonnanceurs à priorité Garantis hors-ligne : ordonnanceurs classiques du domaine Garantis en-ligne : famille d’ordonnanceurs avec acceptation dynamique, ordonnanceurs par serveurs ou à réquisition de temps libre Autres ordonnanceurs à garantie Au dessus d’une politique à partage de temps Avec fonctionnement en mode dégradé Autres ordonnanceurs sans garantie Ordonnanceurs « au mieux » par prévision des caractéristiques temporelles (boucle de rétroaction) « familles  » parce que paramétrables par affectation prio par exemple, ou caractéristiques du PID… Une infrastructure de simulation pour l’évaluation de performances de systèmes temps-réel

45 Famille d’ordonnanceurs dynamiques (3/4)
Hypothèse forte : priorités conservatives Priorités relatives indépendantes du temps Priorités relatives indépendantes de l’insertion et de la suppression de tâches Définition d’un algorithme de garantie paramétrable Fondé sur le calcul du temps processeur disponible pour chaque tâche : temps résiduel Paramétrable par une fonction de comparaison de priorité conservative Regroupe les affectations de priorités classiques (EDF, RM/DM, …) Priorités Prio classiques => fixe (toutes), dynamique (certaines), … et meme Fifo ! Une infrastructure de simulation pour l’évaluation de performances de systèmes temps-réel

46 Prise en compte de la granularité d’horloge Règles de prise en compte définies
Objectif Conserver la sûreté des tests d’acceptation Se placer dans les cas les plus pessimistes Exemple Échéance relative D = 4 WCET C = 2.5 Date d’échéance pessimiste Date de début au plus tôt D = 4 Temps résiduel pessimiste Date de fin pessimiste Date de début au plus tard C = 2.5 Pr le majorant du temps occupe, ca va au-dela => prise en compte des preemptions (on compte qu’une tache s’est executee pdt 1 tick complet des qu’elle a ete schedulee au moins une fois pdt le tick => utilisation des proprietes conservatives des priorites pour pas avoir a parcourir la liste de toutes les taches afin de voir si elle a ete executee ; on se contente de prendre la tache en tete). 4eme regle : difficilement representable ici : evolution dans le temps du CPU utilise + doit prendre en compte les preemptions des autres taches. Minorant du temps utilisé Ressources récupérées pessimistes Majorant du temps utilisé ceil(1.2) = 2 Évaluation pessimiste du temps résiduel Minorant du temps utilisé à chaque instant Une infrastructure de simulation pour l’évaluation de performances de systèmes temps-réel