OSEK/VDX

OSEK est le sigle pour «Offene Systeme und deren Schnittstellen für die Elektronik im Kraftfahrzeug», en français Dispositifs ouverts et interfaces correspondantes pour l'électronique des véhicules automobiles.



Catégories :

Technologie automobile - Système d'exploitation

Recherche sur Google Images :


Source image : www.picos18.com
Cette image est un résultat de recherche de Google Image. Elle est peut-être réduite par rapport à l'originale et/ou protégée par des droits d'auteur.

Page(s) en rapport avec ce sujet :

  • Fusion des projets OSEK (Allemand) et VDX (GIE PSA-Renault). Englobe le projet Européen MODISTARC... les inversions de priorités ; les blocages inter- tâches... (source : cert)

OSEK est le sigle pour «Offene Systeme und deren Schnittstellen für die Elektronik im Kraftfahrzeug», en français Dispositifs ouverts et interfaces correspondantes pour l'électronique des véhicules automobiles.

OSEK 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 identique, VDX (Vehicle Distributed eXecutive), rejoignirent le consortium.

L'architecture ouverte présentée par OSEK/VDX comprend trois parties :

La communication

OSEK COM offre des services pour le transfert de données entre tâches et/ou routines d'interruption. L'accès aux services OSEK COM n'est envisageable que via l'interface (API) spécifiée, l'objectif de l'interface étant d'assurer la portabilité, l'interopérabilité et la réutilisation des logiciels d'application.

Gestion de réseau

OSEK NM (network management) définit un jeu de services assurant l'initialisation, le démarrage et le contrôle de l'état des nœuds d'un réseau.

Le dispositif d'exploitation temps réel

Le dispositif d'exploitation temps réel OSEK a pour but de répondre aux contraintes sévères d'exécution en temps réel des logiciels embarqués utilisés par l'électronique automobile. Il permet d'aider à la portabilité entre différents modules constituant une application logicielle. L'une des caractéristiques d'OSEK/VDX est que le dispositif est défini de façon statique lors de la compilation : l'ensemble des services utilisés (tâches, messages, etc. ) sont définis de façon statique dans le langage OIL (OSEK Implementation Language), contrairement aux dispositifs temps réel de type POSIX. Cela entraîne une faible empreinte mémoire et un très faible surcoût processeur dû au dispositif.

La gestion de tâches

Une tâche est une portion de code séquentiel. OSEK OS apporte deux types de tâches :

  • les tâches de base
  • les tâches étendues

Les tâches de base

Une tâche de base rend la main au processeur si :

  • elle est terminée
  • OSEK OS laisse la main à une tâche de priorité plus haute
  • une interruption arrive

Une tâche de base peut prendre trois états différents :

  • suspended : la tâche est passive mais peut être activée
  • ready : la tâche est candidate à l'exécution
  • running : la tâche est en cours d'exécution

Les tâches étendues

Les tâches étendues ont les mêmes caractéristiques que les tâches de base avec en plus la possibilité d'utiliser la gestion des évènements.

Cette possibilité leur «donne accès» a un quatrième état : Waiting. Les tâches étendues ont d'autre part les trois mêmes états que les tâches de base (Running, Suspended, Ready).


Dans l'état «Waiting», la tâche étendue ne peut pas continuer à s'exécuter car elle doit attendre l'arrivée d'au moins un évènement.

Quelques primitives (API) de gestion des tâches

La déclaration d'une tâche se fait grâce à la primitive void DeclareTask (TaskIdentifier).

Au démarrage, une tâche est à l'état «Suspended». Pour l'activer, c'est-à-dire passer à l'état «Ready», on utilise la primitive StatusType ActivateTask (TaskType )

Pour terminer une tâche, c'est-à-dire la passer à l'état «Suspended», on utilise la primitive StatusType TerminateTask (void).

Il existe d'autres primitives pour la gestion des tâches, qui permettent par exemple de connaître le numéro d'identification d'une tâche ou encore l'état courant d'une tâche.

Gestion des priorités
  • Traitement des tâches


Les priorités données aux tâches sont essentielles dans le sens où elle vont servir à l'ordonnanceur à déterminer quelle est la tâche aujourd'hui à l'état «Ready» qui va passer la prochaine à l'état «Running».

Les priorités données aux tâches sont définies de manière statique à la création.

