FR2902271A1

FR2902271A1 - Procede de commande d'un module electronique de radiocommunication par un equipement, equipement, module, signal et fichier de description correspondants.

Info

Publication number: FR2902271A1
Application number: FR0605065A
Authority: FR
Inventors: Didier Lahay; Jacques Montes
Original assignee: Wavecom SA
Current assignee: Sierra Wireless SA
Priority date: 2006-06-07
Filing date: 2006-06-07
Publication date: 2007-12-14
Anticipated expiration: 2026-06-07
Also published as: WO2007141215A1; FR2902271B1; EP2025131A1; US20100064062A1

Abstract

L'invention concerne un procédé de commande d'un module électronique de radiocommunication (21) par un premier équipement(22). Selon l'invention, le procédé comprend une étape de découverte par un second équipement de la ou les interface(s) de commande disponible(s) dudit module, ledit second équipement étant confondu avec ou distinct dudit premier équipement.

Description

Procédé de commande d'un module électronique de radiocommunication par un

équipement, équipement, module, signal et fichier de description correspondants. 1. DOMAINE DE L'INVENTION Le domaine de l'invention est celui des radiocommunications, et plus précisément des terminaux de radiocommunication numériques (aussi appelés dispositifs de radiocommunication), qu'il s'agisse de radiotéléphone ou de dispositifs ou moyens de tous types capables d'échanger des signaux à l'aide d'un système de radiocommunication, implantés par exemple dans des machines ou des véhicules.

Plus précisément, l'invention concerne une technique de commande d'un terminal de radiocommunication par un équipement qui lui est relié. L'équipement est par exemple un micro-ordinateur exécutant une application cliente. L'équipement est relié au terminal de radiocommunication, soit en local (par exemple par un lien série ou USB), soit à distance (par exemple à travers un réseau de communication avec ou sans fil). 2. ART ANTÉRIEUR 2.1 Dispositifs de radiocommunication à base de composants La plupart des dispositifs de radiocommunication comprennent, de façon classique, un ensemble de composants électroniques implantés sur un circuit imprimé.

Ces différents composants ont pour but d'assurer les différentes fonctions nécessaires, depuis la réception d'un signal RF jusqu'à la génération d'un signal audible (dans le cas d'un radio-téléphone), et inversement. Certaines de ces fonctions sont analogiques, et d'autres numériques. La fabrication de ces dispositifs de radiocommunication est un sujet de recherche important. En effet, on vise au moins trois objectifs difficiles à concilier : miniaturiser les dispositifs, augmenter et adapter les fonctionnalités, et simplifier le montage. On sait notamment que l'implantation des différents composants sur le circuit imprimé est une opération relativement complexe, de nombreux composants devant être mis en place sur une surface de plus en plus restreinte, du fait des exigences de miniaturisation.

La conception de ces systèmes est donc complexe, puisqu'elle nécessite en outre d'associer des composants divers, souvent de sources multiples, qu'il faut faire fonctionner ensemble, en respectant les spécificités de chacun. Par ailleurs, après le montage de l'ensemble des composants, des phases de calibration et de tests, souvent longues et complexes, sont nécessaires pour garantir le bon fonctionnement du dispositif.

Enfin, malgré la réduction de la taille de certains composants, l'ensemble occupe une certaine surface, qu'il est difficile de réduire. 2.2 Dispositifs de radiocommunication à base de module Le titulaire de la présente demande de brevet a proposé une approche palliant un certain nombre de ces inconvénients, consistant à regrouper dans un module unique (appelé module électronique de radiocommunication), tout ou au moins la plupart des fonctions d'un dispositif de radiocommunication numérique. Un tel module se présente sous la forme d'un boîtier unique, préférentiellement blindé, que les fabricants de dispositifs peuvent implanter directement, sans devoir prendre en compte une multitude de composants.

Ce module (encore appelé parfois macro composant ) est en effet formé d'un regroupement de plusieurs composants sur un substrat, de façon à être implanté sous la forme d'un unique élément. Il comprend les composants (notamment un processeur et une mémoire) et les logiciels essentiels nécessaires au fonctionnement d'un dispositif de radiocommunication (aussi appelé terminal de radiocommunication ou encore terminal sans-fil) utilisant des fréquences radioélectriques. Il n'y a donc plus d'étapes complexes de conception du design, et de validation de celui-ci. Il suffit de réserver la place nécessaire au module. Un tel module permet donc d'intégrer facilement, rapidement et de façon optimisée l'ensemble des composants dans des terminaux sans-fil (téléphones portables, modems, ou tout autre dispositif exploitant un standard sans fil). Par ailleurs, ce module regroupant toutes les fonctions essentielles et ayant été conçu comme un tout, les problèmes de calibration et de tests ne se posent plus de la même manière, ou sont à tout le moins, grandement simplifiés. Ainsi, les modules diffusés par le titulaire de la présente demande de brevet sont entièrement testés tant sur le plan matériel ( hardware ) que logiciel ( software ) sur la plupart des réseaux sur lesquels ils pourront être utilisés ensuite. En outre, le module englobe avantageusement les aspects de propriété intellectuelle (ou IPRs, pour Intellectual Property Rights ) (toutes les fonctions ont été regroupées, c'est le fabricant du module qui gère les aspects de droits de propriété industrielle correspondants) et d'assistance technique.

Le module précité est par exemple un module de type Wismo (marque déposée) distribué par le déposant de la présente demande de brevet. 2.3 Inconvénients de l'état de l'art Malgré ces avantages indéniables, cette technique présente certains inconvénients.

