Chapitre 4 : Quelques mots sur quelques OS TR

1
Chapitre 4 Quelques mots sur quelques OS TR
2
4.1. Généralité sur les OS TR

• Les principales caractéristiques des noyaux temps
  réel
• ? Conformité à une norme ou pseudo-norme (POSIX,
  projet Sceptre)
• ? Compacité (pour les applications embarquées)
• ? Environnement cibles (microprocesseurs,
  architecture, )
• ? Environnement hôtes (type OS)
• ? Outils d'aide au développement (debug, analyse
  en ligne, )
• ? Primitives temps réel (liste de tous les
  services fournis)
• ? Caractéristiques de l'ordonnanceur (politiques
  d'ordonnancement)
• ? Caractéristiques temporelles
• temps de masquage des interruptions (interrupt
  latency) temps pendant lequel les interruptions
  sont masquées et ne peuvent donc pas être prises
  en compte (exécution de primitives atomiques,
  manipulation des structures critiques, )
• temps de réponse (task response time) temps
  entre l'occurrence d'une interruption et
  l'exécution de la tâche réveillée
• temps de retard de l'ordonnanceur (preemptive
  latency) temps maximal pendant lequel le noyau
  peut retarder l'ordonnanceur.

3
4.1. Généralité sur les OS TR

• Deux grandes catégories d'O.S. temps réel
• gt les OS Temps Réel d'origines (Tornado, QNX, )
• offrent une gestion fine des priorités
• offrent des primitives système rapides, en temps
  borné (gestion des interruptions, des
  sémaphores)
• pas de mémoire virtuelle, mais verrouillage de
  pages en mémoire centrale
• minimisation de l' "overhead" (le temps pris par
  le système pour s'exécuter et se gérer lui-même)
• gt la solution au Temps Réel Dur

4
4.1. Généralité sur les OS TR

• Deux grandes catégories d'O.S. temps réel
• gt les O.S. classiques étendus pour le temps réel
  (Unix)
• permettent le développement concurrent
  d'applications temps réel et non temps réel dans
  un environnement standard et confortable
• Mais il a fallu
• revoir les politiques d'ordonnancement
• renforcer la notion de préemption
• définir des primitives systèmes réentrantes
• définir la notion de processus léger (pour
  faciliter la préemption avec sauvegarde de
  contexte puis la reprise avec restitution de
  contexte)
• gt modifications importantes et complexes
• LynxOS
• Unix System V
• Solaris 2.4
• gt pour le temps réel lâche

5
4.1. Généralité sur les OS TR
Situation de l'offre industrielle des noyaux
temps réel
Étude de Embedded Systems Research (marché USA -
1995)
Pas de prédominance d'un système système
propriétaires - coût (Licence) - techniques
(adaptation aux besoins) - stratégie (maîtrise)
6
4.1. Généralité sur les OS TR
Comparaison de noyaux temps réel du marché (1998)
7
4.2. Introduction à LynxOS
8
4.2. Présentation de LynxOS

• OS TR de LinuxWorks
• LynxOS est une API (Application Program
  Interface) compatible Linux et donc conforme
  POSIX multi-process et multitâches
• Spécialisé dans le traitement des tâches en temps
  réel (routeurs, pilotage automatique, etc.)

9
4.2. Présentation de LynxOS

• Le noyau de LynxOs supporte lexécution dune
  grande variété de services et leur chargement
  sans dégradation de performance.
• Ce système dexploitation permet aux créateurs
  dapplications temps réelles dutiliser les
  fonctions suivantes
• Performance hard en temps réel (comportement
  déterministe, rapide, temps de latence courts)
• Un environnement fiable (Conforme DO-178B)
• Un système ouvert API
• Un service de répertoire riche.

10
4.2. Paradigme de développement de lOS

• Supporte un développement en natif et en croisé

natif developpement et test sur le système où
est installé LynxOS (self-hosted
development) croisé (cross-development)
11
4.2. Outils de développement

• Ensemble doutils LynuxWorks PosixWorks
• LynxOS Open Development Environment (ODE) pour
  des configurations croisées et natives
  
