Technologies de l’informatique de gestion pour les applications temps réel

Introduction

En musique, jouer trop tard la note de bonne hauteur fait finalement une fausse note ! Mais bien qu’en informatique de gestion l’instant exact de réponse du système à une demande n’ait pas beaucoup d’importance, certains usages sont sensibles à la réponse en un temps limité garanti. Dans ce post, nous abordons des technologies disponibles pour réaliser des systèmes déterministes dans le temps (appelés « Temps réel dur »).

Ce type de système est bien connu des industriels (contrôle-commande), des avionneurs (calculateurs de vol), des spécialistes du traitement du signal (streaming audio vidéo)…

Il n’est donc pas forcement demandé que le temps de réaction soit extrêmement court, mais que l’on soit sûr de l’arrivée de la réponse : un temps de réaction de quelques minutes peut être acceptable sur certains systèmes de régulation thermique par exemple, mais il doit être tenu.

Les systèmes « temps réel »

Quelques principes de fonctionnement

Un des principes de fonctionnement est qu’un programme (appelé « Tâche ») qui s’exécute puisse être interrompu pour prendre en compte un événement extérieur. Typiquement, un opérateur qui appuie sur le bouton d’arrêt d’urgence d’un appareil doit être écouté par le calculateur de manière prioritaire. Une fois l’événement détecté, le programme interrompu est mis en attente et le programme de traitement de l’arrêt d’urgence démarre en un temps garanti. Il peut aussi être nécessaire de faire fonctionner à intervalle régulier un programme : changer l’état d’une lampe pour la faire clignoter par exemple. A tout instant il existe donc des programmes concurrents en attente et un programme qui s’exécute. Le programme en cours d’exécution pouvant être arrêté au profit d’un autre sur l’occurrence d’un événement.

Un système temps réel dispose de trois capacités fondamentales :

  • Observer des événements exogènes ou endogènes : arrivé d’un certain message, modification d’une entrée sur un port parallèle, entrée analogique qui dépasse un seuil, écoulement d’un temps donné…
  • Commuter de programme en fonction de l’événement survenu. Le choix du programme à exécuter est choisi par un algorithme d’ordonnancement
  • Garantir le temps de réponse de la tâche appropriée en cas d’occurrence d’événement

Cette dernière capacité crée la distinction « temps réel » d’un système d’information.

Architecture des systèmes temps réel

De nombreuses architectures de systèmes temps réel existent, mais nous aborderons ici la plus courante en deux couches : L’Operating System Temps Réel (OSTR) et l’application

En ce qui concerne l’Operating System Temps Réel :

  • Le gestionnaire d’interruption permet principalement de définir, masquer, autoriser les interruptions provoquée par des stimulations du système
  • L’ordonnanceur donne la main au programme en fonction de la politique d’allocation qu’il implémente. L’ordonnanceur est généralement appelé après une interruption afin de commuter sur la tâche adéquate
  • Les pilotes de périphériques réalisent les entrées sorties de données et signaux
  • Le gestionnaire de temps réalise les fonctions d’horloge sidérale, les time-out, les signaux périodiques… Il s’appuie sur les timers matériels de la plate-forme
  • Le gestionnaire mémoire qui assure l’allocation et désallocation mémoire
  • Les services de communication intertâches sont des structures comme les queues, sémaphores, lifo…que les programmes utilisent pour échanger des informations

Les services de l’OSTR sont utilisés par l’application, elle-même composée de programmes (tâches) qui attendent d’être lancés par l’ordonnanceur et qui utilisent les autres services de l’OSRT. On dispose donc d’une architecture très classique où l’application appelle les services du système d’exploitation temps réel. Un exemple typique est Xenomai.

De nombreux produits OSTR de ce type existent sur le marché : VxWorks, FreeRTOS, LynxOS…

Donc, rien de bien différent avec ce que l’on trouve dans une machine Unix. Les différences viennent essentiellement de la manière dont on répond aux interruptions, on ordonnance les tâches et on gère les accès concurrents aux ressources partagées. Ces différences font que le système est déterministe ou non dans son temps de réponse. Typiquement, le Garbage collector de Java occupe la CPU sur des périodes inconnues à l’avance et rend imprédictible l’instant de réponse d’un programme Java « ordinaire ». De même des boucles d’attente non interruptibles de l’OS peuvent causer des latences importantes et non déterministes.

Panorama technologique

La  frontière entre système temps réel et système « ordinaire » apparait donc comme ténue sur le plan des principes. Il est alors intéressant de regarder jusqu’où ce constat se traduit sur les technologies disponibles.

L’informatique de gestion s’est particulièrement bien outillée durant les 20 dernières années avec notamment des langages plus sûrs tels que Java et .NET. L’offre Open Source s’est enrichie dans tous les domaines d’application (serveurs d’application, frameworks, bases de données, middlewares…). Ces facilités technologiques ont aussi irrigué le monde de l’informatique industrielle, mais de façon un peu moins visible pour différentes raisons : les plateformes d’exécution sont souvent contraintes en termes de place mémoire et de puissance CPU (prix, poids, volume, consommation électrique…) ; les OS Temps Réels spécifiques dominent le marché à cause de leur adaptation aux besoins, les méthodes de conception s’intéressent de près au temps de réponse.

