Chapitre 2 : Introduction au Temps Rel : dfinitions, concepts, techniques

1
Chapitre 2 Introduction au Temps Réel
définitions, concepts, techniques
2
Plan du chapitre

• Définitions
• Bref historique
• Architecture générale et mode de fonctionnement
• Quelques mots sur les contraintes d exécution
  des tâches
• Quelques mots sur le Génie Logiciel temps
  réel 
• Quelques mots sur les O.S. (Operating System)
  Temps Réel
• Quelques mots sur les langages du Temps Réel

3
2.1. Définitions générales
4
2.1. Définitions...

• Définition générale (CNRS 1988)
• Peut être qualifiée de "temps-réel" (ou "temps
  contraint", ou encore "réactif") toute
  application mettant en uvre un système
  informatique dont le fonctionnement est assujetti
  à l'évolution dynamique de l'environnement qui
  lui est connecté et dont il doit contrôler le
  comportement.

5
2.1. Définitions...

• Un peu de classification ou un autre point de
  vue du temps réel.
• Système Transformationnel
• activité de calcul, qui lit ses données et ses
  entrées lors de son démarrage, qui fournit ses
  sorties, puis meurt.
• Système Interactif
• système en interaction quasi permanente avec son
  environnement, y compris après l'initialisation
  du système la réaction du système est
  déterminée par les événements reçus et par l'état
  courant (fonction des événements et des réactions
  passés) le rythme de l'interaction est
  déterminé par le système et non par
  l'environnement.
• Système Réactif ou Temps Réel
• système en interaction permanente avec son
  environnement, y compris après l'initialisation
  du système la réaction du système est
  déterminée par les événements reçus et par l'état
  courant (fonction des événements et des réactions
  passées) mais le rythme de l'interaction est
  déterminé par l'environnement et non par le
  système.

6
2.1. Définitions...

• Un peu de classification ou un autre point de
  vue du temps réel.
• Attention les notions "Interactif" et Réactif"
  sont relatives à l'environnement considéré et à
  sa dynamique !
• gt un système peut être considéré comme réactif
  face à un environnement à dynamique lente, mais
  seulement interactif face à un environnement à
  dynamique plus rapide.
• gt pas de notion absolue ...
• gt ... sauf à considérer un temps de réaction nul
  ! (cf. langages synchrones chapitre 6.2)

7
2.1. Définitions...

• Conséquences de la définition
• Un système Temps Réel reçoit des événements
  émanant du procédé à contrôler ces événements
  peuvent être périodiques ou non
• le système doit réagir avant un délai ou une date
  fixée
• aucun événement ne doit être raté par le système
• Autre formulation un système fonctionne en
  "Temps Réel" s'il est capable d'absorber toutes
  les informations d'entrée sans qu'elles soient
  trop vielles pour l'intérêt qu'elles
  représentent, et par ailleurs de réagir à temps
  pour que cette réaction ait un sens.
• Ne pas réagir à temps peut être considéré comme
  une défaillance catastrophique
• Un système Temps Réel est souvent critique et
  doit souvent être tolérant aux pannes
• mécanismes de tolérance aux défaillances
  (réplication, programmation N-version,
  vérification formelles)

8
2.1. Définitions...
Aspect temporel de la dynamique du procédé
dynamique du procédé très différente suivant
l'application ? milliseconde systèmes radar,
? seconde systèmes de visualisation, ?
minutes chaîne de fabrication ? heures
contrôle de réactions chimiques,
Ordre de grandeur de la contrainte temporelle
9
2.1. Définitions

• Mais de quel temps s'agit-il ?
• Deux entités l'environnement (ou le procédé) à
  contrôler et le système informatique Temps Réel
• gt deux temps le temps de l'environnement et le
  temps du système Temps Réel
• Temps de l'environnement temps chronométrique
  (le temps réel)
• Temps du système informatique temps
  chronologique, constitué de la suite des
  événements ou des instructions du système (pas de
  temps réel vu par le système)
• gt Exigence du temps réel concordance entre le
  temps chronologique de l'environnement et le
  temps chronométrique du système
• gt Le système informatique doit mettre ses
  actions en phase avec le temps chronométrique de
  l'environnement
• (où les actions du systèmes seront en fait ses
  "tâches" et ses "messages"
• gt techniques d'ordonnancement de tâches et de
  communications)

10
2.1. Définitions...

• Quelques exemples
• Commande et contrôle de chaînes de production
• guidage de systèmes mobiles (robotique)
• systèmes embarqués (avion, train, automobile)
• surveillance de réactions ou phénomènes physiques
  (nucléaire, chimie,)
• contrôle de malades et assistance d'opérations
  médicales
• systèmes de communication et multimédia
• systèmes dédiés (conduite d'expérience
  scientifique, traitement du signal)

11
2.1. Définitions...
Quelques exemples
? Robot de production un robot, réalisant une
activité spécifique (peinture, assemblage, tri)
sur une chaîne de production, doit effectuer son
travail en des temps fixés par la cadence de
fabrication. S'il agît trop tôt ou trop tard,
l'objet manufacturier traité sera détruit ou
endommagé conduisant des conséquences financières
ou humaines graves (oubli d'un ou plusieurs
rivets sur un avion). ? Robot d'exploration
(robot BIP) ce robot doit se déplacer dans un
environnement en principe non connu (zone
radioactive après un accident, planète, épave
sous la mer, ). Il est important qu'il puisse
réagir aux obstacles fixes ou mobiles afin de ne
pas conduire à sa perte. ? Téléphone mobile le
système de contrôle-commande doit remplir
plusieurs fonctions dont certaines ont des
contraintes temporelles fortes pour avoir une
bonne qualité de service (quality of service).
Ainsi, la première fonction est de transmettre et
de recevoir les signaux de la parole (577 µs de
parole émises toutes les 4,6 ms et 577 µs de
parole reçues toutes les 4,6 ms à des instants
différents). En parallèle, il est nécessaire de
localiser en permanence le relais le plus proche
et donc de synchroniser les envois par rapport à
cette distance (plus tôt si la distance augmente
et plus tard si la distance diminue). Des
messages de comptes rendus de la communication
sont aussi émis avec une périodicité de plusieurs
secondes. Les contraintes temporelles imposées au
système doivent être imperceptibles à
l'utilisateur.
12
2.1. Définitions...
Quelques exemples
? Système de vidéo-conférence ce système doit
permettre l'émission et la réception d'images
numérisées à une cadence de 30 images par seconde
pour avoir une bonne qualité de service (quality
of service). Afin de minimiser le débit du
réseau, une compression des images est effectuée.
D'autre part la parole doit être aussi transmise
bien que correspondant à un débit d'information
moindre, la régularité de la transmission (gigue
temporelle) est nécessaire pour une reproduction
correcte. De plus ce signal doit être synchronisé
avec le flux d'images. L'ensemble de ces
traitements (numérisations images et parole,
transmission, réception, synchronisation, ) sont
réalisés en cascade, mais avec une cohérence
précise. ? Pilotage d'un procédé de fabrication
(fonderie, laminoir, four verrier, ) la
fabrication d'une bobine d'aluminium (laminage à
froid) exige un contrôle en temps réel de la
qualité (épaisseur et planéité). Cette
vérification en production de la planéité
nécessite une analyse fréquentielle (FFT) qui
induit un coût important de traitement. Le
système doit donc réaliser l'acquisition d'un
grand nombre de mesures (246 Ko/s) et traiter ces
données (moyenne, FFT, ) à la cadence de 4 ms .
Ensuite, il affiche un compte-rendu sur l'écran
de l'opérateur toutes les 200 ms et enfin imprime
ces résultats détaillés toutes les 2 s. Un
fonctionnement non correct de ce système de
contrôle de la qualité peut avoir des
conséquences financières importantes production
non conforme à la spécification demandée.
13
2.1. Définitions...

• Conséquences de la définition
• Temps Réel ? aller vite
• besoin d'un temps de réaction court (1 ms) pour
  le contrôle d'un avion de combat
• besoin d'un temps de réaction moins court (10 ms)
  pour le contrôle d'un avion de transport civil
• besoin d'un temps de réaction moins court (1s)
  pour une IHM
• besoin d'un temps de réaction moins court (1mn)
  pour le contrôle d'un chaîne de production
  (lente)
• besoin d'un temps de réaction moins court (1h)
  pour le contrôle d'une réaction chimique (lente)
• besoin d'un temps de réaction de quelques heures
  pour l'établissement d'une prévision
  météorologique
• besoin d'un temps de réaction de quelques jours
  pour le calcul de la paie
• gt l'important est de respecter l'échéance
• gt un résultat juste hors délai peut être
  inutilisable et considéré comme une faute
• gt et parfois réagir trop tôt est aussi une faute
  (cf. contrôle d'un avion souple)
• Temps Réel Ponctualité

14
2.1. Définitions...

• Deux notions de criticité face au manquement
  d'une échéance
• Contraintes temps réel strictes le dépassement
  d'une échéance est catastrophique
• Contrainte temps réel relatives le dépassement
  d'une échéance peut être toléré (dans une
  certaine mesure)
• gt Temps réel Dur / Temps réel Lâche !
• gt dans le cas des systèmes Temps Réel Dur, on
  cherchera à obtenir un comportement prévisible,
  déterministe et fiable
• gt utilisation de techniques mathématiques
  (ordonnancement, évaluation des pires cas)
• gt dans le cas des systèmes Temps Réel Lâche, on
  cherchera à minimiser la probabilité de rater une
  échéance plusieurs fois de suite...

15
2.2. Un bref historique
16
2.2. Un bref historique du temps réel...

• Fin des années 50
• première apparition de machines numériques dans
  des applications temps réel (système de commandes
  d'une unité de polymérisation d'une raffinerie
  Texaco)
• Années 60
• les systèmes temps réel s'étendent à des secteurs
  critiques tels que l'aérospatiale (système de
  contrôle de vol des capsules Apollo (NASA),
  système de commande de vol du Concorde (Sud
  Aviation))