Un premier inconvénient réside dans les difficultés que rencontrent les développeurs d'applications destinées à être exécutées par les équipements pilotant les modules. En effet, le développeur d'une application pour un équipement destiné à piloter un module de radiocommunication donné doit connaître la ou les interface(s) de commande disponible(s) sur ce module. Pour cela, il doit consulter les documents spécifiques à ce module donné, qui en décrivent les interfaces de commande. Ainsi, dans le cas traditionnel où le module de radiocommunication est piloté en commandes AT, le développeur doit impérativement prendre connaissance, sans automatisation possible, des documents définissant textuellement les commandes AT supportées par ce module, ainsi que les interfaces physiques (par exemple RS232, USB,... pour une interface filaire, et Zigbee, Wifi, GPRS,... pour une interface sans fil) et les protocoles (par exemple Raw data, http/TCP/IP,...) sur lesquels ces commandes sont supportées. Ces documents émanent du fournisseur (constructeur) du module concerné. On rappelle que les commandes AT (pour "ATtention command" en anglais) permettent à l'équipement d'exiger du module de radiocommunication auquel il est relié d'exécuter certaines actions prédéterminées. Pour plus de précisions concernant ces commandes AT, on pourra se reporter notamment à la norme "GSM 07.07" de l'ETSI et à la recommandation V25ter de l'ITU-T. Cette prise de connaissance par le développeur est encore complexifiée par le fait que, même s'il existe un jeu de commandes standardisées (par exemple dans la norme "GSM 07.07" précitée), il se peut que le module à piloter ne les supporte pas toutes et qu'il faille donc en tenir compte dans le développement de l'application exécutée par l'équipement. Cette prise de connaissance par le développeur est également complexifiée par le fait que certaines commandes peuvent être propriétaires (c'est-à-dire spécifiques à un fournisseur de module de radiocommunication) et ne sont décrites que dans la documentation technique fournie par ce fournisseur pour le module concerné. Un autre inconvénient de la technique actuelle est qu'une application déjà développée, et permettant à un équipement de piloter un module avec une interface de commande donnée de ce module, doit être au moins partiellement réécrite (et donc ne peut pas être réutilisée telle quelle) pour permettre à un équipement de piloter le même module avec une autre interface de commande, ou bien un autre module. Encore un autre inconvénient de la technique actuelle est que lors de la phase d'utilisation (c'est-à-dire quand l'équipement est connecté à un module de radiocommunication afin de le piloter en exécutant une application préalablement développée), l'équipement ne peut pas adapter de façon dynamique son fonctionnement en fonction du module auquel il est effectivement connecté (et des interfaces de commande disponibles de ce module). 3. OBJECTIFS DE L'INVENTION L'invention, dans au moins un mode de réalisation, a notamment pour objectif de 20 pallier ces différents inconvénients de l'état de la technique. Plus précisément, l'un des objectifs de la présente invention, dans au moins un mode de réalisation, est de fournir une technique de commande d'un module de radiocommunication par un équipement, permettant de faciliter le développement de l'application exécutée par cet équipement. 25 L'invention a également pour objectif, dans au moins un mode de réalisation, de fournir une telle technique permettant le pilotage du module par l'équipement, à travers n'importe quel type d'interface, en local ou à distance. Un autre objectif de l'invention, dans au moins un mode de réalisation, est de fournir une telle technique, qui soit simple à mettre en oeuvre et peu coûteuse. 30 Encore un autre objectif de l'invention, dans au moins un mode de réalisation, est de fournir une telle technique permettant à l'équipement d'adapter de façon dynamique son fonctionnement en fonction du module auquel il est effectivement connecté (et des interfaces de commande disponibles de ce module). 4. EXPOSÉ DE L'INVENTION Dans un mode de réalisation particulier de l'invention, il est proposé un procédé de commande d'un module électronique de radiocommunication par un premier équipement, ce procédé comprenant une étape de découverte par un second équipement de la ou les interface(s) de commande disponible(s) dudit module, ledit second équipement étant confondu avec ou distinct dudit premier équipement. Le principe général de l'invention consiste donc à exporter de façon automatique, vers l'équipement, les informations relatives à la ou les interfaces de commande du module. Avantageusement, chaque interface de commande disponible dudit module est définie par : un jeu de commandes supportées par le module ; - une interface physique du module sur laquelle ledit jeu de commande est supporté ; - un protocole sur lequel ledit jeu de commande est supporté. Dans un premier mode de réalisation particulier de l'invention, ladite étape de découverte comprend les étapes suivantes : - ledit second équipement envoie au moins une requête de découverte audit module ; - ledit module envoie audit second équipement au moins une réponse, contenant la ou les interface(s) de commande disponible(s) dudit module. De façon avantageuse, ladite au moins une requête de découverte appartient au groupe comprenant : - une requête (AT+HELP ATCmdSet) demandant au module d'envoyer au second équipement une liste de commandes supportées par le module ; - une requête (AT+HELP ATCmdFirst) demandant au module d'envoyer au second équipement une première commande d'une liste de commandes supportées par le module ; - une requête (AT+HELP ATCmdNext) demandant au module d'envoyer au second équipement une commande suivante, par rapport à une commande courante, d'une liste de commandes supportées par le module ; - une requête (AT+ HELP ATCmdPrevious) demandant au module d'envoyer au 5 second équipement une commande précédente, par rapport à une commande courante, d'une liste de commandes supportées par le module ; - une requête (AT+HELP Command) demandant au module d'envoyer au second équipement une liste de paramètres en entrée et/ou de réponses associés à une commande indiquée dans ladite requête ; 10 - une requête (AT+HELP ATCmdItf) demandant au module d'envoyer au second équipement une indication des protocoles et des types d'interface sur lesquels ledit module supporte des commandes. Avantageusement, ladite au moins une requête de découverte est une nouvelle commande AT. 15 Dans ce cas, l'invention reste compatible avec l'utilisation actuelle des modules de radiocommunication pilotés par commandes AT. Il suffit d'adapter le logiciel principal des modules, afin que la partie assurant le traitement des commandes AT classiques puisse également traiter les nouvelles commandes AT introduites par la présente invention. 20 Dans un second mode de réalisation particulier de l'invention, ladite étape de découverte comprend les étapes suivantes : -ledit second équipement envoie audit module au moins une requête d'obtention d'un fichier de description contenant la ou les interface(s) de commande disponible(s) dudit module ; 25 - ledit module envoie ledit fichier de description audit second équipement. De façon avantageuse, ledit second équipement obtient le fichier de description : - en local, grâce à une connexion entre le second équipement et le module, ledit fichier de description étant stocké par le module ; ou - à distance, grâce à une connexion entre le second équipement et un autre 30 équipement distant, ledit fichier de description étant stocké par ledit autre équipement distant.

Avantageusement, ledit fichier de description est un fichier WSDL décrivant la ou les interface(s) de commande disponible(s) dudit module sous la forme d'au moins un service Web hébergé par ledit module. Dans ce cas, le module se comporte donc, au sens de la technologie de services Web, comme un point d'extrémité ( end point en anglais) accessible par tout client Web (c'est-à-dire tout équipement souhaitant le piloter). La ou les interfaces de commande du module sont décrites dans un contrat de service matérialisé dans un fichier WSDL. Dans un mode de réalisation particulier, ledit module héberge et exécute un logiciel principal de radiocommunication et un logiciel client embarqué. En outre, ledit fichier WSDL décrit au moins un service Web qui est fourni par ledit logiciel client et qui utilise au moins une interface de commande disponible du module. On se place dans le contexte (connu) où le fournisseur du module de radiocommunication permet à chaque client d'embarquer sur le module une application cliente qui lui est propre. La nouveauté vient de ce que le fournisseur du module offre en outre à chaque client la possibilité d'intégrer un ou plusieurs services Web dans son application cliente. En d'autres termes, on permet une exportation des interfaces métier du client, sous forme de services Web. Avantageusement, ledit au moins un service Web est décrit, dans ledit fichier WSDL, en réutilisant la syntaxe des commandes AT. Ainsi, dans ce cas, on garde une compatibilité avec les commandes AT actuelles, en les encapsulant dans des services Web génériques. De cette façon, l'équipement pilote le module en lui envoyant des commandes qui, du fait qu'elles respectent la syntaxe des commandes AT, peuvent être traitées par la partie du logiciel principal du module qui traite les commandes AT. En d'autres termes, il n'est pas nécessaire que le module comprenne en outre une couche logicielle spécifique aux services Web. Dans le cas où l'application cliente est embarquée par le module et que cette application cliente expose de nouvelles commandes AT, ces dernières peuvent être exposées de la même manière que celles suppportées en natif sur le module.

Selon une variante avantageuse, ledit au moins un service Web est décrit, dans ledit fichier WSDL, en utilisant une syntaxe distincte de celle des commandes AT.

Dans cette variante, il s'agit d'une implémentation faisant table rase des commandes AT actuelles, les interfaces du module étant redéfinies au format services Web. Il est nécessaire que le module comprenne une couche logicielle spécifique aux services Web (appelée par la suite Modem I/F ou Web Services API , pour Web Services Application Programming Interface en anglais). Selon une variante avantageuse, ladite étape de découverte est suivie des étapes suivantes : - sélection d'une interface de commande du module, parmi la ou les interface(s) de commande disponible(s) préalablement découverte(s) ; - pilotage dudit module par ledit premier équipement, en fonction de l'interface de commande sélectionnée. Dans un premier mode de réalisation particulier de l'invention, lesdites étapes de découverte et sélection sont effectuées avec ledit second équipement, lors d'une phase de développement d'une application et/ou une couche logicielle (Modem Driver) sur laquelle s'appuie ladite application, destiné(es) à être hébergé(es) et exécuté(es) par ledit premier équipement, ladite étape de sélection étant effectuée par un développeur, ledit développement étant fonction de l'interface de commande sélectionnée. En outre, ladite étape de pilotage est effectuée lors d'une phase ultérieure d'utilisation dudit premier équipement en coopération avec ledit module.

Ainsi, on facilite le développement de l'application exécutée par l'équipement. Dans un second mode de réalisation particulier de l'invention, le second équipement est confondu avec le premier équipement. En outre, lesdites étapes de découverte, sélection et pilotage sont effectuées lors d'une phase d'utilisation dudit premier équipement en coopération avec ledit module, ladite étape de sélection étant effectuée de façon automatique et dynamique par ledit premier équipement, en fonction d'une part d'une politique de sélection prédéterminée et d'autre part de la ou les interface(s) de commande disponible(s) découverte(s). De cette façon, l'équipement peut adapter de façon dynamique son fonctionnement en fonction du module auquel il est effectivement connecté (et des interfaces de commande disponibles de ce module).

Par exemple, une application peut prévoir de gérer dès la conception des modules provenant de plusieurs fournisseurs, chacun ayant des spécificités. Dans l'étape de découverte des interfaces, l'application s'adapte si le cas a été prévu dès la conception. Par exemple, une application serveur à distance peut être prévue pour avoir une compatibilité avec le maximum de modules différents possibles et donc décide, après l'étape de découverte, des interfaces à utiliser en fonction de celles disponibles sur le module considéré. Dans un autre mode de réalisation, l'invention concerne un équipement, du type permettant de coopérer avec un module électronique de radiocommunication. Cet équipement comprend des moyens de découverte de la ou les interface(s) de commande disponible(s) dudit module, de façon à permettre la commande dudit module par ledit équipement ou par un autre équipement. Plus généralement, l'équipement selon l'invention comprend des moyens de mise en oeuvre du procédé de commande tel que décrit précédemment (dans l'un quelconque de ses différents modes de réalisation). Dans un autre mode de réalisation, l'invention concerne un module électronique de radiocommunication, du type pouvant être commandé par un premier équipement, ce module comprenant : -des moyens de réception d'au moins une requête de découverte envoyée par un second équipement, confondu avec ou distinct dudit premier équipement ; - des moyens d'envoi d'au moins une réponse audit second équipement, contenant la ou les interface(s) de commande disponible(s) dudit module. Dans une variante de réalisation, l'invention concerne un module électronique de radiocommunication, du type pouvant être commandé par un premier équipement, module comprenant : - des moyens de réception d'au moins une requête d'obtention d'un fichier de description contenant la ou les interface(s) de commande disponible(s) dudit module, envoyée par un second équipement, confondu avec ou distinct dudit premier équipement ; -des moyens d'envoi dudit fichier de description audit second équipement.