Avec des technologies logicielles de gestion plus orientées « événement » et le prix des MIPS et des GO de RAM qui baisse continuellement, on observe que ces technologies gourmandes sont de plus en plus utilisées par l’informatique industrielle. Réciproquement, la garantie du service rendu en un temps contraint offre des perspectives intéressantes aux applications de gestion : transactions financières à basse latence (http://www.sun.com/solutions/documents/pdf/fn_lowlatency.pdf), Business Intelligence temps réel (http://en.wikipedia.org/wiki/Real-time_business_intelligence) par exemple.

Ainsi, la convergence technologique de l’informatique de gestion et de l’informatique industrielle progresse grâce : – aux langages de haut niveau qui prennent en compte des contraintes événementielles et de parallélisme, – à la baisse des coûts matériels, – aux performances élevées des plateformes, – à l’énorme librairie logicielle Open Source.

Voici quelques technologies « de gestion » désormais assez matures qui permettent de construire des systèmes temps réels :

  • Linux temps réel : De nombreuses initiatives ont eu lieu sur ce sujet. Nous nous limiterons ici à l’initiative https://rt.wiki.kernel.org/index.php/Main_Page qui est intégrée au projet Linux kernel. Linux Temps Réel est un OSRT
  • Java temps réel : La « JSR 282: RTSJ version 1.1 » jette les bases de Java Temps Réel. L’implémentation de référence de Sun/Oracle est disponible et payante, http://java.sun.com/javase/technologies/realtime/index.jsp, de même pour Jamaica de Aicas http://www.aicas.com/ et Aonix PERC Pico http://www.aonix.com/Hard_Real-Time.html. IBM propose également WebSphere Real Time. Pour l’instant, je ne connais pas d’initiative Open Source sur ce sujet
  • Serveurs d’application temps réel : Une offre formalisée existe sur ce sujet avec WebSphere Real Time d’IBM, des serveurs légers tels que http://barracudaserver.com/, sans oublier les solutions de haute performance telles que Tornado http://www.tornadoweb.org/ qui peuvent prétendre à ce genre d’application. On peut cependant constater que les capacités temps réel dur de ces offres ne sont pas encore démontrées
  • Les frameworks de développement sur Linux temps réel (C, C++, Java) : Citons le framework Xenomai http://www.xenomai.org/ qui aide notamment à la portabilité des applications temps réel en C/C++. En complément de RTSJ, la librairie Javolution http://www.javolution.org/ qui s’affranchit du Garbage collector et permet de rendre les applications beaucoup plus déterministes
  • Les bases de données temps réel (ou presque…) : C’est clairement le sujet en retard du stack technologique « Temps réel ». Quelques initiatives ont été lancées sans résultat réellement convainquant. L’orientation vers des stockages spécifiques reste de rigueur actuellement. On pourra s’intéresser à http://developer.mimer.com/ mais je n’ai pas testé
  • Ethernet temps réel : L’usage d’Ethernet sur les bus industriels est connu depuis une quinzaine d’années (PROFINET RT, SERCOS III, Modbus/TCP…). La gestion de la collision (CSMA/CD) est le point délicat adressé entre autres par Ethernet-Powerlink http://www.ethernet-powerlink.org/ et IEEE 1588 ce qui assure la prédictibilité de la communication

Au niveau de l’application, sa conception s’appuie souvent sur des méthodes et outils spécifiques (ateliers intégrés). On peut noter que l’usage d’UML est adapté pour représenter les contraintes du temps réel et est répandu. Mais ces spécificités se retrouvent pas ou peu dans l’outillage de conception de l’informatique de gestion. Est-ce un frein pour autant ? Non, car comme nous le montrerons, ces bases de convergences sont suffisantes pour concevoir et réaliser des systèmes temps réel de qualité.

Conclusion

Il apparait des opportunités de plus en plus visibles « d’échanges » technologiques et de cross fertilisation entre informatique de gestion et informatique industrielle « temps réel ». De nombreux composants de gestion existent et peuvent être assemblés dans des architectures temps réel industrielles. La possibilité de prendre en compte des contraintes de déterminisme temporel dans les langages de haut niveau est prometteuse. C’est pour cela que nous mettrons en pratique ces idées sur Java Temps Réel dans des prochains posts : Construction de la plate-forme et écriture d’applications.

Un commentaire sur “Technologies de l’informatique de gestion pour les applications temps réel”

  • Article très clair, mais je souhaitais préciser quelques petits détails. Tout d'abord, l'ordonnanceur est appelé exclusivement à la suite d'une interruption. En effet, c'est le seul moyen asynchrone d'action sur un processeur. La commutation de tâche d'un Unix classique se fait en programmant un générateur d'interruption périodique de façon à assurer la survenance d'une interruption. Il existe en réalité une autre méthode d'action asynchrone (selon le processeur), l'exception, laquelle survient lors de l'accès à une ressource non allouée ou requiérant un accès privilégié. Les interruptions et les exceptions sont les 2 éléments principaux concernant la réalisation d'un OS temps réel dur (avec l'ordonnanceur). La seule JVM suffisamment temps réel dur pour daigner s'attaquer à la certification aéronautique, la DO178B, n'est pas un produit Sun, très en retard sur ce point, mais la JVM PERC, laquelle calcule par exemple le temps de "recollection" qui sera nécessaire au GC lors de la construction de l'instance, ce qui permet lors de l'action du GC de pouvoir recollecter "juste ce que l'on peut". Et Xenomai se constitue en fait d'une collection de patches au kernel Linux (un hyperviseur + un OS temps réel) et d'éléments logiciels permettant de passer un processus d'un comportement Linux à un comportement temps réel dur statiquement (un simple LD_LIBRARY_PATH suffit) ou dynamiquement (ce que je n'ai pas testé). L'utilisation d'informatique temps réel pour des transactions bancaires, par exemple, est très fréquente au Royaume-Uni.
    1. Laisser un commentaire

      Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *


      Ce formulaire est protégé par Google Recaptcha