Discussion :

[icescream1c]

Bonjour!

J'ai un logiciel "temps réel" en C embarqué sur un microcontroleur (j'ai aussi les source sur pc ). Je souhaite connaitre le temps d'utilisation processeur dans le pire des cas d'execution.
Je sais qu'il existe une analyse WCET (worst case execution time) qui est faite à la main. Mais je voudrai savoir si des logiciels sont capable d'effectuer cette analyse?
Et, à defaut, connaissez vous un bon tutoriel sur la méthode d'analyse du pire des cas d'execution, qui me permettrai déjà de définir quel est ce pire des cas?

[souviron34]

vu de l'extérieur ça m'étonnerais beaucoup...

En effet, il faut définir "worst-case"..

Est-ce que c'est fonction :

• du nombre de processus qui tournent ?
• du type des processus qui tournent ?
• de la mémoire ?
• du type des données ?
• d'une interaction avec du hardware (vitesse de bus par exemple) ?
• des algos utilisés ?

Sans plus de précisions, on ne peut en dire plus...

[icescream1c]

En fait je parle de temps réel, mais ce n'est simplement qu'un processus qui est appelé toutes les secondes. Ce processus appel lui meme des fonctions (toujours le meme nombre).
Je pense qu'il faut analyser chacune de ces fonctions pour déterminer les conditions qui vont déclencher le pire des temps de traitement.
A mon avis il y a une analyse à faire sur les algos de chaque fonctions.

[souviron34]

je ré-itère...

Bien poser le problème est le résoudre à 50%.

Qu'est-ce que Worst-Case pour toi ????



Qu'est-ce qui bloquerait ??

Des entrèe-sorties ? de la mémoire ? de la vitesse ? autre ?

[bizulk]

Comme on te le fait comprendre ici, il n'y a aucun logiciel qui fera ce type de travail à ta place.
Avec cela un logiciel embarqué RT est souvent très spécifique et dépendant de son environnement.
Donc tu dois le soumettre à une analyse de ce qu'il exécute sachant que :
_ les accès à des périphériques externe (ex stockage) peuvent être très couteux en temps (mais peut-être pas en charge)
_ les calculs par itération (que seul toi peux connaitre la profondeur) peuvent être couteux en charge mais pas en temps (relativement à ce que j'ai dit au dessus).
...
_ la gestion des interruptions rapprochées et associées a des allocations de ressources sont couteuses en tout
....

[zougagh]

selon mes connaissances y a un logiciel qui s'appeler Bound-T qui permet de calculer le WCET
cordialement

[souviron34]

selon mes connaissances y a un logiciel qui s'appeler Bound-T qui permet de calculer le WCET
cordialement

voir plus haut... qu'est-ce que c'est qua sa définition de Worst Case ??

Voume de données ? nombre de connexions ? temps de calcul ? nombre de fichiers ou de périphériques ? temps d'accès ? Bug dans une partie ? Rupture d'une liaison ?

Je ré-itère : tout dépend de l'appli et de ce qui pour elle est considéré "worst-case" ..

[cr_31]

Bonjour,

Il me semble que la question portait sur le temps d'exécution pire cas (ou WCET). En tant que membre d'une équipe de recherche (équipe TRACES de l'Institut de Recherche en Informatique de Toulouse), je peux apporter quelques éléments sur cette question.

Tout d'abord, ce qu'on appelle habituellement WCET, c'est le temps d'exécution maximum du programme de la tâche étant entendu que ce qui fait varier le temps d'exécution, ce sont les données en entrée (calculer un WCET suppose donc qu'on connaît le matériel cible). En l'état actuel des choses, on ne sait pas prendre en compte l'impact d'événements extérieurs à la tâche qui ne sont pas connus (par exemple : partage de ressources avec d'autres tâches, conflits sur le bus avec des transferts DMA, etc.) [ça paraît très restrictif, mais on n'est pas Madame Soleil !]

Les méthodes utilisées dépendent de la fiabilité attendue pour le résultat : si l'application n'est pas critique, des techniques basées sur des mesures combinées à une analyse statique du code peuvent être suffisante. Il existe un outil commercial qui fait ça, produit par une boîte anglaise (www.rapitasystems.com). Mais ces techniques ne permettent pas de garantir absolument que le WCET calculé est bien une borne supérieure du temps d'exécution.
Si on veut un résultat absolument garanti (ce qui, à mon sens, ne concerne pas tant d'applis que ça), il faut utiliser des méthodes d'analyse statique "pures". Il y a quelques équipes en Europe qui travaillent sur ces aspects qui recouvrent : analyse de flot (calcul de bornes de boucles, etc) et analyse temporelle (calcul des temps d'exécution pire cas de morceaux de code, typiquement des blocs de base, en prenant en compte l'architecture du processeur, la présence ou non de caches, de prédicteur de branchement, etc.).
Je peux donner des pointeurs (articles, contacts) si c'est utile. Ces techniques sont implémentées dans différents outils, académiques (libres) ou commercialisés (ex : outil AbsInt - www.absint.com, qui est certainement le plus abouti de tous ... mais qui est payant).

Dans notre équipe, nous développons une bibliothèque dédiée au calcul de WCET (www.otawa.fr) qui est téléchargeable et utilisable librement (licence LGPL). Nous aimons bien nous frotter à des codes "réels" pour détecter les points à améliorer, donc ne pas hésiter à nous en soumettre ;-)

Voilà. Je peux développer ou fournir des références si cela peut être utile.

Christine

[souviron34]

Merci des pointeurs et des explications

Je pense qu'il faut analyser chacune de ces fonctions pour déterminer les conditions qui vont déclencher le pire des temps de traitement.
A mon avis il y a une analyse à faire sur les algos de chaque fonctions.

Absolument.. Et donc, sans aller du tout à l'encontre du post ci-dessus, tu peux aussi porter ton code sur une plateforme "normale" et faire un profiling (voir gprof).