Plus généralement, le module selon l'invention comprend des moyens de mise en oeuvre du procédé de commande tel que décrit précédemment (dans l'un quelconque de ses différents modes de réalisation). Dans un autre mode de réalisation, l'invention concerne un signal transmis depuis un équipement vers un module électronique de radiocommunication, ce signal comprenant au moins une requête de découverte de la ou les interface(s) de commande disponible(s) dudit module. Dans un autre mode de réalisation, l'invention concerne un support d'enregistrement contenant un fichier de description associé à un module électronique de radiocommunication, ledit module étant du type pouvant être commandé par un équipement, ledit fichier de description contenant la ou les interface(s) de commande disponible(s) dudit module, ledit fichier de description étant destiné à être stocké en local sur le module ou à distance sur un autre équipement. 5. LISTE DES FIGURES D'autres caractéristiques et avantages de modes de réalisation de l'invention apparaîtront à la lecture de la description suivante de plusieurs modes de réalisation particulier de l'invention, donnés à titre d'exemple indicatif et non limitatif, et des dessins annexés, dans lesquels : la figure 1 présente un organigramme d'un mode de réalisation particulier du procédé selon l'invention ; la figure 2 présente un schéma bloc fonctionnel d'un module de radiocommunication et de deux équipements (l'un local et l'autre distant), illustrant des premier et deuxième modes de réalisation du procédé selon l'invention ; la figure 3 présente un schéma bloc fonctionnel d'un module de radiocommunication et de deux équipements (l'un local et l'autre distant), illustrant des troisième et quatrième modes de réalisation du procédé selon l'invention ; la figure 4 présente un schéma bloc fonctionnel d'un module de radiocommunication et de deux équipements (locaux), illustrant un cinquième mode de réalisation du procédé selon l'invention ; la figure 5 illustre un premier exemple d'application du procédé de l'invention, dans le cas d'un compteur d'eau pilotant un module de radiocommunication afin de communiquer avec un serveur de collecte ; et la figure 6 illustre un second exemple d'application du procédé de l'invention, dans le cas d'un serveur de collecte pilotant un module de radiocommunication embarquant une application cliente déportée depuis un compteur d'eau vers le module. 6. DESCRIPTION DÉTAILLÉE Sur toutes les figures du présent document, les éléments et étapes identiques sont désignés par une même référence numérique. 6.1 Principe général de l'invention L'invention concerne donc un procédé de commande d'un module électronique de radiocommunication par un équipement. Comme illustré par l'organigramme de la figure 1, le procédé comprend : - une étape 1 de découverte par l'équipement de la ou les interface(s) de commande disponible(s) du module ; - une étape 2 de sélection d'une interface de commande du module, parmi la ou les interface(s) de commande disponible(s) préalablement découverte(s) ; - une étape 3 de pilotage du module par l'équipement, en fonction de l'interface de commande sélectionnée. Pour les échanges entre le module et l'équipement, différents formats de commandes peuvent être envisagés pour les étapes de découverte, sélection et pilotage, tout en restant dans le cadre de la présente invention. A titre d'exemple, on décrit ci-après plus en détail les trois cas suivants : - utilisation de commandes AT pour les échanges entre le module et l'équipement (voir le paragraphe 6.2) ; -utilisation de services Web pour les échanges entre le module et l'équipement (voir le paragraphe 6.3) ; - utilisation de commandes AT et de services Web pour les échanges entre le module et l'équipement (voir le paragraphe 6.4).

La figure 5 illustre un premier exemple d'application du procédé de l'invention : un compteur d'eau 51 pilote un module de radiocommunication 52 afin de communiquer, via un réseau de radiocommunication 54 (réseau GSM par exemple), avec un serveur de collecte 53.

Pendant la phase de développement d'une première application cliente 511 destinée à être exécutée par le compteur d'eau 51, ce dernier, ou le plus souvent en pratique un autre équipement (par exemple un PC) spécifique au développement, communique avec le module 52 afin de connaître les interfaces de commande disponibles du module (étape 1 de découverte).

Puis, dans cette même phase de développement, le développeur sélectionne l'une des interfaces de commande disponibles préalablement découvertes (étape 2 de sélection), et tient compte de l'interface sélectionnée dans le développement qu'il effectue. Lors d'une phase ultérieure d'utilisation du compteur d'eau 51, le pilotage du module se déroule par exemple comme suit (étape 3 de pilotage). A fréquence fixe (par exemple une fois par mois), la première application cliente 511 exécutée par le compteur d'eau 51 obtient d'un capteur 512 une information relative à la quantité d'eau consommée. Puis elle pilote le module 52, en envoyant des commandes à une application principale de radiocommunication 521 exécutée par le module, afin de transmettre cette information à une seconde application cliente 531 exécutée par le serveur de collecte 53. Cette transmission s'effectue par exemple sous la forme d'un envoi de message de type SMS par le module 52. Dans une variante de ce premier exemple d'application du procédé de l'invention, les étapes de découverte et sélection sont effectuées au cours de la phase d'utilisation. Plus précisément, l'étape de sélection est effectuée de façon automatique et dynamique par le compteur d'eau 51, en fonction d'une part d'une politique de sélection prédéterminée et d'autre part de la ou les interface(s) de commande disponible(s) découverte(s). La figure 6 illustre un second exemple d'application du procédé de l'invention : un serveur de collecte 63 pilote, via un réseau de radiocommunication 64 (réseau GSM par exemple), un module de radiocommunication 62 embarquant une première application cliente 622 déportée depuis un compteur d'eau 61 vers le module. On se place ici dans un des contextes possibles de la technique Open AT (marque déposée), tel que décrit en détail dans le brevet français FR 2 822 627 publié le 27 septembre 2002, et dont le déposant de la présente demande de brevet est le titulaire. Dans le présent second exemple, et conformément à l'un des contextes possibles de la technique Open AT (marque déposée), le module de radiocommunication 62 exécute d'une part une application principale de radiocommunication 621 et d'autre part la première application cliente 622 précitée.

