FR 2830403 A1 20030404 FR 0112692 A 20011002 Module de radiocommunication exécutant un logiciel principal dont les couches basses sont ouvertes à un logiciel client également exécuté par le module. Le domaine de l'invention est celui des systèmes de radiocommunication notamment, mais non exclusivement, selon le standard GSM (pour"Global System for Mobile communications"en anglais), DCS 1800 (pour"Digital Cellular System 1800 MHz"en anglais), PCS 1900 (pour"Personal Communication System"en anglais), GPRS (pour"General Packet Radio service"), ou encore UMTS (pour"Universal Mobile Telecommunication System"en anglais). Plus précisément, l'invention concerne un module de radiocommunication. On rappelle que le module de radiocommunication est un élément essentiel d'un radiotéléphone. Habituellement (première application), le module de radiocommunication est compris dans un terminal (ou ME, pour''Mobile Equipment" en anglais) qui coopère avec une carte SIM (pour"Subscriber Identity Module"en anglais, ou module d'identification d'abonné). D'autres applications ont d'ores et déjà été envisagées pour le module de radiocommunication précité. Il a notamment été proposé (seconde application) d'intégrer le module de radiocommunication dans des dispositifs autres que des terminaux de radiocommunication, mais nécessitant néanmoins une fonctionnalité de communication sans fil. A titre d'exemple, on peut citer des dispositifs de télémétrie (relevés de compteur), des dispositifs d'alarme ou encore des dispositifs lecteur de cartes bancaires. n a également été proposé (troisième application) de fournir le module de radiocommunication sous forme indépendante : il est alors qualifié de modem. Un tel modem ne comprend aucun élément matériel (écran, clavier, haut-parleur,...) d'interface homme/machine. Il est destiné à coopérer avec un équipement tiers (supportant un logiciel client), qui lui possède des éléments matériels d'interface homme/machine. L'équipement tiers peut notamment, mais non exclusivement, être un micro-ordinateur. Typiquement, le module de radiocommunication héberge et exécute un logiciel principal comprenant : une application de gestion du système d'exploitation, aussi appelée bloc"OS" (pour"Operating System"en anglais), qui gère les aspects système tels que le gestionnaire de tâches, le gestionnaire de mémoire, le gestionnaire de temporisation, etc. ; une application de gestion des radiocommunications, aussi appelée bloc"couche 3 GSM", qui gère les aspects réseau tels que la gestion des appels sortants et entrants, la gestion des réceptions et envois de messages courts texte, etc. On notera que le bloc"couche 3 GSM"peut ne pas respecter la totalité des recommandations GSM pour les couches 3. Il peut également être conforme à un autre standard (DCS 1800, PCS 1900, GPRS, UMTS,...) ; une application de gestion de périphériques pouvant être connectés au module de radiocommunication, aussi appelée bloc"HWL" (pour"HardWare Layer"en anglais). Par périphériques, on entend notamment, mais non exclusivement, un écran, un clavier, un microphone, un haut-parleur, un bus série, un élément d'entrées/sorties GPIO ("General Purpose Inputs/outputs"), une batterie, un lecteur de SIM, etc ; une application propriétaire, faisant appel aux trois blocs"OS","couche 3 GSM" et"HWL"précités afin d'offiir à l'utilisateur une pluralité de fonctionnalités propres à un dispositif intégrant le module de radiocommunication. On rappelle que ce dispositif est par exemple un radiotéléphone (première application précitée), un "autre dispositif' (seconde application précitée) ou encore un modem (troisième application précitée). Actuellement, le logiciel principal est un logiciel propriétaire, développé par le fabriquant du module de radiocommunication. Il comprend un fichier binaire contenant notamment l'application propriétaire ainsi que les blocs"OS","couche 3 GSM"et "HWL"précités. De façon classique, ce fichier binaire résulte d'une compilation d'une pluralité de fichiers sources (par exemple en langage"C"), puis d'une édition de lien entre les fichiers sources compilés (aussi appelés fichiers objets). La technique actuelle, selon laquelle le logiciel principal est un logiciel propriétaire, présente plusieurs inconvénients. Tout d'abord, elle ne permet pas à un client de développer lui-même sa propre application. En effet, le client doit impérativement faire développer son application par le constructeur du module de radiocommunication (pour obtenir l'application propriétaire précitée). Un autre inconvénient de la technique actuelle est que si le client souhaite apporter des modifications à l'application propriétaire, il doit à nouveau impérativement passer par le constructeur du module de radiocommunication. Le client n'est donc pas maître des évolutions qu'il souhaite pour son application et doit en permanence compter sur les ressources du constructeur de module de radiocommunication. L'invention 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 est de fournir une technique permettant à un client de développer sa propre application, puis de l'embarquer et la faire exécuter par un module de radiocommunication. Cette application, dite"application cliente", doit pouvoir être développée par le client luimême, indépendamment du constructeur du module de radiocommunication. Elle doit remplacer Inapplication propriétaire"précitée, au sein du module de radiocommunication. L'invention a également pour objectif de permettre au client de développer une application cliente"distribuée", comprenant une pluralité d'applications"de tâche" effectuant plusieurs tâches temps réel, entre lesquelles le client peut définir des priorités. Un autre objectif de l'invention est de fournir une architecture logicielle, au sein du module de radiocommunication, qui permette de supporter une nouvelle technique de pilotage du module de radiocommunication, qui soit simple et peu coûteuse (en terme de matériel et de consommation énergétique). On rappelle que la technique actuelle de pilotage d'un module de radiocommunication par un équipement tiers présente plusieurs inconvénients. Tout d'abord, elle nécessite un double jeu de ressources (processeur et mémoire). En effet, le module de radiocommunication comprend un processeur et une mémoire (premier jeu de ressources) et l'équipement tiers dispose également d'un processeur et d'une mémoire (second jeu de ressources). La technique actuelle précitée est donc coûteuse en terme de matériel et de consommation énergétique. Un autre inconvénient de la technique actuelle précitée est que le module de radiocommunication subit entièrement le pilotage effectué par l'équipement tiers. En effet, le logiciel client de pilotage, hébergé et exécuté par l'équipement tiers, est le"maître", tandis que le logiciel principal, hébergé et exécuté par le module de radiocommunication, est l"'esclave". Selon un autre objectif de l'invention, la nouvelle technique de pilotage du module de radiocommunication, supportée par la nouvelle architecture logicielle selon l'invention, permet au module de radiocommunication, lorsque le pilotage est effectué par un équipement tiers, de pouvoir superviser (y inclus agir sur) le déroulement de ce pilotage. En d'autres termes, on souhaite que le module de radiocommunication ne joue pas uniquement un rôle d'esclave. Encore un autre objectif de l'invention est, dans le contexte de la nouvelle technique précitée de pilotage d'un module de radiocommunication, de faciliter la tâche du client dans le processus de développement de sa propre application cliente. L'invention a également pour objectif de proposer une solution simple et efficace aux problèmes de dialogue entre sous-applications clientes (principale et secondaire) qui résultent de la mise en cuivre d'un mode de réalisation particulier de la présente invention dans lequel : l'application cliente est"distribuée"au sens précité et comprend : * une première application"de tâche", réalisant une première tâche temps réel d'exécution de commandes de pilotage (par exemple des commandes AT), * une seconde application"de tâche", réalisant une seconde tâche temps réel telle que la seconde application"de tâche"joue le rôle d'une application cliente de pilotage et/ou le rôle d'une application cliente de supervision ; la seconde application"de tâche"comprend elle-même : * une sous-application cliente principale, * au moins une sous-application cliente secondaire. Ces différents objectifs, ainsi que d'autres qui apparaîtront par la suite, sont atteints selon l'invention à l'aide d'un module de radiocommunication, du type hébergeant et exécutant un logiciel principal comprenant : une application de gestion du système d'exploitation (OS), une application de gestion des radiocommunications (couche 3 GSM) et une application de gestion de périphériques pouvant être connectés au module de radiocommunication (HWL). Selon l'invention, chacune desdites applications comprises dans le logiciel principal est associée à un jeu de fonctions d'exécution de niveau 1. Ledit module de radiocommunication héberge et exécute en outre au moins un logiciel client comprenant au moins une application cliente, associée à un jeu de fonctions sources de niveau 1. Ledit logiciel principal et/ou ledit logiciel client comprend (nnent) une application d'interface de niveau 1, permettant l'interfaçage des fonctions sources de niveau 1, associées à ladite application cliente, avec les fonctions d'exécution de niveau 1, associées à ladite application de gestion du système d'exploitation et à au moins une desdites applications de gestion des radiocommunications et de gestion de périphériques. De cette façon, on ouvre à ladite au moins une application cliente, l'accès à au moins certaines des fonctionnalités du logiciel principal. Le principe général de l'invention consiste donc à utiliser deux logiciels (principal et client) pouvant dialoguer entre eux, et à héberger sur le logiciel client embarqué (au moins) une application cliente. Ainsi, le logiciel principal ne comprend plus d'application principale propriétaire. En d'autres termes, l'accès à des couches basses du module de radiocommunication (blocs"OS","couche 3 GSM"et"HWL" précités), développées par le fabricant du module de radiocommunication, est ouvert à des applications clientes, développées par des clients. L'ensemble de ces couches basses est parfois aussi appelé"Open-Stack"dans la suite de la description. La nouvelle technique selon l'invention peut être vue comme une plate-forme logicielle, permettant aux clients de développer leurs propres applications clientes et de les télécharger dans les modules de radiocommunication. Les clients peuvent développer, indépendamment du constructeur du module de radiocommunication, leurs propres applications puis les embarquer et les faire exécuter par les modules de radiocommunication. De même, les clients peuvent modifier ou faire évoluer leurs applications clientes sans que cela nécessite l'intervention du fabricant du module de radiocommunication. Ainsi, on peut distinguer selon la présente invention les trois types d'interfaçage suivants, via l'application d'interface de niveau 1 : interfaçage de la ou des application (s) cliente (s) avec les blocs"OS"et"couche 3 GSM" ; interfaçage de la ou des application (s) cliente (s) avec les blocs"OS"et"HWL" ; interfaçage de la ou des application (s) cliente (s) avec les blocs"OS","couche 3 GSM"et"HWL". On notera que la ou les applications clientes peuvent être contenues dans le logiciel client sous plusieurs formes : soit il y a une unique application cliente, contenue dans le logiciel client sous la forme d'un fichier binaire. L'application d'interface de niveau 1 est dans ce cas contenue soit dans ce fichier binaire (ce qui suppose que le fichier objet contenant l'application cliente ait fait l'objet d'une édition de lien avec le fichier objet contenant l'application d'interface de niveau 1), soit dans un autre fichier binaire ; soit il y a plusieurs applications clientes, contenues dans le logiciel client sous la forme d'un même fichier binaire. L'application d'interface de niveau 1 est dans ce cas contenue soit dans ce fichier binaire (ce qui suppose que les fichiers objet contenant les applications clientes aient fait l'objet d'une édition de lien avec le fichier objet contenant l'application d'interface de niveau 1), soit dans un autre fichier binaire ; soit il y a plusieurs applications clientes, contenues dans le logiciel client sous la forme de plusieurs fichiers binaires (chaque fichier binaire contenant une ou plusieurs applications clientes). L'application d'interface de niveau 1 est dans ce cas contenue soit dans l'un de ces fichiers binaires (ce qui suppose, pour le fichier binaire concerné, que le ou les fichiers objet contenant la ou les applications clientes aient fait l'objet d'une édition de lien avec le fichier objet contenant l'application d'interface de niveau 1), soit dans un autre fichier binaire. On notera que l'expression"de niveau 1"est utilisée pour qualifier des entités impliquées dans des relations entre application (s) cliente (s) et application (s) comprise (s) dans le logiciel principal. Ces"entités de niveau 1"sont notamment les fonctions d'exécution associées aux applications comprises dans le logiciel principal, les fonctions source associées à la ou aux applications) cliente (s), ou encore l'application d'interface entre application (s) cliente (s) et application (s) comprise (s) dans le logiciel principal. On utilise par la suite une expression distincte, à savoir"de niveau 2", pour qualifier des entités impliquées dans des relations entre deux applications clientes, dans le cadre d'un mode de réalisation particulier de l'invention relatif au pilotage du module de radiocommunication. Ces"entités de niveau 2"sont notamment les fonctions d'exécution et les fonctions source spécifiques aux commandes de pilotage (selon le standard AT, par exemple), ou encore l'application d'interface entre celles-ci. Préférentiellement, ledit logiciel client comprend une application cliente de démarrage global, et au moins une application cliente de tâche réalisant au moins une tâche temps réel. Le jeu de fonctions sources de niveau 1 associé à l'application cliente de démarrage global comprend une fonction source de niveau 1 de démarrage global, dont le rôle est de fournir au logiciel principal des informations lui permettant d'initialiser et de dialoguer avec chaque application cliente de tâche. Ainsi, le logiciel principal n'a besoin de connaître que cette fonction source de niveau 1 de démarrage global pour pouvoir lancer, lorsqu'il le souhaite, l'application cliente de démarrage global. Il n'a donc pas à connaître les points de dialogue (fonctions source de niveau 1 d'initialisation et de traitement d'un message) de chaque application cliente de tâche. Ces points de dialogue sont présentés en détail par la suite. De façon préférentielle, ledit logiciel client comprend au moins deux applications clientes de tâche, associées chacune à un jeu de fonctions sources de niveau 1 et réalisant chacune au moins une tâche temps réel distincte. Ledit logiciel principal et/ou ledit logiciel client comprend (nnent) des moyens de partage des ressources de calcul entre lesdites applications clientes de tâche, de façon à permettre un fonctionnement multitâches temps réel. Avantageusement, le jeu de fonctions sources de niveau 1 associé à chaque application cliente de tâche comprend une fonction source de niveau 1 d'initialisation, permettant d'initialiser ladite application cliente de tâche. Cette fonction source de niveau 1 d'initialisation est appelée une fois par le logiciel principal pour initialiser la tâche réalisée par l'application cliente de tâche concernée. Préférentiellement, lesdites informations fournies par la fonction source de démarrage global au logiciel principal comprennent : le nombre d'applications clientes de tâche à initialiser ; pour chaque application cliente de tâche à initialiser, la fonction source de niveau 1 d'initialisation correspondante. De façon préférentielle, le jeu de fonctions sources de niveau 1 associé à chaque application cliente de tâche comprend une fonction source de niveau 1 de réception et traitement d'un message provenant du logiciel principal, un paramètre de ladite fonction source de niveau 1 de réception et traitement étant ledit message. Cette fonction source de niveau 1 de réception et traitement d'un message est appelée à chaque fois que le logiciel principal envoie un message à l'application cliente de tâche concernée. Chaque application cliente possède sa propre fonction source de niveau 1 de réception et traitement d'un message. Préférentiellement, lesdites informations fournies par la fonction source de niveau 1 de démarrage global au logiciel principal comprennent en outre, pour chaque application cliente de tâche à initialiser, la fonction source de niveau 1 de réception et traitement. De cette façon, le logiciel principal dispose de deux points de dialogue (fonctions source de niveau 1) avec chaque application cliente, à savoir la fonction source de niveau 1 d'initialisation et la fonction source de niveau 1 de réception et traitement. Dans un mode de réalisation particulier de l'invention, le jeu de fonctions sources de niveau 1 associé à chaque application cliente de tâche comprend une fonction source de niveau 1 d'inscription à un service de boîte aux lettres géré par le logiciel principal, permettant à ladite application cliente de tâche de se voir affecter une boîte aux lettres qui lui est propre et dans laquelle elle souhaite recevoir des informations provenant d'au moins une source prédéterminée. Préférentiellement, chaque source prédéterminée d'informations est une boîte aux lettres affectée à au moins une tâche principale effectuée par le logiciel principal, et contenant des informations que ladite tâche principale souhaite communiquer à une ou plusieurs autres entités. La ou les autres entités auxquelles une tâche principale souhaite communiquer des informations sont des applications clientes de tâche et/ou d'autres tâches principales. Dans un mode de réalisation avantageux de l'invention, ledit logiciel client comprend au moins : une première application cliente réalisant une première tâche temps réel d'exécution de commandes de pilotage, envoyées à ladite première application par au moins une application cliente de pilotage et appartenant à un jeu de commandes de pilotage prédéterminé, ladite première application cliente étant basée notamment sur un jeu de fonctions d'exécution de niveau 2, spécifiques aux commandes de pilotage et permettant chacune l'exécution d'au moins une desdites commandes de pilotage, une seconde application cliente réalisant une seconde tâche temps réel telle que ladite seconde application cliente joue au moins un des deux rôles suivants : * le rôle d'une application cliente de pilotage, envoyant des commandes de pilotage à la première application cliente, et recevant de la première application cliente des réponses, résultant de l'exécution de certaines des commandes de pilotage ; * le rôle d'une application cliente de supervision, gérant l'exécution de commandes de pilotage envoyées par une application cliente de pilotage, dite application cliente externe, hébergée et exécutée par un équipement tiers coopérant avec le module de radiocommunication ; ladite seconde application cliente étant basée notamment sur un jeu de fonctions sources de niveau 2, spécifiques aux commandes de pilotage et permettant chacune l'envoi ou la réception, vers ou en provenance de la première application cliente, de commandes de pilotage ou de réponses à des commandes de pilotage, une application d'interface de niveau 2, spécifique aux commandes de pilotage, permettant l'interfaçage desdites fonctions sources et d'exécution de niveau 2, ladite application d'interface de niveau 2 s'appuyant elle-même sur ladite application d'interface de niveau 1. Ainsi, la présente invention propose une nouvelle architecture logicielle au sein du module de radiocommunication (ouvertures des couches basses à un logiciel client embarqué), qui permet de supporter une nouvelle technique de pilotage du module de radiocommunication, simple et peu coûteuse. Cette nouvelle technique de pilotage du module de radiocommunication consiste à héberger sur le module de radiocommunication un logiciel client comprenant : une première application cliente capable d'exécuter des commandes de pilotage (commandes AT par exemple). Dans la pratique, cette première application cliente pourra être fournie par le fabricant de module de radiocommunication ; une seconde application cliente, assurant le pilotage et/ou la supervision du module de radiocommunication, en faisant exécuter des commandes à la première application cliente. Dans le cas où la seconde application cliente assure le pilotage du module de radiocommunication, ce dernier présente un fonctionnement autonome et peu coûteux. En effet, il n'a pas à coopérer avec un équipement tiers, et le logiciel principal et le logiciel client utilisent les mêmes ressources (même processeur et même mémoire). Dans le cas où la seconde application cliente assure la supervision du module de radiocommunication, ce dernier n'est pas limité à un rôle d'esclave vis-à-vis de l'équipement tiers qui exécute le logiciel client de pilotage. En effet, la seconde application cliente gère le pilotage demandé par le logiciel client (externe) de pilotage, exécuté par l'équipement tiers. On notera que, dans ce cas, le logiciel client embarqué est un logiciel supplémentaire par rapport à la configuration de l'art antérieur. Toutefois, ce logiciel supplémentaire est peu coûteux puisqu'il utilise les mêmes ressources (processeur et mémoire) que le logiciel principal également hébergé par le module de radiocommunication. Préférentiellement, pour permettre à la seconde application cliente de jouer le rôle d'une application cliente de pilotage : la seconde application cliente comprend des moyens d'envoi de commandes de pilotage vers les moyens d'exécution compris dans la première application cliente ; la première application cliente comprend des moyens d'envoi des réponses, résultant de l'exécution de certaines des commandes de pilotage par les moyens d'exécution compris dans la première application cliente, vers la seconde application cliente ; la seconde application cliente comprend des moyens de traitement des réponses envoyées vers elle par la première application cliente. De façon préférentielle, pour permettre à la seconde application cliente de jouer le rôle d'une application cliente de supervision : la première application cliente comprend des moyens d'aiguillage de commandes, en fonction d'une politique d'aiguillage de commandes déterminée, de façon à transmettre les commandes de pilotage provenant de l'application cliente externe vers la seconde application cliente et/ou vers les moyens d'exécution compris dans la première application cliente ; la seconde application cliente comprend des moyens de traitement des commandes de pilotage aiguillées vers elle par lesdits moyens d'aiguillage de commandes. Avantageusement, la seconde application cliente comprend des moyens de sélection de la politique d'aiguillage de commandes appliquée par lesdits moyens d'aiguillage de commandes, parmi un ensemble de politiques d'aiguillage de commandes telles que respectivement : les commandes de pilotage provenant de l'application cliente externe sont transmises uniquement aux moyens d'exécution compris dans la première application cliente ; les commandes de pilotage provenant de l'application cliente externe sont transmises uniquement à la seconde application cliente ; les commandes de pilotage provenant de l'application cliente externe sont transmises aux moyens d'exécution compris dans la première application cliente et la seconde application cliente. De façon avantageuse, lesdits moyens de traitement des commandes prennent, pour chaque commande, au moins une décision appartenant au groupe comprenant : envoi de la commande de pilotage vers les moyens d'exécution compris dans la première application cliente, la seconde application cliente comprenant à cet effet des moyens d'envoi de commandes de pilotage vers les moyens d'exécution ; fourniture ou non d'une réponse, uniquement en fonction d'au moins une information relative à la commande, sans exécution de la commande, la seconde application cliente comprenant à cet effet des moyens d'envoi de la réponse à l'application cliente externe, via la seconde application cliente. Préférentiellement, pour permettre à la seconde application cliente de jouer le rôle d'une application cliente de supervision : la première application cliente comprend des moyens d'aiguillage de réponses, en fonction d'une politique d'aiguillage de réponses déterminée, de façon à transmettre des réponses, résultant de l'exécution de certaines des commandes de pilotage par les moyens d'exécution compris dans la première application cliente, vers la seconde application cliente et/ou vers l'application cliente externe ; la seconde application cliente comprend des moyens de traitement des réponses aiguillées vers elle par lesdits moyens d'aiguillage de réponses. Avantageusement, la seconde application cliente comprend des moyens de sélection de la politique d'aiguillage de réponses appliquée par lesdits moyens d'aiguillage de réponses, parmi un ensemble de politiques d'aiguillage de réponses telles que respectivement : les réponses provenant des moyens d'exécution sont transmises uniquement à l'application cliente externe ; les réponses provenant des moyens d'exécution sont transmises uniquement à la seconde application cliente ; les réponses provenant des moyens d'exécution sont transmises à la seconde application cliente et à l'application cliente externe. Préférentiellement, ledit jeu de fonctions sources de niveau 2 comprend notamment une fonction de traitement d'un message provenant de la première application, un paramètre de ladite fonction de traitement étant ledit message. De façon préférentielle, ledit jeu de commandes de pilotage est un jeu de commandes AT standard. Ceci permet un développement rapide des première et seconde applications clientes, les commandes AT étant bien connues et déjà utilisées pour le développement des logiciels clients externes (hébergés par les équipements tiers). Ceci facilite également le développement d'une seconde application cliente fortement basée sur un logiciel client externe existant. Avantageusement, ledit jeu de commandes de pilotage comprend, outre les commandes AT standard, une commande AT supplémentaire, dite commande de chargement, permettant à l'application cliente externe de charger une nouvelle seconde application cliente ou la totalité d'un nouveau logiciel client dans le module de radiocommunication. De façon avantageuse, ledit jeu de commandes de pilotage comprend, outre les commandes AT standard, une commande AT supplémentaire, dite commande de désactivation, permettant à l'application cliente externe de désactiver la seconde application cliente. Dans un mode de réalisation particulier de l'invention, ladite seconde application cliente comprend une sous-application cliente principale et au moins une sousapplication cliente secondaire, esclave de la sous-application cliente principale, les traitements effectués par ladite seconde application cliente étant répartis entre ladite sous-application cliente principale et ladite au moins une sous-application cliente secondaire. Le présent mode de réalisation particulier de l'invention se situe donc dans le contexte de la nouvelle technique précitée de pilotage d'un module de radiocommunication. Dans ce contexte, il est proposer d'utiliser non pas une seconde application cliente"monobloc", mais une seconde application cliente"distribuée" ("multiblocs") comprenant une sous-application cliente principale combinée avec une ou plusieurs sous-application (s) cliente (s) secondaire (s). Chaque sous-application cliente secondaire est une sous-application esclave, en terme de lancement et d'arrêt, de la sous-application cliente principale qui l'appelle. Mais une fois démarrée, la sous-application cliente secondaire a accès, indépendamment de la sous-application cliente principale, à l'ensemble des fonctions d'exécution offertes par la première application cliente (via un mécanisme, détaillé par la suite, d'abonnement à un service d'envoi de messages provenant de la première application cliente). Les sous-applications clientes secondaires sont des"blocs élémentaires"qui peuvent être fournis aux clients par un développeur tiers (typiquement le fabriquant du module de radiocommunication). Ainsi, le travail de développement du client est réduit puisqu'il ne développe que la"sous-application cliente principale", qui sous-traite certains traitements en faisant appel à une ou plusieurs sous-application (s) cliente (s) secondaire (s). On notera que le client peut également développer lui-même des sousapplications clientes secondaires, s'il souhaite pouvoir les appeler dans différentes sousapplications clientes principales qu'il développe. De façon préférentielle, ladite fonction source de niveau 1 d'initialisation est comprise dans le jeu de fonctions sources de niveau 1 associé à la seconde application cliente de tâche et permet d'initialiser ladite sous-application cliente principale. Préférentiellement, la sous-application cliente principale est associée à un jeu de fonctions sources de niveau 2 comprenant une fonction source de niveau 2 d'abonnement à un service d'envoi de messages provenant de la première application cliente. Lors de cet abonnement, la sous-application cliente principale communique à la première application cliente l'adresse d'une fonction source de niveau 2 de traitement d'un message, dans laquelle la sous-application cliente principale souhaite recevoir des messages provenant de la première application cliente. C'est ce mécanisme d'abonnement à un service d'envoi de messages provenant de la première application cliente qui permet à la sous-application cliente principale de faire appel à l'ensemble des fonctions d'exécution offertes par la première application cliente, en pouvant recevoir les messages envoyés par la première application cliente dans le cadre de l'exécution de ces fonctions. Préférentiellement, la sous-application cliente secondaire est associée à un jeu de fonctions sources de niveau 2 comprenant une fonction source de niveau 2 d'initialisation de la sous-application cliente secondaire, qui est appelée par la sousapplication cliente principale. De cette façon, la sous-application cliente principale n'a à connaître que ce point de dialogue ("fonction source de niveau 2 d'initialisation de la sous-application cliente secondaire"), ainsi que son pendant présenté ci-après ("fonction source de niveau 2 d'arrêt de la sous-application cliente secondaire"). Il s'agit donc d'une solution simple et efficace aux problèmes de dialogue entre sous-application cliente principale et sousapplication cliente secondaire. En effet, le développeur d'une sous-application cliente secondaire n'a pas à écrire autant de versions de celle-ci que de clients voulant l'intégrer dans leurs sous-applications clientes principales. Il suffit qu'il leur indique les deux points de dialogue précités. Il est à noter qu'il convient d'éviter que deux développeurs de sous-applications clientes secondaires utilisent des points de dialogue identiques. Pour cela, on peut par exemple prévoir que chaque développeur demande auprès d'un service central un identifiant unique pour chaque sous-application cliente secondaire qu'il souhaite développer. Par ailleurs, le mécanisme de dialogue entre la sous-application cliente principale et la sous-application cliente secondaire permet notamment à la sous-application cliente secondaire de communiquer à la sous-application cliente principale les résultats de l'exécution de sa ou ses tâches. Le dialogue peut être bidirectionnel ou monodirectionnel. De façon préférentielle, le jeu de fonctions sources de niveau 2 associé à la sousapplication cliente secondaire comprend une fonction source de niveau 2 d'abonnement à un service d'envoi de messages provenant de la première application cliente. Lors de cet abonnement, la sous-application cliente secondaire communique à la première application cliente l'adresse d'une fonction source de niveau 2 de traitement d'un message, dans laquelle la sous-application cliente secondaire souhaite recevoir des messages provenant de la première application cliente. Préférentiellement, ladite fonction source de niveau 2 d'initialisation de la sousapplication cliente secondaire comprend au moins un paramètre permettant la mise en carre d'un mécanisme de dialogue entre la sous-application cliente principale et la sousapplication cliente secondaire. De façon, préférentielle, le jeu de fonctions sources de niveau 2 associé à la sousapplication cliente secondaire comprend une fonction source de niveau 2 d'arrêt de la sous-application cliente secondaire, qui est appelée par la sous-application cliente principale. Préférentiellement, le jeu de fonctions sources de niveau 2 associé à la sous- application cliente secondaire comprend une fonction source de niveau 2 de désabonnement audit service d'envoi de messages provenant de la première application cliente. L'invention concerne également un procédé d'ouverture de l'accès à au moins certaines des fonctionnalités d'un logiciel principal d'un module de radiocommunication. On suppose que le module de radiocommunication est du type hébergeant et exécutant un logiciel principal comprenant une application de gestion du système d'exploitation (OS), une application de gestion des radiocommunications (couche 3 GSM) et une application de gestion de périphériques pouvant être connectés au module de radiocommunication (HWL). Selon l'invention, chacune desdites applications comprises dans le logiciel principal est associée à un jeu de fonctions d'exécution de niveau 1. Le module de radiocommunication héberge et exécute en outre au moins un logiciel client comprenant au moins une application cliente, associée à un jeu de fonctions sources de niveau 1. Le logiciel principal et/ou ledit logiciel client comprend (nnent) une application d'interface de niveau 1, permettant l'interfaçage des fonctions sources de niveau 1, associées à ladite application cliente, avec les fonctions d'exécution de niveau 1, associées à ladite application de gestion du système d'exploitation et à au moins une desdites applications de gestion des radiocommunications et de gestion de périphériques. D'autres caractéristiques et avantages 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, et des dessins annexés, dans lesquels : la figure 1 présente un schéma simplifié d'un mode de réalisation particulier d'un module de radiocommunication selon la présente invention, faisant apparaître le logiciel principal comprenant les couches basses, ainsi que le logiciel client comprenant une application d'interface de niveau 1 et une pluralité d'applications clientes ; la figure 2 illustre un mécanisme de lancement des applications clientes comprises dans le logiciel client ; la figure 3 illustre un mécanisme de dialogue entre deux applications clientes de tâche comprises dans le logiciel client ; la figure 4 illustre un mécanisme d'appel, au sein d'une application cliente, d'une fonction source de niveau 1 relative au bloc"HWL" ; la figure 5 illustre un mécanisme d'appel, au sein d'une application cliente, d'une fonction source de niveau 1 relative au bloc"couche 3 GSM" ; la figure 6 illustre un mécanisme d'appel, au sein d'une application cliente, de fonctions source de niveau 1 relatives aux blocs"HWL"et"couche 3 GSM" ; la figure 7 illustre un mécanisme d'abonnement d'une application cliente à un service de boîte aux lettres géré par le logiciel principal ; la figure 8 illustre une nouvelle technique de pilotage du module de radiocommunication, supportée par l'architecture logicielle selon l'invention, au sein du module de radiocommunication. L'invention concerne donc un module de radiocommunication hébergeant et exécutant, avec le même jeu de ressources (processeur et mémoire), un logiciel principal et (au moins) un logiciel client embarqué. De façon classique, comme illustré sur la figure 1, le logiciel principal 3 comprend : un bloc"HWL"3a, qui est une application de gestion de périphériques pouvant être connectés au module de radiocommunication ; un bloc"OS"3b, qui est une application de gestion du système d'exploitation, gérant les aspects système tels que le gestionnaire de tâches, le gestionnaire de mémoire, le gestionnaire de temporisation, etc. ; un bloc"couche 3 GSM", qui est une application de gestion des radiocommunications, gérant les aspects réseau tels que la gestion des appels sortants et entrants, la gestion des réceptions et envois de messages courts texte, etc. Chacun des trois blocs"HWL","OS"et"couche 3 GSM"est associé à un jeu de fonctions d'exécution de niveau 1. Dans le mode de réalisation particulier illustré sur la figure 1, le logiciel client embarqué 6 (concept propre à la présente invention) comprend : trois applications clientes, à savoir : une application cliente de démarrage 6a et deux applications clientes de tâche, n01 6b et n 2 6c, chacune de ces applications clientes étant associée àunjeu de fonctions sources de niveau 1 ; une application d'interface de niveau 1 6d, permettant l'interfaçage des fonctions sources de niveau 1 (associées aux applications clientes 6a, 6b et 6c) avec les fonctions d'exécution de niveau 1 (associées aux blocs"HWL"3a,"OS"3b et "couche 3 GSM"3c). Ainsi, les applications clientes 6a, 6b et 6c communiquent avec les blocs"HWL" 3a,"OS"3b et"couche 3 GSM"3c, via l'application d'interface de niveau 1 6d. A cet effet, chacun de ces éléments comprend une interface"API" (pour"Application Programming Interface"en anglais). On rappelle qu'une interface"API"est une description des règles de communication correspondant à un certain ensemble fonctionnel. Chacune des applications clientes 6a, 6b et 6c comprend un bloc"Application Mandatory API", formant interface décrivant des fonctions devant être définies dans l'application cliente. Il est clair que les blocs"Application Mandatory API"des différentes applications clientes peuvent ne pas être strictement identiques. L'application d'interface (ou librairie d'interface application) de niveau 1 6d comprend les quatre blocs suivants : un bloc"HWL API", formant interface décrivant l'accès au bloc"HWL"3a, cette interface décrit des fonctions se trouvant dans la librairie d'interface application de niveau 1 ; un bloc"OS API", formant interface décrivant l'accès au bloc"OS"3b, cette interface décrit des fonctions se trouvant dans la librairie d'interface application de niveau 1 ; un bloc"couche 3 GSM API", formant interface décrivant l'accès au bloc "couche 3 GSM"3c, cette interface décrit des fonctions se trouvant dans la librairie d'interface application de niveau 1 ; un bloc"Standard API", formant interface décrivant l'accès à des fonctions standard, cette interface décrit des fonctions se trouvant dans la librairie d'interface application de niveau 1. Côté logiciel principal 3 : le bloc"HWL"3a comprend un bloc"HWL API", pendant du bloc du même nom compris dans l'application d'interface de niveau 1 6d ; le bloc"OS"3b comprend un bloc"OS API", pendant du bloc du même nom compris dans l'application d'interface de niveau 1 6d ; le bloc"couche 3 GSM"3c comprend un bloc"couche 3 GSM API", pendant du bloc du même nom compris dans l'application d'interface de niveau 1 6d. L'application d'interface de niveau 1 6d est par exemple un fichier binaire, qui se présente sous la forme d'une librairie (déjà compilée). Le logiciel principal 3 est par exemple un fichier binaire, résultant d'une édition de lien entre une pluralité de fichiers objets, résultant eux-mêmes de la compilation de fichiers source contenant notamment les blocs"HWL"3a,"OS"3b et"couche 3 GSM" 3c. En ce qui concerne les applications clientes 6a, 6b et 6c, on peut envisager les variantes suivantes : soit les applications clientes sont contenues dans le logiciel client 6 sous la forme d'un même fichier binaire, résultant d'une édition de lien impliquant notamment les fichiers objet contenant ces applications clientes ; soit les applications clientes sont contenues dans le logiciel client 6 sous la forme de plusieurs fichiers binaires (chaque fichier binaire contenant une ou plusieurs applications clientes). Le logiciel client embarqué 6 et le logiciel principal 3 utilisent chacun une partie distincte d'une même mémoire vive (RAM). Le client définit la taille de la pile mémoire nécessaire à la bonne exécution du logiciel client embarqué. Une tentative d'accès de l'un des deux logiciels à une partie de la mémoire vive réservée à l'autre logiciel provoque un arrêt de fonctionnement. On présente maintenant, en relation avec la figure 2, un mécanisme de lancement des applications clientes 6a, 6b et 6c comprises dans le logiciel client 6. Les éléments compris dans le module de radiocommunication 1, et déjà présentés ci-dessus en relation avec la figure 1, conservent les mêmes références numériques. Chacune des étapes de ce mécanisme est illustrée sur la figure 2 par un cercle dans lequel est inscrit le numéro de l'étape concernée. La même convention est adoptée dans les figures suivantes relatives à la présente invention (et qui sont décrites en détail dans la suite de la description). Le fonctionnement de ce mécanisme de lancement des applications clientes 6a, 6b et 6c peut être résumé ainsi : - étape" !" : le logiciel principal 3 détecte la présence d'une application cliente de démarrage 6a et la lance par l'intermédiaire du gestionnaire OS 3b (autre nom du"bloc OS"présenté auparavant) ; - étape "2" : le lancement de l'application cliente de démarrage 6a se fait via l'application d'interface de niveau 1 6d. Cette dernière appelle au sein de l'application cliente de démarrage 6a une fonction source (de niveau 1) de démarrage global. Cette fonction source ("wmapmGlobalInitIevellQ") est présentée en détail dans la suite de la description ; - étape "3" : au sein de l'application cliente de démarrage 6a, la fonction source "wm~apmGIobalInitlevellO"effectue un démarrage global consistant à à fournir au logiciel principal 3 des informations permettant à ce dernier d'initialiser et dialoguer avec chaque application cliente de tâche 6b et 6c. Ces informations sont par exemple les suivantes : le nombre d'applications clientes de tâche (deux dans l'exemple décrit ci-dessus) comprises dans le logiciel client embarqué, les fonctions de dialogue associées à chacune de ces applications clientes de tâche. Ces fonctions source de dialogue ("AppliInitn x~levell"et"AppliParsern x~levell") sont présentées en détail dans la suite de la description ; - étape "4" : au sein du logiciel principal 3, le gestionnaire OS 3b initialise les applications clientes de tâche 6b et 6c en appelant leurs fonctions d'initialisation respectives ("AppliInitl Jevell" et "AppliInit2 ~levell"). On présente maintenant, en relation avec la figure 3, un mécanisme de dialogue entre deux applications clientes de tâche 6b, 6c comprises dans le logiciel client 6. Le fonctionnement de ce mécanisme peut être résumé ainsi : - étape" !" : le logiciel principal 3 a initialisé l'application cliente de tâche n l par l'appel de la fonction source AppliInitl~levellO au travers de l'application d'interface de niveau 1 6d. Cette fonction source effectue l'appel à une fonction ("wmosStartTimerlevcI10") de déclenchement d'une temporisation dans le logiciel principal ; - étape "2" : l'application d'interface 6d appelle, au sein du logiciel principal 3, la ou les fonction d'exécution appropriée (s) ; - étape "3" : au sein du logiciel principal 3, le gestionnaire OS 3b effectue le traitement demandé qui consiste à armer une temporisation ; - étape "4" : après échéance de la temporisation, le gestionnaire OS 3b informe l'application cliente de tâche n01 ayant armé la temporisation, au travers de l'application d'interface 6d ; - étape "5" : le dialogue avec l'application cliente de tâche n01 se fait via l'application d'interface 6d, qui appelle au sein de l'application cliente de tâche n01 la fonction source"AppliParscrlleveI10"précitée ; - étape "6" : au sein de l'application cliente de tâche n01, la fonction source "AppliParserl~1evellO" appelée envoie un message à l'application cliente de tâche n 2, en appelant une fonction source "wmosSendMsgIevell ()" (présentée en détail par la suite) ; - étape "7" : l'application d'interface 6d appelle, au sein du logiciel principal 3, la ou les fonction d'exécution appropriée (s) ; - étape "8" : au sein du logiciel principal 3, le gestionnaire OS 3b effectue le traitement demandé qui consiste à envoyer le message à l'application cliente de tâche n 2, à travers l'application d'interface 6d ; - étape "9" : le dialogue avec l'application cliente de tâche n 2 se fait via l'application d'interface 6d, qui appelle au sein de l'application cliente de tâche n02 la fonction source "AppliParser2~levellO" précitée ; - étape"10" : au sein de l'application cliente de tâche n 2, la fonction source "AppliParser2levell0"appelée traite le message reçu. On présente maintenant, en relation avec la figure 4, un mécanisme d'appel, au sein d'une application cliente, d'une fonction source de niveau 1 relative au bloc"HWL". On suppose qu'une temporisation a été armée par l'application cliente de tâche n l, et qu'elle est en attente d'expiration de cette temporisation. Dans cet exemple, les appels au gestionnaire HWL 3a sont effectués par l'application cliente de tache n l. il est clair que cet exemple reste valable si les appels sont effectués par toute autre application cliente de tâche du logiciel client embarqué. Le fonctionnement de ce mécanisme peut être résumé ainsi : - étape" !" : après échéance de la temporisation, le gestionnaire OS 3b informe l'application cliente de tâche n01 ayant armé la temporisation, au travers de l'application d'interface 6d ; - étape "2" : le dialogue avec l'application cliente de tâche n01 se fait via l'application d'interface 6d, qui appelle au sein de l'application cliente de âche n l la fonction source"AppliParserl-levello" ; - étape "3" : au sein de l'application cliente de tâche n01, la fonction source "AppliParserllevellO"souhaite par exemple lire une valeur stockée en mémoire Eeprom. Pour cela, elle appelle la fonction "wmhwlE2pReadlevellO" ; - étape "4" : l'application d'interface 6d appelle, au sein du logiciel principal 3, la ou les fonction d'exécution appropriée (s) dans le gestionnaire HWL 3a ; - étape "5" : au sein du logiciel principal 3, le gestionnaire HWL 3a effectue le traitement demandé, qui consiste à lire une valeur stockée en mémoire Eeprom. Puis l'application cliente de tâche n l, via l'application d'interface 6d, retourne la valeur lue à l'application cliente de tâche n 1. Il est clair que la fonction "wm~hwlE2pRead~level1()", discutée ci-dessus, n'est qu'un exemple parmi une pluralité de fonctions source de niveau 1 relatives au bloc"HWL". On présente maintenant, en relation avec la figure 5, un mécanisme d'appel, au sein d'une application cliente, d'une fonction source de niveau 1 relative au bloc"couche 3 GSM". Les hypothèses et remarques indiquées ci-dessus en commentaires de la figure 4 s'appliquent également à la présente figure 5. Le fonctionnement de ce mécanisme peut être résumé ainsi : - étape" !" : après échéance de la temporisation, le gestionnaire OS 3b informe l'application cliente de tâche n01 ayant armé la temporisation, au travers de l'application d'interface 6d ; - étape "2" : le dialogue avec l'application cliente de tâche n01 se fait via l'application d'interface 6d, qui appelle au sein de l'application cliente de tâche n01 la fonction source"AppliParserl~levellO" ; - étape "3" : au sein de l'application cliente de tâche nl, la fonction source "AppliParserllevell ()" souhaite par exemple envoyer un message au réseau. Pour cela, elle appelle la fonction"wmosRfkSendlcvellQ" ; - étape "4" : l'application d'interface 6d appelle, au sein du logiciel principal 3, la ou les fonction d'exécution appropriée (s) dans le gestionnaire"Couche 3 GSM"3c ; - étape "5" : au sein du logiciel principal 3, le gestionnaire"Couche 3 GSM"3c effectue le traitement demandé ; - étape "6" : après traitement (envoi d'un message au réseau) et obtention d'une réponse du réseau, le gestionnaire"Couche 3 GSM"3c informe l'application cliente de tâche nl, via l'application d'interface 6d ; - étape "7" : le dialogue avec l'application cliente de tâche n01 se fait via l'application d'interface 6d, qui appelle au sein de l'application cliente de tâche n l la fonction source"AppliParserlleveI10"précitée ; - étape "8" : au sein de l'application cliente de tâche nl, la fonction source "AppliParserlJevellQ"traite le message reçu. Il est clair que la fonction "wm~osRtkSend~level1()", discutée ci-dessus, n'est qu'un exemple parmi une pluralité de fonctions source de niveau 1 relatives au bloc"couche 3 GSM". On présente maintenant, en relation avec la figure 6, un mécanisme d'appel, au sein d'une application cliente, de fonctions source de niveau 1 relatives aux blocs"HWL"et "couche 3 GSM". Dans cet exemple, on suppose que l'application cliente de tâche n01 souhaite lire une valeur stockée en mémoire Eeprom, puis envoyer un message au réseau. Elle dialogue pour cela : avec le bloc"HWL"3a (étapes'1"à"5"correspondant aux étapes"1"à"5"de la figure 4 décrite ci-dessus), puis avec le bloc"Couche 3 GSM"3c (étapes"3bis","6"et"7"correspondant aux étapes"3"à"5"de la figure 5 décrite ci-dessus). On présente maintenant, en relation avec la figure 7, un mécanisme d'abonnement d'une application cliente à un service de boîte aux lettres géré par le logiciel principal. Le fonctionnement de ce mécanisme peut être résumé ainsi : - étape" 1" : après échéance de la temporisation, le gestionnaire OS 3b informe l'application cliente de tâche n01 ayant armé la temporisation, au travers de l'application d'interface 6d ; - étape "2" : le dialogue avec l'application cliente de tâche n01 se fait via l'application d'interface 6d, qui appelle au sein de l'application cliente de tâche n l la fonction source"AppIiParscrllevell ()" ; - étape "3" : au sein de l'application cliente de tâche n l, la fonction source "AppliParserllevellO"souhaite par exemple demander un abonnement aux informations relatives à la batterie (indication de niveau de charge, par exemple). Pour cela, elle appelle une fonction source ("wmMbxSubscribeO") d'inscription à un service de boîte aux lettres géré par le logiciel principal, de façon à se voir affecter une boîte aux lettres qui lui est propre et dans laquelle elle souhaite recevoir des informations provenant d'au moins une source prédéterminée (la tâche "batterie"dans cet exemple). Cette fonction source est présentée en détail par la suite ; - étape "4" : l'application d'interface 6d appelle, au sein du logiciel principal 3, la ou les fonction d'exécution appropriée (s) dans le gestionnaire OS 3b ; - étape "5" : au sein du logiciel principal 3, le gestionnaire OS 3b effectue le traitement demandé, qui consiste dans cet exemple à mémoriser l'application cliente de tâche n01 en tant que destinatrice des informations de batterie ; - étape "6" : quand des informations de batterie sont disponibles, le gestionnaire HWL 3a les envoie à l'application cliente de tâche n l, via l'application d'interface 6d. Pour cela, le gestionnaire HWL 3a consulte en interne le gestionnaire OS 3b, afin de connaître la ou les boîte (s) aux lettres destinatrice (s) de ces informations ; - étape"7" : le dialogue avec l'application cliente de tâche n01 se fait via l'application d'interface 6d, qui appelle au sein de l'application cliente de tâche n01 la fonction source"AppIiParserlIevcllO"précitée ; - étape "8" : au sein de l'application cliente de tâche nl, la fonction source "AppliParserlIevellQ"traite les informations de batterie reçues. Il est à noter que le bloc"OS"3b comprend un gestionnaire de tâches. Ce dernier gère aussi bien les tâches offertes par le logiciel principal 3 que celles offertes par le logiciel client 6. Chaque tâche est associée à une boîte aux lettres, qui est assimilée à la source des informations générées par cette tâche. Ainsi, à chaque fois q'une tâche veut communiquer avec une autre tâche, elle utilise le gestionnaire de tâche du bloc"OS". Certaines tâches du logiciel principal 3 ont des informations à communiquer au logiciel client embarqué 6. Ce dernier peut décider vers laquelle de ses applications de tâche il veut recevoir ces informations. Ainsi, dans l'exemple décrit ci-dessus, la tâche"batterie" du logiciel principal 3 possède des informations qui concernent la gestion de la batterie et c'est l'application cliente de tâche n l qui les gère (et donc souhaite les recevoir dans sa boîte aux lettres). On présente maintenant, en relation avec la figure une nouvelle technique de pilotage du module de radiocommunication, supportée par l'architecture logicielle selon l'invention, au sein du module de radiocommunication. Un mode de réalisation particulier de l'architecture logicielle du module de radiocommunication, selon l'invention, a été présenté ci-dessus en relation avec les figures 1 à 7. Dans ce mode de réalisation particulier, le logiciel principal 3 comprend les blocs"HWL"3a,"OS"3b et"couche 3 GSM"3c, et le logiciel client embarqué 6 comprend une application cliente de démarrage 6a, deux applications clientes de tâche (n l) 6b et (n 2) 6c, et une application d'interface de niveau 1 6d. Dans la suite de la description, on suppose que les commandes de pilotage sont des commandes AT. Pour plus de précisions concernant les commandes AT, on pourra se reporter d'une part aux normes"GSM 07. 05" et"GSM 07. 07" de l'ETSI et d'autre part à la recommandation V25ter de l'ITU-T, qui sont insérées ici par référence. Il est clair toutefois que la présente invention n'est nullement limitée à ce type de commande de pilotage. Afin de proposer une nouvelle technique de pilotage du module de radiocommunication, on prévoit que : l'application cliente de tâche n l réalise une première tâche temps réel d'exécution de commandes AT. Ces dernières sont envoyées à l'application cliente de tâche n l par (au moins) une application cliente de pilotage ; l'application cliente de tâche n 2 réalise une seconde tâche temps réel lui permettant de jouer au moins un des deux rôles suivants : * le rôle d'une application cliente de pilotage, envoyant des commandes AT à l'application cliente de tâche n01, et recevant de l'application cliente de tâche n01 des réponses, résultant de l'exécution de certaines des commandes AT ; * le rôle d'une application cliente de supervision, gérant l'exécution de commandes AT envoyées par une application cliente de pilotage, dite application cliente externe, hébergée et exécutée par un équipement tiers coopérant avec le module de radiocommunication. L'application cliente de tâche n01 est basée notamment sur un jeu de fonctions d'exécution de niveau 2, spécifiques aux commandes AT et permettant chacune l'exécution d'au moins une des commandes AT. L'application cliente de tâche n 2 est basée notamment sur un jeu de fonctions sources de niveau 2, spécifiques aux commandes AT et permettant chacune l'envoi ou la réception, vers ou en provenance de l'application cliente de tâche n l, de commandes AT ou de réponses à des commandes AT. On prévoit en outre une application d'interface de niveau 2 6e, spécifique aux commandes AT. Elle permet l'interfaçage des fonctions sources et d'exécution de niveau 2. Cette interface de niveau 2 6e s'appuie elle-même sur l'application d'interface de niveau 1 6d. Il est important de bien distinguer : les jeux de fonctions source et d'exécution de niveau 2, spécifiques aux commandes AT, et qui sont utilisés dans les relations entre les applications clientes de tâche n l et 2 ; les jeux de fonctions source et d'exécution de niveau 1, présentés ci-dessus de façon détaillée en relation avec les figures 1 à 7 et avec l'annexe 1, et qui sont utilisés dans les relations entre chaque application cliente de tâche (n l ou 2) et les blocs"HWL","OS"et"couche 3 GSM"du logiciel principal 3. Dans le cas où l'application cliente de tâche n 2 joue le rôle d'une application cliente de pilotage, le fonctionnement de la technique de pilotage peut être résumé ainsi - étape" !" : l'application cliente de tâche n 2 appelle une fonction source (wmatSendCommandlevel2") d'envoi vers l'application cliente de tâche n01 d'une ou plusieurs commande (s) AT. Cette fonction source est présentée en détail dans la suite de la description ; - étape "2" : l'application d'interface de niveau 2 6e appelle la ou les fonctions d'exécution appropriées au sein de l'application cliente de tâche n l ; - étape "3" : l'application cliente de tâche n01 exécute la ou les commande (s) AT ; - étape "4" : après exécution, l'application cliente de tâche n01 envoie la ou les réponse (s) AT à l'application cliente de tâche n 2 (si la commande d'envoi précitée a été paramétrée en ce sens) ; - étape "5" : cette ou ces réponse (s) est (sont) expédiée (s) via l'application d'interface de niveau 2, qui appelle, au sein de l'application cliente de tâche n 2, la fonction source ("wm~apmAppliParserlevel2") de traitement d'un message provenant de l'application cliente de tâche n l. Un paramètre de cette fonction source de traitement est le message qui contient la ou les réponse (s) précitée (s). Cette fonction source est présentée en détail dans la suite de la description ; - étape "6" : au sein de l'application cliente de tâche n 2, la fonction source de traitement traite la réponse. On présente maintenant de façon détaillée le cas où l'application cliente de tâche n 2 joue le rôle d'une application cliente de supervision. Dans ce second cas, le module de radiocommunication n'est pas autonome (contrairement au premier cas), mais est piloté par un équipement tiers avec lequel il coopère, par exemple via une liaison série. Une application cliente externe, hébergée par l'équipement tiers, envoie des commandes AT au module de radiocommunication, en vue de leur exécution par ce dernier. Dans ce second cas, de façon transparente pour l'application cliente externe, l'application cliente de tâche n 2 supervise l'exécution (ou non) des commandes AT par l'application cliente de tâche n l. L'application cliente de tâche n 2 (application de supervision) peut décider de la mise en ouvre, au sein du module de radiocommunication, notamment de : un mécanisme d'aiguillage et de traitement des commandes AT, envoyées par l'application cliente externe. Trois variantes de mise en ouvre de ce mécanisme sont par exemple proposées, selon lesquelles l'application cliente de tâche nl transmet les commandes AT qu'elle reçoit : soit uniquement à des moyens d'exécution compris dans l'application cliente de tâche n l (première variante), soit uniquement à l'application cliente de tâche n 2 (seconde variante), soit aux deux (troisième variante) ; un mécanisme d'aiguillage et de traitement des réponses AT, résultant de l'exécution par des moyens d'exécution compris dans l'application cliente de tâche n01 de commandes AT. Trois variantes de mise en ouvre de ce mécanisme sont par exemple proposées, selon lesquelles les réponses AT générées par l'application cliente de tâche n l sont transmises respectivement uniquement à l'application cliente externe (première variante), uniquement à l'application cliente de tâche n 2 (seconde variante), ou bien aux deux (troisième variante). On notera que la première variante de chacun des deux mécanismes précités (relatifs aux commandes AT et aux réponses AT respectivement) signifie que l'application cliente de tâche n 2 peut décider d'être totalement passive à certains moments. On présente maintenant la seconde variante du mécanisme d'aiguillage et de traitement des commandes AT, qui permet à l'application cliente de tâche n 2 de filtrer les commandes AT provenant de l'application cliente externe. Le fonctionnement de cette seconde variante du mécanisme d'aiguillage et de traitement des commandes AT peut être résumé en deux phases successives, à savoir : une phase préalable de sélection, par l'application cliente externe, de la (seconde) politique d'aiguillage de commandes AT, selon laquelle les commandes AT sont retransmises uniquement à l'application cliente de tâche n 2, et une phase de traitement, selon la (seconde) politique d'aiguillage de commandes sélectionnée, des commandes AT envoyées par l'application cliente externe. La phase préalable de sélection de la seconde politique d'aiguillage de commandes AT comprend les étapes suivantes : - étape "1" : l'application cliente de tâche n 2 appelle une fonction source ("wmatCmdPreParserSubscribeleveI2") d'inscription auprès de l'application cliente de tâche n l à un service d'aiguillage de commandes AT (ou"command pre-parsing service"en anglais), avec un paramètre de cette fonction d'inscription qui indique le choix de la seconde politique d'aiguillage de commandes AT. Cette fonction source est présentée en détail dans la suite de la description ; - étape "2" : l'application d'interface de niveau 2 6e appelle, au sein de l'application cliente de tâche n01, la ou les fonction (s) d'exécution appropriée (s), dite (s) fonction d'enregistrement de l'inscription au service d'aiguillage de commandes AT ; - étape "3" : l'application cliente de tâche n01 établit l'inscription demandée par l'application cliente de tâche n 2, via l'application d'interface de niveau 2. Dans un seul souci de simplification, on suppose dans la suite de la description que la ou les fonction (s) d'enregistrement de l'inscription au service d'aiguillage de commandes AT sont comprises, au sein de l'application cliente de tâche n l, dans les moyens d'exécution de commandes AT. Egalement dans un seul souci de simplification, on suppose dans la suite de la description que les moyens d'aiguillage de commandes (discutés ci-après) sont compris, au sein de l'application cliente de tâche n l, dans les moyens d'exécution de commandes AT. La phase de traitement des commandes AT comprend les étapes suivantes : - étape "4" : l'application cliente externe envoie une commande AT à l'application cliente de tâche n l ; - étape "5" : la liaison série transmet la commande AT à des moyens d'aiguillage de commandes, compris dans les moyens d'exécution compris dans l'application cliente de tâche n01 et fonctionnant selon la seconde politique d'aiguillage de commandes AT (sélectionnée lors de la phase préalable) ; - étape "6" : sans être exécutée par les moyens d'exécution, la commande AT est retransmise uniquement à l'application cliente de tâche n 2 ; - étape "7" : la commande AT est expédiée par l'application d'interface de niveau 2, qui appelle, au sein de l'application cliente de tâche n 2, la fonction source ("wmapmAppliParserIcvcl2") de traitement d'un message provenant de l'application cliente de tâche n01, paramétrée ici notamment par un message qui contient la commande AT et qui indique qu'il s'agit de la commande AT"originale". Cette fonction source est présentée en détail dans la suite de la description ; - étape"8" : au sein de l'application cliente de tâche n 2, la fonction source de traitement traite la commande AT. Ce traitement consiste par exemple à renvoyer la commande AT vers les moyens d'exécution compris dans l'application cliente de tâche n l (selon le mécanisme correspondant au premier cas décrit ci-dessus). Il peut également consister en la fourniture arbitraire d'une réponse par l'application cliente de tâche n 2 elle-même, sans que la commande AT soit exécutée. Dans ce cas, l'application cliente de tâche n 2 tient par exemple compte d'au moins une information relative à la commande AT concernée (type de commande, nature du ou des paramètres, etc). D'une façon générale, quel que soit le traitement effectué, on comprend que l'application cliente de tâche n 2"filtre"la commande AT. On présente maintenant la troisième variante du mécanisme d'aiguillage et de traitement des commandes AT, qui permet à l'application cliente de tâche n 2 d'espionner les commandes AT provenant de l'application cliente externe. Le fonctionnement de cette troisième variante du mécanisme d'aiguillage et de traitement des commandes AT peut aussi être résumé en deux phases successives, à savoir : une phase préalable de sélection, par l'application cliente externe, de la (troisième) politique d'aiguillage de commandes AT, selon laquelle les commandes AT sont retransmises non seulement à l'application cliente de tâche n 2 mais aussi aux moyens d'exécution compris dans l'application cliente de tâche n l, et une phase de traitement, selon la (troisième) politique d'aiguillage de commandes sélectionnée, des commandes AT envoyées par l'application cliente externe. Le fonctionnement de cette troisième variante diffère de celui de la seconde variante essentiellement en ce que : lors de l'étape "1" de la phase préalable, l'application cliente de tâche n 2 sélectionne la troisième (et non pas la seconde) politique d'aiguillage de commandes AT ; lors de l'étape "6" de la phase de traitement, la commande AT est transmise aux moyens d'exécution et une copie de cette commande AT est transmise à l'application cliente de tâche n 2 ; lors de l'étape "8" de la phase de traitement, au sein de l'application cliente de tâche n 2, la fonction source de traitement traite la copie de la commande AT ; la phase de traitement comprend en outre une étape"7"', au cours de laquelle les moyens d'exécution compris dans l'application cliente de tâche n l exécutent la commande AT. On présente maintenant la seconde variante du mécanisme d'aiguillage et de traitement des réponses AT, qui permet à l'application cliente de tâche n 2 de filtrer les réponses AT destinées à l'application cliente de tâche n 1. Le fonctionnement de cette seconde variante du mécanisme d'aiguillage et de traitement des réponses AT peut aussi être résumé en deux phases successives, à savoir : une phase préalable de sélection, par l'application cliente externe, de la (seconde) politique d'aiguillage de réponses AT, selon laquelle les réponses AT générées par l'application cliente de tâche n l sont transmises uniquement à l'application cliente de tâche n 2 ; une phase de traitement, selon la (seconde) politique d'aiguillage de réponses sélectionnée, des réponses AT générées par l'application cliente de tâche n01. La phase préalable de sélection de la seconde politique d'aiguillage de réponses AT comprend les étapes suivantes : - étape" !" : l'application cliente de tâche n 2 appelle une fonction source ("wrrLatRspPreParserSubscribe-level2") d'inscription auprès de l'application cliente de tâche n01 à un service d'aiguillage de réponses AT (ou"response pre-parsing service"en anglais), avec un paramètre de cette fonction d'inscription qui indique le choix de la seconde politique d'aiguillage de réponses AT. Cette fonction source est présentée en détail dans la suite de la description ; - étape "2" : l'application d'interface de niveau 2 6e appelle, au sein de l'application cliente de tâche n01, la ou les fonction (s) d'exécution appropriée (s), dite (s) fonction d'enregistrement de l'inscription au service d'aiguillage de réponses AT ; - étape "3" : l'application cliente de tâche n l établit l'inscription demandée par l'application cliente de tâche n 2, via l'application d'interface de niveau 2. Dans un seul souci de simplification, on suppose dans la suite de la description que la ou les fonction (s) d'enregistrement de l'inscription au service d'aiguillage de réponse AT sont comprises, au sein de l'application cliente de tâche n l, dans les moyens d'exécution de commandes AT. Egalement dans un seul souci de simplification, on suppose dans la suite de la description que les moyens d'aiguillage de réponses (discutés ci-après) sont compris, au sein de l'application cliente de tâche n l, dans les moyens d'exécution de commandes AT. La phase de traitement des réponses AT comprend les étapes suivantes : 1 - étape "4" : l'application cliente externe envoie une commande AT à l'application cliente de tâche nO 1 ; - étape "5" : la liaison série transmet la commande AT aux moyens d'exécution compris dans l'application cliente de tâche n l ; - étape "6" : les moyens d'exécution exécutent la commande AT et génère une réponse AT ; - étape"7" : des moyens d'aiguillage de réponses, compris dans les moyens d'exécution et fonctionnant selon la seconde politique d'aiguillage de réponses AT (sélectionnée lors de la phase préalable), envoient la réponse AT à l'application cliente de tâche n 2 ; - étape "8" : la réponse AT est expédiée par l'application d'interface de niveau 2, qui appelle, au sein de l'application cliente de tâche n 2, la fonction source ("wm~apmAppliParserlevel2") de traitement d'un message provenant de l'application cliente de tâche n l, paramétrée ici notamment par un message qui contient la réponse AT et qui indique qu'il s'agit de la réponse AT"originale" ; - étape "9" : au sein de l'application cliente de tâche n 2, la fonction source de traitement traite la réponse AT. On peut parler ici de"filtrage"des réponses AT par l'application cliente de tâche n 2. On présente maintenant, en relation avec la figure 7, la troisième variante du mécanisme d'aiguillage et de traitement des réponses AT, qui permet à l'application cliente de tâche n 2 d'espionner les réponses AT destinées à l'application cliente de tâche nO 1. Le fonctionnement de cette troisième variante du mécanisme d'aiguillage et de traitement des réponses AT peut aussi être résumé en deux phases successives, à savoir : une phase préalable de sélection, par l'application cliente externe, de la (troisième) politique d'aiguillage de réponses AT, selon laquelle les réponses AT sont retransmises non seulement à l'application cliente de tâche n01 mais aussi à l'application cliente de tâche n 2, et une phase de traitement, selon la (troisième) politique d'aiguillage de réponses sélectionnée, des réponses AT générées par l'application cliente de tâche n l. Le fonctionnement de cette troisième variante diffère de celui de la seconde variante essentiellement en ce que : lors de l'étape "1" de la phase préalable, l'application cliente de tâche n 2 sélectionne la troisième (et non pas la seconde) politique d'aiguillage de réponses AT ; lors de l'étape "7" de la phase de traitement, la réponse AT est transmise à l'application cliente externe et une copie de cette réponse AT est transmise vers l'application cliente de tâche n 2 ; lors de l'étape "9" de la phase de traitement, au sein de l'application cliente de tâche n 2, la fonction source de traitement traite la copie de la réponses AT ; la phase de traitement comprend en outre une étape"8"', au cours de laquelle la réponse est envoyée à travers la liaison série, et une étape"9"'au cours de laquelle l'application cliente externe reçoit et traite la réponse. Dans une variante de la nouvelle technique selon l'invention de pilotage du module de radiocommunication (dont un mode de réalisation particulier a été décrit cidessus), l'application cliente de tâche n 2 6c n'est pas"monobloc", mais"distribuée" ("multiblocs"). Elle comprend une sous-application cliente principale 7 combinée avec une ou plusieurs sous-application (s) cliente (s) secondaire (s) 8. Chaque sous-application cliente secondaire 8 est une sous-application esclave, en terme de lancement et d'arrêt, de la sous-application cliente principale 7 qui l'appelle. Mais une fois démarrée, la sousapplication cliente secondaire 8 a accès, indépendamment de la sous-application cliente principale 7, à l'ensemble des fonctions d'exécution offertes par la sous-application cliente de tâche n l (via un mécanisme, détaillé par la suite, d'abonnement à un service d'envoi de messages provenant de l'application cliente de tâche n e). Chaque sous-application cliente secondaire est un"bloc élémentaire"qui peut être fourni au client par un développeur tiers (typiquement le fabriquant du module de radiocommunication). Ainsi, le travail de développement du client est réduit puisqu'il ne développe que la sous-application cliente principale, qui sous-traite certains traitements en faisant appel àune ou plusieurs sous-application (s) cliente (s) secondaire (s). On notera que le client peut également développer lui-même des sousapplications clientes secondaires, s'il souhaite pouvoir les appeler dans différentes sousapplications clientes principales qu'il développe. On présente ci-après successivement la mise en ouvre de plusieurs mécanismes dans le cadre de la variante précitée de la nouvelle technique selon l'invention de pilotage du module de radiocommunication. On présente tout d'abord un mécanisme de lancement de la sous-application cliente principale 7 et d'abonnement de celle-ci à un service d'envoi de messages provenant de l'application cliente de tâche n l. Le fonctionnement de ce mécanisme peut être résumé ainsi : - étape" !" : l'application cliente de tâche n l détecte la présence d'une sous- application cliente principale et la lance ; - étape "2" : le lancement de la sous-application cliente principale se fait via l'application d'interface de niveau 2, qui appelle au sein de la sous- application cliente principale une fonction source d'initialisation de la sous-application cliente principale. Cette fonction source ("wmapmAppliInit2Ievell") est présentée en détail dans la suite de la description ; - étape "3" : au sein de la sous-application cliente principale, la fonction source "wm~apmAppliInit2~level1" initialise la sous-application cliente principale. Comme expliqué en détail dans les étapes suivantes ("4"à "6"), cette initialisation consiste notamment à donner à l'application cliente de tâche n l l'adresse d'une fonction source (par exemple "wmapmAppIiParserleveI2") permettant à la sous-application cliente principale de recevoir des messages provenant d : l'application cliente de tâche n01 ; - étape "4" : la sous-application cliente principale fait appel à une fonction source d'abonnement à un service d'envoi de messages provenant de l'application cliente de tâche n l ("wmosMsgParscrSubscribeIevel2"). Cette fonction source est présentée en détail dans la suite de la description ; 1 tt il - étape 5 l'application d'interface de niveau 2 appelle, au sein de l'application cliente de tâche n l, la ou les fonction d'exécution appropriée (s), dite (s) fonction d'enregistrement de l'abonnement (ou inscription) au service d'envoi des messages destinés à la sous-application cliente principale ; - étape "6" : l'application cliente de tâche n l établit l'inscription demandée, via l'application d'interface de niveau 2, par la sous-application cliente principale. Selon une variante, l'application cliente de tâche n l fait appel à la fonction source "wm~osMsgParserSubscribe~leve12" quand elle le souhaite (indépendamment de l'exécution de la fonction source d'initialisation). On présente maintenant un mécanisme de lancement de la sous-application cliente secondaire 8 et d'abonnement de celle-ci à un service d'envoi de messages provenant de l'application cliente de tâche n l. Le fonctionnement de ce mécanisme peut être résumé comme suit : - étape" !" : la sous-application cliente principale, après réception d'un message dans sa fonction source "wm~apmAppliParser~level2()", appelle une fonction source de la sous-application cliente secondaire, à savoir la fonction source d'initialisation de l'application cliente secondaire 8 ("wmapp2Pipelevel2 (init)"). Cette fonction source (qui doit être connue de la sous-application cliente principale est présentée en détail dans la suite de la description ; - étape "2" : au sein de la sous-application cliente secondaire, la fonction source "wmapp2PipeIcveI2 (init)" initialise la sous-application cliente secondaire. Comme expliqué en détail dans les étapes suivantes ("3"à "5"), cette initialisation consiste notamment à donner à l'application cliente de tâche n01 l'adresse d'une fonction source (par exemple "wmapp2MsgParserlevel2") permettant à la sous-application cliente secondaire de recevoir des messages provenant de l'application cliente de tâche n l ; - étape "3" : la sous-application cliente secondaire fait appel à la fonction source d'abonnement à un service d'envoi de messages provenant de l'application cliente de tâche n l ("wm~osMsgParserSubscribe~level2"). Cette fonction source est présentée en détail dans la suite de la description ; - étape "4" : l'application d'interface de niveau 2 appelle, au sein de l'application cliente de tâche n01, la ou les fonction d'exécution appropriée (s), dite (s) fonction d'enregistrement de l'abonnement (ou inscription) au service d'envoi des messages destinés àla sous-application cliente secondaire ; - étape "5" : l'application cliente de tâche n l établit l'inscription demandée, via l'application d'interface de niveau 2 6e, par la sous-application cliente secondaire 8. Après qu'elle a été ainsi lancée, la sous-application cliente secondaire 8 effectue sa fonction (ensemble de traitements ou tâches), de façon autonome par rapport à la sous-application cliente principale 7. Comme expliqué en détail ci-après, elle a pour cela à sa disposition l'ensemble des fonctions d'exécution offertes par l'application cliente de tâche n l. Selon une variante, la sous-application cliente secondaire 8 fait appel à la fonction source "wm~osMsgParserSubscribe~leve12" quand elle le souhaite (indépendamment de l'exécution de la fonction source d'initialisation de la sousapplication cliente secondaire). On notera que la fonction source d'initialisation de la sous-application cliente secondaire peut comprendre au moins un paramètre permettant la mise en ouvre d'un mécanisme de dialogue entre la sous-application cliente principale et la sous-application cliente secondaire. Cette caractéristique de l'invention est décrite en détail dans la suite de la description. On présente maintenant un mécanisme d'arrêt de la sous-application cliente secondaire 8 et de désabonnement de celle-ci au service d'envoi de messages provenant de l'application cliente de tâche n l. Le fonctionnement de ce mécanisme peut être résumé comme suit : - étape" !" : la sous-application cliente principale 7, après réception d'un message dans sa fonction source"wmapmAppliParserlevel20", appelle une fonction source de la sous-application cliente secondaire 8, à savoir la fonction source d'arrêt de la sous-application cliente secondaire ("wm~app2Pipe~level2 (stop)"). Cette fonction source (qui doit être connue de la sous-application cliente principale) est présentée en détail dans la suite de la description ; - étape "2" : au sein de la sous-application cliente secondaire 8, la fonction source "wm~app2Pipelevel2 (stop)" effectue les traitements d'arrêt de la sous- application cliente secondaire. Comme expliqué en détail dans les étapes suivantes ("3"à"5"), ces traitements consistent notamment pour la sous- application cliente secondaire à se désabonner du service d'envoi de messages venant de l'application cliente de tâche n01 ; - étape "3" : la sous-application cliente secondaire fait appel à la fonction source de désabonnement au service d'envoi de messages provenant de l'application cliente de tâche n01 ("wmosMsgParserUnsubscribeIeveI2"). Cette fonction source est présentée en détail dans la suite de la description ; - étape "4" : l'application d'interface de niveau 2 appelle, au sein de l'application cliente de tâche n l, la ou les fonction d'exécution appropriée (s), dite (s) fonction désabonnement (ou de retrait de l'inscription) au service d'envoi des messages destinés àla sous-application cliente secondaire ; - étape "5" : l'application cliente de tâche n01 établit l'arrêt de l'inscription, demandé, via l'application d'interface de niveau 2, par la sous-application cliente secondaire. On présente maintenant un exemple de traitements pouvant être effectués par la sousapplication cliente secondaire, pour décharger la sous-application cliente principale. Dans cet exemple, on suppose que : l'application cliente de tâche n 2 joue le rôle d'une application cliente de pilotage ? les traitements consistent en l'envoi par la sous-application cliente secondaire 8 d'une commande et la réception de la réponse correspondante ; la sous-application cliente secondaire 8 a été initialisée et qu'elle s'est abonnée au service d'envoi de messages venant de l'application cliente de tâche n01 ; lors de l'abonnement, la sous-application cliente secondaire 8 a donné "wm~app2MsgParser~level2()" comme fonction source de réception des messages. Le fonctionnement de cet exemple de traitements peut être résumé comme suit : - étape "1" : la sous-application secondaire 8 appelle une fonction source d'envoi vers l'application cliente de tâche n01 d'une ou plusieurs commandes AT, afin que cette dernière les exécute (et effectue donc un"traitement de commandes AT"). Cette fonction source ("wm~atSendCommandlevel2") est présentée en détail dans la suite de la description ; - étape "2" : l'application d'interface de niveau 2 6e appelle, au sein des moyens d'exécution compris dans l'application cliente de tâche n l, la ou les fonction d'exécution appropriée (s), dite (s) fonction (s) de traitement des commandes AT ; - étape "3" : les moyens d'exécution 4 exécutent la ou les commande (s) AT ; - étape "4" : après exécution, les moyens d'exécutions 4 envoient la ou les réponse (s) AT à la sous-application cliente secondaire 8 (si la fonction source d'envoi a été paramétrée en ce sens) ; - étape "5" : cette ou ces réponse (s) est (sont) envoyée (s), à travers l'application d'interface de niveau 2, vers la sous-application cliente secondaire 8 ; - étape "6" : au sein de la sous-application cliente secondaire, la fonction source de réception et traitement "wm~app2MsgParseclevel20" traite la réponse. Cette fonction source est celle que la sous-application cliente secondaire a donnée lors de l'inscription pour la réception des messages venant de l'application cliente de tâche n l. Un paramètre de cette fonction source de réception et traitement est le message qui contient la ou les réponse (s) précitée (s). On discute maintenant, toujours dans le cadre de la variante de la nouvelle technique selon l'invention de pilotage du module de radiocommunication, le cas où l'application cliente de tâche n 2 joue le rôle d'une application de supervision. Dans ce cas, la sous-application cliente secondaire 8 peut par exemple effectuer les traitements suivants : mise en cuivre d'un mécanisme d'aiguillage de commandes, permettant à la sous- application cliente secondaire 8 de filtrer ou espionner les commandes provenant de l'application cliente externe ; mise en oovre d'un mécanisme d'aiguillage de réponses, permettant à la sous- application cliente secondaire 8 de filtrer ou espionner les réponses destinées à l'application cliente externe. On ne décrit pas ci-après en détail ces exemples de traitements effectués par la sous-application cliente secondaire. On notera toutefois qu'un texte explicatif relatif à la mise en navre par la sous-application cliente secondaire des deux mécanismes d'aiguillage (de commandes et de réponses respectivement) précités, peuvent être obtenus en effectuant la transposition suivante : on part du texte explicatif ci-dessus dans è cas où l'application cliente de tâche n 2 est"monobloc", et on considère que c'est la sous-application cliente secondaire qui est impliquée (au lieu de l'application cliente de tâche n 2). On trouvera en Annexe 1 une présentation détaillée de certaines fonctions sources de niveau 1, sur lesquelles sont basées l'application cliente de démarrage 6a et les applications clientes de tâche 6b, 6c. On trouvera en Annexe 2 une présentation détaillée de certaines fonctions sources de niveau 2 sur lesquelles sont basées l'application cliente de tâche n 2 et les sous-applications clientes principale et secondaire (dans le cas de la variante), introduites dans le cadre de la nouvelle technique selon l'invention de pilotage du module de radiocommunication (voir description ci-dessus en relation avec la figure 8). ANNEXE 1 : Présentation détaillée de certaines fonctions sources de niveau 1, sur lesquelles sont basées l'application cliente de démarrage et les applications clientes de tâche. Remarque préliminaire : la liste qui suit n'est pas exhaustive. On notera que tous les exemples de fonctions source de niveau 1, associées aux applications clientes de tâche, sont relatifs au bloc"OS". Même si elles n'apparaissent pas dans la liste ci-dessous, il est clair qu'il existe de nombreuses fonctions source de niveau l, associées aux applications clientes de tâche, qui sont relatifs aux blocs"HWL"et"couche 3 GSM" (un exemple de fonction relative à chacun de ces deux blocs peut être trouvé dans les explications cidessus données en relation avec les figures. A1) "wm~apmGlobalInit level1()" Fonction source de niveau 1 de démarrage global, dont le rôle est de fournir au logiciel principal 3 des informations lui permettant d'initialiser et de dialoguer avec chaque application cliente de tâche 6b, 6c. A2) "apmAppliInit n x level1()" Fonction source de niveau 1 d'initialisation, permettant d'initialiser une application cliente de tâche n x. Cette fonction est appelée une fois lors de l'initialisation de l'application cliente de tâche concernée. Nom exact : void AppliInitl (wmapmInitTypee hùttype) ; Paramètres : InitType : indique l'item qui déclenche l'initialisation. Les valeurs correspondantes sont : hmprlpf pn11m { WMAPMPOWERON, WMAPMREBOOTFROMEXCEPTION } wm~apmInitType~e ; WMAPMPOWERON signifie qu'un allumage normal s'est produit. WMAPMREBOOTFROMEXCEPTION signifie que le module a été redémarré après une exception. A3) "apmAppliParser n x level1()" Fonction source de niveau 1 de réception et traitement d'un message provenant du logiciel principal. Cette fonction est appelée à chaque fois qu'une application cliente reçoit un message provenant du logiciel principal. Nom exact : bool AppliParserl (wmapmMsgt * Message) ; Paramètres : Message : La structure de "Message" dépend de son type : typedef struct { u16 MbxSrc ; /* Boîte aux lettre source */ u16 MbxDst ;/* Boîte aux lettres destinatrice s 16 Length ; /* Longueur du corps du message */ s 16 TypMsg ; /* type du message reçu : indique la structure associée au corps du message */ } wmapmHeadert ; typedef struct { wmapmHeadert Header ; /* en-tête du message */ wmapmBodyt Body ;/* corps de message spécifique */ } wmapmMsgt ; TypMsg peut prendre les valeurs suivantes : WMOSTIMER : signifie que le message est envoyé à l'expiration d'une temporisation. WM~HWL~xxx... WM~L3xxx... Valeurs retournées : Le paramètre de retour indique si le message a été pris en compte (vrai) ou non (faux). A4)"Informations de tâches globales" &num;define WMOSMAXCUSTTASK 4 /* Identifiants d'applications clientes de tâches (ou"tâches clientes") */ enum { WMOSCUSTTASK1,/* Tâche de priorité haute */ WMOSCUSTTASK2, WM~OS~CUST~TASK~3, WM~OS~CUST~TASK- 4,/* Tâche de priorité basse */ } ; /* Identifiants de boîtes aux lettres */ typedefenum { /* Identifiants de boîtes aux lettres (MBX) de tâches clientes */ WM~OS~MBX~CUST~1,/* MBX associée àWMOSCUSTTASKJ */ WMOSMBXCUST2,/* MBX associée à WM~OS~CUST~TASK~2*/ WMOSMBXCUST3,/* MBX associée àWMOSCUSTTASK3 */ WMOSMBXCUST4,/* MBX associée à WM~OS~CUST~TASK~4*/ /* Identifiants de boîtes aux lettres (MBX) de tâches du logiciel principal */ WM~OS~MBX~CORE~CC,/* associée au gestionnaire de contrôle d'appel (Call Control management) */ WM~OS~MBX~CORE~SS,/* associée au gestionnaire de services supplémentaires (Supplementary Services management) */ WM~OS~MBX~CORE~SMS,/* associée au gestionnaire de service de messages courts (Short Message Services management) */ WM~OS~MBX~CORE~MM,/* associée au gestionnaire de mobilité (Mobility Management) */ WM~OS~MBX~CORE~RR,/* associée au gestionnaire de ressources radio (Radio WM OS MBX CORE RR Resource management) */ WM~OS~MBX~CORE~DATA, /* associée au gestionnaire de données d'appel (Data Call management) */ WM~OS~MBX~CORE~IR,/* associée au gestionnaire d'infrarouge (Infrared management) */ WMOSMBXCOREIP,/* associée au gestionnaire d'IP (IP management) */ WM~OS~MBX~CORE~SIM,/* associée au gestionnaire de SIM (SIM management) */ /* Identifiants de boîtes aux lettres (MBX) de HWL et BATT */ WM~OS~MBX~CORE~HWL,/* associée au gestionnaire de HWL (HWL management) */ WM~OS~MBX ~CORE~BATT, /* associée au gestionnaire de batterie (Battery management) */ } Mbxt ; AS) "wm osSendMs1LlevellO" Fonction source de niveau 1 d'envoi d'un message (préalablement alloué et rempli) vers une autre application cliente de tâche, via l'application d'interface et le logiciel principal. Nom exact : bool Wl1l~osSendMsg (void * Msg) ; Paramètres : Msg : le message à envoyer Valeurs retournées : Le paramètre de retour indique si le message a été envoyé (vrai) ou non (faux). A6)"wm osStartTimer levell" Fonction source de niveau 1 de déclenchement d'une temporisation dans le logiciel principal. A7) "wm osStopTimer level1" Fonction source de niveau 1 d'arrêt d'une temporisation préalablement déclenchée dans le logiciel principal. A8) "wm osDebu2Trace levell " Fonction source de niveau 1 de suivi de la mise au point A9) "wm osDebugFatalError level1" Fonction source de niveau 1 d'indication d'une erreur fatale et de redémarrage A10)"wm osWriteFIashData levell" Fonction source de niveau 1 d'écriture de données dans une mémoire comprise dans le module de radiocommunication All)"wm osReadFlashData levell" Fonction source de niveau 1 de lecture de données dans une mémoire comprise dans le module de radiocommunication A12) "wm osGetLenFlashData levell Il Fonction source de niveau 1 de fourniture de la longueur de données stockées dans une mémoire comprise dans le module de radiocommunication A13)"wm osDeIeteFlashData levell" Fonction source de niveau 1 de suppression de données stockées dans une mémoire comprise dans le module de radiocommunication A14) "wm osGetAllowedMemoryFlashData level1" Fonction source de niveau 1 de fourniture de la quantité de mémoire allouée au sein d'une mémoire comprise dans le module de radiocommunication A15)"wmosGetFreeMemoryFlashData levell" Fonction source de niveau 1 de fourniture de la quantité de mémoire libre au sein d'une mémoire comprise dans le module de radiocommunication A16) "wm osGetMemorvFlashData levell Il Fonction source de niveau 1 de demande d'allocation de mémoire au sein d'une mémoire comprise dans le module de radiocommunication A17) "wm osReleaseMemoryFlashData level1" Fonction source de niveau 1 de demande de libération de mémoire au sein d'une mémoire comprise dans le module de radiocommunication. A18) "wm~MbxSubscribe" Fonction source de niveau 1 d'inscription à un service de boîte aux lettres géré par le logiciel principal, permettant à une application cliente de tâche de se voir affecter une boîte aux lettres qui lui est propre et dans laquelle elle souhaite recevoir des informations provenant d'au moins une source prédéterminée. Par défaut, toutes les informations sont envoyées à WM~OS~CDST~MBX~1, c'est-àdire à la boîte aux lettres associées à WMOSCUSTTASK1 (l'application cliente de tâche n 1). Nom exact : bool wmMbxSubscribe (wm~apmMbxSubscription~t *TabMbxSubs) ; Paramètres : TabMbsSubs : Table contenant les entités et leurs boîtes aux lettres associées. Typedef struct { Mbxt MbxSrc ;/* boîte aux lettres source, identifie un des WM~OS~CORE~MBX~x */ Mbxt MbxDst ;/* boîte aux lettres destination, identifie un des WMOSCUSTMBXx */ } wm~apmMbxSubscription~t ; Valeurs retournées : Le paramètre de retour indique si l'inscription a été prise en compte (vrai) ou non (faux). ANNEXE 2 : Présentation détaillée de certaines fonctions sources de niveau 2, sur lesquelles sont basées l'application cliente de tâche n 2 et les sous-applications clientes principale et secondaire (dans le cas de la variante), introduites dans le cadre de la nouvelle technique selon l'invention de pilotage du module de radiocommunication. Remarque préliminaire : la liste qui suit n'est pas exhaustive. Al) "wm osMsgParserSubscribe level20" Fonction d'inscription de l'application cliente de tâche n 2 ou d'une sous-application cliente (principale ou secondaire) auprès de l'application cliente de tâche n01 à un service de réception des messages venant de l'application cliente de tâche n l. L'application cliente de tâche n01 mémorise cette fonction et s'en servira chaque fois qu'il a quelque chose à transmettre à la sous-application cliente (principale ou secondaire) concernée. Nom exact : void wmosMsgParserSubscribelevel2 (void (* SubscribeFunction) (wmapmMsgt *) ) ; Paramètres : SubscribeFunction (wmapmMsgt *) : fonction offerte par l'appelant (application cliente de tâche n 2 ou sous-application cliente (principale ou secondaire)) pour que le logiciel principal puisse lui envoyer des messages. Un prototype de cette fonction offerte est détaillée ci-après ("wnLapmAppliParser level2"pour la sous-application cliente principale, ou"wmapp2MsgParserIevel2"pour la sous-application cliente secondaire). Valeur retournée : La paramètre de retour indique si l'abonnement a été pris en compte (VRAI) ou non (FAUX). A2) "wm osMseParserUnsubscribe level20" Fonction d'arrêt de l'inscription d'une application cliente de tâche n 2 ou d'une sousapplication cliente (principale ou secondaire), auprès de l'application cliente de tâche n 1, à un service de réception des messages venant de l'application cliente de tâche n 1. L'application cliente de tâche n01 oublie la fonction précédemment mémorisée. Nom exact : bool wmosMsgParserUnsubscribe~level2 (void (* SubsFunction) (wmapmMsgt *) ) ; Paramètres : SubsFunction (wmapmMsgt *) : fonction offerte par l'appelant (application cliente de tâche n 2 ou sous-application cliente (principale ou secondaire)) pour que l'application cliente de tâche n01 puisse lui envoyer des messages. Cette fonction doit être la même que celle donnée lors de l'abonnement à ce service, sinon l'arrêt de l'abonnement ne sera pas pris en compte. Valeur retournée : La paramètre de retour indique si l'arrêt de l'abonnement a été pris en compte (VRAI) ou non (FAUX) A3)"wm~app2Pipe~level2(FunctionTypefonction,...)" Prototype de la fonction que doit offrir la sous-application cliente secondaire à la sousapplication cliente principale pour pouvoir dialoguer avec elle. Cette fonction est à arguments variables, le nombre et le type des arguments dépend du premier paramètre fonction . Nom exact : void WID~app2Pipe~Ieve12 (FunctionType fonction,...) ; Paramètres : fonction : fonction demandée. Elle implique le nombre et le type des paramètres suivants. Certaines valeurs sont réservées (par exemple de 0 à 127), les autres (par exemple de 128 à 255) sont laissées libres pour utilisation par les dialogues particuliers entre la sous-application cliente principale et la sous-application cliente secondaire. A3-1) Paramètres variables pour fonction = WMAPPFUNCTIONINIT : void wm~app2Pipe~1evel2 ( FunctionType~t fonction, InitType~t Init, void (* MainAppDialogFunction) (wm~apmMsgt *), void * (* SecondaryAppDialogFunction) (wm~apmMsgt *), ) ; La sous-application secondaire doit s'initialiser et faire son traitement. InitType~t Init : le type d'initialisation (APMJNITPOWERON ou APMINITREBOOT) void (* MainAppDialogFunction) (wmapmMsgt *) : adresse de la fonction que doit utiliser la sous-application cliente secondaire pour envoyer des messages à la sousapplication cliente principale. Si une telle fonction n'est pas souhaitée par la sousapplication cliente principale, celle-ci passe une valeur NULL. void * (* SecondaryAppDialogFunction) (wmapmMsgt *) : La souis-application cliente secondaire doit donner l'adresse de la fonction qu'elle offre à la sous-application cliente principale. Si la sous-application cliente secondaire n'offre pas cette fonction, elle doit positionner la valeur à NULL. A3-2) Paramètres variables pour fonction = WMAPPFUNCTIONSTOP : void wmapp2PipeIevel2 ( FunctionType~t fonction, ) ; La sous-application cliente secondaire doit arrêter ses traitements, se désabonner de tous ses abonnements, et libérer l'ensemble des ressources utilisées. A4) "wm~apmAppliParser~level2" Prototype de la fonction source que doit proposer l'application cliente de tâche n 2 pour recevoir des messages venant de l'application cliente de tâche n l. Le message formant paramètre de cette fonction de traitement (aussi dite"de réception") contient notamment une commande AT ou une réponse à une commande AT. On notera que tout ce qui est décrit ci-dessous s'applique également à la fonction source, dans laquelle la sous-application cliente principale ou la sous-application cliente secondaire souhaite recevoir des messages provenant de l'application cliente de tâche n l. Seul change le nom de la fonction elle-même (par exemple "wm~app2MsgParser~level2"au lieu de"wm~apmAppliParser~level2"). Nom exact : bool wm~apmAppliParserJevel2 (wmapmMsgt * Message) ; Paramètres Message La structure du message change avec chaque type de message reçu : typedef struct { s 16 MsgTyp ; /*"MsgTyp"est un type de message reçu, qui permet de déterminer la structure associée du corps du message */ wmapmBodyt Body ;/*"Body"est un corps de message spécifique */ } wrnapmmsg-t ; Valeurs de"MsgTyp" : WMATSENDRSP Le message contient une réponse à une commande AT préalablement envoyée à l'application cliente de tâche n l par l'application cliente de tâche n 2 WM~AT~UNSOLICITED Le message contient une commande AT non sollicitée WMATCMDPREPARSER Le message contient une commande AT envoyée par une application cliente externe, via l'application cliente de tâche nO 1 WM~AT~RSP~PRE~PARSER Le message contient une réponse AT résultant de l'exécution par l'application cliente de tâche n l d'une commande AT provenant d'une application externe. WM~OS~TIMER Le message est envoyé à l'expiration d'une temporisation. La structure du corps est : typedef union { /* Sont incluses ici toutes les structures spécifiques associées aux types de message"MsgTyp"*/ /* WM~AT~SEND~RSP */ wmatResponset ATResponse ; /* WMATUNSOLICITED */ wmatUnsolicitedt ATUnsolicited ; /* WM~AT~CMD~PRE~PARSER */ wmatCmdPreParsert ATCmdPreParser ; ;/* WMATRSPPREPARSER */ wmatRspPreParsert ATRspPreParser /* WM~OS~TIMER */ wmpsTimert OSTimer ; } wmapmBodyt ; Les sous-structures du corps sont : Corps pour WMATSENDRSP : typedef struct { wm~atSendRspType~e Type ; u16 StrLength ; /* Longueur de strData */ char StrData [l] ; /* réponse AT */ } wm~atResponse~t ; typedef enum { WM~AT~SEND~RSP~TO~EMBEDDED, WM~AT~SEND~RSP~TO~EXTERNAL, WM~AT~SEND~RSP~BROADCAST } wm~atSendRspType~e ; (voir le détail de la fonction "wm~atSendCommand~level2", pour la description de"wmatSendRspTypee description"). *Corps pour WMATUNSOLICITED : typedef struct { wm~atUnsolicited~e Type ; ul6 StrLength ; char StrData [l] ; } wm~atUnsolicited~t ; typedefenum { WMATUNSOLICITEDTOEXTERNAL, WMATUNSOLICITEDTOEMBEDDED, WMATUNSOLÏCITEDBROADCAST } wm~atUnso1icited3 ; (voir le détail de la fonction"wmatUnsoIicitedSubscriptionlevel2", pour la description de "wm~atUnsolicited~e"). Corps pour WMATCMDPREPARSER : typedef struct { wm~atCmdPreSubscribe~e Type ; ul6 StrLength ; char StrData [1]; } wm~atCmdPreParser~t ; typedefenum { WMATCMDPREWAVECOMTREATMENT,/* Valeur par défaut */ WMATCMDPREEMBEDDEDTREATMENT, WMATCMDPREBROADCAST } wmatCmdPreSubscribee ; (voir le détail de la fonction "wm~atRspPreParserSubscribe~1eveI2", pour la description de"wmatCmdPrcSubscribee"). Corps pour WMATRSPPREPARSER : typedef struct { wmatRspPreSubscribee Type ; u16 StrLength ; char StrData [l] ; } wmatRspPreParsert ; typedefenum { WM~AT~RSP~PRE~WAVECOM~TREATMENT, /* Valeur par défaut */ WMATRSPPREEMBEDDEDTREATMENT, WM~AT~RSP~PRE~BROADCAST } wm~atRspPreSubscribe~e ; (voir le détail de la ibnction"wmatRspPreParserSubscribeleveI2", pour la description de"wmatRspPreSubscribee"). Corps pour WMOSTIMER : typedef struct { u8 Ident ;/* Identifiant de Temporisation */ } wmosTimer t ; (voir le détail de la fonction"wmosStartTimerlevel2", pour la description de "Ident"). Valeurs retournées Le paramètre de retour indique si le message a été traité (VRAI) ou non (FAUX). AS) "wm atSendCommand leve12" fonction d'envoi vers l'application cliente de tâche n01 d'au moins une commande AT, dont un paramètre indique le (s) application (s) destinatrice (s) (à savoir l'application cliente de tâche n 2 (ou la sous-application cliente (principale ou secondaire)) embarquée et/ou l'application cliente externe) de la réponse résultant de l'exécution de cette commande AT. Nom exact : void wm~atSendCommand~level2 (u16 AtStringSize, wmatSendRspTypee ResponseType, char *AtString,) ; Paramètres AtString Ce paramètre peut être tout type de chaîne de commandes AT, en caractères ASCII. Plusieurs chaînes peuvent être envoyées en même temps. AtStringSize Taille du paramètre précédent : AtString. ResponseType Type de la réponse typedefenum { WMATSENDRSPTOEMBEDDED,/* Valeur par défaut */ WMATSENDRSPTOEXTERNAL, WMATSENDRSPBROADCAST } wmatSendRspTypee ; WMATSENDRSPTOEMBEDDED Toutes les réponses sont redirigées vers l'application cliente de tâche n 2 (ou la sous-application cliente (principale ou secondaire)) embarquée (Embedded application). C'est le mode par défaut. WMATSENDRSPTOEXTERNAL Toutes les réponses sont redirigées vers l'application cliente externe (PC). WMATSENDRSPBROADCAST Toutes les réponses sont redirigées ("diffusées") vers l'application cliente de tâche n 2 (ou la sous-application cliente (principale ou secondaire)) embarquée et l'application cliente externe (PC). A6) "wm atUnsolicitedSubscription level2" fonction d'inscription auprès de l'application cliente de tâche n01 à un service de réception de commandes AT non sollicitées, dont un paramètre indique vers quelle (s) application (s) destinatrice (s) (à savoir l'application cliente de tâche n 2 (ou la sous- application cliente (principale ou secondaire)) embarquée et/ou l'application cliente externe) doit être redirigée chacune des commandes AT non sollicitées Nom exact : void wm~atUnsolicitedSubscription~level2 (wm~atUnsolicited~e Unsolicited) ; Paramètres Unsolicited Ce paramètre décrit l'action effectuée quand une commande AT non sollicitée arrive. typedefenum { WM~AT~UNSOLICITED~TO~EXTERNAL, /* Valeur par défaut */ WMATUNSOLICITEDTOEMBEDDED, WMATUNSOLICITEDBROADCAST, } wm~atUnsolicited~e ; WMATUNSOLICITEDTOEXTERNAL Toutes les commandes non sollicitées seront redirigées vers l'application cliente externe (PC) (mode par défaut) WMATUNSOLICITEDTOEMBEDDED Toutes les commandes non sollicitées seront redirigées vers l'application cliente de tâche n 2 (ou la sous-application cliente (principale ou secondaire)) embarquée WMATUNSOLICITEDBROADCAST Toutes les commandes non sollicitées seront redirigées (diffusées) vers l'application cliente externe (PC) et l'application cliente de tâche n 2 (ou la sous- application cliente (principale ou secondaire)) embarquée A7) "wm atCmdPreParserSubscribe level2" fonction d'inscription auprès de l'application cliente de tâche n01 à un service d'aiguillage de commandes AT, dont un paramètre indique vers quelle (s) application (s) destinatrice (s) (à savoir l'application cliente de tâche n 2 (ou la sous-application cliente (principale ou secondaire)) embarquée et/ou l'application cliente de tâche n 1) doit être aiguillée chacune des commandes AT provenant d'une application externe. Nom exact : void wmatCmdPreParserSubscribejevel2 (wmatCmdPreSubscribee SubscribeType) Paramètres SubscribeType Ce paramètre décrit l'action effectuée quand une commande AT arrive typedef enum { WMATCMDPREWAVECOMTREATMENT,/* Valeur par défaut */ WMATCMDPREEMBEDDEDTREATMENT, WMATCMDPREBROADCAST } wmatCmdPreSubscribee ; WMATCMDPREWAVECOMTREATMENT L'application cliente de tâche n 2 (ou la sous-application cliente (principale ou secondaire)) embarquée ne veut pas filtrer (ni espionner) les commandes envoyées par l'application cliente externe (mode par défaut). WMATCMDPREEMBEDDEDTREATMENT L'application cliente de tâche n 2 (ou la sous-application cliente (principale ou secondaire)) embarquée veut filtrer les commandes envoyées par l'application cliente externe WMATCMDPREBROADCAST L'application cliente de tâche n 2 (ou la sous-application cliente (principale ou secondaire)) embarquée veut espionner les commandes envoyées par l'application cliente externe A8)"wm atRspPreParserSubscribe level2" fonction d'inscription auprès de l'application cliente de tâche n l à un service d'aiguillage de réponses, dont un paramètre indique vers quelle (s) application (s) destinatrice (s) (à savoir l'application cliente de tâche n 2 (ou la sous-application cliente (principale ou secondaire)) embarquée et/ou l'application cliente externe) doit être aiguillée chacune des réponses résultant de l'exécution par l'application cliente de tâche n l d'une commande AT provenant d'une application externe. Nom exact : void wm~atRspPreParserSubscribe~leveI2 ( wm~atRspPreSubscribe~e SubscribeType) ; Paramètres SubscribeType Ce paramètre décrit l'action effectuée quand une commande AT arrive typedefenum { WMATRSPPREWAVECOMTREATMENT,/* Valeur par défaut */ WMATRSPPREEMBEDDEDTREATMENT, WMATRSPPREBROADCAST } wm~atRspPreSubscribe~e ; WMATRSPPREWAVECOMTREATMENT L'application cliente de tâche n 2 (ou la sous-application cliente (principale ou secondaire)) embarquée ne veut pas filtrer (ni espionner) les réponses envoyées à l'application cliente externe (mode par défaut). WMATRSPPREEMBEDDEDTREATMENT L'application cliente de tâche n 2 (ou la sous-application cliente (principale ou secondaire)) embarquée veut filtrer les réponses envoyées à l'application cliente externe. WMATRSPPREBROADCAST L'application cliente de tâche n 2 (ou la sous-application cliente (principale ou secondaire)) embarquée veut espionner les réponses envoyées à l'application cliente externe. A9) "wm atSendRspExternalApp level2" fonction d'envoi vers l'application cliente externe, via l'application cliente de tâche n l, d'au moins une réponse. L'utilisation de cette fonction n'est possible que si une inscription préalable au service d'aiguillage de réponses a été effectuée, avec aiguillage d'une copie des réponses notamment vers l'application cliente de tâche n 2 (ou la sous- application cliente (principale ou secondaire)) embarquée. Nom exact : void wm~atSendRspExternalApp~leveI2 (u16 AtStringSize, char *AtString,) ; Paramètres AtString peut être tout type de chaîne de réponses AT, en caractères ASCII AtStringSize Taille du paramètre précédent : AtString AIO) "DataFlowService level2 " fonction d'émission et/ou réception de données par l'application cliente de tâche n 2 (ou la sous-application cliente (principale ou secondaire)) embarquée, via l'application cliente de tâche n01, après qu'une communication de données a été établie REVENDICATIONS 1. Module de radiocommunication, du type hébergeant et exécutant un logiciel principal comprenant : une application de gestion du système d'exploitation (OS), une application de gestion des radiocommunications (couche 3 GSM), une application de gestion de périphériques pouvant être connectés au module de radiocommunication (HWL), caractérisé en ce que chacune desdites applications comprises dans le logiciel principal est associée à un jeu de fonctions d'exécution de niveau 1, en ce que ledit module de radiocommunication héberge et exécute en outre au moins un logiciel client comprenant au moins une application cliente, associée à un jeu de fonctions sources de niveau 1, et en ce que ledit logiciel principal et/ou ledit logiciel client comprend (nnent) une application d'interface de niveau 1, permettant l'interfaçage des fonctions sources de niveau 1, associées à ladite application cliente, avec les fonctions d'exécution de niveau 1, associées à ladite application de gestion du système d'exploitation et à au moins une desdites applications de gestion des radiocommunications et de gestion de périphériques, de façon à ouvrir, à ladite au moins une application cliente, l'accès à au moins certaines des fonctionnalités du logiciel principal. 2. Module de radiocommunication selon la revendication 1, caractérisé en ce que ladite application d'interface est comprise dans ledit logiciel client. 3. Module de radiocommunication selon l'une quelconque des revendications 1 et 2, caractérisé en ce que ledit logiciel client comprend un fichier binaire contenant au moins deux applications clientes. 4. Module de radiocommunication selon l'une quelconque des revendications 1 et 2, caractérisé en ce que ledit logiciel client comprend au moins deux fichiers binaires, contenant chacun au moins une application cliente. 5. Module de radiocommunication selon l'une quelconque des revendications 1 à 4, caractérisé en ce que ledit logiciel client comprend une application cliente de démarrage global, et au moins une application cliente de tâche réalisant au moins une tâche temps réel, et en ce que le jeu de fonctions sources de niveau 1 associé à l'application cliente de démarrage global comprend une fonction source de niveau 1 de démarrage global ("wmapmGIobat ! nit ! evell"), dont le rôle est de fournir au logiciel principal des informations lui permettant d'initialiser et de dialoguer avec chaque application cliente de tâche. 6. Module de radiocommunication selon l'une quelconque des revendications 1 à 5, caractérisé en ce que ledit logiciel client comprend au moins deux applications clientes de tâche, associées chacune à un jeu de fonctions sources de niveau 1 et réalisant chacune au moins une tâche temps réel distincte, et en ce que ledit logiciel principal et/ou ledit logiciel client comprend (nnent) des moyens de partage des ressources de calcul entre lesdites applications clientes de tâche, de façon permettre un fonctionnement multitâches temps réel. 7. Module de radiocommunication selon l'une quelconque des revendications 5 et 6, caractérisé en ce que le jeu de fonctions sources de niveau 1 associé à chaque application cliente de tâche comprend une fonction source de niveau 1 d'initialisation ("Appliln ! tn x~levell"), permettant d'initialiser ladite application cliente de tâche. 8. Module de radiocommunication selon la revendication 5 et la revendication 7, caractérisé en ce que lesdites informations fournies par la fonction source de démarrage global au logiciel principal comprennent : le nombre d'applications clientes de tâche à initialiser ; pour chaque application cliente de tâche à initialiser, la fonction source de niveau 1 d'initialisation correspondante. 9. Module de radiocommunication selon l'une quelconque des revendications 5 à 8, caractérisé en ce que le jeu de fonctions sources de niveau 1 associé à chaque application cliente de tâche comprend une fonction source de niveau 1 de réception et traitement ("AppliParsern x~levell") d'un message provenant du logiciel principal, un paramètre de ladite fonction source de niveau 1 de réception et traitement étant ledit message. 10. Module de radiocommunication selon les revendication 8 et 9, caractérisé en ce que lesdites informations fournies par la fonction source de niveau 1 de démarrage global au logiciel principal comprennent en outre : pour chaque application cliente de tâche à initialiser, la fonction source de niveau 1 de réception et traitement. 11. Module de radiocommunication selon l'une quelconque des revendications 5 à 10, caractérisé en ce que le jeu de fonctions sources de niveau 1 associé à chaque application cliente de tâche comprend une fonction source de niveau 1 ("wm~apmMbxSubscribe") d'inscription à un service de boîte aux lettres géré par le logiciel principal, permettant à ladite application cliente de tâche de se voir affecter une boîte aux lettres qui lui est propre et dans laquelle elle souhaite recevoir des informations provenant d'au moins une source prédéterminée. 12. Module de radiocommunication selon la revendication 11, caractérisé en ce que chaque source prédéterminée d'informations est une boîte aux lettres affectée à au moins une tâche principale effectuée par le logiciel principal, et contenant des informations que ladite tâche principale souhaite communiquer à une ou plusieurs autres entités. 13. Module de radiocommunication selon l'une quelconque des revendications 1 à 12, caractérisé en ce que ledit logiciel client comprend au moins une application cliente de tâche, associée à un jeu de fonctions sources de niveau 1 et réalisant chacune au moins une tâche temps réel distincte, et en ce que le jeu de fonctions sources de niveau 1 associé à chaque application cliente de tâche comprend au moins une fonction appartenant au groupe comprenant : une fonction source de niveau 1 ("wmosSendMsgIeveIl") d'envoi d'un message (préalablement alloué et rempli) vers une autre application cliente de tâche, via ladite application d'interface et ledit logiciel principal ; une fonction source de niveau 1 ("wmosStartTimer ! evetl") de déclenchement d'une temporisation dans ledit logiciel principal ; une fonction source de niveau 1 ("wm~osStopTimer~level1") d'arrêt d'une temporisation préalablement déclenchée dans ledit logiciel principal ; une fonction source de niveau 1 ("wmosDebugTraceIeveIl") de suivi de la mise au point ; une fonction source de niveau 1 ("wm~osDebugFatalError~level1") d'indication d'une erreur fatale et de redémarrage ; une fonction source de niveau 1 ("wm~osWriteFlashData~levell ") d'écriture de données dans une mémoire comprise dans le module de radiocommunication ; une fonction source de niveau 1 ("wmosReadFtashDatateveM") de lecture de données dans une mémoire comprise dans le module de radiocommunication ; une fonction source de niveau 1 ("wm~osGetLenFlashData~level1") de fourniture de la longueur de données stockées dans une mémoire comprise dans le module de radiocommunication ; une fonction source de niveau 1 ("wm~osDeleteFlashData~level1") de suppression de données stockées dans une mémoire comprise dans le module de radiocommunication ; une fonction source de niveau 1 ("wmosGetAIIowedMemoryFIashDataIeveIl") de fourniture de la quantité de mémoire allouée au sein d'une mémoire comprise dans le module de radiocommunication ; une fonction source de niveau 1 ("wmosGetFreeMemoryFlashDatalevetl") de fourniture de la quantité de mémoire libre au sein d'une mémoire comprise dans le module de radiocommunication ; une fonction source de niveau 1 ("wmosGetMemoryFIashDatalevetl") de demande d'allocation de mémoire au sein d'une mémoire comprise dans le module de radiocommunication ; une fonction source de niveau 1 ("wm~osReleaseMemoryFlashData~levell") de demande de libération de mémoire au sein d'une mémoire comprise dans le module de radiocommunication. 14. Module de radiocommunication selon l'une quelconque des revendications 1 à 13, caractérisé en ce que le logiciel client embarqué et le logiciel principal utilisent chacun une partie distincte d'une même mémoire vive, une tentative d'accès de l'un des logiciels à une partie de la mémoire vive réservée à l'autre logiciel provoquant un arrêt de fonctionnement. 15. Module de radiocommunication selon l'une quelconque des revendications 1 à 14, caractérisé en ce qu'il est compris dans un dispositif appartenant au groupe comprenant : des terminaux de radiocommunication ; des dispositifs, autres que des terminaux de radiocommunication, nécessitant une fonctionnalité de communication sans fil ; des modems. 16. Module de radiocommunication selon l'une quelconque des revendications 1 à 15, caractérisé en ce que ledit logiciel client comprend au moins : une première application cliente réalisant une première tâche temps réel d'exécution de commandes de pilotage, envoyées à ladite première application par au moins une application cliente de pilotage et appartenant à un jeu de commandes de pilotage prédéterminé, ladite première application cliente étant basée notamment sur un jeu de fonctions d'exécution de niveau 2, spécifiques aux commandes de pilotage et permettant chacune l'exécution d'au moins une desdites commandes de pilotage, une seconde application cliente réalisant une seconde tâche temps réel telle que ladite seconde application cliente joue au moins un des deux rôles suivants : * le rôle d'une application cliente de pilotage, envoyant des commandes de pilotage à la première application cliente, et recevant de la première application cliente des réponses, résultant de l'exécution de certaines des commandes de pilotage ; * le rôle d'une application cliente de supervision, gérant l'exécution de commandes de pilotage envoyées par une application cliente de pilotage, dite application cliente externe, hébergée et exécutée par un équipement tiers coopérant avec le module de radiocommunication ; ladite seconde application cliente étant basée notamment sur un jeu de fonctions sources de niveau 2, spécifiques aux commandes de pilotage et permettant chacune l'envoi ou la réception, vers ou en provenance de la première application cliente, de commandes de pilotage ou de réponses à des commandes de pilotage, une application d'interface de niveau 2, spécifique aux commandes de pilotage, permettant l'interfaçage desdites fonctions sources et d'exécution de niveau 2, ladite application d'interface de niveau 2 s'appuyant elle-même sur ladite application d'interface de niveau 1. 17. Module de radiocommunication selon la revendication 16, caractérisé en ce que, pour permettre à la seconde application cliente de jouer le rôle d'une application cliente de pilotage : la seconde application cliente comprend des moyens d'envoi de commandes de pilotage vers les moyens d'exécution compris dans la première application cliente ; la première application cliente comprend des moyens d'envoi des réponses, résultant de l'exécution de certaines des commandes de pilotage par les moyens d'exécution compris dans la première application cliente, vers la seconde application cliente ; - la seconde application cliente comprend des moyens de traitement des réponses envoyées vers elle par la première application cliente. 18. Module de radiocommunication selon l'une quelconque des revendications 16 et 17, caractérisé en ce que, pour permettre à la seconde application cliente de jouer le rôle d'une application cliente de supervision : la première application cliente comprend des moyens d'aiguillage de commandes, en fonction d'une politique d'aiguillage de commandes déterminée, de façon à transmettre les commandes de pilotage provenant de l'application cliente externe vers la seconde application cliente et/ou vers les moyens d'exécution compris dans la première application cliente ; - la seconde application cliente comprend des moyens de traitement des commandes de pilotage aiguillées vers elle par lesdits moyens d'aiguillage de commandes. 19. Module de radiocommunication selon la revendication 18, caractérisé en ce que la seconde application cliente comprend des moyens de sélection de la politique d'aiguillage de commandes appliquée par lesdits moyens d'aiguillage de commandes, parmi un ensemble de politiques d'aiguillage de commandes telles que respectivement : les commandes de pilotage provenant de l'application cliente externe sont transmises uniquement aux moyens d'exécution compris dans la première application cliente ; les commandes de pilotage provenant de l'application cliente externe sont transmises uniquement à la seconde application cliente ; les commandes de pilotage provenant de l'application cliente externe sont transmises aux moyens d'exécution compris dans la première application cliente et la seconde application cliente. 20. Module de radiocommunication selon l'une quelconque des revendications 18 et 19, caractérisé en ce que lesdits moyens de traitement des commandes prennent, pour chaque commande, au moins une décision appartenant au groupe comprenant : envoi de la commande de pilotage vers les moyens d'exécution compris dans la première application cliente, la seconde application cliente comprenant à cet effet des moyens d'envoi de commandes de pilotage vers les moyens d'exécution ; fourniture ou non d'une réponse, uniquement en fonction d'au moins une information relative à la commande, sans exécution de la commande, la seconde application cliente comprenant à cet effet des moyens d'envoi de la réponse à l'application cliente externe, via la seconde application cliente. 21. Module de radiocommunication selon l'une quelconque des revendications 16 à 20, caractérisé en ce que, pour permettre à la seconde application cliente de jouer le rôle d'une application cliente de supervision : la première application cliente comprend des moyens d'aiguillage de réponses, en fonction d'une politique d'aiguillage de réponses déterminée, de façon à transmettre des réponses, résultant de l'exécution de certaines des commandes de pilotage par les moyens d'exécution compris dans la première application cliente, vers la seconde application cliente et/ou vers l'application cliente externe ; - la seconde application cliente comprend des moyens de traitement des réponses aiguillées vers elle par lesdits moyens d'aiguillage de réponses. 22. Module de radiocommunication selon la revendication 21, caractérisé en ce que la seconde application cliente comprend des moyens de sélection de la politique d'aiguillage de réponses appliquée par lesdits moyens d'aiguillage de réponses, parmi un ensemble de politiques d'aiguillage de réponses telles que respectivement : les réponses provenant des moyens d'exécution sont transmises uniquement à l'application cliente externe ; les réponses provenant des moyens d'exécution sont transmises uniquement à la seconde application cliente ; les réponses provenant des moyens d'exécution sont transmises à la seconde application cliente et à l'application cliente externe. 23. Module de radiocommunication selon l'une quelconque des revendications 16 à 22, caractérisé en ce que ledit jeu de fonctions sources de niveau 2 comprend notamment une fonction ("wm~apmAppliParsecleve12") de traitement d'un message provenant de la première application, un paramètre de ladite fonction de traitement étant ledit message. 24. Module de radiocommunication selon la revendication 23, caractérisé en ce que ledit message formant paramètre de ladite fonction de traitement possède une structure comprenant : un premier champ contenant une information relative au type dudit message ; un second champ contenant le corps spécifique dudit message. 25. Module de radiocommunication selon la revendication 24, caractérisé en ce que le type dudit message appartient au groupe comprenant : - message contenant une réponse à une commande de pilotage préalablement envoyée à la première application par la seconde application ; - message contenant une commande de pilotage non sollicitée ; - message contenant une commande de pilotage envoyée par une application cliente externe, via la première application ; - message contenant une réponse résultant de l'exécution par la première application d'une commande de pilotage envoyée par l'application cliente externe 9 - message envoyé à l'expiration d'une temporisation. 26. Module de radiocommunication selon l'une quelconque des revendications 23 à 25, caractérisé en ce que ledit jeu de fonctions sources de niveau 2 comprend en outre au moins une fonction appartenant au groupe comprenant : une fonction source de niveau 2 ("wm~atSendCommand~leveI2") d'envoi vers la première application d'au moins une commande de pilotage, un premier paramètre de ladite fonction d'envoi étant ladite au moins une commande de pilotage, un second paramètre de ladite fonction d'envoi indiquant le (s) application (s) destinatrice (s), à savoir la seconde application et/ou l'application cliente externe, de la réponse résultant de l'exécution de ladite commande de pilotage ; une fonction source de niveau 2 ("wm-atUnsolicitedSubscription-level2") d'inscription auprès de la première application à un service de réception de commandes de pilotage non sollicitées, un paramètre de ladite fonction d'inscription indiquant vers quelle (s) application (s) destinatrice (s), à savoir la seconde application cliente et/ou l'application cliente externe, doit être redirigée chacune des commandes de pilotage non sollicitées ; une fonction source de niveau 2 ("wmatCmdPreParserSubscribelevel2") d'inscription auprès de la première application à un service d'aiguillage de commandes de pilotage, un paramètre de ladite fonction d'inscription indiquant vers quelle (s) application (s), à savoir la première application et/ou la seconde application, doit être aiguillée chacune des commandes de pilotage provenant de l'application cliente externe ; une fonction source de niveau 2 ("wmatRspPreParserSubscribetevet2") d'inscription auprès de la première application à un service d'aiguillage de réponses, un paramètre de ladite fonction d'inscription indiquant vers quelle (s) application (s), à savoir l'application cliente externe et/ou la seconde application, doit être aiguillée chacune des réponses résultant de l'exécution par la première application d'une commande de pilotage ; une fonction source de niveau 2 ("wm~atSendRspExternalApp~leve12") d'envoi vers l'application cliente externe, via la première application, d'au moins une réponse, un paramètre de ladite fonction d'envoi étant ladite au moins une réponse. 27. Module de radiocommunication selon l'une quelconque des revendications 16 à 26, caractérisé en ce que ledit jeu de commandes de pilotage est un jeu de commandes AT standard. 28. Module de radiocommunication selon la revendication 27, caractérisé en ce que ledit jeu de commandes de pilotage comprend, outre les commandes AT standard, une commande AT supplémentaire (AT+WDWL), dite commande de chargement, permettant à l'application cliente externe de charger une nouvelle seconde application cliente ou la totalité d'un nouveau logiciel client dans le module de radiocommunication. 29. Module de radiocommunication selon l'une quelconque des revendications 27 et 28, caractérisé en ce que ledit jeu de commandes de pilotage comprend, outre les commandes AT standard, une commande AT supplémentaire, dite commande de désactivation (AT+WOPEN), permettant à l'application cliente externe de désactiver la seconde application cliente. 30. Module de radiocommunication selon l'une quelconque des revendications 16 à 29, caractérisé en ce que ladite seconde application cliente comprend une sousapplication cliente principale et au moins une sous-application cliente secondaire, esclave de la sous-application cliente principale, les traitements effectués par ladite seconde application cliente étant répartis entre ladite sous-application cliente principale et ladite au moins une sous-application cliente secondaire. 31. Module de radiocommunication selon la revendication 30 et la revendication 7, caractérisé en ce que ladite fonction source de niveau 1 d'initialisation ("AppliIniCnox~levell") est comprise dans le jeu de fonctions sources de niveau 1 associé à la seconde application cliente de tâche et permet d'initialiser ladite sousapplication cliente principale. 32. Module de radiocommunication selon la revendication 31, caractérisé en ce que la sous-application cliente principale est associée à un jeu de fonctions sources de niveau 2 comprenant une fonction source de niveau 2 d'abonnement à un service d'envoi de messages provenant de la première application cliente ("wm~osMsgParserSubscribe~level2"), et en ce que lors de cet abonnement, la sous-application cliente principale communique à la première application cliente l'adresse d'une fonction source de niveau 2 de traitement d'un message ("wm~apmAppliParser~leveI2"), dans laquelle la sous-application cliente principale souhaite recevoir des messages provenant de la première application cliente. 33. Module de radiocommunication selon l'une quelconque des revendications 30 à 32, caractérisé en ce que la sous-application cliente secondaire est associée à un jeu de fonctions sources de niveau 2 comprenant une fonction source de niveau 2 d'initialisation de la sous-application cliente secondaire ("wm~app2Pipe (Init) jevel2"), qui est appelée par la sous-application cliente principale. 34. Module de radiocommunication selon la revendication 33, caractérisé en ce que le jeu de fonctions sources de niveau 2 associé à la sous-application cliente secondaire comprend une fonction source de niveau 2 d'abonnement à un service d'envoi de messages provenant de la première application cliente ("wm~osMsgParserSubscribe~level2"), et en ce que lors de cet abonnement, la sous-application cliente secondaire communique à la première application cliente l'adresse d'une fonction source de niveau 2 de traitement d'un message ("wmapp2MsgParserIevei2"), dans laquelle la sousapplication cliente secondaire souhaite recevoir des messages provenant de la première application cliente. 35. Module de radiocommunication selon l'une quelconque des revendications 33 et 34, caractérisé en ce que ladite fonction source de niveau 2 d'initialisation de la sousapplication cliente secondaire comprend au moins un paramètre permettant la mise en ouvre d'un mécanisme de dialogue entre la sous-application cliente principale et la sousapplication cliente secondaire. 36. Module de radiocommunication selon l'une quelconque des revendications 33 à 35, caractérisé en ce que le jeu de fonctions sources de niveau 2 associé à la sousapplication cliente secondaire comprend une fonction source de niveau 2 d'arrêt de la sous-application cliente secondaire ("wm~app2Pipe (Stop) ~level2"), qui est appelée par la sous-application cliente principale. 37. Module de radiocommunication selon l'une quelconque des revendications 33 à 36, caractérisé en ce que le jeu de fonctions sources de niveau 2 associé à la sousapplication cliente secondaire comprend une fonction source de niveau 2 de désabonnement audit service d'envoi de messages provenant de la première application cliente ("wm~osMsgParserUnsubscribe~level2"). 38. Procédé d'ouverture de l'accès à au moins certaines des fonctionnalités d'un logiciel principal d'un module de radiocommunication, ledit module de radiocommunication étant du type hébergeant et exécutant un logiciel principal comprenant : une application de gestion du système d'exploitation (OS), une application de gestion des radiocommunications (couche 3 GSM), une application de gestion de périphériques pouvant être connectés au module de radiocommunication (HWL), caractérisé en ce que chacune desdites applications comprises dans le logiciel principal est associée à un jeu de fonctions d'exécution de niveau l, en ce que ledit module de radiocommunication héberge et exécute en outre au moins un logiciel client comprenant au moins une application cliente, associée à un jeu de fonctions sources de niveau 1, et en ce que ledit logiciel principal et/ou ledit logiciel client comprend (nnent) une application d'interface de niveau 1, permettant l'interfaçage des fonctions sources de niveau 1, associées à ladite application cliente, avec les fonctions d'exécution de niveau 1, associées à ladite application de gestion du système d'exploitation et à au moins une desdites applications de gestion des radiocommunications et de gestion de périphériques.