OSEK/VDX
Un article de Wikipédia, l'encyclopédie libre.
OSEK est le sigle pour « Offene Systeme und deren Schnittstellen für die Elektronik im Kraftfahrzeug », en français Systèmes 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 similaire, VDX (Vehicle Distributed eXecutive), rejoignirent le consortium.
L’architecture ouverte présentée par OSEK/VDX comprend trois parties :
- La communication (échange de données entre unités de contrôle)
- La gestion de réseau
- Le système d’exploitation temps réel
Sommaire
|
[modifier] 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 possible que via l’interface (API) spécifiée, le but de l’interface étant d’assurer la portabilité, l’interopérabilité et la réutilisation des logiciels d’application.
[modifier] 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.
[modifier] Le système d’exploitation temps réel
Le système 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 système est défini de façon statique lors de la compilation : tous les services utilisés (tâches, messages, etc.) sont définis de façon statique dans le langage OIL (OSEK Implementation Language), contrairement aux systèmes temps réel de type POSIX. Cela entraîne une faible empreinte mémoire et un très faible surcoût processeur dû au système.
[modifier] Services offerts par OSEK OS
[modifier] La gestion de tâches
Une tâche est une portion de code séquentiel. OSEK OS fournit deux types de tâches :
- les tâches basiques
- les tâches étendues
[modifier] Les tâches basiques
Une tâche basique 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 basique 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
[modifier] Les tâches étendues
Les tâches étendues ont les mêmes caractéristiques que les tâches basiques 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 par ailleurs les trois mêmes états que les tâches basiques (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.
[modifier] 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 <TaskID>)
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.
[modifier] Gestion des priorités
- Traitement des tâches
Les priorités données aux tâches sont primordiales dans le sens où elle vont servir à l’ordonnanceur à déterminer quelle est la tâche actuellement à 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 considérée comme étant la plus ancienne dans la file FIFO des tâches de même priorité, et sera donc la première à en sortir. A l’inverse, une tâche qui sort de l’état « Waiting » est placée comme la première dans la file FIFO des tâches de même priorité, et sera donc 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 toutes les 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.
[modifier] 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 servant à 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 également 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.
[modifier] 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é aussi bien par une tâche étendue que par une tâche basique. Le déclenchement est réalisé grâce à un service de l’OS et peut également ê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.
[modifier] Alarmes et compteurs
OSEK fournit des objets permettant de 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 destinés à l’enregistrement des ticks en provenance d’un timer ou d’un dispositif émettant des stimuli (par exemple des capteurs). OSEK ne fournit pas d’API permettant de 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 quand une certaine valeur de cette référence sera atteinte. Les alarmes sont statiquement associées à un compteur et à 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 et à une tâche est statique, la valeur à laquelle l’alarme expire est dynamique et peut donc être changé en cours d’exécution.
Une alarme peut être utilisée pour effectuer les actions suivantes :
- activation d’une tâche
- déclenchement d’un évènement
[modifier] 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.
[modifier] Gestion des erreurs
[modifier] Les routines crochets (hook routines)
OSEK fournit des mécanismes de « crochets » qui permettent à l'utilisateur de dérouter le déroulement normal de l’OS de façon à prendre temporairement le contrôle du système.
Les routines crochets sont appelées par l’OS et ont une priorité supérieure à toutes les 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 système
[modifier] Les différents types d’erreur
On distingue deux types d’erreur :
- les « application errors » qui arrivent lorsque l’OS n’a pas pu correctement exécuter l’API demandée
- les « fatal errors » qui arrivent lorsque 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 appelée si la variable StatusType retournée par une API n’est pas égale à « E_OK ».
[modifier] Classes de conformité
Le système d’exploitation doit pouvoir s’adapter à différents niveaux de complexité du système 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 systèmes des plus simples aux plus complexes.
OSEK définit quatre niveaux différents :
- BCC1 : uniquement 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
[modifier] 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 fournis par le système 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 de plus haute priorité.
- Séquencement préemptif mélangé :
Le système autorise la présence de tâches dont l’exécution peut ou non être interrompue.
[modifier] Voir aussi
[modifier] Articles Connexes
- sur les Système temps réel
- sur le concept Multi-Tâche
- sur les Noyaux de système d'exploitation
[modifier] Liens Externes
- L'OSEK de la société Vector
- PICOS18 : l'OSEK open-source de Pragmatec
- openOSEK is a free, open source (LGPL license)
- Trampoline, une autre implémentation libre et gratuite (LGPL license) Implémentation qui marche sur plusieurs plate-formes, contrairement à OpenOsek qui n'est pas vraiment fonctionnel.