Pendant la phase de développement d'une seconde application cliente 631 exécutée par le serveur de collecte 63, ce dernier (ou bien un autre équipement, par exemple un PC, spécifique au développement) communique avec le module 62 afin de connaître les interfaces de commande disponibles du module (étape 1 de découverte). Eventuellement, les interfaces de commande disponibles permettent également d'exposer les commandes AT par l'application embarquée. Puis, dans cette même phase de développement, le développeur sélectionne l'une des interfaces de commande disponibles préalablement découvertes (étape 2 de sélection), et tient compte de l'interface sélectionnée dans le développement qu'il effectue.

Lors d'une phase ultérieure d'utilisation du serveur de collecte 63, le pilotage du module se déroule par exemple comme suit (étape 3 de pilotage). A fréquence fixe (par exemple une fois par mois), la seconde application cliente 631 exécutée par le serveur de collecte 63 pilote le module 62, afin que la première application cliente 622 obtienne d'un capteur 612 (compris dans le compteur d'eau 61) une information relative à la quantité d'eau consommée et renvoie cette information à la seconde application cliente 631. L'envoi de cette réponse s'effectue par exemple sous la forme d'un envoi de message de type SMS par le module 62. Dans une variante de ce second exemple d'application du procédé de l'invention, les étapes de découverte et sélection sont effectuées au cours de la phase d'utilisation. Plus précisément, l'étape de sélection est effectuée de façon automatique et dynamique par le serveur de collecte 63, en fonction d'une part d'une politique de sélection prédéterminée et d'autre part dela ou les interface(s) de commande disponible(s) découverte(s). 6.2 Implémentation avec utilisation des commandes AT On présente maintenant, en relation avec la figure 2, des premier et deuxième modes de réalisation du procédé selon l'invention, basés sur l'utilisation de commandes AT pour les échanges entre le module 21 et un équipement local 22 (premier mode de réalisation), ou entre le module 21 et un équipement distant 23 (deuxième mode de réalisation).

Le module de radiocommunication 21 comprend : - une application principale de radiocommunication 211, comprenant elle-même une partie 212 dédiée au traitement des commandes AT. L'application principale de radiocommunication 211 est aussi nommée logiciel de modem (ou modem software sur la figure 2), du fait que le module de radiocommunication joue le rôle d'un modem sans fil). Dans un souci de simplification, les ressources de stockage (mémoire) et d'exécution (CPU) de cette application principale, au sein du module 21, ne sont pas représentées sur la figure 2 ; - une interface GPRS 214 ; - une couche HTTP-TCP-IP 213 (au-dessus de l'interface GPRS 214) ; - une interface USB 215 ; -une interface RS232 216 ; et - une interface Ethernet 217. L'équipement local 22 comprend une application cliente locale 221, une interface USB 222, une interface RS232 223 et une interface Ethernet 224. Il est relié au module 21 par l'intermédiaire d'un lien local 24 (lien USB, RS232 ou Erthernet dans cet exemple), sur lequel transitent les commandes AT. L'équipement distant 23 comprend une application cliente distante 231 et une couche HTTP-TCP-IP 232, au-dessus d'une interface GPRS 233. Il est relié au module 21 par l'intermédiaire d'un lien distant 25 (lien GPRS/IP dans cet exemple), sur lequel transitent les commandes AT (ces dernières sont encapsulées dans des paquets IP). Dans un souci de simplification, les ressources de stockage (mémoire) et d'exécution (CPU) des applications clientes locale 221 et distante 231, au sein de l'équipement local 22 et de l'équipement distant 23 respectivement, ne sont pas représentées sur la figure 2. Pour mettre en oeuvre l'étape de découverte (référencée 1 sur la figure 1), l'équipement 22 ou 23 utilise une ou plusieurs nouvelles commandes AT (qui font partie de la présente invention) permettant à l'équipement de récupérer les commandes AT supportées par le module 21. Une nouvelle commande, appelée par exemple AT+HELP ATCmdSet , est telle que si l'équipement l'envoie au module, ce dernier envoie en réponse la liste des commandes AT qu'il supporte, telles que par exemple : AT+CPIN? - AT+CPIN= - AT+CREG? - AT+CKPD= - etc. Dans une variante, la nouvelle commande AT+HELP ATCmdSet est remplacée/complétée par un jeu de trois nouvelles commandes AT, appelées par exemple AT+HELP ATCmdFirst , AT+HELP ATCmdNext et AT+HELP ATCmdPrevious . Celles-ci permettent à l'équipement de demander au module de lui envoyer une par une les commandes AT qu'il supporte. Ainsi : - si l'équipement envoie au module la nouvelle commande AT+HELP 25 ATCmdFirst , le module lui envoie en réponse une première commande de la liste de commandes qu'il supporte (le module renvoie par exemple la commande AT+CPIN? ) ; - si l'équipement envoie au module la nouvelle commande AT+HELP ATCmdNext , le module lui envoie en réponse une commande suivante, par rapport à une commande courante, de la liste de commandes qu'il supporte (le module renvoie par exemple la commande AT+CPIN= ) ; - si l'équipement envoie au module la nouvelle commande AT+HELP ATCmdPrevious , le module lui envoie en réponse une commande précédente, par rapport à une commande courante, de la liste de commandes qu'il supporte (le module renvoie par exemple la commande AT+CPIN? ). Une autre nouvelle commande, appelée par exemple AT+HELP Command , est telle que si l'équipement l'envoie au module, ce dernier envoie en réponse une liste de paramètres en entrée (IN) et/ou de réponses (OUT) associés à la commande (dont le nom est Command ) indiquée en attribut de la nouvelle commande AT+HELP Command . Exemple : si l'équipement envoie la commande AT+HELP CPIN? , le module répond en voyant : - OUT=SIM_READY/SIM PIN/SIM PUK/ERROR/CME_ERROR ...

Autre exemple : si l'équipement envoie la commande AT+HELP CPIN= , la réponse du module peut être l'une des réponses suivantes : - IN=PIN, OUT=PIN_READY/ERROR_16/ERROR_17 ... - IN=PUK,PIN, OUT= IN_READY/ERROR_16/ERROR_17 ... Encore une autre nouvelle commande, appelée par exemple AT+HELP ATCmdItf , est telle que si l'équipement l'envoie au module, ce dernier envoie en réponse une indication des protocoles et des types d'interface sur lesquels le module supporte des commandes AT. Par exemple, les commandes AT supportées par le module sont par défaut en protocole Raw Data, mais on peut envisager de les encapsuler dans des trames IP afin d'avoir un module vu comme un périphérique IP générique. Exemple : si l'équipement envoie la commande AT+HELP ATCmdItf , la réponse du module peut être l'une des réponses suivantes : - +ATCMDITF RS232,RaW (Raw Data sur le lien RS232) ; - +ATCMDITF USB,RaW (Raw Data sur le lien USB) ; - +ATCMDITF GPRS,RaW/HTTP (Raw Data et HTTP supportés à travers le lien GPRS) Ainsi, dans les premier et second modes de réalisation illustrés sur la figure 2, les étapes de découverte et de pilotage sont effectuées grâce à l'utilisation des commandes AT. Comme déjà discuté plus haut, ces deux étapes sont effectuées soit par un même équipement, si elles sont toutes les deux exécutées lors d'une phase d'utilisation de cet équipement, soit chacune par un équipement distinct, si elles sont exécutées dans une phase de développement et une phase d'utilisation respectivement. 6.3 Implémentation avec utilisation de la technologie Web services On présente maintenant, en relation avec la figure 3, des troisième et quatrième modes de réalisation du procédé selon l'invention, basés sur l'utilisation de la technologie des services Web pour les échanges entre le module 31 et un équipement local 32 (troisième mode de réalisation), ou entre le module 31 et un équipement distant 33 (quatrième mode de réalisation). Le module de radiocommunication 31 comprend : - une application principale de radiocommunication 311, aussi nommée logiciel de modem (ou modem software sur la figure 2). Dans un souci de simplification, les ressources de stockage (mémoire) et d'exécution (CPU) de cette application principale, au sein du module 31, ne sont pas représentées sur la figure 3; - une interface USB 315 ; une interface RS232 316 ; - une interface Ethernet 317 ; - une interface GPRS 318 ; - une couche HTTP-TCP-IP 314, au-dessus des interfaces USB , 25 RS232 , Ethernet et GPRS ; - une couche SOAP 313, au-dessus de la couche HTTP-TCP-IP ; - une couche Modem I/F (couche logicielle d'interface) 312, au-dessus de la couche SOAP ; - un fichier WSDL 319.

