LES NOYAUX TEMPS REELS

P R E S E N T A T I O N R E S U M E E D U R T O S O S E K / V D X

1. PRESENTATION :
L'exécutif temps réel OSEK (Offene Systeme und deren Schnittstellen für die Elektronik im Kraftfahrzeug ou Open Systems and the Corresponding
Interfaces for Automotive Electronics) a été créé en 1993 par un consortium de constructeurs et équipementiers automobiles allemands (BMW,
Bosch, DaimlerChrysler, Opel, Siemens, et VW) ainsi qu’un département de l’université de Karlsruhe. Leur but était de développer un standard
pour une architecture ouverte reliant les divers contrôleurs électroniques d’un véhicule. En 1994, les constructeurs français Renault et PSA qui
développaient un projet similaire, VDX (Vehicle Distributed eXecutive), rejoignirent le consortium.
L’architecture ouverte présentée par l'exécutif OSEK/VDX est organisée autour des ECUs (Electronic Control Unit). Elle comprend trois parties :
 OSEK-OS (real time operating system) : environnement d'exécution des ECUs
 OSEK-COM (communication) : échange de données entre et inter ECUs
 OSEK-NM (network management) : gestion réseau, configuration, registration et monitoring des ECUs

2. CONTEXTE :
 Electronique embarquée dans les véhicules
 Contraintes temps réel (dures et souples) : powertrain, chassis, body et telematics
 Sûreté de fonctionnement élevée

 Avènement futur des systèmes "tout électrique" ou "X by Wire", c’est-à-dire systèmes pour lesquelles toute transmission hydraulique
ou mécanique est remplacée par une transmission numérique
 Support matériel minimal : peu de RAM, ECU 8 et 16 bits
 Architecture distribuée autour de différents réseaux : CAN, LIN, etc.
 Fonctions transversales avec interopérabilité des sous-systèmes pour réaliser la fonction désirée
 Flexibilité de l’architecture : ajout de fonctions, portabilité et réutilisabilité des fonctions logicielles)
 Moindre coût.

3. LES TACHES DANS OSEK/VDX OS

La tâche est l'objet actif de l'application sachant que tous les objets sont statiques :
 Pas de création dynamique d’objets
 Pas de suppression dynamique d’objets
On distingue :
Tâche basique Tâche étendue

1. Tâches basiques :
 Sans points bloquants
 Rendent la main au processeur une fis terminée
 3 états : Running – Ready – Suspended

2. Tâches étendues : En plus des propriétés des tâches

basiques
 Peuvent invoquer des ser vices bloquants
 Possèdent un état supplémentaire : waiting,

1|Page
 LES NOYAUX TEMPS REELS
P R E S E N T A T I O N R E S U M E E D U R T O S O S E K / V D X

4. L'ORDONNANCEMENT DES TACHES

 Priorité fixe non modifiable (la valeur 0 est la plus faible priorité)

 3 modes d’ordonnancement :
 Préemptif : toutes les tâches en mode préemptif et une tâche peut être interrompue au profit d’une autre plus prioritaire
 Non préemptif : toutes les tâches en mode non-préemptif et une tâche perd le processeur lorsqu’elle le demande explicitement
 Mixte : les attributs des tâches peuvent être préemptif ou non préemptif.
• Engendre moindre consommation de RAM
• Non préemption pour protection d’une ressource

 Gestion des ressources partagées avec "Priority Ceiling Protocol" qui influe sur l’ordonnancement.

 Notion de groupe de tâches :

 Un groupe est un ensemble de tâches liées par une ressource interne
 Les tâches internes au groupe, partageant une ressource ne peuvent se préempter :
• C’est intéressant pour des tâches coopérantes (à l’aide d’une même ressource)
• C’est plus simple que la gestion classique de ressource car complètement transparent à l’application
 Pour les tâches externes qui ont une priorité inférieure ou égale à la plus haute priorité du groupe, les tâches du groupe sont
non-préemptives
 Pour les tâches externes qui ont une priorité supérieure à la plus haute priorité du groupe, les tâches du groupe sont
préemptives

5. LES CLASSES DE CONFORMITE

La spécification OSEK/VDX OS définit des classes de conformité. Chaque classe équivaut à une version du système d'exploitation offrant des
niveaux spécifiques d'utilisation de ressources (processeur et mémoire).
Les classes de conformité sont définies par les données suivantes :
 Requête multiple d'activation de tâche ou non
 Types de tâches (basique, étendue)
 Nombre de tâches par priorité
A partir de cela, nous pouvons distinguer 4 classes de conformités distinctes :
 BCC1 : composée uniquement de tâches basiques, limitée à une demande d'activation par tâche et une seule tâche par priorité.
 BCC2 : idem que BCC1 avec les possibilités supplémentaires d'avoir des demandes d'activations multiples ainsi que d'avoir plusieurs
tâches par priorité.
 ECC1 : idem que BCC1, avec la possibilité d'utiliser des tâches étendues.
 ECC2 : idem que ECC2, avec les possibilités supplémentaires d'avoir des demandes d'activations multiples (sur les tâches basiques
uniquement) ainsi que d'avoir plusieurs tâches par priorité.

2|Page