Ubuntu-fr

dylouf

Temps réel dur, Xenomai & Python ?

Bonjour à tous,

Dans le monde de l'automatisme, les langages de programmation (ST, LADDER, ...) sont pauvres par rapport à ce que l'on peut trouver en informatique. Je n'ai jamais vu de notion d'héritage, de polymorphisme comme en POO, dans ce type de langage. Le code est souvent répétitif et l'on programme souvent les mêmes (même en utilisant les blocs fonctions).

Je souhaite donc développer des programmes orientés automatisme (qui se trouve normalement dans un automate Schneider, Siemens, etc), en utilisant un langage OO, en l’occurrence Python. Le code automate se situerai donc dans un ordinateur tournant sur Ubuntu.
En me renseignant, j'ai vu que je pouvais utiliser Xenomai pour obtenir un système temps réel dur. Mais je n'ai jamais vu d'exemple utilisant un programme python (seulement du C).
Le lien entre le pc et les actionneurs/capteurs serai un automate, vide de programme, qui communiquerai en OPC avec le programme python.

Ma question est donc : est-t-il possible pour toute partie opérative, de développer l'intelligence de l'automatisme (avec une contrainte de temps réel dur grâce à Xenomai) dans l'ordinateur avec le langage Python ?

Merci d'avance.

NicoZic56

Re : Temps réel dur, Xenomai & Python ?

Bonjour dylouf.

Je crois que la question est beaucoup plus compliquée que ce que tu penses.
Il faut bien définir la notion de temps réel dur.

- Au niveau du système
Linux (depuis le patch prempt rt) a un ordonnanceur temps-réel. Cela signifie qu'il est possible de scheduler une tâche utilisateur prioritairement par rapport au système.
Néanmoins, Linux n'est pas un OS temps réel dur, car le temps de traitement des interruptions n'est pas garanti; et celui-ci préempte l'exécution de tâches temps réelles.
Techniquement, cela peut créer des latences de l'ordre de la milliseconde (avec un PC moderne, et un hardware propre).
Xenomai propose une solution basée sur un co-kernel. On définit un sous-système temps réel, qui va s'exécuter prioritairement par rapport à linux. La mise en oeuvre n'est pas simple. Seule des tâches prévues pour être temps réel vont pouvoir s'exécuter dans le contexte temps réel de xenomai. Les contraintes sont nombreuses : pas d'allocation mémoire, pas d'accès au système de fichier, pas de concurrence d'accès avec une tâche non temps réel. Ces tâches ne peuvent donc être développées que en C ou C++, mais avec certaines précautions : par exemple, il ne faut pas utiliser les chaines de caractères C++ ou la STL, celles-ci provoquant des allocations mémoires. Néanmoins, il est possible d'utiliser l'héritage. (Les puristes disent même que le polymorphisme n'est pas strictement temps réel à cause du temps passé à résoudre la virtualité).
Il faut également que l'applicatif se base pour ses entrées sorties uniquement sur des drivers xenomai.
Voila donc pour Xenomai. En bref, il ne suffit pas d'installer Xenomai pour que, comme par magie le système devienne temps réel.
Il faut utiliser Xenomai pour régler lorsque le temps de réponse souhaité est largement inférieur à la millisecondes, c'est à dire inférieur au temps de latence des interruptions.

- Au niveau des drivers
Sauf erreur de ma part, OPC c'est un protocole windows non ?
Déjà, le bus de communication doit être temps réel. Ce n'est pas le cas de l'ethernet classique, il faut de l'etherat, powerlink....
Ensuite la couche de protocole doit aussi être temps réelle et s'interfacer avec le driver.

- Au niveau de l'applicatif
Python est un langage objet interprété.
Bien que très performant, il s'agit d'un interpréteur : le code est généré à la volée, ce qui n'est pas temps réel.
Python est vraiment objet, cela a des implications sur la gestion de la mémoire : il n'est pas possible de manipuler des objets sans allocations mémoires.
Il est donc tout à fait exclu d'envisager une tâche temps-réel dur (xenomai) avec python (et puis cela n'a pas de sens, l'interprếteur python va avoir des latences largement supérieures à la millisecondes).
Je pense qu'il doit être possible de scheduler une tâche linux temps réel développé avec python, mais il faudrait vérifier.

Il faut que vous définissiez votre exigence en terme de temps de réponse sur le système, et que tout le système soit dimensionné en conséquence :
- puissance CPU nécessaire
- bande passante sur le réseau nécessaire
- latences maximales : sur le bus de communication et sur le système informatique.

Mon avis sur la question.
Python, sur un linux standard peut être à mon avis une bonne solution pour piloter des choses assez simple sur des automates dispersés avec un temps de réponse de l'ordre de la seconde. Aller au-delà avec cette architecture me paraît risqué.
Il est par exemple illusoire de vouloir réaliser un asservissement de moteur à distance.

Ensuite, moi je verrais plutôt le programme python comme superviseur des automates : IHM et éventuellement échange d'informations non temps réels entre les automates.

---

============
"Il n'y a que deux sortes de langages de programmation: ceux dont les gens disent toujours du mal et ceux que personne n'utilise."
Bjarne Stroustrup

dylouf

Re : Temps réel dur, Xenomai & Python ?

Merci pour cette réponse très intéressante.

Le système concerné n'a pas besoin d'un temps de réponse très rapide. Les tâches les plus compliquées (qui ne le sont pas) sont des simples régulations de température, qui tournent très bien sur des cycles à 20ms.

Mais au vu de ta réponse, il me semble que la meilleure des solutions qui reste, est de continuer à développer l'automatisme dans l'automate. Il y a encore trop de contraintes à gérer. On m'a parlé de notions OO qui existerait dans le dernier logiciel Codesys. Peut être que je peux me tourner là dessus, mais nous travaillons normalement avec B&R automation.

Sauf erreur de ma part, OPC c'est un protocole windows non ?

OPC-DA est un protocole windows, mais OPC-UA est multi-plateforme.

En tout cas merci, c'est le genre de réponse que je souhaitais lire.

Dernière modification par dylouf (Le 12/08/2013, à 07:16)