Dans une variante, le fichier WSDL 339 est stocké sur un serveur externe, accessible via une adresse Internet (référencée 340 sur la figure 3). L'équipement local 33 comprend : - une application cliente locale 331 ; -une interface USB 335 ; - une interface RS232 336 ; - une interface Ethernet 337 ; - une couche HTTP-TCP-IP 334, au-dessus des interfaces USB , RS232 , Ethernet et GPRS ; - une couche SOAP 333, au-dessus de la couche HTTP-TCP-IP ; - une couche Modem Driver (couche logicielle pilote) 332, au-dessus de la couche SOAP . L'équipement local 33 est relié au module 31 par l'intermédiaire d'un lien local 35 (lien USB, RS232 ou Erthernet dans cet exemple), sur lequel transitent les requêtes 15 et réponses de type services Web (échanges selon le protocole SOAP). L'équipement distant 32 comprend : - une application cliente distante 321 ; - une interface GPRS 325 ; - une couche HTTP-TCP-IP 324, au-dessus de l'interface GPRS ; 20 - une couche SOAP 323, au-dessus de la couche HTTP-TCP-IP ; - une couche Modem Driver (couche logicielle pilote) 322, au-dessus de la couche SOAP . La couche Modem Driver 322, 332 de chacun des équipements 32, 33 est générée par un analyseur WSDL 339, à partir du fichier WSDL. 25 L'équipement distant 32 est relié au module 31 par l'intermédiaire d'un lien distant 34 (lien GPRS/IP dans cet exemple), sur lequel transitent les requêtes et réponses de type services Web (échanges selon le protocole SOAP). Dans un souci de simplification, les ressources de stockage (mémoire) et d'exécution (CPU) des applications clientes locale 331 et distante 321, au sein de l'équipement local 33 et de l'équipement distant 32 respectivement, ne sont pas représentées sur la figure 3. Pour mettre en oeuvre l'étape de découverte (référencée 1 sur la figure 1), l'équipement 32 ou 33 récupère le fichier WSDL 319, 339 en local (cas du stockage sur le module) ou à distance (cas du stockage réseau). Les couches SOAP 313, 323 et 333 implémentent le protocole SOAP qui est un protocole de transmission de messages. Il définit un ensemble de règles pour structurer des messages qui peuvent être utilisés dans de simples transmissions unidirectionnelles, mais il est particulièrement utile pour exécuter des dialogues requête- réponse RPC (Remote Procedure Call). C'est le protocole des messages de services Web. La couche Modem I/F 312 est une couche logicielle implémentant le contrat de service supporté par le logiciel de modem (modem software), matérialisé par le fichier WSDL. Dans un mode de réalisation, ce sont les commandes AT exposées en services Web, ce qui permet de réutiliser des commandes existantes. Dans un autre mode de réalisation, c'est une implémentation de nouvelles interfaces supportées par le logiciel de modem. Les couches Modem Driver 322, 332 sont des couches d'interface logicielle crées (par exemple automatiquement) à partir du fichier WSDL. Elles proposent en interface haute les services Web découverts et les encapsule dans le protocole SOAP. L'ensemble formé des couches SOAP 323 et Modem Driver 322 (ou SOAP 333 et Modem Driver 332) est le corollaire de l'ensemble formé par les couches SOAP 313 et Modem I/F 312: le premier envoie des requêtes et l'autre les traite et renvoie des réponses qui sont à leur tout traitées par le premier.

Ainsi, dans les troisième et quatrième modes de réalisation illustrés sur la figure 3, les étapes de découverte et de pilotage sont effectuées grâce à la technologie des services Web. Comme déjà discuté plus haut, ces deux étapes sont effectuées soit par un même équipement, si elles sont toutes les deux exécutées lors d'une phase d'utilisation de cet équipement, soit chacune par un équipement distinct, si elles sont exécutées dans une phase de développement et une phase d'utilisation respectivement.