• Années 70
• l'arrivée des mini-calculateurs accélère
  l'insertion d'outils informatisés dans les
  environnements temps réel (chaîne de production)
• Depuis les années 80
• invasion de tous les secteurs industriels par
  l'informatique temps réel grâce à la
  micro-informatique, et au développement des
  techniques de communication
• gt systèmes temps réel distribués
• gt explosion de l'informatique embarquée
  (aérospatial, nucléaire, télécom, marine,
  automobile)

17
2.3. Principe de larchitecture et du
fonctionnement dun système temps réel
18
2.3. Archi. générale et modes de fonctionnement

• Principe
• Quelle que soit la nature et la complexité du
  système, on décompose un système temps réel en
• le système contrôlé
• le système de contrôle
• Le système contrôlé environnement (procédé)
  équipé d'une instrumentation qui réalise
  l'interface avec le système de contrôle
• Le système de contrôle éléments matériels
  (microprocesseurs) et logiciels dont la mission
  est d'agir sur le procédé via les actionneurs en
  fonction de l'état de ce procédé indiqué par les
  capteurs de manière maintenir ou conduire le
  procédé dans un état donné

19
2.3. Archi. générale et modes de fonctionnement
20
2.3. Archi. générale et modes de fonctionnement

• Exemple de systèmes contrôlés
• équipements isolés
• robot, machine à laver, caméra, radar, gouvernes
  d'un avion, moteur
