WO2007141215A1 - Procede de commande d ' un module electronique de radiocommunication - Google Patents

Procede de commande d ' un module electronique de radiocommunication Download PDF

Info

Publication number
WO2007141215A1
WO2007141215A1 PCT/EP2007/055417 EP2007055417W WO2007141215A1 WO 2007141215 A1 WO2007141215 A1 WO 2007141215A1 EP 2007055417 W EP2007055417 W EP 2007055417W WO 2007141215 A1 WO2007141215 A1 WO 2007141215A1
Authority
WO
WIPO (PCT)
Prior art keywords
module
equipment
control interface
interface
file
Prior art date
Application number
PCT/EP2007/055417
Other languages
English (en)
Inventor
Didier Lahay
Jacques Montes
Original Assignee
Wavecom
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Wavecom filed Critical Wavecom
Priority to US12/303,698 priority Critical patent/US20100064062A1/en
Priority to EP07729811A priority patent/EP2025131A1/fr
Publication of WO2007141215A1 publication Critical patent/WO2007141215A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]

Definitions

  • the field of the invention is that of radiocommunications, and more precisely of digital radiocommunication terminals (also called radiocommunication devices), whether radiotelephone or devices or means of all types. capable of exchanging signals using a radio communication system, implanted for example in machines or vehicles. More specifically, the invention relates to a control technique of a radiocommunication terminal by equipment connected thereto.
  • the equipment is for example a microcomputer running a client application.
  • the equipment is connected to the radiocommunication terminal either locally (for example via a serial or USB link) or remotely (for example through a wired or wireless communication network).
  • Radio communication devices typically include a set of electronic components implanted on a printed circuit board. These different components are intended to provide the various necessary functions, from the reception of an RF signal to the generation of an audible signal (in the case of a radio-telephone), and vice versa. Some of these functions are analog, and others digital.
  • Such a module is in the form of a single housing, preferably shielded, that the device manufacturers can implement directly, without having to take into account a multitude of components.
  • This module (sometimes called “macro component”) is indeed formed of a grouping of several components on a substrate, so as to be implanted in the form of a single element. It includes the components (including a processor and a memory) and the essential software necessary for the operation of a radiocommunication device (also called a radio terminal or a wireless terminal) using radio frequencies. So there are no more complex stages of design design, and validation of it. All you have to do is reserve the necessary space for the module.
  • Such a module makes it possible to easily integrate, quickly and optimally all the components in wireless terminals (mobile phones, modems, or any other device operating a wireless standard).
  • this module regrouping all the essential functions and having been conceived as a whole, the problems of calibration and tests no longer arise in the same way, or are at least greatly simplified.
  • the modules distributed by the holder of this patent application are fully tested both hardware ("hardware”) and software ("software”) in most networks on which they can be used later.
  • the module advantageously covers IP aspects (or IPRs, for all Intellectual Property Rights) (all the functions have been grouped, it is the manufacturer of the module that manages the corresponding IPR aspects) and technical assistance.
  • the aforementioned module is for example a Wismo type module (registered trademark) distributed by the applicant of the present patent application.
  • a first drawback lies in the difficulties encountered by the application developers intended to be executed by the equipment controlling the modules.
  • the developer of an application for a device for controlling a given radiocommunication module must know the control interface (s) available (s) on this module. For this, it must consult the documents specific to this given module, which describe the control interfaces.
  • the radiocommunication module is controlled by AT commands
  • the developer must imperatively take cognizance, without automation possible, of the documents defining textually the AT commands supported by this module, as well as the physical interfaces (for example RS232,
  • USB for a wired interface
  • Zigbee for a wired interface
  • Wifi for a wireless interface
  • protocols eg Raw data, http / TCP / IP, (7) on which these commands are supported.
  • Another disadvantage of the current technique is that an application already developed, and allowing a device to control a module with a given control interface of this module, must be at least partially rewritten (and therefore can not be reused as it is ) to allow one device to drive the same module with another control interface, or another module.
  • the invention in at least one embodiment, is intended in particular to overcome these various disadvantages of the state of the art.
  • one of the objectives of the present invention in at least one embodiment, is to provide a technique for controlling a radio communication module by a device, making it possible to facilitate the development of the application executed by this device. equipment.
  • the invention also aims, in at least one embodiment, to provide such a technique for controlling the module by the equipment, through any type of interface, locally or remotely.
  • Another object of the invention in at least one embodiment, is to provide such a technique, which is simple to implement and inexpensive. Yet another object of the invention, in at least one embodiment, is to provide such a technique allowing the equipment to adapt dynamic its operation according to the module to which it is actually connected (and available control interfaces of this module). 4. PRESENTATION OF THE INVENTION
  • a method for controlling an electronic radiocommunication module by a first device comprising a step of discovery by a second device of the available control interface (s) ( s) of said module, said second equipment being confused with or distinct from said first equipment.
  • Said discovery step comprises a step of obtaining by the second equipment a description file containing the available control interface (s) of said module, said description file being a WSDL file describing the interface or interfaces (s) available control (s) of said module in the form of at least one web service hosted by said module.
  • the general principle of the invention therefore consists in automatically exporting to the equipment the information relating to the control interface or interfaces of the module.
  • the module behaves, in the sense of web services technology, as an end point ("end point" in English) accessible by any Web client (that is to say, any equipment wishing to drive it). Where the module's control interfaces are described in a service agreement embodied in a WSDL file.
  • each available control interface of said module is defined by: a set of commands supported by the module; a physical interface of the module on which said control set is supported; a protocol on which said control set is supported.
  • said second equipment obtains the description file: locally, thanks to a connection between the second equipment and the module, said description file being stored by the module; or remotely, through a connection between the second equipment and another remote device, said description file being stored by said other remote device.
  • said module hosts and executes a main radiocommunication software and an embedded client software.
  • said WSDL file describes at least one web service that is provided by said client software and that uses at least one available control interface of the module.
  • said at least one Web service is described in said WSDL file by reusing the syntax of the AT commands.
  • compatibility with current AT commands is preserved by encapsulating them in generic web services.
  • the equipment controls the module by sending commands that, because they respect the syntax of the AT commands, can be processed by the part of the main software module that processes the AT commands.
  • the module it is not necessary for the module to further include a software layer specific to Web services.
  • said client application is embedded by the module and this client application exposes new AT commands, they can be exposed in the same way as those supported natively on the module.
  • said at least one Web service is described in said WSDL file, using a syntax distinct from that of the AT commands.
  • Module I / F a software layer specific to Web Services
  • Web Services API a software layer specific to Web Services
  • said discovery step is followed by the following steps: selection of a control interface of the module from among the available control interface (s) previously discovered; control of said module by said first equipment, as a function of the selected control interface.
  • said discovery and selection steps are performed with said second equipment, during an application development phase and / or a software layer (Modem Driver) on which supports said application, intended (s) to be hosted and executed by said first equipment, said selection step being performed by a developer, said development being a function of the selected control interface.
  • said driving step is performed during a subsequent phase of use of said first equipment in cooperation with said module.
  • the second equipment is confused with the first equipment.
  • said steps of discovery, selection and control are performed during a phase of use of said first equipment in cooperation with said module, said selection step being performed automatically and dynamically by said first equipment, depending on part of a predetermined selection policy and secondly of the available control interface (s).
  • the equipment can dynamically adapt its operation according to the module to which it is actually connected (and the available control interfaces of this module).
  • an application can plan to manage from the design of the modules from several suppliers, each with specificities.
  • the application adapts if the case was planned from the design.
  • a remote server application may be provided to have compatibility with as many different modules as possible and so decide, after the discovery step, interfaces to use according to those available on the module.
  • the invention in another embodiment, relates to equipment of the type that makes it possible to cooperate with an electronic radiocommunication module.
  • This equipment includes means for discovering the control interface (s) available (s) of said module, so as to allow the control of said module by said equipment or other equipment.
  • Said discovery means comprise means for obtaining by said equipment a description file containing the available control interface (s) of said module, said description file being a WSDL file describing the interface or interfaces ( s) available control (s) of said module in the form of at least one web service hosted by said module.
  • the equipment comprises means for implementing the control method as described previously (in any one of its various embodiments).
  • the invention relates to an electronic radiocommunication module, of the type that can be controlled by a first device, said module generating at least one Web service, a WSDL file describing the control interface (s) available. (s) of said module in the form of said at least one web service.
  • the invention relates to a recording medium containing a description file associated with an electronic radiocommunication module, said module being of the type that can be controlled by a first piece of equipment, said description file being a WSDL file.
  • FIG. 1 shows a flowchart of a particular embodiment of the method according to the invention
  • FIG. 2 shows a functional block diagram of a radiocommunication module and two pieces of equipment (one local and the other remote), illustrating first and second embodiments of the method according to the invention
  • FIG. 3 shows a functional block diagram of a radiocommunication module and two pieces of equipment (one local and the other remote), illustrating third and fourth embodiments of the method according to the invention
  • FIG. 1 shows a flowchart of a particular embodiment of the method according to the invention
  • FIG. 2 shows a functional block diagram of a radiocommunication module and two pieces of equipment (one local and the other remote), illustrating first and second embodiments of the method according to the invention
  • FIG. 3 shows a functional block diagram of a radiocommunication module and two pieces of equipment (one local and the other remote), illustrating third and fourth embodiments of the method according to the invention
  • FIG. 1 shows a flowchart of a particular embodiment of the method according to the invention
  • FIG. 2 shows a functional block diagram
  • FIG. 4 shows a functional block diagram of a radiocommunication module and two (local) equipments, illustrating a fifth embodiment of the method according to the invention
  • FIG. 5 illustrates a first example of application of the method of the invention, in the case of a water meter driving a radiocommunication module in order to communicate with a collection server
  • FIG. 6 illustrates a second example of application of the method of the invention, in the case of a collection server driving a radiocommunication module carrying a client application remote from a water meter to the module.
  • the invention therefore relates to a method for controlling an electronic radiocommunication module by a device.
  • the method comprises: a step 1 of discovery by the equipment of the available control interface (s) of the module; a step 2 of selecting a control interface of the module from among the available control interface (s) previously discovered; a step 3 of control of the module by the equipment, according to the selected control interface.
  • FIG. 5 illustrates a first example of application of the method of the invention: a water meter 51 controls a radiocommunication module 52 in order to communicate, via a radio communication network 54 (GSM network for example), with a server collection 53.
  • GSM network for example
  • a first client application 511 intended to be executed by the water meter 51
  • the latter or more often in practice another equipment (for example a PC) specific to the development, communicates with the module 52 in order to know the available control interfaces of the module (step 1 of discovery).
  • another equipment for example a PC
  • control step 2 the developer selects one of the previously discovered available control interfaces (selection step 2), and takes into account the interface selected in the development that it performs.
  • selection step 3 the control of the module takes place for example as follows (control step 3).
  • the first client application 511 executed by the water meter 51 obtains from a sensor 512 information relating to the quantity of water consumed.
  • the module 52 controls the module 52, by sending commands to a main radiocommunication application 521 executed by the module, in order to transmit this information to a second client application 531 executed by the collection server 53. This transmission is carried out for example under the form of sending SMS type message by the module 52.
  • the discovery and selection steps are performed during the use phase. More precisely, the selection step is performed automatically and dynamically by the water meter 51, as a function, on the one hand, of a predetermined selection policy and, on the other hand, of the interface (s) of available order (s) available.
  • FIG. 6 illustrates a second example of application of the method of the invention: a pilot collection server 63, via a radio communication network 64 (GSM network for example), a radiocommunication module 62 carrying a first client application 622 deported since a water meter 61 to the module.
  • GSM radio communication network
  • FIG. 6 illustrates a second example of application of the method of the invention: a pilot collection server 63, via a radio communication network 64 (GSM network for example), a radiocommunication module 62 carrying a first client application 622 deported since a water meter 61 to the module.
  • the radiocommunication module 62 executes on the one hand a main radiocommunication application 621 and on the other hand the first client application 622 above.
  • the latter (or other equipment, for example a PC, specific to the development) communicates with the module 62 in order to know the control interfaces available from the module (step 1 of discovery).
  • the available control interfaces also make it possible to expose the AT commands by the embedded application.
  • selection step 2 the developer selects one of the previously discovered available control interfaces (selection step 2), and takes into account the interface selected in the development that it performs.
  • control step 3 the control of the module takes place for example as follows (control step 3).
  • the second client application 631 executed by the collection server 63 drives the module 62, so that the first client application 622 obtains a sensor 612 (included in the water meter 61) information relating to the amount of water consumed and returns this information to the second client application 631.
  • the sending of this response takes place for example in the form of an SMS type message sending by the module 62
  • the discovery and selection steps are performed during the use phase. More precisely, the selection step is performed automatically and dynamically by the collection server 63, as a function, on the one hand, of a predetermined selection policy and, on the other hand, of the control interface (s). available discovery (s).
  • the radiocommunication module 21 comprises: a main radiocommunication application 211, itself comprising a part 212 dedicated to the processing of the AT commands.
  • the main radiocommunication application 211 is also called “modem software” (or “Modem software” in Figure 2), as the radiocommunication module acts as a wireless modem).
  • modem software or “Modem software” in Figure 2
  • the storage (memory) and execution (CPU) resources of this main application, within the module 21, are not represented in FIG. 2; a "GPRS” interface 214; an "HTTP-TCP-IP” layer 213 (above the "GPRS” interface 214); a USB interface 215; an "RS232" interface 216; and an "Ethernet” interface 217.
  • the local equipment 22 comprises a local client application 221, a "USB” interface 222, an "RS232" interface 223 and an “Ethernet” interface 224. It is connected to the module 21 via a local link 24 ( USB link, RS232 or Erthernet in this example), over which the AT commands pass.
  • the remote equipment 23 comprises a remote client application 231 and an "HTTP-TCP-IP" layer 232, over a "GPRS" interface 233. It is connected to the module 21 via a remote link 25 (GPRS / IP link in this example), over which the AT commands pass (the latter are encapsulated in IP packets).
  • the storage (memory) and execution (CPU) resources of the local client applications 221 and remote 231, within the local equipment 22 and the remote equipment 23 respectively, are not represented. in Figure 2.
  • the equipment 22 or 23 uses one or more new AT commands (which form part of the present invention) allowing the equipment to retrieve the AT commands. supported by the module 21.
  • the new "AT + HELP ATCmdSet” command is replaced / supplemented by a set of three new AT commands, called for example "AT + HELP ATCmdFirst", “AT + HELP ATCmdNext” and "AT + HELP”
  • ATCmdPrevious allow the equipment to request the module to send one by one the AT commands that it supports.
  • the device sends the module the new "AT + HELP ATCmdFirst” command
  • the module sends in response a first command of the list of commands that it supports (the module returns for example the command "AT + CPIN? "); - if the equipment sends to the module the new command "AT + HELP
  • AT + HELP Command Another new command, called for example "AT + HELP Command", is such that if the equipment sends it to the module, the latter sends in response a list of input parameters (IN) and / or responses (OUT) associated with the command (whose name is "Command") indicated as an attribute of the new command "AT + HELP Command".
  • ATCmdltf is such that if the equipment sends it to the module, the latter sends in response an indication of the protocols and types of interface on which the module supports AT commands.
  • the AT commands supported by the module are by default Raw Data protocol, but we can consider encapsulating them in IP frames in order to have a module seen as a generic IP device.
  • the module response may be one of the following:
  • the discovery and control steps are performed through the use of AT commands. As already discussed above, these two steps are performed either by the same equipment, if they are both executed during a phase of use of this equipment, or each by a separate equipment, if they are executed in one phase. development and a phase of use respectively.
  • third and fourth embodiments of the method according to the invention are now presented, based on the use of web services technology for exchanges between the module 31 and a local device 32 (third device). embodiment), or between the module 31 and a remote equipment 33 (fourth embodiment).
  • the radiocommunication module 31 comprises: a main radiocommunication application 311, also called “modem software” (or “modem software” in FIG. 2).
  • a main radiocommunication application 311 also called “modem software” (or “modem software” in FIG. 2).
  • modem software or “modem software” in FIG. 2
  • the storage (memory) and execution (CPU) resources of this main application, within the module 31, are not represented in FIG. 3; a USB interface 315; an interface "RS232"316; an Ethernet interface 317; a "GPRS” interface 318; an "HTTP-TCP-IP” layer 314, above the "USB” interfaces,
  • the WSDL file 339 is stored on an external server, accessible via an Internet address (referenced 340 in FIG. 3).
  • Local equipment 33 includes: a local client application 331; - a "USB” interface 335; an interface "RS232" 336; an Ethernet interface 337; an "HTTP-TCP-IP” layer 334, above the "USB" interfaces,
  • the local equipment 33 is connected to the module 31 via a local link 35 (USB link, RS232 or Erthernet in this example), over which the requests and responses of the Web services type (exchanges according to the SOAP protocol) pass.
  • Remote equipment 32 includes: a remote client application 321; a "GPRS" interface 325; an "HTTP-TCP-IP” layer 324, above the "GPRS”interface; a "SOAP” layer 323, above the "HTTP-TCP-IP”layer; a "Modem Driver” layer 322, above the "SOAP” layer.
  • the "Modem Driver" layer 322, 332 of each of the devices 32, 33 is generated by a WSDL analyzer 338, from the WSDL file.
  • the remote device 32 is connected to the module 31 via a remote link 34 (GPRS / IP link in this example), on which the requests and responses of the Web services type (SOAP-based exchanges) are transited.
  • GPRS / IP link in this example
  • the equipment 32 or 33 retrieves the WSDL file 319, 339 locally (in the case of storage on the module) or remotely (in the case of network storage).
  • the "SOAP" layers 313, 323 and 333 implement the SOAP protocol which is a message transmission protocol. It defines a set of rules for structuring messages that can be used in simple unidirectional transmissions, but it is particularly useful for executing RPC (Remote Procedure CaIl) call-answer dialogs. This is the protocol for Web services messages.
  • the layer “Modem I / F 312 is a software layer implementing the service contract supported by the modem software (modem software), materialized by the WSDL file. In one embodiment, these are the exposed AT commands in web services, which allows reuse of existing commands. In another embodiment, it is an implementation of new interfaces supported by the modem software.
  • the "Modem Driver" layers 322, 332 are software interface layers created (for example automatically) from the WSDL file. They offer high-level Web services discovered and encapsulates them in the SOAP protocol.
  • the set of layers "SOAP” 323 and “Modem Driver” 322 (or “SOAP” 333 and “Modem Driver” 332) is the corollary of the assembly formed by the layers “SOAP” 313 and “Modem I / F 312: the first sends requests and the other deals with them and returns responses which are in turn processed by the first.
  • the discovery and piloting steps are performed using Web services technology. As already discussed above, these two steps are performed either by the same equipment, if they are both executed during a phase of use of this equipment, or each by a separate equipment, if they are executed in one phase. development and a phase of use respectively.
  • the discovery step is performed using Web services technology (operating in "Web service” mode) and makes it possible to discover AT interfaces. then the equipment switches to "AT commands” mode on the link used to detect the commands (that is to say, to discover the AT interfaces).
  • the equipment performs the step of controlling the module with AT commands.
  • the available command interfaces of the module are described in the WSDL file using the syntax of the AT commands.
  • FIG. 4 shows a fifth embodiment of the method according to the invention, in which one and the same radiocommunication module 41 can be controlled by two separate devices 22, 33.
  • one and the same radiocommunication module 41 can be controlled by two separate devices 22, 33.
  • it is compatible with the applications customers piloting it with AT commands, and with client applications driving it with Web services technology.
  • these two devices 22, 33 are local and identical to equipment bearing the same references in Figures 2 and 3 respectively. They are not described again. In a variant, one or both of the equipment may be remote.
  • One 22 is connected to the module 41 via a first local link 44, over which AT commands.
  • the other 33 is connected to the module 41 via a second local link 45, on which transit requests and responses of the Web services type (exchanges according to the SOAP protocol).
  • the module 41 comprises a combination of the means (not described again) included in the modules 21 ( Figure 2) and 31 ( Figure 3) already described above.
  • a main radiocommunication application 411 itself comprising a part 212 dedicated to the processing of AT commands; a "USB” interface 315; an interface "RS232”316; an Ethernet interface 317; a "GPRS” interface 318; an "HTTP-TCP-IP” layer 314, above the "USB”, “RS232", “Ethernet” and “GPRS”interfaces; a "SOAP” layer 313, above the "HTTP-TCP-IP”layer; a layer “Modem I / F” (interface software layer) 312, above the "SOAP”layer; a WSDL 319 file.
  • the diverted use, according to the invention, of the Web services technology for the control of a radiocommunication module by a device offers the following advantages: it makes it possible to automatically discover the available interfaces (commands and responses) of a module radiocommunication; it allows to control a module through any type of interface: local
  • the description file can be retrieved locally on the module or on a specific website; discovery techniques (WS-Discovery), Metadata (WS-
  • Radiocommunication module can be used; it unifies access to resources and therefore the interfaces offered; it allows to relocate the services offered; it makes it possible to offer a programmatic interface more widely used and tooled than that of standard AT commands; the radiocommunication module behaves as an end point accessible by any web client.
  • the module becomes an IP module; it facilitates the implementation of remote maintenance and development operations; it allows an application to dynamically discover the interfaces offered by a radiocommunication module: * allows greater flexibility in the development of applications based on a fleet of equipment (machines) that use different access technologies: GSM / GPRS, Wifi, Bluetooth, Zigbee, UWB, ...;
  • an application can detect! the methods, implemented by different manufacturers for the same service; for example, the AT Simtoolkit commands are defined by each manufacturer, a discovery of the interfaces of the SATK family (Simtoolkit service), would allow applications to adapt to the module used;
  • * new modules can be added and dynamically identified by the application; who can then check the compatibility with the module thus detected; it provides a more natural module programming interface for application developers than AT commands, while remaining independent of the hardware architecture (HW) and operating system (OS) chosen for the application and the module: * bi-processor architecture, for example for a PDA or Smartphone, under Linux (registered trademark) or Windows (registered trademark), requires a specific driver for each module used.
  • the use of Web services technology greatly simplifies the writing of these drivers, the specific driver becoming trivial (limited to a hardware interface);
  • a particular API would be declared to validate access to higher levels; - Coupled with the security standards used in Web services technologies, access to the interfaces and therefore the modem commands can be secured: Web services over Https (SSL or TLS).
  • APPENDIX 1 Mapping AT & WSDL Commands
  • AT Commands Describes a set of commands and responses for controlling a modem

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer And Data Communications (AREA)

Abstract

L'invention concerne un procédé de commande d'un module électronique de radiocommunicat ion (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. Ladite étape de découverte comprend une étape d'obtention par le second équipement d'un fichier de description contenant la ou les interface (s) de commande disponible (s) dudit module. 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 service Web hébergé par ledit module. Le service Web peut être décrit, dans le fichier WSDL, en réutilisant la syntaxe des commandes AT.

Description

PROCEDE DE COMMANDE D ' UN MODULE ELECTRONIQUE DE RADIOCOMMUNICATION
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 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. 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 œuvre et peu coûteuse. 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 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. Ladite étape de découverte comprend une étape d'obtention par le second équipement d'un fichier de description contenant la ou les interface(s) de commande disponible(s) dudit module, ledit fichier de description étant 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.
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.
Le module se comporte, 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). Là ou les interfaces de commande du module sont décrites dans un contrat de service matérialisé dans un fichier WSDL.
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é.
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 équipement distant, ledit fichier de description étant stocké par ledit autre équipement distant.
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 supporté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. Lesdits moyens de découverte comprennent des moyens d'obtention par ledit équipement d'un fichier de description contenant la ou les interface(s) de commande disponible(s) dudit module, ledit fichier de description étant 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.
Plus généralement, l'équipement selon l'invention comprend des moyens de mise en œuvre 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, ledit module hénergeant au moins un service Web, un fichier WSDL décrivant la ou les interface(s) de commande disponible(s) dudit module sous la forme dudit au moins un service Web. 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 premier équipement, ledit fichier de description étant 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, ledit fichier de description étant destiné à être stocké en local sur le module ou à distance sur un autre équipement, ledit fichier étant destiné à être obtenu par un second équipement, confondu avec ou distinct dudit premier équipement, de façon à permettre audit premier équipement de commander le module. 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 de la 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 œuvre 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 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 READYZSIM PINZSIM PUKZERRORZCME 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=PUK5PIN, OUT= IN READY/ERROR 16/ERROR 17 ... Encore une autre nouvelle commande, appelée par exemple « AT+HELP
ATCmdltf », 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 ATCmdltf », la réponse du module peut être l'une des réponses suivantes :
+ATCMDITF RS232,RaW (Raw Data sur le lien RS232) ; - +ATCMDITF USB5RaW (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 »,
« 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 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 » ; - 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 338, à partir du fichier WSDL. 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 œuvre 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 Procédure CaIl). 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 tour 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 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 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 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
(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 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 ; 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 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 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
Figure imgf000024_0001
ANNEXE 2 :
Exemple de portage en Web services d'une simple commande AT pour saisir le code PIN du modem.
• Commande : o AT+CPDSNPIN code o Ou AT+CPESNPUK 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 " ?>
<!-- WSDL description of the Wavecom GSM/GPRS modem Web API. This API îs drafted for example purpose only. --> <!-- Définitions and used namespaces used by the API --> <!-- tns : type name space xsd : schéma name space soap : soap name space wsdl : wsdl name space --> <definitions name="urn: WisMoCommand" targetNamespace="urn: WisMoCommand" xmlns="http: //schémas .xmlsoap. org/wsdl/" xmlns : tns="urn : WisMoCommand" xmlns:xsd="http: //www. w3. org/2001/XMLSchema" xmlns : soap="http: //schémas .xmlsoap. org/wsdl/soap/" xmlns :wsdl="http: //schémas .xmlsoap. org/wsdl/" > <! — Types for AT command parameters and received results —> <! — Defined with schémas —> <types> <xsd: schéma targetNamespace="urn: WisMoCommand">
<xsd:element name="PINCode" type="xsd: stπng" /> <xsd:element name="PUKCode" type="xsd: stπng" /> <xsd:element name="PINReady" type="xsd:boolean" /> <xsd:element name="PINErrorCode" type="xsd: stπng" /> <xsd:complexType name="PINStatus">
<xsd : sequence>
<xsd: élément name="isPinReady" type="tns : PINReady"/> <xsd: élément name="errorCode" type="tns : PINErrorCode"/> </xsd: sequence> </xsd:complexType> </xsd:schema> </types>
<!-- Messages for PIN management API --> <!-- AT+CPIN? -->
<message name="GetPmStatus "> </message>
<!-- AT+CPIN="xxxx" --> <message name="EnterPIN"> <part name="PIN" type="tns : PINCode" /> </message>
<!-- AT+CPIN="xxxxxxxx", "xxxx" --> <message name="EnterPUK">
<part name="PUK" type="tns : PUKCode" /> <part name="PIN" type="tns : PINCode" /> </message
<!-- AT+CPIN message response --> <message name="PINResult">
<part name="Result" type="tns : PINStatus" /> </message>
<!-- Port AT Command API --> <portType name="WisMoCommandPort">
<operation name="doGetPINStatus">
<input message="tns : GetPmStatus " /> <output message="tns : PINResult " />
< /opéra tion> <operation name="doEnterPIN">
<input message="tns : doEnterPIN " /> <output message="tns : PINResult" /> </opération>
<operation name="doEnterPUK">
<input message="tns : doEnterPUK" /> <output message="tns : PINResult" /> </opération> </portType> <!-- Binding with Document/literal SOAP over HTTP --> <binding name="WisMoCommandBinding" type="tns : WisMoCommandPort"> <soap:binding style="document" transport="http : //schémas . xmlsoap . org/soap/http" /> <operation name="doGetPINStatus">
<soap: opération soapAction="urn:WisMoCommand" /> <input>
<soap:body use="literal"/> </input> <output>
<soap:body use="literal" /> </output> </opération>
<operation name="doEnterPIN"> <soap: opération soapAction="urn:WisMoCommand" />
<input>
<soap:body use="literal"/> </input> <output> <soap:body use="literal" />
</output> </opération> <operation name="doEnterPUK">
<soap: opération soapAction="urn:WisMoCommand" /> <input>
<soap:body use="literal"/> </input> <output>
<soap:body use="literal" /> </output>
</opération> </binding>
<! — Endpoint as example —> <service name="WavecomModem" > <port name="WisMoCommandPort" bindmg="tns : WisMoCommandBindmg" > soap : address location="http: //localhost : 8080/WavecomModem/WisMoCommand/" /> </port> </service> </définitions>
2) Description WSDL du service modem PIN en réutilisant la syntaxe commandes AT < ?xml version= " 1 . 0 " encoding="UTF- 8 " ?> <!-- WSDL description of the Wavecom GSM/GPRS modem Web API. This API îs drafted for example purpose only. —>
<! — Définitions and used namespaces used by the API —> <!-- tns : type name space xsd : schéma name space soap : soap name space wsdl : wsdl name space —> <definitions name="urn: WavecomATCommand" targetNamespace="urn: WavecomATCommand" xmlns="http: //schémas .xmlsoap. org/wsdl/" xmlns : tns="urn : WavecomATCommand" xmlns:xsd="http: //www. w3. org/2001/XMLSchema" xmlns : soap="http: //schémas .xmlsoap. org/wsdl/soap/" xmlns :wsdl="http: //schémas .xmlsoap. org/wsdl/" > <! — Types for AT command parameters and received results —> <! — Defined with schémas —> <types>
<xsd: schéma targetNamespace="urn: WavecomATCommand">
<xsd: élément name="ATCommand" type="xsd: stπng" />
<xsd:element name="ATResponse" type="xsd: stπng" /> <xsd:element name="ATUnsolicited" type="xsd: stπng" />
</xsd:schema> </types>
<!-- Messages for AT Requests management API --> <message name="ATCommand"> <part name="Command" type="tns :ATCommand" /> </message>
<!— Message for AT Response management API --> <message name="ATResponse">
<part name="Result" type="tns :ATResponse" /> </message>
<!— Message for AT Unsolicited management API --> <message name="ATUnsolicited">
<part name="Unsolicited" type="tns :ATUnsolicited" /> </message> <!-- Port AT Command API --> <portType name="WavecomATCommandPort"> <operation name="doSendCommand">
<input message="tns :ATCommand" /> <output message="tns :ATResponse" /> </opération>
<operation name="getUnsolicited">
<output message="tns :ATUnsolicited" /> </opération> </portType> <!-- Binding with Document/literal SOAP over HTTP -->
<binding name="WavecomATCommandBinding" type="tns: WavecomATCommandPort"> <soap:binding style="document" transport="http : //schémas . xmlsoap . org/soap/http" /> <operation name="doSendCommand "> <soap: opération soapAction="urn:WavecomATCommand" />
<input>
<soap:body use="literal"/> </input> <output> <soap:body use="literal" />
</output> </opération> <operation name="getUnsolicited ">
<soap: opération soapAction="urn:WavecomATCommand" /> <output>
<soap:body use="literal" /> </output> </opération> </binding> <! — Endpoint as example —>
<service name="WavecomATModem" >
<port name="WavecomATCommandPort" bindmg="tns : WavecomATCommandBinding" > soap : address location="http : / /localhost : 8080 /WavecomModem/WavecomATCommand/ " /> </port>
</service> </defimtions>

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, en ce que ladite étape de découverte comprend une étape d'obtention par le second équipement d'un fichier de description contenant la ou les interface(s) de commande disponible(s) dudit module, et 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 service Web hébergé par ledit module.
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 des revendications 1 et 2, 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 équipement distant, ledit fichier de description étant stocké par ledit autre équipement distant.
4. Procédé selon l'une quelconque des revendications 1 à 3, 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.
5. Procédé selon l'une quelconque des revendications 1 à 4, 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.
6. Procédé selon l'une quelconque des revendications 1 à 4, 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.
7. Procédé selon l'une quelconque des revendications 1 à 6, 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.
8. Procédé selon la revendication 7, 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.
9. Procédé selon la revendication 7, 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).
10. 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, en ce que lesdits moyens de découverte comprennent des moyens d'obtention par ledit équipement d'un fichier de description contenant la ou les interface(s) de commande disponible(s) dudit module, et 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 service Web hébergé par ledit module.
11. Equipement selon la revendication 10, 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é.
12. Equipement selon l'une quelconque des revendications 10 et 11, 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) ; des moyens de pilotage dudit module en fonction de l'interface de commande sélectionnée.
13. Module électronique de radiocommunication, du type pouvant être commandé par un premier équipement, caractérisé en ce qu'il héberge au moins un service Web, un fichier WSDL décrivant la ou les interface(s) de commande disponible(s) dudit module sous la forme dudit au moins un service Web.
14. Module selon la revendication 13, 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.
15. 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 étant 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, ledit fichier de description étant destiné à être stocké en local sur le module ou à distance sur un autre équipement, ledit fichier étant destiné à être obtenu par un second équipement, confondu avec ou distinct dudit premier équipement, de façon à permettre audit premier équipement de commander le module.
16. Support d'enregistrement selon la revendication 15, 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.
17. Support d'enregistrement selon l'une quelconque des revendications 15 et 16, 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.
18. Support d'enregistrement selon l'une quelconque des revendications 15 et 16, 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.
PCT/EP2007/055417 2006-06-07 2007-06-01 Procede de commande d ' un module electronique de radiocommunication WO2007141215A1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
US12/303,698 US20100064062A1 (en) 2006-06-07 2007-06-01 Method for the control of an electronic radio communication module
EP07729811A EP2025131A1 (fr) 2006-06-07 2007-06-01 Procede de commande d ' un module electronique de radiocommunication

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0605065 2006-06-07
FR0605065A FR2902271B1 (fr) 2006-06-07 2006-06-07 Procede de commande d'un module electronique de radiocommunication par un equipement, equipement, module, signal et fichier de description correspondants.

Publications (1)

Publication Number Publication Date
WO2007141215A1 true WO2007141215A1 (fr) 2007-12-13

Family

ID=37735173

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2007/055417 WO2007141215A1 (fr) 2006-06-07 2007-06-01 Procede de commande d ' un module electronique de radiocommunication

Country Status (4)

Country Link
US (1) US20100064062A1 (fr)
EP (1) EP2025131A1 (fr)
FR (1) FR2902271B1 (fr)
WO (1) WO2007141215A1 (fr)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10684899B2 (en) * 2013-03-13 2020-06-16 Northrop Grumman Systems Corporation Mobile applications architecture
CN107040528A (zh) * 2017-03-31 2017-08-11 合肥民众亿兴软件开发有限公司 一种通信网络系统

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030093468A1 (en) * 2001-10-19 2003-05-15 William Doyle Gordon Method of providing XML web services on an embedded device
WO2005008386A2 (fr) * 2003-07-07 2005-01-27 Mformation Technologies, Inc. Systeme et procede pour la gestion par voie hertzienne d'un reseau et de dispositifs sans fil
WO2005086458A1 (fr) * 2004-03-09 2005-09-15 Telefonaktiebolaget Lm Ericsson (Publ) Procede et systeme de gestion de service web

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7512906B1 (en) * 2002-06-04 2009-03-31 Rockwell Automation Technologies, Inc. System and methodology providing adaptive interface in an industrial controller environment
US8250226B2 (en) * 2005-07-21 2012-08-21 Ca, Inc. Generating one or more clients for generating one or more synthetic transactions with one or more web service operations
US7698362B2 (en) * 2005-08-01 2010-04-13 Ricoh Company, Ltd. Web service connecting apparatus and web service connecting method

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030093468A1 (en) * 2001-10-19 2003-05-15 William Doyle Gordon Method of providing XML web services on an embedded device
WO2005008386A2 (fr) * 2003-07-07 2005-01-27 Mformation Technologies, Inc. Systeme et procede pour la gestion par voie hertzienne d'un reseau et de dispositifs sans fil
WO2005086458A1 (fr) * 2004-03-09 2005-09-15 Telefonaktiebolaget Lm Ericsson (Publ) Procede et systeme de gestion de service web

Non-Patent Citations (6)

* Cited by examiner, † Cited by third party
Title
"Data Transmission Systems and Equipment - Serial Asynchronous Automatic Dialing and Control for Character Mode DCE on Wireless Data Services", TIA STANDARD, no. TIA-678-A, September 2004 (2004-09-01), pages I-IV, 1 - 80, XP017002542 *
"Serial asynchronous automatic dialling and control", ITU-T STANDARD IN FORCE (I), INTERNATIONAL TELECOMMUNICATION UNION, GENEVA,, CH, no. V250 7/3, 14 July 2003 (2003-07-14), XP017403645 *
KAMINSKY A: "JiniME: Jini Connection Technology for Mobile devices", INTERNET CITATION, 3 August 2000 (2000-08-03), XP002253531, Retrieved from the Internet <URL:http://www.cs.rit.edu/~anhinga/whitepapers/JiniMEWhitePaper/printable.ht> [retrieved on 20030904] *
REES J ET AL: "WEBCARD: A JAVA CARD WEB SERVER", SMART CARD RESEARCH AND ADVANCED APPLICATIONS. IFIP WORKING CONFERENCE ON SMART CARD RESEARCH AND ADVANCED APPLICATIONS, 20 September 2000 (2000-09-20), pages 197 - 207, XP001013569 *
SONYERICSSON: "AT Commands Online Reference", DEVELOPERS GUIDELINES, October 2004 (2004-10-01), pages 1-28, 162-163, 185 - 190, XP002421900, Retrieved from the Internet <URL:http://www.sonyericsson.com/downloads/dg_at_2003_r4a.pdf> [retrieved on 20070223] *
TIMO SKYTTÄ: "Web Services: Usage and challenges in mobile phones (computers)", 6 March 2006 (2006-03-06), pages 1 - 26, XP002421901, Retrieved from the Internet <URL:www.w3.org/2006/Talks/WS-mobilephones_Nokia.pdf> [retrieved on 20070223] *

Also Published As

Publication number Publication date
FR2902271B1 (fr) 2009-01-09
FR2902271A1 (fr) 2007-12-14
EP2025131A1 (fr) 2009-02-18
US20100064062A1 (en) 2010-03-11

Similar Documents

Publication Publication Date Title
EP1193947B1 (fr) Système de communication basé sur le langage WSDL
EP1969461A1 (fr) Systeme et procede pour le deploiement d&#39;applications web personnalisees
WO2005101739A1 (fr) Systeme et procede de controle d&#39;equipements a distance a l&#39;aide de commandes at, dispositif, module de radiocommunication et programme correspondants
US20090300110A1 (en) Mobile core client architecture
FR3031219A1 (fr) Procede d&#39;association d&#39;un objet avec un utilisateur, dispositif, objet et produit programme d&#39;ordinateur correspondant
EP2025131A1 (fr) Procede de commande d &#39; un module electronique de radiocommunication
EP2350994B1 (fr) SYSTèME DOMOTIQUE ET PROCéDéS DE CONFIGURATION ET D&#39;UTILISATION ASSOCIéS
WO2021148741A1 (fr) Technique d&#39;administration a distance d&#39;un dispositif par un serveur d&#39;administration
EP1371251A1 (fr) Module de radiocommunication hebergeant et executant un logiciel client, et procede correspondant de mise en oeuvre d&#39;un logiciel client de pilotage
FR2908196A1 (fr) Procede de transfert de donnees multimedia
FR2856230A1 (fr) Systeme et procede de controle d&#39;equipements a distance a l&#39;aide de fonctions api, dispositif et module de radiocommunication et jeu de fonctions correspondants
EP2674860A1 (fr) Procédé de traitement de données par un module de navigation
EP1639787A2 (fr) Systeme et procede de controle d&#39;equipements a distance a l&#39;aide de commandes at, dispositif et module de radiocommunication et jeu de commandes correspondants.
FR3006528A1 (fr) Systeme et procede de supervision de communication entre composants applicatifs
EP3376823B1 (fr) Dispositif de communication
EP3817294B1 (fr) Procede et module pour la regulation de la connectivite d objets connectes
EP2736275B1 (fr) Module électronique pour rendre un message accessible par un sytème d&#39;exploitation visé
WO2013029954A1 (fr) Systeme de supervision embarque d&#39;une machine a partir d&#39;un terminal portable
EP2086282B1 (fr) Système de communication autoadaptatif
WO2008025853A2 (fr) Procédé de contrôle à distance d&#39;un terminal de radiocommunication
EP3110109A1 (fr) Procédé et dispositif de mise à jour des capacités d&#39;un objet connecté à un réseau de communications
FR2822628A1 (fr) Module de radiocommunication executant un logiciel principal et un logiciel client comprenant plusieurs applications clientes
FR2971383A1 (fr) Dispositif et procede de communication dans un environnement temps reel
FR2835373A1 (fr) Systeme et procede de gestion de l&#39;etablissement d&#39;une connexion de flux, au sein d&#39;un reseau audiovisuel domestique
WO2010012961A2 (fr) Mise à jour de critères de recherche de contenu définis pour un fournisseur de service

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 07729811

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 2007729811

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 12303698

Country of ref document: US