Dans une variante (non illustrée), l'étape de découverte est effectuée grâce à la technologie des services Web (fonctionnement en mode service Web ) et permet de découvrir des interfaces AT. puis l'équipement bascule en mode commandes AT sur le lien ayant servi à détecter les commandes (c'est-à-dire découvrir les interfaces AT).

Enfin, l'équipement effectue l'étape de pilotage du module grâce aux commandes AT. En d'autres termes, les interfaces de commande disponibles du module sont décrites, dans le fichier WSDL, en utilisant la syntaxe des commandes AT. 6.4 Implémentation avec utilisation des commandes AT et la technologie Web services On présente maintenant, en relation avec la figure 4, un cinquième mode de réalisation du procédé selon l'invention, dans lequel un même module de radiocommunication 41 peut être piloté par deux équipements distincts 22, 33. Ainsi, il est compatible avec les applications clientes le pilotant avec des commandes AT, et avec les applications clientes le pilotant avec la technologie des services Web. A titre illustratif, ces deux équipements 22, 33 sont locaux et identiques aux équipements portant les mêmes références sur les figures 2 et 3 respectivement. Ils ne sont donc pas décrits à nouveau. Dans une variante, l'un des équipements (ou les deux) pourrai(en)t être distant(s). L'un 22 est relié au module 41 par l'intermédiaire d'un premier lien local 44, sur lequel transitent des commandes AT. L'autre 33 est relié au module 41 par l'intermédiaire d'un second lien local 45, sur lequel transitent des requêtes et réponses de type services Web (échanges selon le protocole SOAP). Le module 41 comprend une combinaison des moyens (non décrits à nouveau) compris dans les modules 21 (figure 2) et 31 (figure 3) déjà décrits ci-dessus. Plus précisément, il comprend : - une application principale de radiocommunication 411, comprenant elle-même une partie 212 dédiée au traitement des commandes AT ; - une interface USB 315 ; une interface RS232 316 ; - une interface Ethernet 317 ; - une interface GPRS 318 ; - une couche HTTP-TCP-IP 314, au-dessus des interfaces USB , RS232 , Ethernet et GPRS ; - une couche SOAP 313, au-dessus de la couche HTTP-TCP-IP ; - une couche Modem I/F (couche logicielle d'interface) 312, au-dessus de la 5 couche SOAP ; - un fichier WSDL 319. 6.5 Avantages de l'invention L'utilisation détournée, selon l'invention, de la technologie des services Web pour la commande d'un module de radiocommunication par un équipement offre les 10 avantages suivants : - elle permet de découvrir automatiquement les interfaces disponibles (commandes et réponses) d'un module de radiocommunication ; - elle permet de piloter un module à travers n'importe quel type d'interface : locale (par lien série ou USB par exemple), ou distante à travers un réseau de 15 communication avec ou sans fil ; - le fichier de description (WSDL) peut être récupéré en local sur le module ou sur un site Internet déterminé ; - les techniques de découverte (WS-Discovery), de Metadata (WS- MetadataTransfer), de Security (WS-Security) et de remontée d'évènements 20 (WS-Eventing) définis par l'organisation OASIS ( Organization for the Advancement of Structured Information Standards ) peuvent être utilisées ; - elle permet d'unifier l'accès à des ressources et donc les interfaces offertes ; - elle permet de délocaliser les services offerts ; - elle permet d'offrir une interface programmatique plus largement utilisée et 25 outillée que celle des commandes AT standard ; - le module de radiocommunication se comporte comme un point d'extrémité ( end point ) accessible par tout client Web. Le module devient un module IP ; - elle facilite la mise en place d'opérations de maintenance et de développement à distance ; 30 - elle permet à une application de découvrir dynamiquement des interfaces offertes par un module de radiocommunication : * permet une plus grande flexibilité dans l'élaboration d'applications basées sur un parc d'équipements (machines) qui utilisent des technologies d'accès différentes : GSM/GPRS, Wifi, Bluetooth, Zigbee, UWB,... ; * grâce au contrat de service, une application peut détecter). les méthodes, implémentées par différents constructeurs pour un même service ; par exemple, les commandes AT Simtoolkit sont définies par chaque constructeur, une découverte des interfaces de la famille SATK (service Simtoolkit), permettrait aux applications de s'adapter au module utilisé ; * de nouveaux modules peuvent être ajoutés et identifiés dynamiquement par l'application ; qui peut alors vérifierla compatibilité avec le module ainsi détecté ; - elle offre une interface de programmation des modules plus naturelle pour les développeurs d'application que dans le cas des commandes AT, tout en restant 15 indépendante de l'architecture matérielle (HW) et du système d'exploitation (OS) choisis pour l'application et le module : * architecture biprocesseur, par exemple pour un PDA ou Smartphone, sous Linux (marque déposée) ou Windows (marque déposée), nécessite un driver (pilote) spécifique pour chaque module utilisé. L'utilisation de la technologie des services Web simplifie grandement l'écriture de ces drivers, le driver spécifique devenant trivial (limité à une interface matérielle) ; * beaucoup d'outils et de librairies sont déjà disponibles pour la technologie des services Web, ce qui rend l'utilisation de cette technologie triviale pour les développeurs d'applications sans fil ( Wireless ) ; * architecture mono-processeur sur un système d'exploitation (OS) de type Wavecom Open AT (marque déposée) : l'application cliente embarquée sur le module expose ses fonctionnalités métier sous forme de services Web. Exemple, un module embarquant une application cliente de gestion d'un compteur d'eau ou d'électricité expose ses interfaces Web 20 25 30 services au système de collecte des données local ou distant (voir ci- dessus la description de la figure 6 qui illustre cette application) ; possibilité d'automatisation de tests. Une fois ces interfaces découvertes, il est possible de lancer une campagne de test automatisée ; - les interfaces disponibles peuvent être de différents niveaux, par exemple dans un premier temps, certaines interfaces apparaissent, puis sur entrée d'une clé secrète un ensemble plus étendu d'interfaces peut devenir disponible. Dans le premier niveau d'interface, une API particulière serait déclarée pour permettre justement de valider les accès à des niveaux supérieurs ; - couplé aux standards de sécurité utilisés dans les technologies Web services, l'accès aux interfaces et donc aux commandes du modem peuvent être sécurisées : Web services sur Https (SSL ou TLS).

ANNEXE 1 : Mapping Commandes AT & WSDL Définitions • Commandes AT : Décrit un ensemble de commandes et de réponses pour le pilotage d'un modem • WSDL ù Définition : Décrit formellement le contenu des messages (formalisme SOAP, structure de messages XML standardisée) d'un service, décrit les protocoles et adresses utilisés pour le service. WSDL description WSDL Elément Description Open AT Analogie Proposition Type Définition des types de données Ensemble de types Définition des types (basé sur XML schéma) utilisés structurés structurés nécessaires par le service aux échanges de données avec le modem Message Définition abstraite d'une Structure typée Définition de structure de donnée typée utilisée commandes types avec pour communiquer avec le service le modem Operation Description d'une action proposée Fonction Définition des par le service En mode RPC : commandes fournies Nom chaque partie des par le modem et Message d'entrée [éventuel] messages réponses associées Message de sortie [éventuel] correspondent à un paramètre : entrée ou retour Port Type Ensemble d'opérations API Ensemble des abstraites (non reliées à un Layer indépendante commandes protocole de transport ni à une du protocole de disponibles sur le adresse) transport modem Peut y en avoir plusieurs pour besoins de structuration Binding Association d'un Port Type Protocole Choix de http ou avec un protocole de transport et Https, style Document style d'encodage ex : HTTP & rpc ou document Port Association d'un Binding avec Serveur URL du modem dans une adresse de service : URL le réseau utilisateur Service Ensemble de ports Back end Le Modem Même Port type avec plusieurs Bindings = alternative 10 ANNEXE 2 : Exemple de portage en Web services d'une simple commande AT pour saisir le code PIN du modem. • Commande : o AT+CPIN=PIN code o Ou AT+CPIN=PUK code, new PIN code o Ou AT+CPIN? • Réponse : o OK ou chaîne de statut 1) Description WSDL du service modem PIN sans réutiliser la syntaxe commandes AT < ?xml version= "1.0" encoding="UTF-8"?> <I-- WSDL description of the Wavecom GSM/GPRS modem Web API. This API is drafted for example purpose only. --> 15 <I-- Definitions and used namespaces used by the API --> <1-- tns : type naine space xsd : schema naine space soap : soap naine space wsdl : wsdl naine space --> 20 <definitions naine="urn:WisMoCommand" targetNamespace="urn:WisMoCommand" xmins="http://schemas.xmisoap.org/wsdl/" xmins:tss="urn:WisMoCommand" xmins:xsd="http://www.w3.org/2001/XMLSchema" 25 xmins:soap="http://schemas.xmisoap.org/wsdl/soap/" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" > <1-- Types for AT command parameters and received results --> <1-- Defined with schemas --> <types> 30 <xsd:schema targetNamespace="urn:WisMoCommand"> <xsd:element name="PINCode" type="xsd:string" /> <xsd:element name="PUKCode" type="xsd:string" /> <xsd:element name="PINReady" type="xsd:boolean" /> <xsd:element name="PINErrorCode" type="xsd:string" /> 35 <xsd:complexType name="PINStatus"> <xsd:sequence> <xsd:element naine="isPinReady" type="tns:PINReady"/> <xsd:element narre="errorCode" type="tns:PlNErrorCode"/> </xsd:sequence> 40 </xsd:complexType> </xsd:schema> </types>   <message naine="GetPinStatus"> </message> <1-- AT+CPIN="xxxx" --> <message narre="EnterPIN"> <part name="PIN" type="tns:PINCode" /> 10 </message> <1--AT+CPIN="xxxxxxxx", "xxxx" --> <message name="EnterPUK"> <part name="PUK" type="tns:PUKCode" /> <part name="PIN" type="tns:PINCode" /> 15 </message <1-- AT+CPIN message response --> <message naine="PINResult"> <part narre="Result" type="tns:PlNStatus" /> </message> 20  <portType name="WisMoCommandPort"> <operation name="doGetPlNStatus"> <input message="tns:GetPinStatus" /> <output message="tns:PINResult" /> 25 </operation> <operation naine="doEnterPlN"> <input message="tns:doEnterPlN " /> <output message="tns:PINResult" /> </operation> 30 <operation naine="doEnterPUK"> <input message="tns:doEnterPUK" /> <output message="tns:PINResult" /> </operation> </portType> 35  <binding narre="WisMoCommandBinding" type="tns:WisMoCommandPort"> <soap:binding style="document" transport="http://schemas.xmisoap.org/soap/http" /> <operation narre="doGetPlNStatus"> 40 <soap:operation soapAction="urn:WisMoCommand" /> <input> <soap:body use="literal"/> </input> <output> <soap:body use="literal" /> </output> </operation> <operation naine="doEnterPlN"> <soap:operation soapAction="urn:WisMoCommand" /> <input> <soap:body use="literai"/> </input> <output> <soap:body use="literal" /> </output> </operation> <operation name="doEnterPUK"> <soap:operation soapAction="urn:WisMoCommand" /> <input> <soap:body use="literal"/> </input> <output> <soap:body use="literal" /> </output> </operation> </binding> <I-- Endpoint as example --> <service naine="WavecomModem" > <port name="WisMoCommandPort" binding="tns:WisMoCommandBinding" > <soap:address location="http://localhost:8080/WavecomModem/WisMoCommand/" </port> </service> </definitions> 2) Description WSDL du service modem PIN en réutilisant la syntaxe commandes AT <?xinl version= "1.0" encoding="UTF-8"?> <1-- WSDL description of the Wavecom GSM/GPRS modem Web API. This API is drafted for example purpose only. --> <l-- Definitions and used namespaces used by the API --> <1-- tns : type narre space xsd : schema name space soap : soap narre space wsdl : wsdl narre space --> <definitions narre="urn:WavecomATCommand" targetNamespace="urn: WavecomATCommand" xmins="http://schemas.xmisoap.org/wsdl/" xmins:tns="urn:WavecomATCommand" xmins:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmins:wsdl="http://schemas.xmisoap.org/wsdl/" > <1-- Types for AT command parameters and received results --> <1-- Defined with schemas --> <types> <xsd:schema targetNamespace="urn:WavecomATCommand"> <xsd:element name="ATCommand" type="xsd:string" <xsd:element narre="ATResponse" type="xsd:string" <xsd:element name="ATUnsolicited" type="xsd:string" /> </xsd:schema> </types> <1-- Messages for AT Requests management API --> <message name="ATCommand"> <part naine="Command" type="tns:ATCommand" /> </message> <1ù Message for AT Response management API --> <message name="ATResponse"> <part name="Result" type="tns:ATResponse" /> </message> < 1ù Message for AT Unsolicited management API --> 30 <message naine="ATUnsolicited"> <part narre="Unsolicited" type="tns:ATUnsolicited" /> </message> <1-- Port AT Command API --> <portType narre="WavecomATCommandPort"> 35 <operation name="doSendCommand"> <input message="tns:ATCommand" /> <output message="tns:ATResponse" /> </operation> < operation name=" getUnsolicited"> 40 <output message="tns:ATUnsolicited" /> </operation> </portType> <1-- Binding with Document/literal SOAP over HTTP --> <binding naine="WavecomATCommandBinding" type="tns: WavecomATCommandPort"> <soap:binding style="document" transport="http://schemas.xmisoap.org/soap/http" /> <operation name="doSendCommand "> <soap:operation soapAction="urn:WavecomATCommand" /> <input> <soap:body use="literal"/> </input> <output> <soap:body use="literal" /> </output> </operation> <operation naine="getUnsolicited "> <soap:operation soapAction="urn:WavecomATCommand" /> <output> <soap:body use="literal" /> </output> </operation> </binding> <1-- Endpoint as example --> <service name="WavecomATModem" > <port name="WavecomATCommandPort" binding="tns:WavecomATCommandBinding" > <soap:address location="http://localhost:8080/WavecomModem/WavecomATCommand/" /> </port> </service> </definitions>

