FR 2919083 A1 20090123 FR 0756590 A 20070718 Procédé de gestion de l'exécution d'une architecture logicielle d'un circuit de radiocommunication à fréquence processeur constante, produit programme d'ordinateur et circuit correspondants. 1. DOMAINE DE L'INVENTION Le domaine de l'invention est celui des dispositifs de radiocommunication. Par dispositifs de radiocommunication (aussi appelés terminaux de radiocommunication ou terminaux sans-fil), on entend tous dispositifs ou moyens capables d'échanger des signaux à l'aide d'un système de radiocommunication, implantés par exemple dans des machines ou des véhicules (marchés M2M, pour Machine to Machine , et automobile). Le domaine d'application de l'invention couvre toute technologie de radiocommunication cellulaire (GSM, 3G, 4G, DECT, CDMA, Wi-Max...) ou point à point (Wifi, Bluetooth, Zigbee...). Plus précisément, l'invention concerne une technique de gestion de l'exécution par un processeur d'une architecture logicielle comprise dans un circuit de radiocommunication, dans le cas où cette architecture logicielle comprend une pile logicielle de radiocommunication supportant la capacité d'exécution d'au moins une application client, c'est-à-dire du code tierce par comparaison avec le code de l'application principale de radiocommunication (firmware) qui est également exécutée par le processeur et gère la pile logicielle de radiocommunication (pile GSM par exemple). L'invention s'applique notamment, mais non exclusivement, dans le cas où le circuit de radiocommunication est un module électronique de radiocommunication destiné à être intégré à un dispositif de radiocommunication. Il s'agit par exemple d'un module de la famille WMP , Quick ou Plug and Play (marques déposées) de la société WAVECOM (déposante de la présente demande de brevet). La société WAVECOM a en effet depuis plusieurs années proposé une approche palliant un certain nombre d'inconvénients en regroupant dans un module unique (appelé module électronique de radiocommunication), tout ou au moins la plupart des fonctions d'un dispositif de radiocommunication numérique. Un tel module se présente sous la forme d'un boîtier unique, préférentiellement blindé, que les fabricants de dispositifs peuvent implanter directement, sans devoir prendre en compte une multitude de composants. Ce module (encore appelé parfois macro composant ) est en effet formé d'un regroupement de plusieurs composants sur un substrat, de façon à être implanté sous la forme d'un unique élément. Il comprend les composants (notamment un processeur, des mémoires, et des logiciels) essentiels nécessaires au fonctionnement d'un dispositif de radiocommunication utilisant des fréquences radioélectriques. Il n'y a donc plus d'étapes complexes de conception du design, et de validation de celui-ci. Il suffit de réserver la place nécessaire au module. Un tel module permet donc d'intégrer facilement, rapidement et de façon optimisée l'ensemble des composants dans des terminaux sans- fil (téléphones portables, modems, ou tout autre dispositif exploitant un standard sans fil). Dans une variante d'application de l'invention, le circuit de radiocommunication n'est pas un module de radiocommunication au sens précité mais un circuit imprimé compris dans un dispositif de radiocommunication et sur lequel sont directement implantés un ensemble de composants électroniques ayant pour but d'assurer les différentes fonctions de radiocommunication nécessaires, depuis la réception d'un signal RF jusqu'à la génération d'un signal audible (dans le cas d'un radio-téléphone), et inversement. 2. ART ANTÉRIEUR On connaît dans l'art antérieur des circuits de radiocommunication permettant d'embarquer des applications client (aussi appelées applicatifs client ). Le circuit de radiocommunication est par exemple un module électronique de radiocommunication de la famille WISMO (marque déposée) mettant en oeuvre le concept Open AT (marque déposée) de la société WAVECOM (déposante de la présente demande de brevet), offrant un environnement d'exécution d'au moins un applicatif client embarqué. Il est clair que d'autres environnements d'exécution d'un applicatif client embarqué peuvent être utilisés, tels que Java (marque déposée) ou Python (marque déposée). Un des problèmes des modules qui fournissent des capacités pour embarquer les applications de leurs clients est qu'aucune garantie sur la puissance de calcul disponible n'est fournie au client de manière optimisée. En effet, la fonction (pile logicielle) de radiocommunication (téléphonie cellulaire GSM ou CDMA par exemple) demande, en fonction de son état, une puissance de calcul très différente. La puissance de calcul de la plateforme (sur laquelle s' exécute la pile de radiocommunication et l'applicatif client) étant finie à une fréquence donnée, et l'applicatif client ayant une priorité inférieure à celle de la pile, cet applicatif client n'aura que la partie de puissance de calcul restante pour s'exécuter. Cela peut poser des problèmes lorsque l'applicatif client a des calculs à faire et/ou des opérations à mener en un temps donné pour ne pas perdre des informations (notamment lorsque celles-ci sont remontées de manière temps réel). Par exemple, lorsque l'applicatif client acquiert des valeurs en temps réel (par exemple toutes les 10 millisecondes), il doit les traiter (par exemple, calcul d'une moyenne, d'un écart type...) et les stocker en mémoire non volatile pour ne pas les perdre. Pour ce faire, il doit donc effectuer ce traitement en un temps donné (dans notre exemple inférieur à 10 millisecondes) sinon au bout d'un moment il n'y aura plus assez de mémoire pour stocker les valeurs brutes (avant calcul), et certaines seront perdues, ce qui peut être très problématique et remettre en cause l'intérêt du système au global. La difficulté est que la pile GSM a besoin d'une puissance de calcul variable en fonction des différents états dans lesquels elle se trouve : - éteinte (déconnecté) : le module n'est pas connecté au réseau GSM/GPRS et donc ne peut pas passer de communication ; - en recherche de réseau : le module a perdu la synchronisation avec le réseau (démarrage / hors couverture....) mais est en recherche de réseau sur lequel se synchroniser ; - au repos (idle) : le module est connecté au réseau GSM/GPRS. Il est donc dans la capacité de recevoir, passer des appels, envoyer/recevoir des SMS, initier une connexion GPRS mais n'utilise aucune de ces possibilités ; - en appel voix ; - en appel données ; - en transfert de données (GPRS, EDGE, 3G, HSDPA, HSUPA...) ; - en envoi/réception de messages courts (SMS) ; - en envoi/réception de données de service supplémentaires (USSD). Or les systèmes embarqués possèdent en règle générale au moins un mode de fonctionnement sur batterie et doivent donc gérer de manière fine leur consommation en terme de courant. Ainsi, surdimensionner la puissance de calcul d'un système embarqué comportant une pile GSM comme solution pour s'affranchir des pics de puissance de calcul consommée par la pile GSM n'est pas une solution viable pour un système embarqué autonome puisqu'elle engendre un surcoût important pour la solution globale (la notion de puissance de calcul optimale est donc primordiale lors de la conception d'un système embarqué pour ne pas engendrer de surcoûts rédhibitoires). Le point le plus important est qu'il est impossible pour l'applicatif client de connaître en avance de phase les besoins en terme de puissance de la pile de protocole. Par exemple, lorsque l'on recherche un réseau, il n'y a pas de moyen pour l'applicatif client pour prédire le moment auquel le système va le retrouver et donc la charge de puissance de calcul nécessaire à la synchronisation avec le réseau cellulaire et par voie de conséquence la puissance de calcul qui lui fera défaut lorsque cette synchronisation s'opérera, ni même le moment auquel cette puissance de calcul fera défaut. De la même manière, la perte de synchronisation réseau (par exemple lorsque les cellules GSM sont trop loin pour pouvoir être détectées par le système embarqué) entraîne une demande de puissance de calcul supplémentaire de la part de la pile de protocole et pourrait donc impacter la puissance de calcul disponible pour l'applicatif client pendant la resynchronisation réseau, avec les dangers que cela comporte en terme de perte de données si elles ne sont pas traitées suffisamment rapidement. Ainsi, dans un système embarqué comportant une pile GSM/GPRS, la majorité des évènements traités par la pile et impactant la puissance de calcul laissée libre à l'applicatif client ne peuvent être prédits par l'applicatif client, et peuvent ainsi impacter le bon fonctionnement du système au global. En résumé, l'exécution d'une pile de radiocommunication (par exemple une pile GSM/GPRS) nécessite une puissance de calcul importante et variable suivant les états de cette pile, sous peine de perdre la synchronisation au réseau (et donc de ne plus être capable de passer/recevoir des appels, envoyer/recevoir des SMS, USSD...). Selon une première technique connue, ne sachant pas quel impact l'exécution des applicatifs client aura sur le bon fonctionnement de leur propre pile de radiocommunication (pile GSM/GPRS par exemple), et donc sur le bon fonctionnement global de leur produit, les fabricants de modules de radiocommunication (notamment à destination des marchés M2M et automobile) ne fournissent pas à leurs clients la capacité de garantir une valeur de puissance de calcul définie et optimisée quel que soit l'état de la pile de radiocommunication. Donc à puissance de calcul (aussi appelée puissance CPU) constante (c'est-à-dire à fréquence d'horloge du processeur constante) la puissance CPU allouée à l'applicatif client dépend de l'activité de la pile de radiocommunication. Ceci peut poser problème lorsque l'applicatif client demande plus de puissance de calcul qu'il ne lui est alloué. Dans le meilleur des cas, l'applicatif client sera plus lent. Dans le pire des cas, il sera non fonctionnel. Dans les deux cas, lorsque la situation se produit sur le terrain, les conséquences peuvent en être extrêmement dommageables/importantes/coûteuses. Par exemple, à 104 MHz, une plateforme standard fournit 104 MIPS de puissance CPU. Si on suppose par exemple que la pile GSM/GPRS a besoin lors d'un transfert GPRS (demandé par l'applicatif client) de 32 MIPS pour s'exécuter, l'applicatif client peut alors bénéficier des 72 MIPS restants. Mais si l'applicatif a besoin de 85 MIPS pour s'exécuter normalement, il lui manquera 13 MIPS. Cette situation peut amener à un dysfonctionnement ou à l'arrêt du fonctionnement de l'applicatif client. Selon une seconde technique connue, les fournisseurs de pile de radiocommunication (pile GSM/GPRS par exemple) fournissent un code qui, compilé et exécuté sur une plateforme associée, permet de passer/recevoir des appels... Ces fournisseurs de solutions logicielles permettent ainsi à leurs clients d'exécuter du code à tous niveaux, code qui pourrait donc bénéficier d'une puissance de calcul définie et optimisée quel que soit l'état de la pile de radiocommunication. Mais en aucun cas ils ne garantissent alors que la pile de radiocommunication fonctionnera correctement. En outre, ceci implique une très grande complexité de conception de l'application client et donc une très forte expertise dans le domaine des radiocommunications (GSM/GPRS par exemple). Pour ces raisons, cette seconde technique alternative est difficilement utilisable, notamment par les clients des marchés M2M et à plus forte raison par toute personne non experte à la fois dans le domaine d'application finale du produit global et dans le domaine des télécommunications, notamment des technologies GSM/GPRS. De ce fait, la majorité des architectures logicielles permettant d'embarquer du code externe sur une plateforme de radiocommunication ( Wireless platform en anglais) sont conformes à la première technique connue (garantie du bon fonctionnement de la pile GSM/GPRS, mais aucune garantie sur la puissance de calcul fournie à]: applicatif client. 3. OBJECTIFS DE L'INVENTION L'invention, dans au moins un mode de réalisation, a notamment pour objectif de pallier ces différents inconvénients de l'état de la technique. Plus précisément, l'un des objectifs de la présente invention, dans au moins un mode de réalisation, est de fournir une technique de gestion de l'exécution par un processeur d'une architecture logicielle comprise dans un circuit de radiocommunication, dans le cas où cette architecture logicielle comprend une pile logicielle de radiocommunication et au moins une application client, cette technique permettant, pour une fréquence donnée du processeur, de garantir une certaine puissance de calcul à ladite au moins une application client, quelle que soit l'activité de la pile logicielle de radiocommunication. En garantissant une certaine puissance de calcul à ladite au moins une application client, le client a moins, voire plus du tout, à se soucier de l'état de la pile de radiocommunication pour concevoir et définir son application (c'est-à-dire développer le code source de cette application). Si le bridage de la pile est suffisant quel que soit l'état de la pile, le client peut même définir son application de la même manière, qu'elle soit destinée à être exécutée sur un processeur d'un circuit sans pile logicielle de radiocommunication ou sur un processeur un peu plus puissant d'un circuit (de radiocommunication) comportant de manière native une pile de radiocommunication. L'invention a également pour objectif, dans au moins un mode de réalisation, de fournir une telle technique qui soit simple à mettre en oeuvre et peu coûteuse. 4. EXPOSÉ DE L'INVENTION Dans un mode de réalisation particulier de l'invention, il est proposé un procédé de gestion de l'exécution par un processeur d'une architecture logicielle comprise dans un circuit de radiocommunication, ladite architecture logicielle comprenant une pile logicielle de radiocommunication et au moins une application client. Ce procédé comprend les étapes suivantes, pour une fréquence donnée dudit processeur : a) obtention d'une première puissance de calcul associée à ladite pile ; b) obtention d'une deuxième puissance de calcul associée à ladite au moins une application client ; c) si la somme desdites première et deuxième puissances de calcul est supérieure ou égale à un seuil prédéterminé, bridage d'au moins une fonctionnalité de ladite pile, pour libérer de la puissance de calcul pour ladite au moins une application client. Le principe général de ce mode de réalisation particulier consiste donc à brider (c'est-à-dire limiter) de façon automatique certaine(s) fonctionnalité(s) de la pile de radiocommunication pour pouvoir libérer de la puissance processeur (puissance CPU) allouable à ladite au moins une application client. Ainsi, on optimise la puissance de calcul fournie à ladite au moins une application client, et on facilite le développement par le client de son ou ses applications, puisque celle(s)-ci peu(ven)t être moins complexe(s) puisque moins ou pas du tout dépendante(s) de l'état de la pile de radiocommunication. De façon avantageuse : 80%*M S 100%*M, avec S ledit seuil et M la puissance de calcul du processeur à ladite fréquence donnée dudit processeur. Avantageusement, la première puissance de calcul associée à la pile est une puissance prise ou demandée par la pile, et la deuxième puissance de calcul associée à ladite au moins une application client est une puissance prise ou demandée par ladite au moins une application client. Par puissance de calcul demandée par une entité (pile ou application client), on entend la puissance de calcul que cette entité veut se voir réserver. Par puissance de calcul prise par une entité, on entend la puissance de calcul réellement utilisée par cette entité. Pour entité donnée et à un instant donné, la puissance de calcul demandée et la puissance de calcul prise par cette entité peuvent donc être différentes. Par exemple, l'application client peut demander une puissance de calcul de 85 MIPS pendant une plage temporelle donnée, mais ne prendre qu'une puissance de 80 MIPS à un instant donné de cette plage temporelle. La prise en compte des seules puissances de calcul prises permet d'obtenir une gestion plus fine du temps processeur et donc d'optimiser le bridage (on évite de brider inutilement certaine(s) fonctionnalité(s) de la pile). La prise en compte des seules puissances de calcul demandées permet de simplifier la gestion du temps processeur, mais l'optimisation du bridage est moindre que dans le cas précédent. De façon avantageuse, ledit procédé comprend une étape de définition d'au moins deux niveaux de bridage, et en ce que lesdites étapes a), b) et c) sont effectuées de manière itérative jusqu'à ce que ladite somme desdites première et deuxième puissances de calcul soit inférieure audit seuil, chaque itération étant associée à un niveau de bridage inférieur au niveau de bridage associé à l'itération précédente. En procédant par itération, on optimise le bridage. Plus le nombre de niveaux de bridage est élevé, plus la granularité du bridage est fine. Avantageusement, ladite étape c) de bridage aboutit à un niveau de bridage courant inférieur ou égal à un niveau de bridage maximal déterminé. Ce niveau de bridage maximal peut être défini par le client. La puissance de calcul pouvant être garantie à l'application client est d'autant plus grande que le client accepte un bridage important de la pile de radiocommunication. Selon une caractéristique avantageuse, ledit procédé comprend une étape de modification dynamique, par ladite au moins une application client, dudit niveau de bridage maximal déterminé. Avantageusement, ladite architecture logicielle comprend une application client maître et au moins une application client secondaire, et ladite étape de modification dynamique est effectuée par ladite application client maître. Ainsi, l'application client maître peut à tout moment, pour ses besoins propres, changer la configuration du bridage (c'est-à-dire des dégradations de capacités de calcul acceptées pour la pile de radiocommunication), les applications client secondaires étant tributaire des décisions prises par l'application client maître. De façon avantageuse, le bridage d'une fonctionnalité donnée de ladite pile consiste à effectuer une action appartenant au groupe comprenant : -limitation d'au moins un paramètre de ladite fonctionnalité donnée ; -report d'une exécution de ladite fonctionnalité donnée ; et - annulation d'une exécution de ladite fonctionnalité donnée. Avantageusement, ladite étape de bridage comprend au moins une action de bridage appartenant au groupe comprenant : - limitation du nombre de modes d'envoi et de réception de données pouvant être utilisés ; - réduction du débit d'au moins un des modes d'envoi et de réception de données pouvant être utilisés ; - report de l'envoi d'au moins un message ; - non réponse à au moins un appel entrant ; - limitation d'au moins une des fonctionnalités de ladite pile liées à la signalisation, à l'enregistrement sur le réseau et à la gestion de la mobilité, avec un débit de données nul ou réduit. Cette liste n'est pas exhaustive. Selon une caractéristique avantageuse, ladite architecture logicielle comprend une application de gestion d'au moins un périphérique, et ladite étape de bridage d'au moins une fonctionnalité de la pile est complétée ou au moins partiellement remplacée par une étape de bridage d'au moins une fonctionnalité de ladite application de gestion d'au moins un périphérique. On considère dans ce cas que la gestion de périphériques n'est pas liée à la gestion de la pile de radiocommunication à proprement parler. Avantageusement, ledit circuit est un module électronique de radiocommunication destiné à être intégré à un dispositif de radiocommunication. De façon avantageuse, ledit procédé est mis en oeuvre dans une application principale qui, quand elle est exécutée par ledit processeur, gère ladite pile logicielle de radiocommunication et offre un environnement d'exécution de ladite au moins une application client. Dans un autre mode de réalisation, l'invention concerne un produit programme d'ordinateur téléchargeable depuis un réseau de communication et/ou enregistré sur un support lisible par ordinateur et/ou exécutable par un processeur, ledit produit programme d'ordinateur comprenant des instructions de code de programme pour l'exécution des étapes du procédé précité, lorsque ledit programme est exécuté sur un ordinateur. Dans un autre mode de réalisation, l'invention concerne un circuit de radiocommunication, comprenant un processeur exécutant une architecture logicielle comprenant une pile logicielle de radiocommunication et au moins une application client. Ce circuit comprend : - des moyens d'obtention d'une première puissance de calcul associée à ladite pile ; -des moyens d'obtention d'une deuxième puissance de calcul associée à ladite au moins une application client ; - des moyens de comparaison de la somme desdites première et deuxième puissances de calcul avec un seuil prédéterminé ; - des moyens de bridage d'au moins une fonctionnalité de ladite pile, pour libérer de la puissance de calcul pour ladite au moins une application client, lesdits moyens de bridage étant activés si lesdits moyens de comparaison détectent que la somme desdites première et deuxième puissances de calcul est supérieure ou égale audit seuil prédéterminé. Plus généralement, le circuit de radiocommunication selon l'invention comprend des moyens de mise en oeuvre du procédé tel que décrit précédemment (dans l'un quelconque de ses différents modes de réalisation). 5. LISTE DES FIGURES D'autres caractéristiques et avantages de modes de réalisation de l'invention apparaîtront à la lecture de la description suivante, donnée à titre d'exemple indicatif et non limitatif (tous les modes de réalisation de l'invention ne sont pas limités aux caractéristiques et avantages des modes de réalisation décrits ci-après), et des dessins annexés, dans lesquels : - la figure 1 présente une architecture logicielle connue, d'une pile GSM supportant la capacité d'exécution d'au moins une application client ; - la figure 2 présente un mode de réalisation particulier d'un dispositif de radiocommunication selon l'invention, comprenant un module de radiocommunication possédant une architecture logicielle selon la figure 1 ; et - la figure 3 présente un organigramme d'un mode de réalisation particulier du procédé selon l'invention. 6. DESCRIPTION DÉTAILLÉE On présente maintenant, en relation avec la figure 1, une architecture logicielle connue, d'une pile GSM supportant la capacité d'exécution d'une application client. Cette architecture logicielle comprend typiquement une pile logicielle de radiocommunication (dans l'exemple de la figure 1, une pile GSM, ou GSM Stack en anglais) comprenant : - un gestionnaire d'interruptions de radiocommunication 1 ( GSM Stack IT Handler ), qui fournit des services de lien physique ( Physical Link Services ) et assure la synchronisation avec le réseau GSM. Il correspond à la couche physique GSM ; - un ensemble de tâches 2 spécifiques à la pile GSM ( GSM Stack Tasks L1-L3 ), réparties en couches (L1 à L3), et qui fournissent un service de contrôle et lien logique ( Logical Link and Control Service ). Dans la norme GSM, il correspond à L1 / L2 / L3, RR / LAPD / MM / CCRLC / MAC / LLC / SNDCP / SM ; - un ensemble de tâches 3 liées à des commandes AT ( GSM AT Commands Task ), qui fournissent un service de contrôle de la pile GSM. Dans la norme GSM, il correspond à la couche Application ; et - une tâche 4 dite Idle Task ou Tâche de fond qui s'exécute lorsqu'aucune autre tâche ne demande la ressource CPU. Cette architecture logicielle comprend en outre au moins une application client 5 (dans cet exemple une unique application Open AT ), comprenant un ensemble de tâches client. Au sein de la pile GSM, cette application client 5 est positionnée entre l'ensemble de tâches 3 liées à des commandes AT et la tâche de fond 4. La flèche référencée 6 indique un axe de temps de réaction indicatif (depuis environ 1 ms jusqu'à environ 10 ms). La flèche référencée 7 indique un axe niveau de priorité (depuis la tâche de fond 4, qui est la moins prioritaire, jusqu'au gestionnaire d'interruptions de radiocommunication 1, qui est le plus prioritaire). Cette architecture logicielle peut également être décomposée en deux domaines : - un domaine 8 de gestion des interruptions, dans lequel est compris le gestionnaire d'interruptions de radiocommunication 1 ; et - un domaine 9 de gestion des tâches, dans lequel sont comprises toutes les tâches précitées (tâches 2 spécifiques à la pile GSM, tâches 3 liées à des commandes AT, tâche de fond 4 et tâches de l'application client 5). Ainsi, avec cette structure connue, toute application cliente peut être exécutée par le module tout en garantissant le bon fonctionnement de la pile GSM/GPRS. Néanmoins aucune garantie sur la puissance de calcul optimisée fournie à l'applicatif client n'est fournie. Dans l'exemple illustré sur la figure 1, l'architecture logicielle comprend une seule application client 5. Il est clair cependant que l'homme du métier peut aisément transposer cet exemple au cas où l'architecture logicielle comprend une pile GSM et plusieurs applications client (chaque application client comprenant un ensemble de tâches client et étant positionnée, au sein de la pile GSM, entre l'ensemble de tâches 3 liées à des commandes AT et la tâche de fond 4). On présente maintenant, en relation avec la figure 2, un mode de réalisation particulier d'un dispositif de radiocommunication selon l'invention. Il comprend une carte-mère 41 sur laquelle est implanté un module de radiocommunication 44 possédant une architecture logicielle selon la figure 1, obtenue par exécution par un processeur 43 (et une mémoire RAM 46) de : - une application principale de radiocommunication 42 comprenant un bloc logiciel 421 qui gère la pile logicielle de radiocommunication (pile GSM par exemple) et un bloc logiciel 422 qui permet la mise en oeuvre du procédé de l'invention (permettant de gérer l'exécution de l'architecture logicielle par le processeur) ; et - une application client 45. Il est important de noter que le procédé selon l'invention, qui est embarqué dans le module de radiocommunication 44, ne perturbe en aucune façon le réseau de radiocommunication (réseau cellulaire). Sa mise en oeuvre reste conforme du point de vue réseau aux recommandations ETSI/3GPP. L'application principale de radiocommunication 42 et l'application client 45 sont par exemple stockées dans une mémoire morte 47 (ROM par exemple) et, à l'initialisation du module de radiocommunication 44, les instructions de code de ces applications sont chargées dans une mémoire vive 46 (RAM par exemple) avant d'être exécutées par le processeur 43. Par ailleurs, le module de radiocommunication 44 est relié à un connecteur 26 de dispositifs externes, via des interfaces d'Entrées/Sorties à usages divers (GPIOs) 27, des interfaces série de type SPI (Serial Peripheral Interface) (SPI1, SPI2) 28 et 29, une interface USB 210 et une liaison véhiculant des interruptions (IT) 211. On présente maintenant, en relation avec la figure 3, un mode de réalisation particulier du procédé selon l'invention. Dans une étape El, on obtient une première puissance de calcul P1 associée à la pile 421, et dans une étape E2, on obtient une deuxième puissance de calcul P2 associée à l'application client 45. Les première et deuxième puissances de calcul P1 et P2 sont soit cellesdemandées par la pile et l'application client, soit celles réellement prises par ces dernières. Elles sont par exemple obtenues grâce au système d'exploitation (OS, pour Operating System en anglais) qui gère le temps processeur (aussi appelé temps CPU). Les techniques d'obtention de telles informations de puissance de calcul, grâce à un système d'exploitation, sont bien connues de l'homme du métier et ne nécessitent donc pas d'explication détaillée. Dans une étape E3, on détecte si la somme des première et deuxième puissances de calcul (P1 + P2) est supérieure ou égale à un seuil prédéterminé S. Ce seuil est par exemple tel que : 80%*M S 100%*M, avec M la puissance de calcul du processeur à la fréquence du processeur à laquelle on se place. Les étapes El à E3 sont par exemple effectuées à des instants prédéterminés (par exemple selon un cycle de période prédéterminée) et/ou à des instants de réalisation d'évènements prédéterminés, tels que par exemple : - quand la pile s'apprête à passer dans un nouvel état nécessitant une puissance de calcul supérieure de celle utilisée dans l'état courant, - quand la puissance de calcul demandée par l'application client est modifiée, - quand la configuration du bridage a été modifiée, En cas de détection positive à l'étape E3, on passe à l'étape E4, au cours de laquelle on effectue un bridage d'au moins une fonctionnalité de la pile (on agit de préférence sur des fonctionnalités qui ont des demandes importantes de puissance CPU), pour libérer de la puissance de calcul pour l'application client. A l'issue de l'étape E4, on revient à l'étape El. En cas de détection négative à l'étape E3, on revient directement à l'étape El. Optionnellement, plusieurs niveaux de bridage sont définis. Les étapes E1, E2, E3 et E4 sont effectuées de manière itérative, tant que le critère d'arrêt P1 + P2 Dans un mode de réalisation particulier, ce niveau de bridage maximal déterminé est modifiable de façon dynamique par l'application client. Un mécanisme complémentaire de débridage peut être prévu. Par exemple, à l'issue de l'étape E4, on effectue des étapes identiques aux étapes El et E2, puis une étape de comparaison du type : P1 + P2 REVENDICATIONS 1. Procédé de gestion de l'exécution par un processeur d'une architecture logicielle comprise dans un circuit de radiocommunication (44), ladite architecture logicielle comprenant une pile logicielle de radiocommunication (2) et au moins une application client (5), caractérisé en ce qu'il comprend les étapes suivantes, pour une fréquence donnée dudit processeur : a) obtention (El) d'une première puissance de calcul associée à ladite pile ; b) obtention (E2) d'une deuxième puissance de calcul associée à ladite au moins une application client ; c) si la somme desdites première et deuxième puissances de calcul est supérieure ou égale à un seuil prédéterminé, bridage (E4) d'au moins une fonctionnalité de ladite pile, pour libérer de la puissance de calcul pour ladite au moins une application client. 2. Procédé selon la revendication 1, caractérisé en ce que : 80%*M S 100%*M, avec S ledit seuil et M la puissance de calcul du processeur à ladite fréquence donnée dudit processeur. 3. Procédé selon l'une quelconque des revendications 1 et 2, caractérisé en ce que la première puissance de calcul associée à la pile est une puissance prise ou demandée par la pile, et en ce que la deuxième puissance de calcul associée à ladite au moins une application client est une puissance prise ou demandée par ladite au moins une application client. 4. Procédé selon l'une quelconque des revendications 1 à 3, caractérisé en ce qu'il comprend une étape de définition d'au moins deux niveaux de bridage, et en ce que lesdites étapes a), b) et c) sont effectuées de manière itérative jusqu'à ce que ladite somme desdites première et deuxième puissances de calcul soit inférieure audit seuil, chaque itération étant associée à un niveau de bridage inférieur au niveau de bridage associé à l'itération précédente. 5. Procédé selon l'une quelconque des revendications 1 à 4, caractérisé en ce que ladite étape c) de bridage aboutit à un niveau de bridage courant inférieur ou égal à un niveau de bridage maximal déterminé. 6. Procédé selon la revendication 5, caractérisé en ce qu'il comprend une étape de modification dynamique, par ladite au moins une application client, dudit niveau de bridage maximal déterminé. 7. Procédé selon la revendication 6, caractérisé en ce que ladite architecture logicielle comprend une application client maître et au moins une application client secondaire, et en ce que ladite étape de modification dynamique est effectuée par ladite application client maître. 8. Procédé selon l'une quelconque des revendications 1 à 7, caractérisé en ce que le bridage d'une fonctionnalité donnée de ladite pile consiste à effectuer une action appartenant au groupe comprenant : - limitation d'au moins un paramètre de ladite fonctionnalité donnée ; - report d'une exécution de ladite fonctionnalité donnée ; et - annulation d'une exécution de ladite fonctionnalité donnée. 9. Procédé selon l'une quelconque des revendications 1 à 8, caractérisé en ce que ladite étape de bridage comprend au moins une action de bridage appartenant au groupe comprenant : - limitation du nombre de modes d'envoi et de réception de données pouvant être utilisés ; - réduction du débit d'au moins un des modes d'envoi et de réception de données pouvant être utilisés ; - report de l'envoi d'au moins un message ; - non réponse à au moins un appel entrant ; - limitation d'au moins une des fonctionnalités de ladite pile liées à la signalisation, à l'enregistrement sur le réseau et à la gestion de la mobilité, avec un débit de données nul ou réduit. 10. Procédé selon l'une quelconque des revendications 1 à 9, caractérisé en ce que ladite architecture logicielle comprend une application de gestion d'au moins un périphérique, et en ce que ladite étape de bridage d'au moins une fonctionnalité de la pile est complétée ou au moins partiellement remplacée par une étape de bridage d'au moins une fonctionnalité de ladite application de gestion d'au moins un périphérique. 11. Procédé selon l'une quelconque des revendications 1 à 10, caractérisé en ce que ledit circuit (44) est un module électronique de radiocommunication destiné à être intégré à un dispositif de radiocommunication. 12. Procédé selon l'une quelconque des revendications 1 à 11, caractérisé en ce qu'il est mis en oeuvre dans une application principale (42) qui, quand elle est exécutée par ledit processeur, gère ladite pile logicielle de radiocommunication (2) et offre un environnement d'exécution de ladite au moins une application client (5). 13. Produit programme d'ordinateur téléchargeable depuis un réseau de communication et/ou enregistré sur un support lisible par ordinateur et/ou exécutable par un processeur, caractérisé en ce qu'il comprend des instructions de code de programme pour l'exécution des étapes du procédé selon au moins une des revendications 1 à 12, lorsque ledit programme est exécuté sur un ordinateur. 14. Circuit de radiocommunication (44), comprenant un processeur exécutant une architecture logicielle comprenant une pile logicielle de radiocommunication (2) et au moins une application client (5), caractérisé en ce qu'il comprend : - des moyens d'obtention d'une première puissance de calcul associée à ladite pile ; - des moyens d'obtention d'une deuxième puissance de calcul associée à ladite au moins une application client ; -des moyens de comparaison de la somme desdites première et deuxième puissances de calcul avec un seuil prédéterminé ; - des moyens de bridage d'au moins une fonctionnalité de ladite pile, pour libérer de la puissance de calcul pour ladite au moins une application client, lesdits moyens de bridage étant activés si lesdits moyens de comparaison détectent que la somme desdites première et deuxième puissances de calcul est supérieure ou égale audit seuil prédéterminé.