• outilsPosixWorks additionnels
• GNU Toolchain
• outils de compilation, debug, tools
• un Système de Contrôle de Révisions (RCS)
• éditeur Emacs et outils GNU
• TotalView debugger
• SpyKer trace graphique
• VisualLynux Windows-based IDE (Integrated
  Development Environment
• LynxInsure détection de bugs pendant les
  phases de dévelopment et dintégration
• TimeScan analyse de performances

12
4.3. Introduction à VxWorks
13
4.3. La crise du logiciel embarqué
Objectifs des RTOS fournir du logiciel de
qualité et des services pour que lutilisateur
arrive à créer des applications embarquées
rapidement, à faible côut et avec un risque
minimum.
Low Cost RISC / 32-bit Microprocessors
Ajouté à cela
Embedded Software Crisis
Complex Applications
Time-to-market pressure
de nouvelles technologies de nouvelles
applications lexplosion des semiconducteurs lInt
ernet
Increasing Development Costs
14
4.3. La société WindRiver

• Fondée in 1981
• 500 Employés
• ISO 9001 Certified
• Multinationale Headquarters en Alameda, CA.
  Direct Wind River offices in UK, France, Italy,
  Israel, Germany, Sweden, Japan, Korea.
• Wind River Systems en Europe 100 personnes
• 2 Centres Hot Line et Support techniques (France
  UK)
• 4 Cenres RD (France, UK, Scotland, Israel)

15
4.3. Conception de VxWorks-Tornado

• UNIX et Windows excellents pour le
  développement dapplications interactives mais
  pas temps réel.
• Par ailleurs, les OS TR offraient souvent des
  environnements de développement peu conviviaux.
• Wind River utilise deux systèmes complémentaires
  et coopératifs (VxWorks et UNIX, ou VxWorks et
  Windows)
• VxWorks gère les aspects TR critique
• la machine hôte est utilisée pour le
  développement et pour les applications non
  critiques
• Tornado

16
4.3. Présentation de VxWorks

• RTOS optimisé pour des applications TR embarquées
  
• temps de latence faible pour le traitement dIt
  et le changement de contexte
• Surcharge appel system faible
• Modulable
• Portable grâce aux BSP
• Premier système à intégrer le cross-développement
  à partir dune station Unix
• Adhère à POSIX
• Programmation en C,C,Java,
• Disponible sur bus VME PCI Motorola 680x0
  683xx, Intel ix86 i960, MIPS, SPARC, PpwerPC, ...

17
4.3. Présentation de VxWorks

• Caractéristiques du noyau Wind
• Multitâche avec ordonnancement préemptif basé sur
  priorité, différents moyens de synchronisation/com
  munication intertâche, supporte linterception
  dinterruptions, les chiens de garde, et la
  gestion mémoire.
• Compatible POSIX
• la plupart des interfaces sont spécifiées par le
  standard 1003.1b ? portabilité
• Système dES
• rapide et flexible, compatible ANSI C
• inclut les E/S bufferisées standard Unix et les
  E/S asynchrones standard POSIX

18
4.3. Le noyau Wind

• Consiste en un micro-noyau et des utilitaires
  périphériques
• Minimise le temps passé en mode superviseur pour
  optimiser les performances
• Modulaire une centaine déléments configurables
• Possibilité d avoir de très petits run-time.

19
4.3. Quest-ce quune tâche VxWorks ?

• Une tâche a un contexte dexécution. Elle
  possède
• un pointeur dinstruction (position courante de
  lexécution)
• des copies privées des registres CPU
• une pile pour les variables locales, les
  arguments de fonctions,
• Seule une tâche peut être en cours dexécution à
  un moment donné.
• Quand une tâche ne sexécute pas, son contexte
  est stocké dans son Task Control Block (TCB)
  ainsi que sa pile.Le TCB est la structure de
  données que le noyau utilise pour représenter et
  contrôler les tâches.

20
4.3. Gestion des tâches

• Nombre illimité de tâches
• 256 niveaux de priorités
• Ordonnancement préemptif round-robin
• Temps de changement de contexte ltquelques µs

21
4.3. Ordonnancement préemptif basé sur priorité

• A tout instant, la tâche prête de plus forte
  priorité sexécute.
• Une tâche de plus forte priorité qui passe prête
  préempte la tâche en cours dexécution.
• Les interruptions préemptent toute tâche.

Notes On this board, INT 6 is the system clock,
INT 3 is the network interrupt.
22
4.3. Communication Intertâche

• Les tâches doivent coordonner leurs exécutions
• VxWorks offre un ensemble de mécanismes de
  communication
• mémoire partagée partage simple des données
  (entre toutes les tâches)
• sémaphores exclusion mutuelle basique et
  synchronisation
• files de messages et pipes transfert de
  messages intra CPU
• sockets et remote procedure calls transfert via
  réseau
• signals traitement d exceptions

23
Communication par mémoire partagée

• Ex procedure réentrante

24
4.3. Communication Intertâche sémaphores

• Mécanisme basique de synchronisation et
  dexclusion mutuelle.
• Objets du noyau permettant de
• bloquer/débloquer des tâches
• coordonner leur exécution avec celles des autres
  tâches et les événements externes.
• VxWorks offre 3 types de sémaphores ( POSIX)
• binaire synchronisation
• compteurs allocation de ressources
• mutex (exclusion mutuelle) héritage de priorité
• Gestion de la file dattente des tâches
• FIFO
• par priorité des tâches

25
4.3. Communication Intertâche messages

• Buffer FIFO de messages de longueur prédéfinie
• Inclut la synchronisation et lexclusion mutuelle
  
• une tâche se suspend en cas de lecture sur file
  vide ou décriture sur file pleine. Possibilité
  spécifier time-out.

26
4.3. Communication Intertâche pipes

• Periphériques d E/S virtuels, associés a des
  files de messages
• Taille max prédéfinie du pipe et des messages
• Même synchronisation que sur les files
• Les ISRs peuvent écrire mais pas lire (idem
  files).
• Une caractéristique importante ? files select(
  ). Permet à une tâhce d attendre quune donnée
  soit disponible sur un ensemble de périphériques
  d E/S (pipes, sockets, périphériques série).

27
4.3. Communication Intertâche signaux

• VxWorks implante les signaux POSIX.
• Deux utilisations
• Avertir une tâche dun événement de façon
  asynchrone
• Traitement dexceptions
• Si une tâche commet une exception, elle est
  suspendue sauf si elle a installé un handler de
  signal pour le handler correspondant
• ? le handler peut relancer la tâche ou
  reprendre son exécution à un état antérieur

28
4.3. Communication Intertâche interruptions

• Pour obtenir la réponse la plus rapide possible à
  des interruptions externes les interrupt service
  routines (ISRs) s exécutent dans un contexte
  spécial hors du contexte des tâches ? éviter les
  changements de contexte.
• ISR ? fonction C associée par lutilisateur à un
  vecteur d It
• ladresse de lISR est stockée dans la table des
  vecteur d It elle est directement appelée par
  le hardware
• lISR démarre le travail (sauvegarde des
  registres, ...) et appelle ensuite la fonction C
  qui traite lIt

29
4.3. Communication Intertâche watchdog timers

• Mécanisme qui permet à une fonction C de
  sexécuter après un délai spécifié.
• Utilisés pour la scrutation périodique et la
  détection de dépasement de deadline

30
4.3. Les entrées / sorties

• Basées sur POSIX
• Tous les canaux d entrée/sortie sont représentés
  par des descripteurs de fichier
• Ils sont manipulés par les fonctions
• open, read, write,ioctl, close
• Entrées/sorties bufférisées
• fread/fwrite fgetc/fputc
• Entrées/sorties formattées
• fscanf/fprintf

31
4.3. Larchitecture de VxWorks
Applications
I/O System
VxWorks libraries
TCP/IP
Wind microKernel
File System
SCSIDriver
Flash Driver
MMUDriver
CacheDriver
SerialDriver
EthernetDriver
OtherDrivers
Hardware
32
4.3. Développement croisé

• Toutes les fonctionnalités sont implémentées sous
  forme de bibliothèque de fonctions C
• Une fonction C peut être
• appelée interactivement depuis le shell
• lancée comme tâche VxWorks
• connectée à une interruption ou à un timer
• Une bibliothèque peut être chargée
• statiquement à la construction du noyau
• avec le loader dynamique depuis le shell ou
  depuis une fonction C

33
4.3. Développement croisé scénario typique

• 1. Booter la cible 4. Télécharger le module
  objet
• 2. Attacher le target serveur 5. Tester
  Debuguer
• 3. Editer compiler 6. Retourner en 3 ou 1
  si nécessaire