Claims

REVENDICATIONS

1. Procédé de commande d'un module électronique de radiocommunication (21 ; 31 ; 41 ; 52 ; 62) par un premier équipement(22, 23 ; 32, 33 ; 51 ; 63), caractérisé en ce qu'il comprend une étape (1) de découverte par un second équipement de la ou les interface(s) de commande disponible(s) dudit module, ledit second équipement étant confondu avec ou distinct dudit premier équipement.

2. Procédé selon la revendication 1, caractérisé en ce que chaque interface de commande disponible dudit module est définie par : - un jeu de commandes supportées par le module ; - une interface physique du module sur laquelle ledit jeu de commande est supporté - un protocole sur lequel ledit jeu de commande est supporté.

3. Procédé selon l'une quelconque des revendications 1 et 2, caractérisé en ce que ladite étape de découverte comprend les étapes suivantes : ledit second équipement envoie au moins une requête de découverte audit module ; - ledit module envoie audit second équipement au moins une réponse, contenant la ou les interface(s) de commande disponible(s) dudit module.

4. Procédé selon la revendication 3, caractérisé en ce que ladite au moins une requête de découverte appartient au groupe comprenant : - une requête demandant au module d'envoyer au second équipement une liste de commandes supportées par le module ; - une requête demandant au module d'envoyer au second équipement une première commande d'une liste de commandes supportées par le module ; - une requête demandant au module d'envoyer au second équipement une commande suivante, par rapport à une commande courante, d'une liste de commandes supportées par le module ; - une requête demandant au module d'envoyer au second équipement une commande précédente, par rapport à une commande courante, d'une liste de 30 commandes supportées par le module ;- une requête demandant au module d'envoyer au second équipement une liste de paramètres en entrée et/ou de réponses associés à une commande indiquée dans ladite requête ; - une requête demandant au module d'envoyer au second équipement une 5 indication des protocoles et des types d'interface sur lesquels ledit module supporte des commandes.

5. Procédé selon l'une quelconque des revendications 3 et 4, caractérisé en ce que ladite au moins une requête de découverte est une nouvelle commande AT.

6. Procédé selon l'une quelconque des revendications 1 et 2, caractérisé en ce que 10 ladite étape de découverte comprend les étapes suivantes : -ledit second équipement envoie audit module au moins une requête d'obtention d'un fichier de description contenant la ou les interface(s) de commande disponible(s) dudit module ; - ledit module envoie ledit fichier de description audit second équipement. 15

7. Procédé selon la revendication 6, caractérisé en ce que ledit second équipement obtient le fichier de description : - en local, grâce à une connexion entre le second équipement et le module, ledit fichier de description étant stocké par le module ; ou - à distance, grâce à une connexion entre le second équipement et un autre 20 équipement distant, ledit fichier de description étant stocké par ledit autre équipement distant.

8. Procédé selon l'une quelconque des revendications 6 et 7, caractérisé en ce que ledit fichier de description est un fichier WSDL (316, 339) décrivant la ou les interface(s) de commande disponible(s) dudit module sous la forme d'au moins un 25 service Web hébergé par ledit module.

9. Procédé selon la revendication 8, ledit module hébergeant et exécutant un logiciel principal de radiocommunication et un logiciel client embarqué, caractérisé en ce que ledit fichier WSDL décrit au moins un service Web qui est fourni par ledit logiciel client et qui utilise au moins une interface de commande disponible du module.

10. Procédé selon l'une quelconque des revendications 8 et 9, caractérisé en ce que ledit au moins un service Web est décrit, dans ledit fichier WSDL, en réutilisant la syntaxe des commandes AT.

11. Procédé selon l'une quelconque des revendications 8 et 9, caractérisé en ce que ledit au moins un service Web est décrit, dans ledit fichier WSDL, en utilisant une syntaxe distincte de celle des commandes AT.