• systèmes complexes
• chaîne de production, avion global, centrale
  nucléaire, contrôle aérien, surveillance
  médicale...

21
2.3. Archi. générale et modes de fonctionnement

• Principe de fonctionnement
• Interaction
• via les mesures issues des capteurs,
• et les commandes envoyées aux actionneurs
• gt Acquisition des mesures périodiques à une
  cadence compatible avec les dynamiques du procédé
• gt élaboration et envoi des commandes dans un
  laps de temps compatible avec les dynamiques du
  procédé
• gt Le double rôle du système de contrôle
• observateur acquisition des mesures
• contrôleur mise en uvre des lois de commandes
  et émission des commandes vers des actionneurs
  spécifiques

22
2.3. Archi. générale et modes de fonctionnement
Peut être réalisé par

• un automate programmable
• un circuit spécifique (ASIC)
• un calculateur (monoprocesseur)
• un système multiprocesseur à mémoire commune
• un système réparti
• ...

23
2.3. Archi. générale et modes de fonctionnement

• Fonctionnement général boucle infinie
• Tant que TOUJOURS faire
• Acquisition des entrées (données capteurs,
  mesures)
• Calcul des ordres à envoyer au procédé
• Émission des ordres
• Fin tant que
• Mais, deux modes de fonctionnement
• fonctionnement cyclique (time driven ou système
  "synchrone" (mais pas le même "synchrone" que les
  langages "synchrones"))
• fonctionnement événementiel (event driven)
• gt fonctionnement mixte à base de traitements
  périodiques et apériodiques (déclenchés sur
  événements)

24
2.3. Archi. générale et modes de fonctionnement

• Fonctionnement Cyclique
• scrutation d'une mémoire d'entrée périodiquement
  (polling)
• gt échantillonnage des entrées sur l'horloge du
  système
• gt activation du système à chaque top d'horloge
• A chaque top d'horloge faire
• Lecture de la mémoire des entrées
• Calcul des ordres à envoyer au procédé
• Émission des ordres
• Fin
• Mais
• système peu "réactif" si l'environnement produit
  des informations à des fréquences différentes
• gt oblige à prévoir toutes les réactions du
  système dans la même boucle
• gt problème de performance
• gt ou oblige à imbriquer des boucles de
  fréquences multiples
• gt difficultés de réalisation, de lisibilité du
  code, d'évolution

25
2.3. Archi. générale et modes de fonctionnement