La valeur 0 représente la priorité la plus basse. Il n'y a pas de valeur limite pour les priorités les plus hautes.

Dans le cas de tâches ayant la même priorité, on donne la main à celle qui a été activée en premier.

Une tâche qui a été préemptée est reconnue comme étant la plus ancienne dans la file FIFO des tâches de même priorité, et sera par conséquent la première à en sortir. A l'inverse, une tâche qui sort de l'état «Waiting» est positionnée comme la première dans la file FIFO des tâches de même priorité, et sera par conséquent la dernière à en sortir.

Pour déterminer la prochaine tâche qui sera exécutée, l'ordonnanceur suit l'algorithme suivant :

  • recherche de l'ensemble des tâches qui sont dans l'état «Ready»
  • à partir de cet ensemble de tâche, l'ordonnanceur détermine celles qui ont la plus haute priorités
  • parmi cet ensemble de tâches à la priorité la plus haute, l'ordonnanceur détermine la plus ancienne (celle qui a été activée en premier), et l'exécute.


Les interruptions et l'ordonnanceur

OSEK définit trois niveaux de traitements :

  • les interruptions
  • l'ordonnanceur
  • les tâches


Les interruptions ont une priorité supérieure aux tâches. L'ordonnanceur a une priorité inférieure aux interruptions mais supérieure aux tâches.


Les fonctions permettant de traiter les interruptions (ISR : Interrupt Service Routine) existent sous deux formes :

- ISR catégorie 1 : l'ISR ne fait pas appel aux services de l'OS. Ces interruptions sont transparentes pour l'OS, sont rapides et ne nécessitent pas de synchronisation avec l'OS.

- ISR catégorie 2 : l'ISR fait appel aux services de l'OS, c'est-à-dire que le code de l'interruption contient des API.


N. B : dans la version 2.1 d'OSEK, il existe aussi une catégorie 3 d'ISR, qui est une combinaison entre les catégories 1 et 2. Mais cette troisième catégorie a été supprimée dans la version 2.2.

Les évènements

Les évènements représentent, comme les interruptions, des événements externes. Le traitement d'un évènement ne s'effectue pas dans une ISR mais dans une tâche dans laquelle l'évènement a été défini.

Le mécanisme d'évènement n'est utilisable que pour les tâches étendues et conditionne l'entrée ou la sortie de l'état «Waiting» de ce type de tâches.

Les évènements ne sont pas des objets indépendants, ils sont rattachés à une tâche étendue, qui est dite «propriétaire» de cet évènement. Un évènement est ainsi identifié par son propriétaire et son nom (ou son masque).

Les évènements peuvent être utilisés comme un moyen de synchronisation entre les tâches ou pour communiquer des informations (binaires) à la tâche étendues auxquelles ils sont rattachés.

Un évènement peut être déclenché autant par une tâche étendue que par une tâche de base. Le déclenchement est réalisé grâce à un service de l'OS et peut aussi être réalisé par des alarmes, des messages ou des ISR. Par contre, la remise à zéro de l'évènement ne peut être effectuée que dans la tâche dans laquelle il a été défini.

Alarmes et compteurs

OSEK apporte des objets servant à traiter des phénomènes récurrents dans le temps. Un tel phénomène pourrait être par exemple l'activation cyclique d'une interruption. Ces objets sont les compteurs et les alarmes.

Les compteurs sont conçus pour l'enregistrement des ticks en provenance d'un timer ou d'un système émettant des stimuli (par exemple des capteurs). OSEK ne apporte pas d'API servant à manipuler directement les compteurs.