12. Procédé selon l'une quelconque des revendications 1 à 11, caractérisé en ce que ladite étape de découverte (1) est suivie des étapes suivantes : - sélection (2) d'une interface de commande du module, parmi la ou les interface(s) de commande disponible(s) préalablement découverte(s) ; -pilotage (3) dudit module par ledit premier équipement, en fonction de l'interface de commande sélectionnée. 15. Procédé selon la revendication 12, caractérisé en ce que lesdites étapes de découverte et sélection sont effectuées avec ledit second équipement, lors d'une phase de développement d'une application (331, 321) et/ou une couche logicielle (332, 322) sur laquelle s'appuie ladite application, destiné(es) à être hébergé(es) et exécuté(es) par ledit premier équipement, ladite étape de sélection étant effectuée par un développeur, ledit développement étant fonction de l'interface de commande sélectionnée, et en ce que ladite étape de pilotage est effectuée lors d'une phase ultérieure d'utilisation dudit premier équipement en coopération avec ledit module. 16. Procédé selon la revendication 12, caractérisé en ce que le second équipement est confondu avec le premier équipement, et en ce que lesdites étapes de découverte, sélection et pilotage sont effectuées lors d'une phase d'utilisation dudit premier équipement en coopération avec ledit module, ladite étape de sélection étant effectuée de façon automatique et dynamique par ledit premier équipement, en fonction d'une part d'une politique de sélection prédéterminée et d'autre part de la ou les interface(s) de commande disponible(s) découverte(s). 17. Equipement, du type permettant de coopérer avec un module électronique de radiocommunication, caractérisé en ce qu'il comprend des moyens de découverte de la ou les interface(s) de commande disponible(s) dudit module, de façon à permettre la commande dudit module par ledit équipement ou par un autre équipement.16. Equipement selon la revendication 15, caractérisé en ce que chaque interface de commande disponible dudit module est définie par : - un jeu de commandes supportées par le module ; une interface physique du module sur laquelle ledit jeu de commande est 5 supporté ; - un protocole sur lequel ledit jeu de commande est supporté. 17. Equipement selon l'une quelconque des revendications 15 et 16, caractérisé en ce que lesdits moyens de découverte comprennent : - des moyens d'envoi d'au moins une requête de découverte audit module ; 10 - des moyens de réception d'au moins une réponse envoyée par ledit module et contenant la ou les interface(s) de commande disponible(s) dudit module. 18. Equipement selon la revendication 17, caractérisé en ce que ladite au moins une requête de découverte est une nouvelle commande AT. 19. Equipement selon l'une quelconque des revendications 15 et 16, caractérisé en 15 ce que lesdits moyens de découverte comprennent : - des moyens d'envoi audit module d'au moins une requête d'obtention d'un fichier de description contenant la ou les interface(s) de commande disponible(s) dudit module ; - des moyens de réception dudit fichier de description envoyé par le module. 20 20. Equipement selon la revendication 19, caractérisé en ce que ladite requête d'obtention appartient au groupe comprenant : - une requête d'obtention en local, grâce à une connexion entre l'équipement et le module, ledit fichier de description étant stocké par le module ; - une requête d'obtention à distance, grâce à une connexion, via le module, entre l'équipement et un autre équipement distant, ledit fichier de description étant stocké par ledit autre équipement distant. 21. Equipement selon l'une quelconque des revendications 15 à 20, caractérisé en ce qu'il comprend en outre : - des moyens de sélection d'une interface de commande du module, parmi la ou les interface(s) de commande disponible(s) préalablement découverte(s) ; 25 30- des moyens de pilotage dudit module en fonction de l'interface de commande sélectionnée. 22. Module électronique de radiocommunication, du type pouvant être commandé par un premier équipement, caractérisé en ce qu'il comprend : - des moyens de réception d'au moins une requête de découverte envoyée par un second équipement, confondu avec ou distinct dudit premier équipement ; - des moyens d'envoi d'au moins une réponse audit second équipement, contenant la ou les interface(s) de commande disponible(s) dudit module. 23. Module selon la revendication 22, caractérisé en ce que ladite au moins une requête de découverte est une nouvelle commande AT. 24. Module électronique de radiocommunication, du type pouvant être commandé par un premier équipement, caractérisé en ce qu'il comprend : - des moyens de réception d'au moins une requête d'obtention d'un fichier de description contenant la ou les interface(s) de commande disponible(s) dudit 15 module, envoyée par un second équipement, confondu avec ou distinct dudit premier équipement ; des moyens d'envoi dudit fichier de description audit second équipement. 26. Module selon la revendication 24, caractérisé en ce qu'il héberge au moins un service Web, et en ce que ledit fichier de description est un fichier WSDL décrivant la 20 ou les interface(s) de commande disponible(s) dudit module sous la forme dudit au moins un service Web. 27. Module selon la revendication 25, ledit module hébergeant et exécutant un logiciel principal de radiocommunication et un logiciel client embarqué, caractérisé en ce que ledit fichier WSDL décrit au moins un service Web qui est fourni par ledit 25 logiciel client et qui utilise au moins une interface de commande disponible du module. 28. Signal transmis depuis un équipement vers un module électronique de radiocommunication, caractérisé en ce qu'il comprend au moins une requête de découverte de la ou les interface(s) de commande disponible(s) dudit module, de façon qu'en réponse à ladite requête de découverte, le module envoie audit 30 équipement au moins une réponse contenant la ou les interface(s) de commandedisponible(s) dudit module, permettant audit équipement ou à un autre équipement de commander ledit module. 28. Signal selon la revendication 27, caractérisé en ce que ladite au moins une requête de découverte appartient au groupe comprenant : - une requête demandant au module d'envoyer à l'équipement une liste de commandes supportées par le module ; - une requête demandant au module d'envoyer à l'équipement une première commande d'une liste de commandes supportées par le module ; - une requête demandant au module d'envoyer à l'équipement une commande suivante, par rapport à une commande courante, d'une liste de commandes supportées par le module ; - une requête demandant au module d'envoyer à l'équipement une commande précédente, par rapport à une commande courante, d'une liste de commandes supportées par le module ; -une requête demandant au module d'envoyer à l'équipement une liste de paramètres en entrée et/ou de réponses associés à une commande indiquée dans ladite requête ; - une requête demandant au module d'envoyer à l'équipement une indication des protocoles et des types d'interface sur lesquels ledit module supporte des commandes. 29. Signal selon l'une quelconque des revendications 27 et 28, caractérisé en ce que ladite au moins une requête de découverte est une nouvelle commande AT. 30. Support d'enregistrement contenant un fichier de description associé à un module électronique de radiocommunication, ledit module étant du type pouvant être commandé par un premier équipement, ledit fichier de description contenant la ou les interface(s) de commande disponible(s) dudit module, ledit fichier de description étant destiné à être stocké en local sur le module ou à distance sur un autre équipement, ledit fichier étant destiné à être envoyé à un second équipement, confondu avec ou distinct dudit premier équipement, en réponse à une requête dudit second équipement, de façon à permettre audit premier équipement de commander le module.31. Support d'enregistrement selon la revendication 30, caractérisé en ce que ledit fichier de description est un fichier WSDL décrivant la ou les interface(s) de commande disponible(s) dudit module sous la forme d'au moins un service Web hébergé par ledit module. 32. Support d'enregistrement selon la revendication 31, ledit module hébergeant et exécutant un logiciel principal de radiocommunication et un logiciel client embarqué, caractérisé en ce que ledit fichier WSDL décrit au moins un service Web qui est fourni par ledit logiciel client et qui utilise au moins une interface de commande disponible du module. 33. Support d'enregistrement selon l'une quelconque des revendications 31 et 32, caractérisé en ce que ledit au moins un service Web est décrit, dans ledit fichier WSDL, en réutilisant la syntaxe des commandes AT. 34. Support d'enregistrement selon l'une quelconque des revendications 31 et 32, caractérisé en ce que ledit au moins un service Web est décrit, dans ledit fichier WSDL, en utilisant une syntaxe distincte de celle des commandes AT.