Brevet FR2905819A1 — publié le 20080314

Procédé de gestion de l'architecture logicielle d'un circuit de radiocommunication, application, produit programme d'ordinateur et circuit correspondants. 1. DOMAINE DE L'INVENTION Le domaine de l'invention est celui des systèmes de radiocommunication utilisant des interruptions, correspondant à des événement asynchrones, pour assurer la synchronisation physique entre différents 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 à 15 point (Wifi, Bluetooth, Zigbee...). Plus précisément, l'invention concerne une technique de gestion de l'architecture logicielle d'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 20 code de l'application principale de radiocommunication (firmware) qui 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 25 module de la famille WISMO (marque déposée) 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 de ces inconvénients, consistant à regrouper dans un module unique (appelé module électronique de radiocommunication), tout ou au moins la plupart des fonctions d'un dispositif de 30 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 2905819 2 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 5 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- 10 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. A titre uniquement illustratif, les inconvénients de l'art antérieur sont présentés ci-après dans le cas où le circuit de radiocommunication est un module électronique de radiocommunication. Il s'agit par exemple d'un module 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). Il est clair que ces inconvénients peuvent être transposés au cas de la variante d'application précitée. Selon une première technique connue, aucune capacité temps réel n'est fournie pour l'application client embarquée sur le module de radiocommunication. En effet, dans un module de radiocommunication, l'exécution d'une pile logicielle de radiocommunication (pile GSM/GPRS par exemple) nécessite des réponses temps réel à 2905819 3 des interruptions en provenance de la partie radio de la plateforme de ce module de radiocommunication (plateforme GSM/GPRS par exemple). Si le module ne prend pas en compte cette interruption en un temps très limité, il perd la synchronisation au réseau. De ce fait, le module n'est plus capable de passer / recevoir de appels, envoyer / recevoir 5 des SMS, USSD... Pour mémoire, et dans le cas particulier d'une pile GSM/GPRS, il est impératif de garantir le bon fonctionnement de celle-ci dans les modes suivants : déconnecté : le module n'est pas connecté au réseau GSM/GPRS et donc ne peut pas passer de communication ; 10 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 ; connecté : le module passe/reçoit un appel ; envoi/réception de SMS / USSD ; 15 transfert GPRS : le module envoie/reçoit des données sur le lien GPRS ; 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. Ne sachant pas quel impact l'exécution des processus des applications client aura 20 sur le bon fonctionnement de leur propre pile logicielle de radiocommunication et donc sur le bon fonctionnement global de leur produit, les fabricants de module de radiocommunication (notamment ceux à destination des marchés M2M et automobile) ne fournissent donc pas à leurs clients la capacité d'embarquer des processus dont l'exécution en temps réel est critique pour le bon fonctionnement du produit final. 25 Selon une seconde technique connue, les fournisseurs de pile logicielle de radiocommunication (pile GSM/GPRS/EDGE/3G par exemple) fournissent un code qui compilé et exécuté sur une plateforme associée (plateforme GSM/GPRS par exemple) permet de passer/recevoir des appels... Ces fournisseurs de solution logicielle permettent ainsi à leurs clients d'exécuter du code à très bas niveau, code qui pourrait donc 30 permettre d'intégrer des processus dont l'exécution en temps réel est critique. Mais en aucun cas ils ne garantissent alors que la pile logicielle de radiocommunication 2905819 4 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, 5 notamment par les clients des marchés M2M et à plus forte raison de 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 10 anglais) sont conformes à la première technique connue et se définissent de la manière décrite dans la figure 1. 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 15 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 20 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. 25 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 une application client 5 (dans cet exemple une application Open AT ), comprenant un ensemble de tâches client. Au 30 sein de la pile GSM, cette application client 5 est positionnées 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 2905819 5 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). 5 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 10 commandes AT, tâche de fond 4 et tâches de l'application client 5). Ainsi, avec cette structure, toute application cliente peut être exécutée par le module tout en garantissant le bon fonctionnement de la stack GSM/GPRS. Néanmoins aucune capacité temps réel ne peut être garantie à cette application cliente. Actuellement, comme illustré par la figure 2, un processeur (non représenté) 15 interne au module 24 exécute une application principale de radiocommunication 24 qui gère la pile logicielle de radiocommunication (pile GSM par exemple). Afin de pallier l'absence de capacité temps réel pour l'application client 25 également exécutée par le module (grâce au processeur interne précité), on est obligé d'utiliser et implanter sur la carte-mère 21 du dispositif de radiocommunication, un processeur supplémentaire 22 20 (par exemple un microcontrôleur) et une mémoire supplémentaire 23, qui sont externes au module de radiocommunication 24 et permettent d'exécuter des processus client dont l'exécution temps réel est critique. En outre, dans cet exemple, le microcontrôleur 22 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) 25 (SPI1, SPI2) 28 et 29, une interface USB 210 et une liaison véhiculant des interruptions (IT) 211. Ces éléments supplémentaires (microcontrôleur et mémoire) augmentent la complexité et le coût de fabrication du dispositif de radiocommunication. Il existe donc un besoin d'offrir une capacité temps réel pour l'application client 30 exécutée par le module, afin de se passer de la nécessité d'utiliser un processeur 2905819 6 supplémentaire et une mémoire supplémentaire, externes au module de radiocommunication. 3. OBJECTIFS DE L'INVENTION L'invention, dans au moins un mode de réalisation, a notamment pour objectif de 5 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'architecture logicielle d'un circuit de radiocommunication, permettant d'exécuter une application client étrangère à la pile de radiocommunication, à un très haut niveau de priorité (ce qui 10 permet d'exécuter des processus dont l'exécution en temps réel est critique), tout en garantissant le bon fonctionnement de cette 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. Un autre objectif de l'invention, dans au moins un mode de réalisation, est de 15 fournir une telle technique, qui permette de se passer de la nécessité d'utiliser un processeur supplémentaire et une mémoire supplémentaire, externes au circuit de radiocommunication. Un objectif complémentaire de l'invention, dans au moins un mode de réalisation, est de fournir une telle technique, qui puisse être mise en oeuvre quelle que 20 soit la quantité de traitement qu'implique l'exécution de l'application client. 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'architecture logicielle d'un circuit de radiocommunication, ladite architecture logicielle comprenant une pile logicielle de radiocommunication et au 25 moins une application client, ladite pile logicielle de radiocommunication comprenant un gestionnaire d'interruptions de radiocommunication et un ensemble de tâche(s) de radiocommunication comprenant au moins une tâche de radiocommunication, ladite application client comprenant un ensemble de tâche(s) client comprenant au moins une tâche client. Ladite application client comprend au moins un premier gestionnaire 30 d'interruptions client. Le procédé comprend une étape de gestion dudit premier gestionnaire d'interruptions client permettant, au sein de ladite pile logicielle de 2905819 7 radiocommunication, d'intercaler ledit premier gestionnaire d'interruptions client entre ledit gestionnaire d'interruptions de radiocommunication et ledit ensemble de tâche(s) de radiocommunication. Le principe général de l'invention consiste donc à définir une nouvelle 5 architecture logicielle, en ajoutant au sein de la pile de radiocommunication au moins un gestionnaire d'interruptions client, ayant un niveau de priorité d'exécution inférieur à celui du gestionnaire d'interruptions de radiocommunication, mais supérieur à celui des tâches de radiocommunication. En d'autres termes, à travers le gestionnaire d'interruptions client, on offre aux développeurs d'applications client (destinées à être 10 exécutées par le circuit) l'accès à des ressources matérielles bas niveau afin de respecter des premières contraintes temporelles critiques (par exemple un temps de réaction de moins de 1 ms). Ainsi, on garantit que l'application client peut traiter des interruptions en temps réel, sans mettre en danger le bon fonctionnement de la pile de radiocommunication. 15 De façon avantageuse, ladite application client comprend au moins deux sous-ensemble de tâche(s) client, qui comprennent chacun au moins une tâche client. En outre, le procédé comprend une étape de gestion desdits au moins deux sous-ensemble de tâche(s) client permettant, au sein de ladite pile logicielle de radiocommunication, de séparer lesdits au moins deux sous-ensemble de tâche(s) client par au moins une tâche 20 de radiocommunication. Ainsi, au sein du domaine de gestion des tâches (partie de la pile relative aux tâches), certaines tâches client ont un niveau de priorité d'exécution plus élevé que d'autres, ce qui permet à ces tâches client d'être exécutées en respectant des secondes contraintes temporelles critiques (par exemple un temps de réaction compris entre 1 ms 25 et 10 ms), moins fortes que les premières précitées. Avantageusement, au moins un desdits sous-ensembles de tâche(s) client comprend une tâche client particulière formant un second gestionnaire d'interruptions client recevant au moins une interruption par l'intermédiaire dudit au moins un premier gestionnaire d'interruptions client ou d'un autre second gestionnaire d'interruptions 30 client de niveau de priorité d'exécution plus élevé que ledit second gestionnaire d'interruptions client. 2905819 8 Ainsi, une application client peut comprendre plusieurs gestionnaires d'interruptions client, ayant différents niveaux de priorité d'exécution et s'intercalant, au sein de la pile de radiocommunication, entre différentes tâches de radiocommunication. Ces gestionnaires d'interruptions client sont organisés en cascade, en s'envoyant des 5 interruptions (dans le sens décroissant des niveaux de priorité d'exécution). De façon avantageuse, lesdites interruptions client appartiennent au groupe comprenant : - des interruptions client externes audit circuit de radiocommunication ; et -des interruptions client internes audit circuit de radiocommunication, 10 comprenant des interruptions provenant d'un registre d'horloge compris dans ledit circuit de radiocommunication. Selon une caractéristique avantageuse, la durée maximale d'exécution d'au moins un processus critique nécessaire pour la conception dudit au moins un premier gestionnaire d'interruptions client et/ou d'au moins une desdites tâches client est 15 prédéterminée. Dans un mode de réalisation avantageux de l'invention, le procédé comprend une étape de contrôle de la durée d'exécution dudit au moins un premier gestionnaire d'interruptions client et/ou d'au moins une desdites tâches client, permettant de s'assurer que ladite la durée d'exécution n'excède pas une durée maximale déterminée. 20 Dans un mode de réalisation particulier de l'invention, ledit circuit est un module électronique de radiocommunication destiné à être intégré à un dispositif de radiocommunication. 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 25 support lisible par ordinateur et/ou exécutable par un processeur. cve produit programme d'ordinateur comprend 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 encore un autre mode de réalisation, l'invention concerne un circuit de radiocommunication, comprenant des moyens de gestion d'une architecture logicielle 30 comprenant une pile logicielle de radiocommunication et au moins une application client, ladite pile logicielle de radiocommunication comprenant un gestionnaire 2905819 9 d'interruptions de radiocommunication et un ensemble de tâche(s) de radiocommunication comprenant au moins une tâche de radiocommunication, ladite application client comprenant un ensemble de tâche(s) client comprenant au moins une tâche client. L'application client comprend au moins un premier gestionnaire 5 d'interruptions client. Le circuit comprend des moyens de gestion dudit premier gestionnaire d'interruptions client, permettant d'intercaler ledit premier gestionnaire d'interruptions client, au sein de ladite pile logicielle de radiocommunication, entre ledit gestionnaire d'interruptions de radiocommunication et ledit ensemble de tâche(s) de radiocommunication. 10 Les différents moyens de gestion précités sont par exemple des éléments logiciels résultant de l'exécution, par un processeur compris dans le circuit, d'une l'application principale de radiocommunication (généralement appelée firmware ). Plus généralement, le circuit selon l'invention comprend des moyens de mise en œuvre du procédé de gestion de l'architecture logicielle, tel que décrit précédemment 15 (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 d'un mode de réalisation préférentiel de l'invention, donné à titre d'exemple indicatif et non limitatif (tous les modes de 20 réalisation de l'invention ne sont pas limités aux caractéristiques et avantages de ce mode de réalisation préférentiel), 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'une application client, sans capacité temps réel pour cette application client ; 25 la figure 2 présente un dispositif de radiocommunication selon l'art antérieur, comprenant un module de radiocommunication possédant une architecture logicielle selon la figure 1 ; la figure 3 présente une architecture logicielle selon un mode de réalisation particulier de l'invention, d'une pile GSM supportant la capacité d'exécution 30 d'une application client, avec capacité temps réel pour cette application client ; 2905819 10 la figure 4 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 3 ; et la figure 5 illustre un exemple d'utilisation de l'exemple d'architecture logicielle 5 selon l'invention de la figure 3. 6. DESCRIPTION DÉTAILLÉE Sur toutes les figures du présent document, les éléments identiques sont désignés par une même référence numérique. Les figures 1 et 2 sont relatives à l'art antérieur et ont déjà été décrites ci-dessus. 10 On présente maintenant, en relation avec la figure 3, une architecture logicielle selon un mode de réalisation particulier de l'invention, d'une pile GSM supportant la capacité d'exécution d'une application client, avec capacité temps réel pour cette application client. Dans ce mode de réalisation particulier, l'invention consiste à fournir aux 15 utilisateurs de l'environnement OPEN AT la capacité d'exécuter du code étranger à la pile GSM/GPRS (c'est-à-dire une application client) sur une plateforme matérielle GSM/GPRS, à un très haut niveau de priorité (ce qui permet d'exécuter des processus dont l'exécution en temps réel est critique), tout en garantissant le bon fonctionnement de la pile GSM/GPRS dans les différents modes précités. 20 On rappelle que le concept OPEN AT est tel que, en plus de l'application principale de radiocommunication qui gère une pile logicielle de radiocommunication (pile GSM par exemple), un module de radiocommunication (par exemple de la famille WISMO ) exécute au moins une application client. Dans ce mode de réalisation particulier de l'invention, l'architecture logicielle 25 comprend une pile GSM et une application client. La pile GSM est classique et identique à celle déjà décrite ci-dessus en relation avec la figure 1. Elle comprend donc un gestionnaire d'interruptions de radiocommunication 1 ( GSM Stack IT Handler ), un ensemble de tâches 2 spécifiques à la pile GSM ( GSM Stack Tasks L1-L3 ), un ensemble de tâches 3 liées 30 à des commandes AT ( GSM AT Commands Task ) et une tâche de fond 4. 2905819 11 En revanche, l'application cliente de la figure 3 se distingue de celle de la figure 1 en ce qu'elle n'est pas monobloc mais comprend : un premier gestionnaire d'interruptions client (Open AT IT Handler n 1) 31, géré de façon à être intercalé entre le gestionnaire d'interruptions de 5 radiocommunication 1 et l'ensemble de tâches 2 spécifiques à la pile GSM ; une tâche client particulière formant un second gestionnaire d'interruptions client (Open AT IT Handler n 2) 32, gérée de façon à être intercalé entre l'ensemble de tâches 2 spécifiques à la pile GSM et l'ensemble de 10 tâches 3 liées à des commandes AT ; et un ensemble de tâches client ( Open AT Application Tasks T 1 ... T5), gérées de façon à être intercalées entre l'ensemble de tâches 3 liées à des commandes AT et la tâche de fond 4. Par rapport à l'architecture de l'art antérieur décrite sur la figure 1, cette 15 architecture permet au client d'exécuter du code au niveau des premier et second gestionnaires d'interruptions client référencés 31 et 32. Il est clair que différentes variantes de cet exemple peuvent être envisagées : avec un seul gestionnaire d'interruptions client ou bien avec plus de deux gestionnaires d'interruptions client, et/ou avec le(s) gestionnaire d'interruptions client intercalé(s) 20 différemment au sein de la pile GSM. L'exécution du code implémenté dans ces premier et second gestionnaires d'interruptions client est déclenchée par une interruption, qui peut être externe au module, ou interne pour le registre d'horloge (Hardware timer). Ceci permet l'exécution en temps réel de processus asynchrones. L'intérêt de cette solution est l'inter-corrélation 25 entre d'une part la prise en compte des besoins temps réel de la pile GSM pour rester synchroniser au réseau et d'autre part des besoins d'exécution temps réel de n'importe quel type de traitement client (qui peut être très lourd), sans mettre en danger cette synchronisation au réseau. De plus, la durée maximale d'exécution des processus critiques nécessaires pour 30 la conception du code à exécuter au niveau des premier et second gestionnaires 2905819 12 d'interruptions client 31, 32 et des tâches client 33 est prédéterminée. Il s'agit par exemple : - de la durée de non-interruptibilité (temps de latence d'interruption) ; - du temps de planification ( Scheduling time en anglais) ; 5 - du temps d'écriture en mémoire non volatile ; - du temps d'allocation d'une zone de stockage en mémoire volatile ; - du temps de positionnement de d'acquisition de valeurs sur les BUS et GPIOs de la plateforme ; - le temps de basculement entre les modes actifs (normaux) et inactif (sleep) ; 10 - le temps de basculement entre les modes standard (26MHz) et Boost 104MHz ; On présente maintenant, en relation avec la figure 4, un mode de réalisation particulier d'un dispositif de radiocommunication selon l'invention. Il comprend une carte-mère 41 sur laquelle sont implantés un module de 15 radiocommunication 44 possédant une architecture logicielle selon la figure 3, obtenue par exécution par un processeur (non représenté) de : une application principale de radiocommunication 42 qui gère la pile logicielle de radiocommunication (pile GSM par exemple) et permet la mise en oeuvre du procédé de l'invention, permettant d'obtenir 20 l'architecture logicielle de l'invention (dans laquelle l'application client est répartie au sein de la pile) ; et une application client 45 dont les différentes parties sont réparties au sein de la pile GSM, comme détaillé ci--dessus en relation avec la figure 3. Du fait qu'une capacité temps réel est offerte à l'application client 45, aucun 25 élément supplémentaire (ni microcontrôleur ni mémoire), externe au module, n'est nécessaire sur la carte-mère 41. Par ailleurs, le module de radiocommunication 44 est relié à un connecteur 26 de dispositifs externes, via les mêmes interfaces et liaisons que celles déjà décrites sur la figure 2 (entre ce même connecteur 26 et le microcontrôleur externe 22). 30 On présente maintenant, en relation avec la figure 5, un exemple d'utilisation de l'exemple d'architecture logicielle selon l'invention de la figure 3. 5 10 15 20 25 30 2905819 13 Cet exemple porte sur : l'acquisition d'une valeur de courant par un capteur en un temps restreint et borné, temps après lequel la valeur remontée par le capteur n'a plus de valeur (par exemple 2 ms) ; le capteur positionnant une interruption au moment précis où la valeur est disponible. cet valeur (mesure) est acquise en vue du calcul de la consommation instantanée, de la moyenne sur plusieurs jours et du stockage du résultat en mémoire de manière asynchrone. ces opérations de calcul et stockage devront se faire à chaque interruption positionnée par le capteur et ce de manière indépendante des modes GSM dans lesquels est le module. de manière hebdomadaire, le système complet envoie par GPRS le rapport de mesure complet (comportant par exemple plusieurs centaines de mesures ponctuelles). On distingue les étapes suivantes : 1. Détection d'une interruption positionnée par le capteur signifiant que la mesure est prête à être acquise sur un bus quelconque de la plateforme. 2. Déclenchement du code client destiné àacquérir cette mesure dans un temps garanti de moins de 2ms (sinon la mesure n'a plus de valeur), ce code étant exécuté au niveau du premier gestionnaire d'interruption (Open AT IT Handler n 1). 3. Acquisition dans le premier gestionnaire d'interruptions client (Open AT IT Handler n 1) de la mesure et stockage en mémoire volatile (processus très rapide, quelques yrs). 4. Notification par le premier gestionnaire d'interruption (Open AT IT Handler n 1) au second Gestionnaire d'interruption client (Open AT IT Handler n 2) que la mesure a été acquise et stockée en mémoire volatile à un emplacement donné. 5. Réveil du second Gestionnaire d'interruption client suite à la notification de mesure envoyée par le premier gestionnaire d'interruption. Acquisition de la valeur instantanée et exécution des calculs de 2905819 14 consommation instantanée et moyenne dans le second gestionnaire d'interruptions client (Open AT IT Handler n 2). Stockage des résultats de ces calculs en mémoire flash (opérations très longues, plusieurs centaines de ms). 5 6. Retour à un état normal : attente d'interruption pour acquisition de valeur instantanée. 7. Chaque semaine, lorsque l'alarme que la tâche cliente Open AT (Open AT Application Tasks Ti) a positionnée sur 1 semaine se déclenche, cet tâche (Open AT Application Tasks Ti) va chercher à l'emplacement 10 défini le rapport complet qui a été acquis, mis en forme et stocké par le second gestionnaire d'interruption suite aux mesures instantanées acquise en un temps limité par le premier gestionnaire d'interruption. 8. une fois le rapport acquis, la tâche cliente Open AT initie une connexion GPRS et envoie le rapport et le supprime de la mémoire une fois l'envoi 15 terminé. Il se peut que pendant cette phase les premier et second gestionnaires interrompent ces tâches ( OPEN AT Application Task T 1 et GSM Stack Tasks ) pour acquérir de nouvelle valeurs). Les actions décrites aux étapes 7 et 8 sont synchrones (elles se répètent de manière prédictive : toutes les semaines, une fois par semaine) et ne nécessitent en 20 aucun cas du temps réel puisque la réception du rapport de manière hebdomadaire par l'infrastructure cliente à plus ou moins 2 minutes prêt ne change absolument rien à la qualité du rapport et à son exploitation ultérieure. Ainsi ces actions sont exécutées par la tâche de basse priorité (Open AT Application Tasks Ti). A l'inverse, la qualité du rapport dépend de la qualité des mesures instantanées qui ne sont valables que si 25 acquises en moins de 2 ms. Ici nous avons donc besoin de temps de réponse garanti. C'est pourquoi les mesures sont acquises par le premier gestionnaire d'interruption (Open AT IT Handler n 1). Enfin l'envoi du rapport par GPRS pourrait modifier le temps d'acquisition de cette mesure instantanée car cela fait travailler la pile GSM. En cela, le client à besoin de 30 l'architecture temps réel proposée par l'invention car elle seule peut lui garantir la qualité de ses mesures quelle que soit l'action que le système entreprend. 2905819 15 Si ces opérations 1 à 8 sont effectuées en mode déconnecté, elles se font de manière séquentielle puisque la pile GSM/GPRS ne tourne pas. Si le module est dans un des modes spécifiés plus hauts (quel qu'il soit), l'étape 2 est garantie car l'architecture logicielle selon l'invention garantit que le traitement 5 d'une interruption ( GSM IT ) en provenance de la partie radio du module ne dure pas plus d' lms quel que soit le mode dans lequel le module est. L'étape 3 (traitement de l'interruption client EXT IT 1 ) ne commencera que lorsque l'interruption en provenance de la partie radio ( GSM IT ) sera traitée, ou cette étape 3 sera interrompue par le traitement de cette interruption. Ceci garantit que la 10 synchronisation avec le réseau est conservée quel que soit le traitement asynchrone à réaliser en temps réel par l'application client. De plus, le fabricant du module garantit le temps maximum nécessaire à l'allocation d'une zone de stockage en mémoire volatile quel que soit l'état GSM du module. Ceci garantit que la mesure peut être stockée moins de 2ms après le déclenchement de l'interruption notifiant la nécessité de l'acquisition de 15 cette mesure. L'étape 4 (traitement de l'interruption client EXT IT2 ) ne commencera que lorsque les tâches de la pile GSM/GPRS auront effectué les opérations nécessaires au maintien de l'appel voix, de l'envoi/réception des données sur le lien GPRS de l'envoi réception d'un SMS, USSD.... 20 Cette découpe en termes de tâche permet donc d'exécuter des processus temps réel quel que soit l'état de la partie GSM/GPRS, tout en garantissant son bon fonctionnement de la pile. Optionnellement, un processus de contrôle permet de s'assurer que le code client dans chacun des premier et second gestionnaires d'interruptions client (Open AT IT 25 Handler n 1 et 2) ne s'exécute pas pendant trop longtemps. REVENDICATIONS 1. Procédé de gestion de l'architecture logicielle d'un circuit de radiocommunication (44), ladite architecture logicielle comprenant une pile logicielle de radiocommunication et au moins une application client (45), ladite pile logicielle de radiocommunication comprenant un gestionnaire d'interruptions de radiocommunication (1) et un ensemble de tâche(s) de radiocommunication comprenant au moins une tâche de radiocommunication (2 à 4), ladite application client comprenant un ensemble de tâche(s) client comprenant au moins une tâche client, caractérisé en ce que ladite application client comprend au moins un premier gestionnaire d'interruptions client (31), et en ce que le procédé comprend une étape de gestion dudit premier gestionnaire d'interruptions client permettant, au sein de ladite pile logicielle de radiocommunication, d'intercaler ledit premier gestionnaire d'interruptions client (31) entre ledit gestionnaire d'interruptions de radiocommunication (1) et ledit ensemble de tâche(s) de radiocommunication (2 à 4). 2. Procédé selon la revendication 1, caractérisé en ce que ladite application client (45) comprend au moins deux sous-ensemble de tâche(s) client, qui comprennent chacun au moins une tâche client, et en ce que le procédé comprend une étape de gestion desdits au moins deux sous- ensemble de tâche(s) client permettant, au sein de ladite pile logicielle de radiocommunication, de séparer lesdits au moins deux sous-ensemble de tâche(s) client par au moins une tâche de radiocommunication. 3. Procédé selon la revendication 2, caractérisé en ce que au moins un desdits sous-ensembles de tâche(s) client comprend une tâche client particulière formant un second gestionnaire d'interruptions client (32) recevant au moins une interruption par l'intermédiaire dudit au moins un premier gestionnaire d'interruptions client ou d'un autre second gestionnaire d'interruptions client de niveau de priorité d'exécution plus élevé que ledit second gestionnaire d'interruptions client. 4. Procédé selon l'une quelconque des revendications 1 à 3, caractérisé en ce que lesdites interruptions client appartiennent au groupe comprenant : - des interruptions client externes audit circuit de radiocommunication ; et 2905819 17 - des interruptions client internes audit circuit de radiocommunication, comprenant des interruptions provenant d'un registre d'horloge compris dans ledit circuit de radiocommunication. 5. Procédé selon l'une quelconque des revendications 1 à 4, caractérisé en ce que la 5 durée maximale d'exécution d'au moins un processus critique nécessaire pour la conception dudit au moins un premier gestionnaire d'interruptions client et/ou d'au moins une desdites tâches client est prédéterminée. 6. Procédé selon l'une quelconque des revendications 1 à 5, caractérisé en ce qu'il comprend une étape de contrôle de la durée d'exécution dudit au moins un premier 10 gestionnaire d'interruptions client et/ou d'au moins une desdites tâches client, permettant de s'assurer que ladite la durée d'exécution n'excède pas une durée maximale déterminée. 7. Procédé selon l'une quelconque des revendications 1 à 6, caractérisé en ce que ledit circuit est un module électronique de radiocommunication (44) destiné à être 15 intégré à un dispositif de radiocommunication. 8. 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 à 7, 20 lorsque ledit programme est exécuté sur un ordinateur. 9. Circuit de radiocommunication, comprenant des moyens de gestion d'une architecture logicielle comprenant une pile logicielle de radiocommunication et au moins une application client, ladite pile logicielle de radiocommunication comprenant un gestionnaire d'interruptions de radiocommunication et un ensemble de tâche(s) de 25 radiocommunication comprenant au moins une tâche de radiocommunication, ladite application client comprenant un ensemble de tâche(s) client comprenant au moins une tâche client, caractérisé en ce que ladite application client comprend au moins un premier gestionnaire d'interruptions client, 30 et en ce que le circuit comprend des moyens de gestion dudit premier gestionnaire d'interruptions client, permettant d'intercaler ledit premier gestionnaire d'interruptions 2905819 18 client, au sein de ladite pile logicielle de radiocommunication, entre ledit gestionnaire d'interruptions de radiocommunication et ledit ensemble de tâche(s) de radiocommunication. 10. Circuit de radiocommunication selon la revendication 9, caractérisé en ce que 5 ladite application client comprend au moins deux sous-ensemble de tâche(s) client, qui comprennent chacun au moins une tâche client, et en ce que le circuit comprend des moyens de gestion desdits au moins deux sous-ensemble de tâche(s) client permettant, au sein de ladite pile logicielle de radiocommunication, de séparer lesdits au moins deux sous-ensemble de tâche(s) client 10 par au moins une tâche de radiocommunication. 11. Circuit de radiocommunication selon la revendication 10, caractérisé en ce que les moyens d'exécution d'au moins un desdits sous-ensembles de tâche(s) client comprennent des moyens d'exécution d'une tâche client particulière formant un second gestionnaire d'interruptions client recevant au moins une interruption reçue par 15 l'intermédiaire dudit au moins un premier gestionnaire d'interruptions client. 12. Circuit de radiocommunication selon l'une quelconque des revendications 9 à 11, caractérisé en ce que lesdites interruptions client appartiennent au groupe comprenant : - des interruptions client externes audit circuit de radiocommunication ; et 20 - des interruptions client internes audit circuit de radiocommunication, comprenant des interruptions provenant d'un registre d'horloge compris dans ledit circuit de radiocommunication. 13. Circuit de radiocommunication selon l'une quelconque des revendications 9 à 12, caractérisé en ce que la durée maximale d'exécution de chaque processus critique 25 nécessaire pour la conception dudit au moins un premier gestionnaire d'interruptions client et/ou d'au moins une desdites tâches client est prédéterminée. 14. Circuit de radiocommunication selon l'une quelconque des revendications 9 à 13, caractérisé en ce qu'il comprend des moyens de contrôle de la durée d'exécution dudit au moins un premier gestionnaire d'interruptions client et/ou d'au moins une 30 desdites tâches client, permettant de s'assurer que ladite la durée d'exécution n'excède pas une durée maximale déterminée. 2905819 19 15. Circuit de radiocommunication selon l'une quelconque des revendications 9 à 14, caractérisé en ce qu'il s'agit d'un module électronique de radiocommunication destiné à être intégré à un dispositif de radiocommunication.