• Fonctionnement Evénementiel
• activation du système à chaque événement (gt
  notion d'interruption)
• gt
• A chaque interruption faire
• Lecture de l'information arrivée
• activation du traitement correspondant
• Émission des ordres issus de ce traitement
• Fin
• Mais que faire si une interruption survient
  alors que le système est en train de traiter une
  interruption précédente
• gt notion de priorité des interruptions
• gt notion de "tâche" associée à une ou plusieurs
  interruptions
• gt mécanisme de préemption et de reprise de tâche
• gt gestion de l'exécution concurrente des tâches
  (ordonnancement)
• gt Un système temps réel est souvent un système
  multitâche incluant un gestionnaire de tâches
  (Ordonnanceur)

26
2.3. Archi. générale et modes de fonctionnement
gt Pour des raisons de facilité de conception,
mise en uvre et d'évolutivité, une
application temps réel est un système multitâche
? tâche associée à un ou des événements ?
tâche associée à une ou des réactions ? tâche
associée à une entité externe à contrôler ? tâche
associée à un traitement particulier ?
Coopération entre tâches
tâche
27
2.3. Archi. générale et modes de fonctionnement
gt Un ordonnacement La partie logicielle d'une
application temps réel peut être vue comme un
ensemble de tâches synchronisées, communicantes
et partageant des ressources critiques. Le rôle
essentiel du système informatique temps réel est
donc de gérer l'enchaînement et la concurrence
des tâches en optimisant l'occupation de l'unité
centrale fonction d'ordonnancement.
?
programme temps réel
Cahier des charges
28
2.3. Archi. générale et modes de fonctionnement

• Organisation générale d'un système temps réel
• Noyau primitives (de services) ordonnanceur
  système d'exploitation

29
2.4. Quelques mots sur les contraintes
d exécution des tâches TR
30
2.4. Contraintes d exécution des tâches

• NB temps physique continu ? temps informatique
  discrétisé
• ? plusieurs représentations du temps non
  exclusives
• référence ponctuelle (date point sur léchelle
  des temps)
• ? décrire les dates, événements qui déterminent
  le déroulement de certaines activités (approche
  synchrone)
• notion de durée ou dintervalles de temps
• ? décrire modéliser les recouvrements et le
  parallélisme de certaines activités (approche
  asynchrone)
• Remarques
• intervalle de durée nulle point
• horloge référence temporelle absolue
• ? pb de la synchronisation des horloges

31
2.4. Contraintes d exécution des tâches

• Contraintes de niveau système
• des contraintes denvironnement, masse, volume,
  consommation, performances, ...
• des contraintes de bon fonctionnement
• objectif ? raisons économiques (maîtrise coûts
  dexploitation par la fiabilité, maintenabilité
  et testabilité) et de sécurité (certificabilité)
• Prise en compte de contraintes de SdF ?
  fiabilité, qualité, conception de systèmes
  tolérants les fautes (ressources redondantes,
  reconfigurations, reprises temporelles des
  traitements, )

32
2.4. Contraintes d exécution des tâches

• Des contraintes de prédictibilité
• Prédictibilité qualité dun système qui, à
  partir de la connaissance de son état présent
  (fonctionnalités, performance, ) permet
  dassurer la connaissance de son comportement
  dans le futur et garantit la maîtrise de son
  fonctionnement en cas de défaillance prévue ou
  non prévue
• Possibilité de décrire le comportement dans le
  temps par un modèle statique fonctionnalités-perfo
  rmances-contraintes ? rend prédictible le
  comportement futur
• (note sous contraintes dhypothèses
  simplificatrices qui restreignent la garantie de
  bon fonctionnement à ce domaine de validité)

33
2.4. Contraintes d exécution des tâches

• Des contraintes de réalisation
• complexité, contraintes de SdF ? approche qualité
  par lutilisation systématique de méthodologies
  rigoureuses pour la conception, réalisation,
  validation, évolution et maintenance des systèmes
  (logiciels) AGL

34
2.4. Contraintes d exécution des tâches

• Contraintes de niveau actions
• Des contraintes de communication
• Les tâches concourent à contrôler/commander un
  procédé ? elles interagissent (émission/réception
  de signaux de synchronisation informations)
• boite aux lettres en mémoire commune (système
  centralisé)
• transfert par messages (système distribué) ?
  délais de transmission non négligeables (support,
  absence de cohérence d'horloges locales,
  difficulté de construire un schéma de
  contrôle global)

35
2.4. Contraintes d exécution des tâches

• Des contraintes de criticité
• Sensibilité de laction (mesurée par les
  conséquences de loccurrence dune faute) sur le
  bon fonctionnement du système
• Exemple non-respect des dates de réveil et
  échéances ? conséquences dont la sévérité dépend
  de la tâche fautive (perte acceptable de
  performance ? catastrophique)
• A chaque tâche est affecté un niveau de criticité
  qui conduira à privilégier l'exécution des tâches
  de grande importance

36
2.4. Contraintes d exécution des tâches

• Des contraintes de préséance
• hiérarchie entre activités selon leurs
  importances relatives (ex. détection/traitement
  des fautes, activités brèves, urgentes, liées à
  certains événements, )
• ? concept de priorité

37
2.4. Contraintes d exécution des tâches

• Des contraintes de préemptiblité
• une activité peut être interrompue ou pas par une
  activité de plus forte préséance ? retrait des
  ressources (processeur) pour les affecter à la
  nouvelle activité (reprise ultérieure quand les
  circonstances le permettront)

38
2.4. Contraintes d exécution des tâches

• Des contraintes dactivation
• Lexécution dune activité peut commencer au plus
  tôt après la réalisation de la condition
  dactivation (date, occurrence dun événement
  externe, interne (transition détat), temporel
  (fin de délai, début de période si activité
  périodique) ou dautre nature (disponibilité de
  ressources, fin dune autre activité, condition
  de synchronisation)
• Possibilité de contraindre la condition dans le
  temps (prise en compte entre 2 dates ou pour une
  durée limitée (time-out)
• 1 ou plusieurs conditions élémentaires en OU ou ET

39
2.4. Contraintes d exécution des tâches

• Des contraintes dimplantation (placement)
• (cas des systèmes distribués)
• Portent sur lidentité du système distribué sur
  lequel une tâche est autorisée à s'exécuter
  (souvent calqué sur la répartition géographique)
  prendre en compte pour évaluer la charge de
  traitement de chaque nud,
• ? activités voisines ou distantes
• Problème crucial en cas de redondance
  matérielle/logicielle pour la conception de
  systèmes sûrs de fonctionnement (tolérer la panne
  d'un/plusieurs nuds et le dépassement d'échéance
  par une/plusieurs tâches)

40
2.4. Contraintes d exécution des tâches

• Différents types de contraintes temporelles selon
  que lactivité est
• périodique (cyclique) activité soit réalisée
  une fois par période T, soit 2 exécutions
  consécutives séparées par une durée T
• ex acquisition dinformations
• sporadique (asynchrone) réalisée à la demande
  ou sous des conditions dactivation non
  périodiques
• ex événements processus, détection faute,
  intervention humaine

41
2.4. Contraintes d exécution des tâches

• Contraintes temporelles
• date de début au plus tôt, date de début au plus
  tard La date de début doit être
• postérieure à la date de réalisation de la
  condition dactivation et à la date de début au
  plus tôt
• antérieure à la date de début au plus tard
• date de fin au plus tôt, date de fin au plus tard
  La date de fin dactivité doit être
• postérieure à la date de fin au plus tôt
• antérieure à la date de fin au plus tard

42
2.4. Contraintes d exécution des tâches

• date de fin au plus tard date de forclusion ou
  deadline
• délai de forclusion (délai de cohérence)
• durée qui sécoule depuis la date de réalisation
  de la condition dactivation jusquà la date de
  forclusion
• Lactivité doit impérativement être terminée
  avant la fin du délai de forclusion.
• A chaque activité est associée une durée
  dexécution.
• Lexécution dune activité peut être
• continue (non interrompue par préemption)
  connexe
• non-connexe les mêmes contraintes de début/fin
  dactivité sont applicables

43
2.4. Contraintes d exécution des tâches

• Expression des contraintes temporelles
• exigence de commencer l'exécution d'une tâche
  après avoir satisfait des conditions nécessaires
  de départ
• exigence de terminer son exécution avant une
  échéance
• La date de début d'exécution au plus tôt (date de
  réveil) découle directement ou indirectement de
  l'occurrence de signaux émis ou prélevés sur
  l'environnement
• La date de fin d'exécution au plus tard
  (échéance) est directement ou indirectement liée
  aux dynamiques de l'environnement
• Toute tâche caractérisée par une date de réveil
  et (ou) une échéance est en général qualifiée de
  tâche à date critique

44
2.4. Contraintes d exécution des tâches

• Le problème du non-déterminisme
• Non déterminisme caractéristique importante car
  pose de sérieux problèmes pour s assurer de la
  maîtrise du comportement du système
• Séquences d actions interrompues par des
  événements externes asynchrones à des instants et
  dans un ordre imprévisibles ? ordre de traitement
  des séquences imprévisible !

45
2.5. Et lon reparle de Génie Logiciel pour
les systèmes TR
46
2.5. La conception de système temps réel

• Où l'on retrouve les étapes classiques du
  développement
• 1ère étape définition du cahier des charges
  (analyse des besoins)
• gt établir clairement les exigences du client
  (nature des lois de commandes, performance,
  ressources matérielles, possibilité de
  maintenance, sûreté de fonctionnement)
• 2ème étape spécification fonctionnelle
• gt formaliser les exigences du client et les
  faire valider
• gt recensement de tous les signaux et
  interruptions, les états (mesures sur le procédé)
  qui traduisent l'évolution du comportement du
  procédé
• gt analyse fonctionnelle analyse temporelle

47
2.5. La conception de système temps réel

• Où l'on retrouve les étapes classiques du
  développement
• 3ème étape conception générale
• gt identification de l'architecture matérielle et
  logicielle
• identification de ce qui sera réalisé par du
  matériel
• identification de la topologie matérielle de
  l'architecture
• identification des tâches de telle sorte que
• forte cohésion interne à chaque tâche
• faible cohésion entre les tâches
• 4ème étape conception détaillée codage
• gt conception des composants matériels
• gt conception des tâches
• définition des attributs des tâches
• nom
• priorité
• caractéristiques temporelles (durée, échéances)
• ressources nécessaires
• programmation des tâches (gt cf. "Quelques mots
  sur les langages temps réel")
• gt choix d'une stratégie d'ordonnancement et
  éventuellement d'un OS temps réel (gt cf
  "Quelques mots sur les OS temps réel)

48
2.6. Quelques mots sur les OS TR
49
2.6. Quelques mots sur les O.S. Temps Réel

• Pourquoi ?
• Lorsqu'il y a partage de ressources entre
  plusieurs tâches, il faut un chef d'orchestre qui
  définit une politique de partage et un "bras
  armé" qui exécute cette politique de partage
• gt Ordonnanceur chef d'orchestre
• gt O.S. support d'exécution des tâches et "bras
  armé" de l'Ordonnanceur (par préemption et
  reprise des tâches)
• (en fait, dans le sens couramment admis, l'O.S.
  contient un ou plusieurs ordonnanceurs au choix
  de l'utilisateur)
• Les Ordonnanceurs et O.S. classiques
• essayent d'assurer un partage équitable des
  ressources, mais généralement sans connaissance
  d'informations temporelles.
• premier arrivé premier servi, tourniquet,
  ordonnancement par priorité...
• gt mais inadapté au temps réel

50
2.6. Quelques mots sur les O.S. Temps Réel

• Les Ordonnanceurs et O.S. temps réel
• gèrent le partage des ressources de manière à ce
  que chaque tâche respecte son échéance
• gt principal paramètre d'allocation le temps
• gt nécessité de connaître
• les ressources et les mécanismes de base utilisés
  par les tâches
• les caractéristiques des tâches,
• les relations entre l'OS et les tâches
• les relations entre les tâches
• Note
• les ressources autres que le processeur sont
  souvent allouées statiquement au moment de la
  création des tâches
• les données, fichiers sont souvent implantés en
  mémoire centrale et non sur disque

51
2.6. Quelques mots sur les O.S. Temps Réel

• Les ressources et les mécanismes de base du Temps
  Réel
• Ressources physiques
• unité centrale, processeur
• mémoire centrale, mémoire de masse
• interfaces E/S
• interfaces de dialogue
• voies de communication
• etc.
• Ressources logiques
• structures de données, dictionnaires, fichiers,
  données partagées
• mécanismes logiciels (communication,
  synchronisation, )
• fins de délais, date, événements
  externes/internes
• etc.

52
2.6. Quelques mots sur les O.S. Temps Réel

• Les ressources et les mécanismes de base le
  processeur
• Rôle exécution des programmes
• Il dispose d'une pile en mémoire pour
  l'exécution des programmes
• Le contexte d exécution dun programme se
  compose de
• compteur de programme
• pointeur de pile
• mot d état
• registres généraux
• Modes d'exécution
• superviseur (ou noyau)
• utilisateur

53
2.6. Quelques mots sur les O.S. Temps Réel

• Les ressources et les mécanismes de base les
  interruptions
• Rôle prendre en compte les événements externes
  au processeur (asynchrones)
• La prise en compte d'une interruption provoque
  l'arrêt du programme en cours et l'exécution d'un
  programme associé à cette IT
• Système de gestion
• hiérarchisé
• non hiérarchisé
• Conditions de prise en compte d'une IT
• IT non masquable
• IT masquable
• Vecteur d'interruptions table de pointeurs vers
  les routines de traitement des interruptions.

54
2.6. Quelques mots sur les O.S. Temps Réel

• Les ressources et les mécanismes de base les
  déroutements
• Rôle prendre en compte les événements internes
  au processeur
• Détectés par le processeur durant l'exécution d
  un programme
• instruction inexistante
• violation de mode
• violation de protection mémoire
• erreur d adressage (adresse inexistante)
• erreur arithmétique (division par 0, débordement)
• Demandés explicitement par un programme
• appels système
• exécution pas à pas
• Mécanisme de prise en compte similaire à celui
  des IT
• Jamais masquables

55
2.6. Quelques mots sur les O.S. Temps Réel

• Les ressources et les mécanismes de base les
  entrées sorties
• Rôle assurer la communication d'un programme
  avec le monde extérieur
• Assurées par
• des instructions spécialisées du processeur
• des zones mémoires spécialisées
• Un périphérique est un dispositif d
  entrée/sortie (terminal, imprimante, disque,...)
• Un contrôleur prend en charge le dialogue avec le
  périphérique et présente une interface logique de
  haut-niveau au processeur
• Un canal correspond aux mécanismes
  dentrée/sortie utilisés par un processeur donné
  pour assurer le dialogue avec le contrôleur

56
2.6. Quelques mots sur les O.S. Temps Réel

• Les ressources et les mécanismes de base les
  processus
• Processus instance d'une tâche
• Un processus peut être
• inactif
• prêt (à être exécuté)
• actif (en exécution)
• suspendu (en attente de ressource ou de la CPU)
• endormi (entre deux périodes d'activations par
  exemple)
• terminé

Attention processus ? programme ! (2 exécutions
dun même programme 2 processus !!)
57
2.6. Quelques mots sur les O.S. Temps Réel

• Les ressources et les mécanismes de base les
  sémaphores
• Le sémaphore (Dijkstra) est un objet sur lequel
  seulement deux opérations sont possibles P(s)
  et V(s), atomiques
• Un sémaphore possède une valeur entière s,
  définie entre deux opérations
• P(s) si s0, bloque le processus appelant,
  sinon s?s-1 et continue
• V(s) sil y a un processus bloqué sur s,
  déblocage, sinon s?s1
• P est une barrière (Prendre) et V un
  laisser-passer (Libérer).
• gt Utilisés pour la synchronisation et
  l'exclusion mutuelle (protection/partage des
  ressources)

58
2.6. Quelques mots sur les O.S. Temps Réel
Architecture logicielle d'un système temps réel
(Rappel)
59
2.6. Quelques mots sur les O.S. Temps Réel
Relation tâches et noyau temps réel
Une application temps-réel étant par définition
un système multi-tâche, le rôle essentiel du
noyau temps réel est donc de gérer l'enchaînement
et la concurrence des tâches en optimisant
l'occupation de l'unité centrale du système
informatique. Ainsi le système temps réel
centralise toutes les demandes d'activation de
tâches et gère des tables lui permettant de
comparer les priorités et l'état de ces diverse
tâches, ainsi que l'état d'occupation des
ressources. La décision d'activation d'une tâche
étant prise, le système temps réel lance les
modules de programmes correspondant à cette tâche
et lui alloue les ressources disponibles. Une
tâche activée peut appeler le noyau temps réel
par une requête. Les différentes requêtes sont
servies par des modules du système temps réel
appelées primitives. La tâche activée occupe le
processeur jusqu'à la fin de son exécution sous
le respect des conditions suivantes ? elle ne
réalise pas d'opérations d'entrées-sorties ? les
ressources utilisées sont disponibles ? aucun
événement extérieur ne revendique le déroulement
d'une tâche plus prioritaire.

Requête
Activation
Noyau temps réel
Exécution programme
Exécution primitive et ordonnanceur
Exécution programme
60
2.6. Quelques mots sur les O.S. Temps Réel
Organisation générale d'un noyau temps réel
61
2.6. Quelques mots sur les O.S. Temps Réel
Les services de coopération entre les tâches

• ??synchronisation
• événements
• - SIGNAL_EVT(signaler l'occurrence d'un
  événement)
• - ATTENDRE_EVT(attendre l'occurrence d'un
  événement)
• ? Primitive bloquante
• sémaphores privées (S00)
• - PRENDRE_SEM (demande d'un sémaphore)
• ? Primitive bloquante (sémaphore déjà pris)
• - RENDRE_SEM (libération d'un sémaphore)
• rendez-vous
• ??communication
• boîtes aux lettres
• - DEPOSER_DONNEE (écriture d'une donnée)
• ? Primitive bloquante (BAL pleine)
• - RETIRER_DONNEE (lecture d'une donnée)
• ? Primitive bloquante (BAL vide)
• tubes

62
2.6. Quelques mots sur les O.S. Temps Réel
Noyau temps réel de référence / 1
63
2.6. Quelques mots sur les O.S. Temps Réel
Noyau temps réel de référence / 2
64
2.6. Quelques mots sur les O.S. Temps Réel
Exemple d'application temps réel
Deux trains circulent sur un même réseau
constitué de 5 rails sachant que les deux trains
doivent au moins être séparés par un rail vide.
Les sections sont alimentées séparément afin de
permettre une commande de marche des trains. Le
repérage du passage des trains se fait par des
capteurs placés au niveau de la sortie de chacune
des sections.
65
2.6. Quelques mots sur les O.S. Temps Réel
Exemple d'application temps réel Programme/1
66
2.6. Quelques mots sur les O.S. Temps Réel
nom tâche tâche_train(1) / x1,0 position
initiale du train 1 / PRENDRE_SEM(sem_section(x1
,0)) PRENDRE_SEM(sem_section(x1,0 1)) x
x1,0 Faire toujours ATTENDRE_EVT(evt_synchro(1
)) / couper alimentation sur la section x du
train/ VENDRE_SEM(sem_section(x)) PRENDRE_SEM
(sem_section(x2)) / mettre alimentation sur
la section x1 du train/ Fin faire fin
tâche nom tâche tâche_train(2) / x2,0
position initiale du train 2 / PRENDRE_SEM(sem_s
ection(x2,0)) PRENDRE_SEM(sem_section(x2,0
1)) x x2,0 Faire toujours ATTENDRE_EVT(evt_
synchro(2)) / couper alimentation sur la
section x du train/ VENDRE_SEM(sem_section(x))
PRENDRE_SEM(sem_section(x2)) / mettre
alimentation sur la section x1 du train/ Fin
faire fin tâche
Exemple d'application temps réel Programme/2
67
2.6. Quelques mots sur les O.S. Temps Réel
Exemple d'application temps réel exécution
(diagramme de Gantt)
68
2.7. Quelques mots sur les langages TR
69
2.7. Quelques mots sur les langages

• Plusieurs voies
• programmation associée à un O.S. / programmation
  sans O.S.
• sémantique synchrone / sémantique asynchrone

• Sémantique synchrone (Lustre, Esterel)
• durées des actions considérées "nulles"
  (négligeables devant la dynamique de
  l'environnement)
• réduction de la concurrence des tâches en un
  programme séquentiel
• déterminisme et simplicité
• mais exécution centralisée en une seule boucle
• possibilité de vérifier formellement le
  comportement du système

• Sémantique asynchrone (Ada)
• plusieurs tâches concurrentes
• entrelacement de ces tâches
• synchronisation par rendez-vous et sémaphore
• risque de non déterminisme
• risque de complexité du comportement

70
2.7. Quelques mots sur les langages

• Quels critères pour le choix de langage de
  programmation de systèmes temps réel ?
• Standard international
• large diffusion
• portabilité et réutilisabilité aisées
• qualité des Ateliers Logiciel associés (outils de
  test, d'analyse, de gestion de configuration)
• pérennité (20 à 30 ans par exemple dans
  l'avionique)
• abstraction face à la cible et aux exécutifs
  temps réel
• simplicité de programmation, notamment pour la
  programmation de tâches ou processus communicants
• maîtrise des temps d'exécution (est-il possible
  de prédire ces temps)
• modularité du développement et du programme
• qualité du code généré (correction et performance
  du code généré par les compilateurs)

71
2.7. Quelques mots sur les langages

• ADA (ADA95)
• Standard international
• large diffusion
• portabilité et réutilisabilité aisées
• qualité des Ateliers Logiciel
• pérennité
• abstraction face à la cible et aux exécutifs
  temps réel
• simplicité de programmation,
• maîtrise des temps d'exécution (est-il possible
  de prédire ces temps)
• modularité du développement et du programme
• qualité du code généré (correction et
  performance)
• gt concept offert
• typage fort, programmation objet...
• programmation multitâche, synchronisation par
  rendez-vous et sémaphore, gestion des exceptions

?
?
?
72
2.7. Quelques mots sur les langages

• C (langage d'usage général) associé à un O.S.
  Temps Réel
• Standard international
• large diffusion
• portabilité et réutilisabilité aisées
• qualité des Ateliers Logiciel
• pérennité
• abstraction face à la cible et aux exécutifs
  temps réel
• simplicité de programmation
• maîtrise des temps d'exécution (est-il possible
  de prédire ces temps)
• modularité du développement et du programme
• qualité du code généré (correction et
  performance)

?
?
?
?
?

• Intérêt
• rapidité du codage et du code
• compatible Unix

• Problèmes
• peut être utilisé comme un assembleur
• gt peu lisible, peu certifiable

73
2.7. Quelques mots sur les langages

• Les langages synchrones
• Standard international
• large diffusion
• portabilité et réutilisabilité aisées
• qualité des Ateliers Logiciel
• pérennité
• abstraction face à la cible et aux exécutifs
  temps réel
• simplicité de programmation
• maîtrise des temps d'exécution (est-il possible
  de prédire ces temps)
• modularité du développement et du programme
• qualité du code généré

?

• Intérêt
• déterminisme
• simplicité
• preuves formelles
• compilation correcte en C (et donc
• rapidité d'exécution)

• Problèmes
• langages trop simples (pas
• d'algorithmique)
• exécution centralisée en une seule
• boucle

74
2.7. Quelques mots sur les langages

• Exemples
• système des commandes de vol Airbus
• décomposition du système en plusieurs tâches
  cycliques atomiques
• programmation des tâches en Lustre et d'une
  bibliothèque d'opérateurs en assembleur
• réalisation "à la main" d'un séquenceur en C
• gt pas d'O.S.
• gt système "time driven"
• système de reconfiguration du réseau électrique
  (partie non critique) Airbus
• décomposition du système en plusieurs tâches
  cycliques non atomiques
• programmation en ADA et en Lustre
• utilisation d'un O.S. avec une politique
  d'ordonnancement à la RMA
• Calculateur de mission Rafale
• décomposition du système en plusieurs tâches
  cycliques non atomiques
• programmation en ADA, C, Esterel
• utilisation d'un O.S. avec une politique
  d'ordonnancement à la RMA