L'alarme a pour but de superviser la valeur d'une référence (par exemple celle d'un compteur). L'alarme se déclenchera lorsque une certaine valeur de cette référence sera atteinte. Les alarmes sont statiquement associées à un compteur ainsi qu'à une tâche. Plusieurs alarmes peuvent être affectées à un même compteur.

N. B : la norme OSEK impose l'implémentation d'au moins une alarme.

Si l'affectation d'une alarme à un compteur ainsi qu'à une tâche est statique, la valeur à laquelle l'alarme expire est dynamique et peut par conséquent être changé en cours d'exécution.

Une alarme est parfois utilisée pour effectuer les actions suivantes :

- activation d'une tâche

- déclenchement d'un évènement

Gestion des ressources

La gestion des ressources comprend la coordination de l'accès aux ressources partagées. Celles-ci peuvent être de l'espace mémoire, des composants hardware, des applications ou encore des instances de l'OS (par exemple le scheduler).

La gestion des ressources assure que :

- deux tâches ne peuvent pas occuper la même ressource au même instant

- il ne peut pas y avoir d'inversion de priorité

- il ne peut pas y avoir d'interblocage

- l'accès à une ressource n'engendre pas d'état «Waiting» pour une tâche

Les phénomènes d'inversion de priorité et d'interblocage peuvent être évités grâce au Priority Ceiling Protocol mise en place par OSEK.

Les routines crochets (hook routines)

OSEK apporte des mécanismes de «crochets» qui autorisent l'utilisateur de dérouter le déroulement normal de l'OS de manière à prendre provisoirement le contrôle du dispositif.

Les routines crochets sont nommées par l'OS et ont une priorité supérieure à l'ensemble des tâches. Elles sont implémentées par le développeur et doivent obligatoirement être implémentées.


Les routines crochets disponibles pour le développeur sont les suivantes :

- StartupHook : utilisé au démarrage de l'application avant l'activation des tâches

- ShutdownHook : utilisé avant l'arrêt de l'OS

- PreTaskHook : utilisé avant chaque changement de contexte d'une tâche

- PostTaskHook : utilisé après chaque changement de contexte d'une tâche

- ErrorHook : utilisé lors de détection d'erreur dispositif

Les différents types d'erreur

On peut distinguer deux types d'erreur :

- les «application errors» qui arrivent quand l'OS n'a pas pu correctement exécuter l'API demandée

- les «fatal errors» qui arrivent quand l'OS n'a plus la garantie de l'intégrité des données internes

C'est grâce à la routine crochet ErrorHook que l'utilisateur peut réaliser des actions, qu'il aura lui-même définies, au moment de l'arrivée d'une erreur. La routine crochet ErrorHook sera nommée si la variable StatusType retournée par une API n'est pas identique à «E_OK».

Classes de conformité

Le dispositif d'exploitation doit pouvoir s'adapter à différents niveaux de complexité du dispositif logiciel qui peut être limité par les ressources disponibles (type de processeur, taille de mémoire, …). C'est pourquoi OSEK introduit le concept de classes de conformité (conformance classes) dont l'objectif est de proposer un niveau de fonctionnalités croissant pour les dispositifs des plus simples aux plus complexes.

OSEK définit quatre niveaux divers :

  • BCC1 : seulement des tâches de base
        Une seule demande d’activation par tâche
        Une seule tâche par niveau de priorité
  • BCC2 : BCC1 plus :
        Plus d’une tâche par niveau de priorité
        Plusieurs demandes d’activation par tâche
  • ECC1 : BCC1 plus des tâches étendues
  • ECC2 : ECC1 plus :
        Plus d’une tâche par niveau de priorité
        Plusieurs demandes d’activation par tâche

Séquencement

OSEK permet différents niveaux de séquencement des tâches.

  • Séquencement non préemptif :

Un changement de contexte vers une tâche d'un niveau de priorité plus élevé ne peut se faire que par une utilisation explicite des services apportés par le dispositif d'exploitation.

  • Séquencement préemptif :

L'exécution d'une tâche peut être suspendue pour autoriser l'exécution d'une tâche qui plus est haute priorité.

  • Séquencement préemptif mélangé :

Le dispositif autorise la présence de tâches dont l'exécution peut ou non être interrompue.

Liens externes

Recherche sur Amazone (livres) :



Ce texte est issu de l'encyclopédie Wikipedia. Vous pouvez consulter sa version originale dans cette encyclopédie à l'adresse http://fr.wikipedia.org/wiki/OSEK/VDX.
Voir la liste des contributeurs.
La version présentée ici à été extraite depuis cette source le 10/04/2009.
Ce texte est disponible sous les termes de la licence de documentation libre GNU (GFDL).
La liste des définitions proposées en tête de page est une sélection parmi les résultats obtenus à l'aide de la commande "define:" de Google.
Cette page fait partie du projet Wikibis.
Accueil Recherche Aller au contenuDébut page
ContactContact ImprimerImprimer liens d'évitement et raccourcis clavierAccessibilité
Aller au menu