FR 2822628 A1 20020927 FR 0112693 A 20011002 Module de radiocommunication exécutant un logiciel principal et un logiciel client comprenant plusieurs applications clientes. 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 Systemen 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. Il héberge et exécute un logiciel principal (communément appelé "logiciel de radiocommunication"ou"logiciel GSM") qui assure notamment des fonctions de communication sans fil (radiocommunication) et pilote divers éléments matériels (écran, clavier, haut-parleur,...) du 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ée). 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. D'une façon générale, l'équipement tiers héberge et exécute un logiciel client de pilotage, permettant de piloter (c'est-à-dire de commander) le module de radiocommunication, grâce à un jeu de commandes de pilotage au format AT. Les commandes AT (pour"ATtention command"en anglais) permettent à l'équipement tiers (ou TE pour"Terminal Equipment") d'exiger du terminal de radiocommunication auquel il est relié d'exécuter certaines actions prédéterminées. A cet effet, le logiciel principal (hébergé par le module de radiocommunication) comprend des moyens d'exécution des commandes AT, qui lui sont envoyées par le logiciel client de pilotage (hébergé par l'équipement tiers). Pour plus de précisions concernant les commandes AT, on pourra se reporter d'une part aux nonnes"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. D'une façon générale, le pilotage du module de radiocommunication par un équipement tiers, grâce aux commandes AT, ne s'applique pas uniquement dans le cadre de la troisième application précitée (module de radiocommunication formant modem), mais aussi dans le cadre des première et seconde application précitées (module de radiocommunication compris dans un terminal de radiocommunication ou un autre dispositif). En d'autres termes, quelle que soit l'application envisagée, le module de radiocommunication peut être piloté par un équipement tiers avec lequel il coopère (généralement via une liaison série). Dans ce cas, un logiciel client de pilotage (comprenant une"application cliente externe"), hébergé et exécuté par l'équipement tiers, envoie des commandes AT à un logiciel principal, hébergé et exécuté par le module de radiocommunication, en vue de leur exécution par ce dernier. Comme illustré sur la figure 2, le fonctionnement de la technique actuelle de pilotage d'un module de radiocommunication par un équipement tiers peut être résumé ainsi : - étape"1" : l'application cliente externe (logiciel client de pilotage) 2 envoie une commande AT ; 1 - étape"2" : la liaison série 5 transmet la commande AT aux moyens 4 d'exécution des commandes AT compris dans le logiciel principal 3 hébergé et exécuté par le module de radiocommunication 1 ; - étape"3" : les moyens 4 d'exécution exécutent la commande AT ; - étape"4" : après exécution, les moyens d'exécution 4 envoient une réponse AT à l'application cliente externe 2 ; - étape"5" : cette réponse est envoyée travers la liaison série 5 ; - étape"6" : l'application cliente externe 2 reçoit la réponse. Chacune de ces étapes 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 h suite de la description). 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 F'esclave". Afin de pallier ces inconvénients de l'état de la technique, la demanderesse (société Wavecom) a déposé le 22 mars 2001 une demande de brevet française n FR 0103909, ayant pour titre"Module de radiocommunication hébergeant et exécutant un logiciel client, et procédé correspondant de mise en ouvre d'un logiciel client de pilotage". Dans cette demande FR 0103909, dont le texte et les dessins sont insérés ici par référence, il est proposé une nouvelle technique de pilotage d'un module de radiocommunication consistant à héberger sur le module de radiocommunication au moins un logiciel client pouvant jouer le rôle d'un logiciel client de pilotage et/ou le rôle d'un logiciel client de supervision. Ainsi, dans le cas où le logiciel client embarqué joue le rôle d'un logiciel client de pilotage, le module de radiocommunication présente un fonctionnement autonome et peu coûteux. En effet, dans ce cas, le module de radiocommunication n'a pas à coopérer avec un équipement tiers, et le logiciel principal et le logiciel client de pilotage utilisent les mêmes ressources (même processeur et même mémoire). Par ailleurs, dans le cas où le logiciel client embarqué joue le rôle d'un logiciel client de supervision, le module de radiocommunication 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, le logiciel client de supervision, exécuté par le module de radiocommunication, gère le pilotage demandé par le logiciel client 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'état de la technique précité. 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. Dans un mode de réalisation préférentiel de la nouvelle technique précitée : le logiciel principal comprend notamment un fichier binaire contenant l'application principale ; le logiciel client comprend notamment un premier fichier binaire contenant l'application cliente, et un second fichier binaire (par exemple sous la forme d'une librairie déjà compilée) contenant une application d'interface entre des fonctions sources, associées à l'application cliente, et des fonctions d'exécution, associées à l'application principale. Cette nouvelle technique de pilotage d'un module de radiocommunication 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. En effet, dans le mode de réalisation préférentiel précité, le logiciel principal et l'application d'interface sont des fichiers binaires"propriétaire", développés par le fabriquant du module de radiocommunication, tandis que l'application cliente est un fichier binaire"client", développé par le client. On rappelle que le processus de développement d'un fichier binaire comprend les étapes suivantes : écriture de fichiers sources, par exemple en langage"C" ; compilation de ces fichiers sources, de façon à générer des fichiers objets (en langage machine pour le microprocesseur se trouvant sur le module de radiocommunication) ; édition de lien des fichiers objets (fichiers sources compilés), de façon à générer un fichier binaire (qui est ensuite téléchargé dans le module de radiocommunication). Dans le contexte de la nouvelle technique précitée de pilotage d'un module de radiocommunication, la présente invention a pour objectif de faciliter la tâche du client dans le processus de développement d'une application cliente. L'invention a également pour objectif de proposer une solution simple et efficace aux problèmes de dialogue entre applications (cliente principale et secondaire) qui résultent de la mise en ouvre du concept général de la présente invention. On rappelle maintenant brièvement deux techniques connues pour résoudre les problèmes de dialogue entre deux applications, avec leurs inconvénients respectifs. Selon une première technique connue, les problèmes de dialogue entre deux applications logicielles sont résolus lors de l'édition de lien. Mais cela impose de connaître l'ensemble des points de dialogues. En outre, l'échange entre deux applications de l'ensemble de leur fonctions sources de dialogue, impose à chaque application de s'adapter à l'autre. Ceci revient à dire que le développeur d'une application (secondaire) devra écrire autant de versions de celle-ci que de clients voulant l'intégrer dans leurs applications (principales). Une seconde technique connue pour résoudre les problèmes de dialogue entre deux applications consiste à mettre en ouvre des mécanismes tels que l'édition de lien dynamique. Un tel mécanisme permet de ne charger en mémoire que les fonction réellement utilisées. Cette technique est par exemple celle des DLL (pour"Dynamic Link Library") de Windows (marque déposée). Malheureusement elle est gourmande en mémoire et s'applique mal aux contraintes fortes en terme de CPU, de mémoire et de temps réel des modules de radiocommunication. 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 assurant notamment des fonctions de radiocommunication, ledit logiciel principal comprenant des moyens d'exécution de commandes de pilotage, envoyées au logiciel principal par au moins un logiciel client de pilotage et appartenant à un jeu de commandes de pilotage prédéterminé. Selon l'invention, ledit module de radiocommunication héberge et exécute en outre au moins un logiciel client, dit logiciel client embarqué, comprenant une application cliente principale et au moins une application cliente secondaire, esclave de l'application cliente principale, les traitements effectués par ledit logiciel client embarqué étant répartis entre ladite application cliente principale et ladite au moins une application cliente secondaire. Le logiciel client embarqué et le logiciel principal comprennent des moyens permettant au logiciel client embarqué de jouer au moins un des deux rôles suivants : le rôle d'un logiciel client de pilotage, envoyant des commandes de pilotage au logiciel principal, et recevant du logiciel principal des réponses, résultant de l'exécution de certaines des commandes de pilotage ; le rôle d'un logiciel client de supervision, gérant l'exécution de commandes de pilotage envoyées par un logiciel client de pilotage, dit logiciel client externe, hébergé et exécuté par un équipement tiers coopérant avec le module de radiocommunication. La présente invention se situe donc dans le contexte de la nouvelle technique précitée de pilotage d'un module de radiocommunication, selon laquelle le module de radiocommunication héberge et exécute un logiciel client pouvant jouer le rôle d'un logiciel client de pilotage et/ou le rôle d'un logiciel client de supervision. Le principe général de l'invention consiste, dans ce contexte, à utiliser non pas une application cliente"monobloc", mais une application cliente"distribuée" ("multiblocs") comprenant une application cliente principale combinée avec une ou plusieurs application (s) cliente (s) secondaire (s). Chaque application cliente secondaire est une application esclave, en terme de lancement et d'arrêt, de l'application cliente principale qui l'appelle. Mais une fois démarrée, l'application cliente secondaire a accès, indépendamment de l'application cliente principale, à l'ensemble des fonctions d'exécution offertes par le logiciel principal (via un mécanisme, détaillé par la suite, d'abonnement à un service d'envoi de messages provenant du logiciel principal). Les 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 1"application cliente principale", qui sous-traite certains traitements en faisant appel à une ou plusieurs application (s) cliente (s) secondaire (s). On notera que le client peut également développer lui-même des applications clientes secondaires, s'il souhaite pouvoir les appeler dans différentes applications clientes principales qu'il développe. Dans un premier mode de réalisation préférentiel de l'invention, ledit logiciel client comprend un fichier binaire contenant ladite application cliente principale et ladite au moins une application cliente secondaire. Dans ce cas, l'application cliente secondaire est préférentiellement fournie sous la forme d'un fichier objet. Ainsi, le fichier source n'est pas communiqué, pour des raisons de préservation du savoir-faire propriétaire (ou"tiers"). Le fichier objet contenant l'application cliente secondaire doit faire l'objet d'une édition de lien avec le ou les fichier (s) objet contenant l'application cliente principale, et c'est le fichier binaire résultant de cette édition de lien qui est téléchargé dans le module. Dans un second mode de réalisation préférentiel de l'invention, ledit logiciel client comprend un premier fichier binaire, contenant ladite application cliente principale, et au moins un second fichier binaire, contenant chacun au moins une application cliente secondaire. Dans ce cas, l'application cliente secondaire est donc fournie sous la forme d'un fichier binaire. Ainsi, de même que dans l'autre cas, le fichier source n'est pas communiqué, pour des raisons de préservation du savoir-faire propriétaire (ou"tiers"). Le fichier binaire contenant l'application cliente secondaire peut être téléchargé directement dans le module. Préférentiellement, pour permettre au logiciel client embarqué de jouer le rôle d'un logiciel client de pilotage : le logiciel client embarqué comprend des moyens d'envoi de commandes de pilotage vers les moyens d'exécution compris dans le logiciel principal ; le logiciel principal 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 le logiciel principal, vers le logiciel client embarqué ; le logiciel client embarqué comprend des moyens de traitement des réponses envoyées vers lui par le logiciel principal. De façon préférentielle, pour permettre au logiciel client embarqué de jouer le rôle d'un logiciel client de supervision : le logiciel principal 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 du logiciel client externe vers le logiciel client embarqué et/ou vers les moyens d'exécution compris dans le logiciel principal ; le logiciel client embarqué comprend des moyens de traitement des commandes de pilotage aiguillées vers lui par lesdits moyens d'aiguillage de commandes. De cette façon, le logiciel client embarqué peut : soit n'effectuer aucune action, les commandes étant transmises uniquement au logiciel principal, qui les exécute directement ; soit effectuer un filtrage des commandes qui lui sont transmises sans être exécutées par le logiciel principal. Le logiciel client embarqué peut ainsi par exemple décider, en fonction de critères déterminés, quelles commandes doivent être exécutées par le logiciel principal et quelles commandes peuvent faire l'objet d'une réponse sans exécution ; soit un"espionnage"des commandes dont il reçoit une copie et qui sont par ailleurs directement exécutées par le logiciel principal. Avantageusement, le logiciel client embarqué 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 du logiciel client externe sont transmises uniquement aux moyens d'exécution compris dans le logiciel principal ; les commandes de pilotage provenant du logiciel client externe sont transmises uniquement au logiciel client embarqué ; les commandes de pilotage provenant du logiciel client externe sont transmises aux moyens d'exécution compris dans le logiciel principal et au logiciel client embarqué. 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 le logiciel principal, le logiciel client embarqué 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, le logiciel client embarqué comprenant à cet effet des moyens d'envoi de la réponse au logiciel client externe, via le logiciel principal. Avantageusement, pour permettre au logiciel client embarqué de jouer le rôle d'un logiciel client de supervision : le logiciel principal 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 le logiciel principal, vers le logiciel client embarqué etSou vers le logiciel client externe ; le logiciel client embarqué comprend des moyens de traitement des réponses aiguillées vers lui par lesdits moyens d'aiguillage de réponses. De cette façon, le logiciel client embarqué peut : soit n'effectuer aucune action, les réponses générées par le logiciel principal étant transmises uniquement au logiciel client externe ; soit effectuer un filtrage des réponses qui lui sont transmises sans être transmises au logiciel client externe. Le logiciel client embarqué peut ainsi par exemple décider, en fonction de critères déterminés, quelles réponses doivent être transmises au logiciel client externe (en étant ou non modifiées) et quelles réponses ne doivent pas l'être ; soit un"espionnage"des réponses dont il reçoit une copie et qui sont par ailleurs directement transmises au logiciel client externe. De façon avantageuse, le logiciel client embarqué 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 au logiciel client externe ; les réponses provenant des moyens d'exécution sont transmises uniquement au logiciel client embarqué ; les réponses provenant des moyens d'exécution sont transmises au logiciel client embarqué et au logiciel client externe. Préférentiellement, ledit module de radiocommunication 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. Préférentiellement, ledit logiciel principal comprend au moins une application principale, associée à un jeu de fonctions d'exécution, permettant chacune l'exécution d'au moins une desdites commandes de pilotage. Chacune desdites applications clientes principale et secondaire est associée à un jeu de fonctions sources, permettant chacune l'envoi ou la réception, vers ou en provenance de l'application principale, de commandes de pilotage ou de réponses à des commandes de pilotage. Le logiciel principal et/ou ledit logiciel client embarqué comprend (nnent) une application d'interface, permettant l'interfaçage desdites fonctions sources avec lesdites fonctions d'exécution. Ainsi, on limite les coûts de développement, du fait que l'application d'interface (aussi appelée par la suite"librairie d'interface application"), une fois développée, peut être utilisée avec différentes applications clientes (principales), voire avec différents logiciel principaux. Dans un mode de réalisation avantageux de l'invention, le jeu de fonctions sources associé à l'application cliente principale comprend notamment une fonction source d'initialisation de l'application cliente principale, qui est appelée au démarrage du module de radiocommunication. Préférentiellement, le jeu de fonctions sources associé à l'application cliente principale comprend une fonction source d'abonnement à un service d'envoi de messages provenant du logiciel principal. Lors de cet abonnement, l'application cliente principale communique au logiciel principal l'adresse d'une fonction source de traitement d'un message, dans laquelle l'application cliente principale souhaite recevoir des messages provenant du logiciel principal. C'est ce mécanisme d'abonnement à un service d'envoi de messages provenant du logiciel principal qui permet à l'application cliente principale de faire appel à l'ensemble des fonctions d'exécution offertes par le logiciel principal, en pouvant recevoir les messages envoyés par le logiciel principal dans le cadre de l'exécution de ces fonctions. De façon préférentielle, le jeu de fonctions sources associé à l'application cliente secondaire comprend notamment une fonction source d'initialisation de l'application cliente secondaire, qui est appelée par l'application cliente principale. Préférentiellement, le jeu de fonctions sources associé à l'application cliente secondaire comprend une fonction source d'abonnement à un service d'envoi de messages provenant du logiciel principal. Lors de cet abonnement, l'application cliente secondaire communique au logiciel principal l'adresse d'une fonction source de traitement d'un message, dans laquelle l'application cliente secondaire souhaite recevoir des messages provenant du logiciel principal. Avantageusement, ladite fonction source d'initialisation de l'application cliente secondaire comprend au moins un paramètre permettant la mise en cuivre d'un mécanisme de dialogue entre l'application cliente principale et l'application cliente secondaire. Préférentiellement, le jeu de fonctions sources associé à l'application cliente secondaire comprend en outre une fonction source d'arrêt de l'application cliente secondaire, qui est appelée par l'application cliente principale. De façon préférentielle, le jeu de fonctions sources associé à l'application cliente secondaire comprend une fonction source de désabonnement audit service d'envoi de messages provenant du logiciel principal. De cette façon, l'application cliente principale n'a à connaître que ce point de dialogue ("fonction source d'initialisation de l'application cliente secondaire"), ainsi que son pendant présenté ci-après ("fonction source d'arrêt de l'application cliente secondaire"). Il s'agit donc d'une solution simple et efficace aux problèmes de dialogue entre application cliente principale et application cliente secondaire. En effet, le développeur d'une application cliente secondaire n'a pas à écrire autant de versions de celle-ci que de clients voulant l'intégrer dans leurs 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 d'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 application cliente secondaire qu'il souhaite développer. Par ailleurs, le mécanisme de dialogue entre l'application cliente principale et l'application cliente secondaire permet notamment à l'application cliente secondaire de communiquer à l'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 avantageuse, ledit type du message appartient au groupe comprenant : message contenant une réponse à une commande de pilotage préalablement envoyée au logiciel principal par le logiciel client embarqué ; message contenant une commande de pilotage non sollicitée ; message contenant une commande de pilotage envoyée par un logiciel client externe, via le logiciel principal ; message contenant une réponse résultant de l'exécution par le logiciel principal d'une commande de pilotage envoyée par le logiciel client externe ; message envoyé à l'expiration d'une temporisation. Dans un mode de réalisation particulier de l'invention, ledit jeu de commandes de pilotage est un jeu de commandes AT standard. Ceci permet un développement rapide du logiciel client embarqué, 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'un logiciel client fortement basé sur un logiciel client externe existant. L'invention concerne également un procédé de mise en cuivre d'un logiciel client de pilotage d'un module de radiocommunication, ledit module de radiocommunication étant du type hébergeant et exécutant un logiciel principal assurant notamment des fonctions de radiocommunication, ledit logiciel principal comprenant des moyens d'exécution de commandes de pilotage, envoyées au logiciel principal par ledit logiciel client de pilotage et appartenant à un jeu de commandes de pilotage prédéterminé. Selon l'invention, ledit module de radiocommunication héberge et exécute en outre au moins un logiciel client, dit logiciel client embarqué, comprenant une application cliente principale et au moins une application cliente secondaire, esclave de l'application cliente principale, les traitements effectués par ledit logiciel client embarqué étant répartis entre ladite application cliente principale et ladite au moins une application cliente secondaire. Le logiciel client embarqué et le logiciel principal dialoguent l'un avec l'autre de façon que le logiciel client embarqué joue au moins un des deux rôles suivants : le rôle dudit logiciel client de pilotage, envoyant des commandes de pilotage au logiciel principal, et recevant du logiciel principal des réponses, résultant de l'exécution de certaines des commandes de pilotage ; le rôle d'un logiciel client de supervision, gérant l'exécution de commandes de pilotage envoyées par ledit logiciel client de pilotage, ledit logiciel client de pilotage, dit logiciel client externe, étant hébergé et exécuté par un équipement tiers coopérant avec le module de radiocommunication. 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 l'application cliente principale et l'application cliente secondaire ; la figure 2 (art antérieur) illustre le fonctionnement de la technique actuelle de pilotage d'un module de radiocommunication par un équipement tiers ; - la figure 3 illustre un mécanisme de lancement de l'application cliente principale et d'abonnement de celle-ci à un service d'envoi de messages provenant du logiciel principal ; - la figure 4 illustre un mécanisme de lancement de l'application cliente secondaire et d'abonnement de celle-ci à un service d'envoi de messages provenant du logiciel principal ; la figure 5 illustre un mécanisme d'arrêt de l'application cliente secondaire et de désabonnement de celle-ci au service d'envoi de messages provenant du logiciel principal ; la figure 6 illustre un exemple de traitements (envoi d'une commande et réception de la réponse correspondante) pouvant être effectués par l'application cliente secondaire, dans le cas où le module de radiocommunication fonctionne selon un premier mode de réalisation de l'invention, dans lequel le logiciel client embarqué joue le rôle d'un logiciel client de pilotage. 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, le logiciel principal (par exemple un"logiciel GSM") assure notamment des fonctions de radiocommunication, et comprend des moyens d'exécution de commandes de pilotage (qui lui envoyées par un logiciel client de pilotage). Le logiciel client embarqué (concept propre à la présente invention) peut jouer : le rôle d'un logiciel client de pilotage, et/ou le rôle d'un logiciel client de supervision. Dans la suite de la description, on suppose que les commandes de pilotage sont des commandes AT. Il est clair toutefois que la présente invention n'est nullement limitée à ce type de commande de pilotage. Dans le mode de réalisation particulier illustré sur la figure 1, le logiciel principal 3 comprend une application principale 3a, basée notamment sur un jeu de fonctions d'exécution, permettant chacune l'exécution d'au moins une des commandes AT. Par ailleurs, le logiciel client embarqué 6 comprend : une application cliente principale 6a, associée à un jeu de fonctions sources, permettant chacune l'envoi ou la réception, vers ou en provenance de l'application principale 3a, de commandes AT ou de réponses à des commandes AT ; une application cliente secondaire 6c, également associée à un jeu de fonctions sources tel que précité ; une application d'interface 6b, permettant l'interfaçage des fonctions sources (de l'application cliente principale 6a et de l'application cliente secondaire 6c) avec les fonctions d'exécution (de l'application principale 3a). Ainsi, l'application cliente principale 6a communique avec l'application principale 3a, via l'application d'interface 6b. De même, l'application cliente secondaire 6c communique avec l'application principale 3a, via l'application d'interface 6b. A cet effet, chaque application (principale 6a, secondaire 6c et d'interface 6b) 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. L'application cliente principale 6a comprend un bloc"Application Mandatory API", formant interface décrivant des fonctions devant être définies dans l'application cliente principale. L'application cliente secondaire 6c comprend également un bloc"Application Mandatory API" (partiellement identique au bloc du même nom compris dans l'application cliente principale), formant interface décrivant des fonctions devant être définies dans l'application cliente secondaire. L'application d'interface (ou librairie d'interface application) 6b comprend les trois blocs suivants : un bloc"AT command API", formant interface décrivant l'accès aux commandes AT, cette interface décrit des fonctions se trouvant dans la librairie d'interface application ; un bloc"OS API", formant interface décrivant l'accès aux fonctions du système d'exploitation (Operating System), cette interface décrit des fonctions se trouvant dans la librairie d'interface application ; 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. Côté logiciel principal 3, l'application principale 3a comprend : un bloc"AT Command API", pendant du bloc du même nom compris dans l'application d'interface 6b ; un bloc"OS API, pendant du bloc du même nom compris dans l'application d'interface 6b. L'application principale 3a constitue le noyau du logiciel principal 3, et l'application cliente principale 6a, l'application cliente secondaire 6c et l'application d'interface 6b constituent le noyau du logiciel client embarqué 6. L'application d'interface 6b est par exemple un fichier binaire, qui se présente sous la forme d'une librairie (déjà compilée). L'application cliente principale 6a est 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). En ce qui concerne l'application cliente secondaire 6c, on peut envisager les deux variantes suivantes : soit elle est fournie sous la forme d'un fichier objet. Dans ce cas, ce fichier objet est pris en compte lors de l'édition de lien générant le fichier binaire contenant l'application cliente principale 6a. En d'autres termes, un même fichier binaire contient l'application cliente principale et l'application cliente secondaire ; soit elle est fournie directement sous la forme d'un fichier binaire. En d'autres termes, l'application cliente principale 6a et l'application cliente secondaire 6c sont contenues dans deux fichiers binaires distincts. 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 3, un mécanisme de lancement de l'application cliente principale 6a et d'abonnement de celle-ci à un service d'envoi de messages provenant du logiciel principal 3. Les éléments compris de façon classique dans un module de radiocommunication, et présentés ci-dessus en relation avec la figure 2 (art antérieur), conservent les mêmes références numériques. Ainsi, le module de radiocommunication 1 héberge et exécute un logiciel principal 3 comprenant notamment des moyens 4 d'exécution des commandes AT. Par ailleurs, selon l'invention et comme présenté ci-dessus en relation avec la figure 1, le module de radiocommunication 1 héberge et exécute en outre un logiciel client embarqué 6, jouant le rôle d'un logiciel client de pilotage ou d'un logiciel client de supervision, et comprenant notamment une application cliente principale 6a, une application cliente secondaire 6c et une application d'interface 6b. Le fonctionnement de ce mécanisme de lancement de l'application cliente principale et d'abonnement de celle-ci à un service d'envoi de messages peut être résumé ainsi : - étape"1" : le logiciel principal 3 détecte la présence d'une application cliente principale 6a et la lance ; - étape"2" : le lancement de l'application cliente principale 6a se fait via l'application d'interface 6b, qui appelle au sein de l'application cliente principale 6a une fonction source d'initialisation de l'application cliente principale 6a. Cette fonction source ("wmapmAppliInit") est présentée en détail dans la suite de la description ; 1 - étape"3" : au sein de l'application cliente principale 6a, la fonction source "wm~apmAppliInit"initialise l'application cliente principale. Comme expliqué en détail dans les étapes suivantes ("4"à"6"), cette initialisation consiste notamment à donner au logiciel principal 3 l'adresse d'une fonction source (par exemple"wm~apmAppliParser") permettant à l'application cliente principale 6a de recevoir des messages provenant du logiciel principal ; - étape"4" : l'application cliente principale 6a fait appel à une fonction source d'abonnement à un service d'envoi de messages provenant du logiciel principal ("wmosMsgParserSubscribe"). Cette fonction source est présentée en détail dans la suite de la description ; - étape"5" : l'application d'interface 6b appelle, au sein du logiciel principal 3, 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 à l'application cliente principale 6a ; - étape"6" : le logiciel principal 3 établit l'inscription demandée, via l'application d'interface 6b, par l'application cliente principale 6a. Selon une variante, l'application cliente principale 6a fait appel à la fonction source"wmosMsgParserSubscribe"quand elle le souhaite (indépendamment de l'exécution de la fonction source d'initialisation de l'application cliente principale 6a). On présente maintenant, en relation avec la figure 4, un mécanisme de lancement de l'application cliente secondaire 6c et d'abonnement de celle-ci à un service d'envoi de messages provenant du logiciel principal 3. Le fonctionnement de ce mécanisme peut être résumé comme suit : - étape"1" : l'application cliente principale 6a, après réception d'un message dans sa fonction source"wmapmAppliParserQ", appelle une fonction source de l'application cliente secondaire 6c, à savoir la fonction source d'initialisation de l'application cliente secondaire 6c ("wmapp2Pipe (init)"). Cette fonction source (qui doit être connue de l'application cliente principale 6a) est présentée en détail dans la suite de la description ; 1 - étape"2" : au sein de l'application cliente secondaire 6c, la fonction source "wmapp2Pipe (init)" initialise l'application cliente secondaire 6c. Comme expliqué en détail dans les étapes suivantes ("3"à"5"), cette initialisation consiste notamment à donner au logiciel principal 3 l'adresse d'une fonction source (par exemple"wmapp2MsgParser") permettant à l'application cliente secondaire 6c de recevoir des messages provenant du logiciel principal 3 ; - étape"3" : l'application cliente secondaire 6c fait appel à la fonction source d'abonnement à un service d'envoi de messages provenant du logiciel principal ("wmosMsgParserSubscribe"). Cette fonction source est présentée en détail dans la suite de la description ; - étape"4" : l'application d'interface 6b appelle, au sein du logiciel principal 3, 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 à l'application cliente secondaire 6c ; -étape"5": le logiciel principal 3 établit l'inscription demandée, via l'application d'interface 6b, par l'application cliente secondaire 6c. Après qu'elle a été ainsi lancée, l'application cliente secondaire 6c effectue sa fonction (ensemble de traitements ou tâches), de façon autonome par rapport à l'application cliente principale 6a. Comme expliqué en détail ci-après, elle a pour cela à sa disposition l'ensemble des fonctions d'exécution offertes par le logiciel principal 3. Selon une variante, l'application cliente secondaire 6c fait appel à la fonction source"wmosMsgParserSubscribe"quand elle le souhaite (indépendamment de l'exécution de la fonction source d'initialisation de l'application cliente secondaire 6c). On notera que la fonction source d'initialisation de l'application cliente secondaire peut comprendre au moins un paramètre permettant la mise en ouvre d'un mécanisme de dialogue entre l'application cliente principale 6a et l'application cliente secondaire 6c. Cette caractéristique de l'invention est décrite en détail dans la suite de la description. On présente maintenant, en relation avec la figure 5, un mécanisme d'arrêt de l'application cliente secondaire 6c et de désabonnement de celle-ci au service d'envoi de messages provenant du logiciel principal 3. Le fonctionnement de ce mécanisme peut être résumé comme suit : - étape"1" : l'application cliente principale 6a, après réception d'un message dans sa fonction source wm~apmAppliParser (), appelle une fonction source de l'application cliente secondaire 6c, à savoir la fonction source d'arrêt de l'application cliente secondaire 6c ("wmapp2Pipe (stop)"). Cette fonction source (qui doit être connue de l'application cliente principale 6a) est présentée en détail dans la suite de la description ; - étape"2" : au sein de l'application cliente secondaire 6c, la fonction source wmapp2Pipe (stop) effectue les traitements d'arrêt de l'application cliente secondaire 6c. Comme expliqué en détail dans les étapes suivantes ("3"à"5"), ces traitements consistent notamment pour l'application cliente secondaire 6c à se désabonner du service d'envoi de messages venant du logiciel principal 3 ; - étape"3" : l'application cliente secondaire 6c fait appel à la fonction source de désabonnement au service d'envoi de messages provenant du logiciel principal ("wmosMsgParserUnsubscribe"). Cette fonction source est présentée en détail dans la suite de la description ; - étape"4" : l'application d'interface 6b appelle, au sein du logiciel principal 3, 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 à l'application cliente secondaire 6c ; - étape"5" : le logiciel principal 3 établit l'arrêt de l'inscription, demandé, via l'application d'interface 6b, par l'application cliente secondaire 6c. On présente maintenant, en relation avec la figure un exemple de traitements pouvant être effectués par l'application cliente secondaire, pour décharger l'application cliente principale 6a. Dans cet exemple, on suppose que : le module de radiocommunication fonctionne selon un premier mode de réalisation de l'invention, dans lequel le logiciel client embarqué joue le rôle d'un logiciel client de pilotage ; les traitements consistent en l'envoi par l'application cliente secondaire 6c d'une commande et la réception de la réponse correspondante ; l'application cliente secondaire 6c a été initialisée et qu'elle s'est abonnée au service d'envoi de messages venant du logiciel principal 3 (cf. figure 4) ; lors de l'abonnement, l'application cliente secondaire 6c a donné "wmapp2MsgParser ()"comme fonction source de réception des messages. Le fonctionnement de cet exemple de traitements peut être résumé comme suit : - étape"1" : l'application secondaire 6c appelle une fonction source d'envoi vers le logiciel principal 3 d'une ou plusieurs commandes AT, afin que ce dernier les exécute (et effectue donc un"traitement de commandes AT"). Cette fonction source ("wmatSendCommand") est présentée en détail dans la suite de la description ; - étape"2" : l'application d'interface 6a appelle, au sein des moyens 4 d'exécution compris dans le logiciel principal 3, 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 à l'application cliente secondaire 6c (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 6a, vers l'application cliente secondaire 6c ; - étape"6" : au sein de l'application cliente secondaire 6c, la fonction source de réception et traitement"wm~app2MsgParser ()"traite la réponse. Cette fonction source est celle que l'application cliente secondaire 6c a donnée lors de l'inscription pour la réception des messages venant du logiciel principal 3. 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 notera que la figure 6 décrite ci-dessus est une transposition de la figure 3 de la demande de brevet française n FR 0103909 déposée le 22 mars 2001 par la demanderesse (société Wavecom). Elle s'en distingue uniquement en ce que c'est l'application cliente secondaire qui est ici impliquée (au lieu de Inapplication cliente embarquée"dans la demande n FR 0103909). Il est également prévu un second mode de réalisation de l'invention, dans lequel le logiciel client embarqué joue le rôle d'un logiciel client de supervision. Dans ce cas, l'application cliente secondaire peut par exemple effectuer les traitements suivants : mise en ouvre d'un mécanisme d'aiguillage de commandes, permettant à l'application cliente secondaire de filtrer ou espionner les commandes provenant du logiciel client externe ; mise en avare d'un mécanisme d'aiguillage de réponses, permettant à l'application cliente secondaire de filtrer ou espionner les réponses destinées au logiciel client externe. On ne décrit pas ci-après en détail (et on n'illustre par avec des figures) ces exemples de traitements effectués par l'application cliente secondaire, dans le cas où le module de radiocommunication fonctionne selon le second mode de réalisation de l'invention précité. On notera toutefois qu'un texte explicatif et des figures, relatifs à la mise en ouvre par l'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 des figures 4 à 7 de la demande de brevet française n FR 0103909 précitée, et du texte explicatif correspondant, et on considère que c'est l'application cliente secondaire qui est impliquée (au lieu de Inapplication cliente embarquée"dans la demande de brevet n FR 0103909). On trouvera en Annexe 1 une présentation détaillée de certaines des fonctions sources sur lesquelles sont basées l'application cliente principale 6a et l'application cliente secondaire 6c. Dans le cadre de la présente invention, de façon optionnelle, on peut également prévoir d'utiliser, outre les commandes AT standard, au moins une des commandes AT supplémentaires suivantes : commande de chargement d'un logiciel client (AT+WDWL), permettant au logiciel client externe de charger dans le module de radiocommunication un nouveau logiciel client, ou une nouvelle partie de logiciel client ; commande de désactivation (AT+WOPEN), permettant au logiciel client externe de désactiver le logiciel client embarqué ou une partie du logiciel client embarqué. ANNEXE 1 : Présentation détaillée de certaines fonctions sources sur lesquelles sont basées l'application cliente principale et l'application cliente secondaire Al)"wmapmAppuInit" Fonction d'initialisation de l'application cliente principale ; est appelée au démarrage du module de radiocommunication. Nom exact : void wmapmAppliInit (wm~apmInitTypee InitType) Paramètres : InitType Ce paramètre permet de déterminer ce qui déclenche l'initialisation, les valeurs sont : typedefenum { WMAPMPOWERON, WM~APM~REBOOT~FORM~EXCEPTION } wmapmInitTypee ; WMAPMPOWERON Démarrage normal WM~APM~REBOOT~FROM~EXCEPTION Le module est redémarré après une exception A2) "wm osMssParserSubscribeQ" Fonction d'inscription d'une l'application cliente (principale ou secondaire) auprès du logiciel principal à un service de réception des messages venant du logiciel principal. Le logiciel principal mémorise cette fonction et s'en servira chaque fois qu'il a quelque chose àtransmettre àl'application cliente (principale ou secondaire) concernée. Nom exact : void wmosMsgParserSubscribe (void (* SubscribeFunction) (wmapmMsgt *)) ; Paramètres : SubscribeFunction (wmapmMsgt *) : fonction offerte par l'appelant (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 après ("wmapmAppliParser"pour l'application cliente principale, ou"wmapp2MsgParser" pour l'application cliente secondaire). Valeur retournée : La paramètre de retour indique si l'abonnement a été pris en compte (VRAI) ou non (FAUX). A3) "wm osMssParserUnsubscribeO" Fonction d'arrêt de l'inscription d'une l'application cliente (principale ou secondaire) auprès du logiciel principal à un service de réception des messages venant du logiciel principal. Le logiciel principal oublie la fonction précédemment mémorisée. Nom exact : bool wmosMsgParserUnsubscribe (void (* SubsFunction) (wmapmMsgt *)) ; Paramètres : SubsFunction (wmapmMsgt *) : fonction offerte par l'appelant (application cliente principale ou secondaire) pour que le logiciel principal 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) A4)"wm app2Pipe (FunctionType fonction,...)" Prototype de la fonction que doivent offrir l'application cliente secondaire à l'application 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 wmapp2Pipe (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 l'application cliente principale et l'application cliente secondaire. A4-1) Paramètres variables pour fonction = WM~APP~FUNCTION~INIT : void wmapp2Pipe ( FunctionTypet fonction, InitType~t mit, void (* MainAppDialogFunction) (wm~apmMsgt *), void * (* SecondaryAppDialogFunction) (wmapmMsgt *), ) ; L'application secondaire doit s'initialiser et faire son traitement. InitTypet Init : le type d'initialisation (APMINITPOWERON ou APMINITREBOOT) void (* MainAppDialogFunction) (wmapmMsgt *) : adresse de la fonction que doit utiliser l'application cliente secondaire pour envoyer des messages à l'application cliente principale. Si une telle fonction n'est pas souhaitée par l'application cliente principale, celle-ci passe une valeur NULL. void * (* SecondaryAppDialogFunction) (wm~apmMsgt *) : L'application cliente secondaire doit donner l'adresse de la fonction qu'elle offre à l'application cliente principale. Si l'application cliente secondaire n'offre pas cette fonction, elle doit positionner la valeur à NULL. A4-2) Paramètres variables pour fonction = WM~APP~FUNCTION~STOP: void wmapp2Pipe ( FunctionType~t fonction, ) ; L'application cliente secondaire doit arrêter ses traitements, se désabonner de tous ses abonnements, et libérer l'ensemble des ressources utilisées. A5)"wm apmAppliParser" Prototype de la fonction source que doit proposer l'application cliente principale pour recevoir des messages venant du logiciel principal. Le message formant paramètre de cette fonction de traitement (aussi dite"de réception") contient notamment une commande AT ou une réponse aune commande AT. On notera que tout ce qui est décrit ci-dessous s'applique également à la fonction source, dans laquelle l'application cliente secondaire souhaite recevoir des messages provenant du logiciel principal. Seul change le nom de la fonction elle-même (par exemple "wmapp2MsgParser"au lieu de"wmapmAppliParser"). Nom exact : bool wm~apmAppliParser (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 */ } winapmmsg-t ; Valeurs de"MsgTyp" : WMATSENDRSP Le message contient une réponse à une commande AT préalablement envoyée au logiciel principal par le logiciel client embarqué WMATUNSOLICITED Le message contient une commande AT non sollicitée WMATCMDPREPARSER Le message contient une commande AT envoyée par un logiciel client externe, via le logiciel principal WMATRSPPREPARSER Le message contient une réponse AT résultant de l'exécution par le logiciel principal d'une commande AT provenant d'une application externe. WMOSTIMER 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 ; /* WMATCMDPREPARSER */ wmatCmdPreParsert ATCmdPreParser ; ;/* WMATRSPPREPARSER */ wmatRspPreParsert ATRspPreParser /* WM OS TIMER */ wm~osTimer~t OSTimer ; } wm~ampBody~t ; Les sous-structures du corps sont : Corps pour WMATSENDRSP : typedefstruct{ wm~atSendRspType~e Type ; ul6 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"wmatSendCommand", pour la description de "wmatSendRspTypee description"). Corps pour WMATUNSOLICITED : typedef struct { wm~atUnsolicited~e Type ; u16 StrLength ; char StrData [l] ; } wm~atUnsolicited~t ; typedefenum{ WMATUNSOLICITEDTOEXTERNAL, WM~AT~UNSOLICITED~TO~EMBEDDED, WMATUNSOLICITEDBROADCAST wmatunsolicited-e ; (voir le détail de la fonction"\vmatUnsolicitedSubscription", pour la description de"wmatUnsolicitede"). Corps pour WMATCMDPREPARSER : OUL wmatCmdPreSubscribee Type ; u16 StrLength ; char StrData [l] ; } wmatCmdPreParsert ; typedef enum { WMATCMDPREWAVECOMTREATMENT,/* Valeur par défaut */ WMATCMDPREEMBEDDEDTREATMENT, WM~AT~CMD~PRE~BROADCAST } wm~atCmdPreSubscribe~e ; (voir le détail de la fonction "wm~atRspPreParserSubscribe", pour la description de"wm~atCmdPreSubscribe~e"). Corps pour WMATRSPPREPARSER : typedef struct { wm~atRspPreSubscribe~e Type ; ul6 StrLength ; char StrData [l] ; } wmatRspPreParsert ; typedef enum { WM~AT~RSP~PRE~WAVECOM~TREASTMENT, /* Valeur par défaut */ WMATRSPPREEMBEDDEDTREATMENT, WM~AT~RSP~PRE~BROADCAST } wm~atRspPreSubscribe~e ; (voir le détail de la fonction"wmatRspPreParserSubscribe", pour la description de"wm~atRspPreSubscribe~e"). Corps pour WM~OS~TIMER : typedef struct { u8 Ident ;/* Identifiant de Temporisation */ } wmosTimert ; (voir le détail de la fonction"wmosStartTimer", pour la description de"Ident"). Valeurs retournées Le paramètre de retour indique si le message a été traité (VRAI) ou non (FAUX). A6)"wm atSendCommand" fonction d'envoi vers le logiciel principal d'au moins une commande AT, dont un paramètre indique le (s) application (s) destinatrice (s) (à savoir l'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 wmatSendCommand (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 typedef enum WM~AT~SEND~RSP~TO~EMBEDDED, /* Valeur par défaut */ WM~AT~SEND~RSP~TO~EXTERNAL, WMATSENDRSPBROADCAST } \vmatSendRspTypee ; WMATSENDRSPTOEMBEDDED Toutes les réponses sont redirigées vers l'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). WMATSENDRSPJBROADCAST Toutes les réponses sont redirigées ("diffusées") vers l'application cliente (principale ou secondaire) embarquée et l'application cliente externe (PC). A7)"wm atUnsolicitedSubscription" fonction d'inscription auprès du logiciel principal à 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 (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 wmatUnsolicitedSubscription ( wm atUnsolicited e Unsolicited) ; Paramètres Unsolicited Ce paramètre décrit l'action effectuée quand une commande AT non sollicitée arrive. typedef enum { WMATUNSOLICITEDTOEXTERNAL,/* Valeur par défaut */ WM~AT~UNSOLICITED~TO~EMBEDDED, WMATUNSOLICITEDBROADCAST, } wmatUnsolicitede ; 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 (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 (principale ou secondaire) embarquée A8) "wm atCmdPreParserSubscribe" fonction d'inscription auprès du logiciel principal à un service d'aiguillage de commandes AT, dont un paramètre indique vers quelle (s) application (s) destinatrice (s) (à savoir l'application cliente (principale ou secondaire) embarquée et/ou l'application principale) doit être aiguillée chacune des commandes AT provenant d'une application externe. Nom exact : void wm~atCmdPreParserSubscribe ( wmatCmdPreSubscribee SubscribeType) ; Paramètres SubscribeType Ce paramètre décrit l'action effectuée quand une commande AT arrive typedefenum{ WMATCMDPREWAVECOMTREATMENT,/* Valeur par défaut */ WMATCMDPREEMBEDDEDTREATMENT, WMATCMDPREBROADCAST } wmatCmdPreSubscribec ; WMATCMDPRJEWAVECOMTREATMENT L'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 (principale ou secondaire) embarquée veut filtrer les commandes envoyées par l'application cliente externe WM~AT~CMD~PRE~BROADCAST L'application cliente (principale ou secondaire) embarquée veut espionner les commandes envoyées par l'application cliente externe A9)"wmatRspPreParserSubscribe" fonction d'inscription auprès du logiciel principal à un service d'aiguillage de réponses, dont un paramètre indique vers quelle (s) application (s) destinatrice (s) (à savoir l'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 le logiciel principal d'une commande AT provenant d'une application externe. Nom exact : void wm~atRspPreParserSubscribe ( wmatRspPreSubscribee SubscribeType) ; Paramètres SubscribeType Ce paramètre décrit l'action effectuée quand une commande AT arrive tpedefenum{ WMATRSPPREWAVECOMTREATMENT,/* Valeur par défaut */ WMATRSPPREEMBEDDEDTREATMENT, WM~AT~RSP~PRE~BROADCAST } wvmatRspPreSubscribe~e ; WM~AT~RSP~PRE~WAVECOM~TREATMENT L'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 (principale ou secondaire) embarquée veut filtrer les réponses envoyées à l'application cliente externe. WMATRSPPREBROADCAST L'application cliente (principale ou secondaire) embarquée veut espionner les réponses envoyées à l'application cliente externe. A10) "wm atSendRspExternalApp" fonction d'envoi vers le logiciel client externe, via le logiciel principal, 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 (principale ou secondaire) embarquée. Nom exact : void wm~atSendRspExternalApp (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 All)"DataFlowService" fonction d'émission et/ou réception de données par l'application cliente (principale ou secondaire) embarquée, via le logiciel principal, après qu'une communication de données a été établie A12)"wm osStartTimer" fonction d'armement d'une temporisation, un paramètre de ladite fonction d'armement indiquant la temporisation à armer A13)"wm osStopTimer" fonction d'arrêt d'une temporisation, un paramètre de ladite fonction d'arrêt indiquant la temporisation à arrêter REVENDICATIONS 1. Module de radiocommunication, du type hébergeant et exécutant un logiciel principal assurant notamment des fonctions de radiocommunication, ledit logiciel principal comprenant des moyens d'exécution de commandes de pilotage, envoyées au logiciel principal par au moins un logiciel client de pilotage et appartenant à un jeu de commandes de pilotage prédéterminé, caractérisé en ce que ledit module de radiocommunication héberge et exécute en outre au moins un logiciel client, dit logiciel client embarqué, comprenant une application cliente principale et au moins une application cliente secondaire, esclave de l'application cliente principale, les traitements effectués par ledit logiciel client embarqué étant répartis entre ladite application cliente principale et ladite au moins une application cliente secondaire, et en ce que le logiciel client embarqué et le logiciel principal comprennent des moyens permettant au logiciel client embarqué de jouer au moins un des deux rôles suivants : le rôle d'un logiciel client de pilotage, envoyant des commandes de pilotage au logiciel principal, et recevant du logiciel principal des réponses, résultant de l'exécution de certaines des commandes de pilotage ; le rôle d'un logiciel client de supervision, gérant l'exécution de commandes de pilotage envoyées par un logiciel client de pilotage, dit logiciel client externe, hébergé et exécuté par un équipement tiers coopérant avec le module de radiocommunication. 2. Module de radiocommunication selon la revendication 1, caractérisé en ce que ledit logiciel client comprend un fichier binaire contenant ladite application cliente principale et ladite au moins une application cliente secondaire. 3. Module de radiocommunication selon la revendication 1, caractérisé en ce que ledit logiciel client comprend un premier fichier binaire, contenant ladite application cliente principale, et au moins un second fichier binaire, contenant chacun au moins une application cliente secondaire. 4. Module de radiocommunication selon l'une quelconque des revendications 1 à 3, caractérisé en ce que, pour permettre au logiciel client embarqué de jouer le rôle d'un logiciel client de pilotage : le logiciel client embarqué comprend des moyens d'envoi de commandes de pilotage vers les moyens d'exécution compris dans le logiciel principal ; le logiciel principal 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 le logiciel principal, vers le logiciel client embarqué ; le logiciel client embarqué comprend des moyens de traitement des réponses envoyées vers lui par le logiciel principal. 5. Module de radiocommunication selon l'une quelconque des revendications 1 à 4, caractérisé en ce que, pour permettre au logiciel client embarqué de jouer le rôle d'un logiciel client de supervision : le logiciel principal 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 du logiciel client externe vers le logiciel client embarqué et/ou vers les moyens d'exécution compris dans le logiciel principal ; le logiciel client embarqué comprend des moyens de traitement des commandes de pilotage aiguillées vers lui par lesdits moyens d'aiguillage de commandes. 6. Module de radiocommunication selon la revendication 5, caractérisé en ce que le logiciel client embarqué 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 du logiciel client externe sont transmises uniquement aux moyens d'exécution compris dans le logiciel principal ; les commandes de pilotage provenant du logiciel client externe sont transmises uniquement au logiciel client embarqué ; les commandes de pilotage provenant du logiciel client externe sont transmises aux moyens d'exécution compris dans le logiciel principal et au logiciel client embarqué. 7. Module de radiocommunication selon l'une quelconque des revendications 5 et 6, 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 le logiciel principal, le logiciel client embarqué 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, le logiciel client embarqué comprenant à cet effet des moyens d'envoi de la réponse au logiciel client externe, via le logiciel principal. 8. Module de radiocommunication selon l'une quelconque des revendications 1 à 7, caractérisé en ce que, pour permettre au logiciel client embarqué de jouer le rôle d'un logiciel client de supervision : le logiciel principal 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 le logiciel principal, vers le logiciel client embarqué et/ou vers le logiciel client externe ; le logiciel client embarqué comprend des moyens de traitement des réponses aiguillées vers lui par lesdits moyens d'aiguillage de réponses. 9. Module de radiocommunication selon la revendication 8, caractérisé en ce que le logiciel client embarqué 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 au logiciel client externe ; les réponses provenant des moyens d'exécution sont transmises uniquement au logiciel client embarqué ; les réponses provenant des moyens d'exécution sont transmises au logiciel client embarqué et au logiciel client externe. 10. Module de radiocommunication selon l'une quelconque des revendications 1 à 9, 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. 11. Module de radiocommunication selon l'une quelconque des revendications 1 àlO, caractérisé en ce que ledit logiciel principal comprend au moins une application principale, associée à un jeu de fonctions d'exécution, permettant chacune l'exécution d'au moins une desdites commandes de pilotage, en ce que chacune desdites applications clientes principale et secondaire est associée à un jeu de fonctions sources, permettant chacune l'envoi ou la réception, vers ou en provenance de l'application principale, de commandes de pilotage ou de réponses à des commandes de pilotage, et en ce que ledit logiciel principal et/ou ledit logiciel client embarqué comprend (nnent) une application d'interface, permettant l'interfaçage desdites fonctions sources avec lesdites fonctions d'exécution. 12. Module de radiocommunication selon la revendication 11, caractérisé en ce que le jeu de fonctions sources associé à l'application cliente principale comprend notamment une fonction source d'initialisation de l'application cliente principale ("wmapmAppIiInit"), qui est appelée au démarrage du module de radiocommunication. 13. Module de radiocommunication selon la revendication 12, caractérisé en ce que le jeu de fonctions sources associé à l'application cliente principale comprend une fonction source d'abonnement à un service d'envoi de messages provenant du logiciel principal ("wmosMsgParserSubscribe"), et en ce que lors de cet abonnement, l'application cliente principale communique au logiciel principal l'adresse d'une fonction source de traitement d'un message ("wm~apmAppliParser"), dans laquelle l'application cliente principale souhaite recevoir des messages provenant du logiciel principal. 14. Module de radiocommunication selon l'une quelconque des revendications Il à 13, caractérisé en ce que le jeu de fonctions sources associé à l'application cliente secondaire comprend notamment une fonction source d'initialisation de l'application cliente secondaire ("wmapp2Pipe (Init)"), qui est appelée par l'application cliente principale. 15. Module de radiocommunication selon la revendication 14, caractérisé en ce que le jeu de fonctions sources associé à l'application cliente secondaire comprend une fonction source d'abonnement à un service d'envoi de messages provenant du logiciel principal ("wmosMsgParserSubscribe"), et en ce que lors de cet abonnement, l'application cliente secondaire communique au logiciel principal l'adresse d'une fonction source de traitement d'un message ("wmapp2MsgParser"), dans laquelle l'application cliente secondaire souhaite recevoir des messages provenant du logiciel principal. 16. Module de radiocommunication selon l'une quelconque des revendications 14 et 15, caractérisé en ce que ladite fonction source d'initialisation de l'application cliente secondaire comprend au moins un paramètre permettant la mise en carre d'un mécanisme de dialogue entre l'application cliente principale et l'application cliente secondaire. 17. Module de radiocommunication selon l'une quelconque des revendications 14 à 16, caractérisé en ce que le jeu de fonctions sources associé à l'application cliente secondaire comprend en outre une fonction source d'arrêt de l'application cliente secondaire ("wmapp2Pipe (Stop) "), qui est appelée par l'application cliente principale. 18. Module de radiocommunication selon l'une quelconque des revendications 14 à 17, caractérisé en ce que le jeu de fonctions sources associé à l'application cliente secondaire comprend une fonction source de désabonnement audit service d'envoi de messages provenant du logiciel principal ("wmosMsgParserUnsubscribe"). 19. Module de radiocommunication selon l'une quelconque des revendications 13 à 18, caractérisé en ce qu'un paramètre de ladite fonction source de traitement d'un message provenant du logiciel principal ("wmapmAppIiParser", "wmapp2MsgParser") est ledit message, et en ce que ledit message formant paramètre 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. 20. Module de radiocommunication selon la revendication 19, caractérisé en ce que ledit type du message appartient au groupe comprenant : message contenant une réponse à une commande de pilotage préalablement envoyée au logiciel principal par le logiciel client embarqué ; message contenant une commande de pilotage non sollicitée ; message contenant une commande de pilotage envoyée par un logiciel client externe, via le logiciel principal ; message contenant une réponse résultant de l'exécution par le logiciel principal d'une commande de pilotage envoyée par le logiciel client externe ; message envoyé à l'expiration d'une temporisation. 21. Module de radiocommunication selon l'une quelconque des revendications Il à 20, caractérisé en ce que les jeux de fonctions sources associés aux applications clientes principale et secondaire comprennent en outre au moins une fonction source appartenant au groupe comprenant : une fonction ("wmatSendCommand") d'envoi vers le logiciel principal 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 la ou les application (s) destinatrice (s) de la réponse résultant de l'exécution de ladite commande de pilotage, à savoir l'application cliente principale et/ou l'application cliente secondaire comprises dans le logiciel client embarqué, et/ou une application cliente externe comprise dans le logiciel client externe ; une fonction ("wmatUnsoIicitedSubscription") d'inscription auprès du logiciel principal à 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) doit être redirigée chacune des commandes de pilotage non sollicitées, à savoir l'application cliente principale et/ou l'application cliente secondaire comprises dans le logiciel client embarqué, et/ou une application cliente externe comprise dans le logiciel client externe ; une fonction ("wmatCmdPreParserSubscribe") d'inscription auprès du logiciel principal à un service d'aiguillage de commandes de pilotage, un paramètre de ladite fonction d'inscription indiquant vers quelle (s) application (s) doit être aiguillée chacune des commandes de pilotage provenant du logiciel client externe, à savoir l'application cliente principale et/ou l'application cliente secondaire comprises dans le logiciel client embarqué, et/ou le logiciel principal ; une fonction ("wmatRspPreParserSubscribe") d'inscription auprès du logiciel principal à un service d'aiguillage de réponses, un paramètre de ladite fonction d'inscription indiquant vers quelle (s) application (s) doit être aiguillée chacune des réponses résultant de l'exécution par le logiciel principal d'une commande de pilotage, à savoir l'application cliente principale et/ou l'application cliente secondaire comprises dans le logiciel client embarqué, et/ou une application cliente externe comprise dans le logiciel client externe ; une fonction ("wmatSendRspExternalApp") d'envoi vers le logiciel client externe, via le logiciel principal, d'au moins une réponse, un paramètre de ladite fonction d'envoi étant ladite au moins une réponse. 22. Module de radiocommunication selon l'une quelconque des revendications 1 à 21, 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. 23. Module de radiocommunication selon l'une quelconque des revendications 1 à 22, caractérisé en ce que Mit jeu de commandes de pilotage est un jeu de commandes AT standard. 24. Module de radiocommunication selon la revendication 23, 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 chargement d'un logiciel client (AT+WDWL), permettant au logiciel client externe de charger dans le module de radiocommunication un nouveau logiciel client, ou une nouvelle partie de logiciel client. 25. Module de radiocommunication selon l'une quelconque des revendications 23 et 24, 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 au logiciel client externe de désactiver le logiciel client embarqué ou une partie du logiciel client embarqué. 26. Procédé de mise en covre d'un logiciel client de pilotage d'un module de radiocommunication, ledit module de radiocommunication étant du type hébergeant et exécutant un logiciel principal assurant notamment des fonctions de radiocommunication, ledit logiciel principal comprenant des moyens d'exécution de commandes de pilotage, envoyées au logiciel principal par ledit logiciel client de pilotage et appartenant à un jeu de commandes de pilotage prédéterminé, caractérisé en ce que ledit module de radiocommunication héberge et exécute en outre au moins un logiciel client, dit logiciel client embarqué, comprenant une application cliente principale et au moins une application cliente secondaire, esclave de l'application cliente principale, les traitements effectués par ledit logiciel client embarqué étant répartis entre ladite application cliente principale et ladite au moins une application cliente secondaire, et en ce que le logiciel client embarqué et le logiciel principal dialoguent l'un avec l'autre de façon que le logiciel client embarqué joue au moins un des deux rôles suivants : le rôle dudit logiciel client de pilotage, envoyant des commandes de pilotage au logiciel principal, et recevant du logiciel principal des réponses, résultant de l'exécution de certaines des commandes de pilotage ; le rôle d'un logiciel client de supervision, gérant l'exécution de commandes de pilotage envoyées par ledit logiciel client de pilotage, ledit logiciel client de pilotage, dit logiciel client externe, étant hébergé et exécuté par un équipement tiers coopérant avec le module de radiocommunication.