EP2010975A2 - Procede et dispositif de communication entre un equipement et un serveur - Google Patents

Procede et dispositif de communication entre un equipement et un serveur

Info

Publication number
EP2010975A2
EP2010975A2 EP07731145A EP07731145A EP2010975A2 EP 2010975 A2 EP2010975 A2 EP 2010975A2 EP 07731145 A EP07731145 A EP 07731145A EP 07731145 A EP07731145 A EP 07731145A EP 2010975 A2 EP2010975 A2 EP 2010975A2
Authority
EP
European Patent Office
Prior art keywords
communication
module
server
remote server
request
Prior art date
Legal status (The legal status 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 status listed.)
Withdrawn
Application number
EP07731145A
Other languages
German (de)
English (en)
Inventor
Simon Bretin
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Sierra Wireless Solutions and Services SA
Original Assignee
Anyware Technologies SA
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
Priority claimed from FR0602287A external-priority patent/FR2898698B1/fr
Priority claimed from FR0602286A external-priority patent/FR2898697B1/fr
Application filed by Anyware Technologies SA filed Critical Anyware Technologies SA
Publication of EP2010975A2 publication Critical patent/EP2010975A2/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B19/00—Programme-control systems
    • G05B19/02—Programme-control systems electric
    • G05B19/04—Programme control other than numerical control, i.e. in sequence controllers or logic controllers
    • G05B19/042—Programme control other than numerical control, i.e. in sequence controllers or logic controllers using digital processors
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/2803—Home automation networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/2803—Home automation networks
    • H04L12/2807—Exchanging configuration information on appliance services in a home automation network
    • H04L12/2814—Exchanging control software or macros for controlling appliance services in a home automation network
    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B2219/00—Program-control systems
    • G05B2219/10—Plc systems
    • G05B2219/12—Plc mp multi processor system
    • G05B2219/1214—Real-time communication between plc, Ethernet for configuration, monitor
    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B2219/00—Program-control systems
    • G05B2219/20—Pc systems
    • G05B2219/23—Pc programming
    • G05B2219/23297—Remote load of program with cellular, wireless, satellite connection
    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B2219/00—Program-control systems
    • G05B2219/20—Pc systems
    • G05B2219/23—Pc programming
    • G05B2219/23298—Remote load of program, through internet

Definitions

  • the present invention relates to a method and a device for programming communication between an equipment and a server through a communicatio module and a programming method of such a device. It applies, in particular, to remote control and control of office, household or industrial equipment, vehicles or buildings. Traditionally, these devices are not equipped with communication interfaces to remote elements (of the Ethernet or Wi-Fi type), but rather communication buses (Serial, RS485, etc.) and inputs / outputs allowing communication to elements close to the equipment.
  • a monitoring operator regularly makes a maintenance pass to verify the proper operation of the equipment and, in case of default, alert a technical service.
  • This procedure has many disadvantages.
  • the delay of detection of a failure can be important and, on the other hand, the quality of intervention of the technical service is subject to the quality of the report transmitted by the surveillance operator.
  • SMS short message system or short message system
  • a remote communication module which monitors the state of the equipment and which, as a function of crossing thresholds, triggers an alarm on a remote terminal, by example e emitting a mini-message, known as SMS (short message system or short message system) to the mobile phone of a maintainer
  • SMS short message system or short message system
  • These systems have many disadvantages. On the one hand, they do not allow centralized management of a set of equipment. On the other hand, they are subject to the availability of the communication network of the alarm. In addition, they request, for the programming, the intervention of a qualified computer scientist. Finally, they can not be reprogrammed remotely.
  • the present invention aims, in a first aspect, a device d means for associating said electronic module with an equipment such that said module receives signals representing states or operating parameters of said equipment through at least one connector; a communication server application on said module; electronic module, said communication server application being adapted to communicate automatically with said equipment as well as with said remote server through at least one communication means and a communication server application on said remote server for the adapt to automatically communicate with said electronic module through at least one communication channel through at least one communication means; each of said server applications being adapted: to decide the transmission of a request to the other server application, according to a predetermined criterion, said remote server and said module being thus adapted to transmit a request to said module or said remote server, respectively, following said decision and upon receipt of said request, to transmit a response to the other server application, said module and said remote server being thus adapted to transmit to said remote server or said module, respectively, said response encapsulating information representative of said states or parameters of said equipment.
  • each of the two server applications can interrogate the other and obtain, in return, instructions or status information.
  • at least one of said server applications comprises means for automatically selecting a communication channel between the electronic module and said remote server, according to characteristics of the data to be transmitted and the available communication channels, at least one of the steps of transmitting a request and responding to said request being performed by implementing the selected communication channel.
  • At least one of said applications comprises means for storing the information to be transmitted as long as a complete request / response cycle has not been positively completed.
  • one of the means of communication is a GSM / GPRS wireless network.
  • the present invention aims at a method of communication between an electronic module and a remote server, characterized in that it comprises: a step of associating said electronic module provided with a programmable controller with an equipment such that said module receives signals representative of states or operating parameters of said equipment through at least one connector; a step of implementing a communication server application on said electronic module, said communication server application being adapted to communicate automatically with said equipment as well as with said remote server through at least one means; Communication ; a step of implementing a communication server application on said remote server to adapt it to communicate automatically with said electronic module through at least one communication channel through at least one communication means ;
  • the method as briefly described above comprises a step of automatically selecting a communication channel between the electronic module and said remote server, according to the characteristics of the data to be transmitted and the available communication channels, at least one of the steps of transmitting a request and responding to said request being performed by implementing the selected communication channel.
  • the method as briefly described above includes a step of storing the information to be transmitted as long as a complete request / response cycle has not been completed positively, in order to be able to send, again, said information through one of the other means of communication.
  • one of the means of communication is a GSM / GPRS wireless network.
  • the present invention aims at a method of developing a machine-to-machine application between a communication module intended to be associated with an equipment and a computer system, characterized in that it comprises: a definition step logical data of an application intended to run on the communication module, the logical data being a representation of the functionalities offered by the equipment, a step of matching each logical data element to at least one acquisition or control means in relation to this datum, thus allowing the actual manipulation of the data,
  • step of defining the communication between the module and the computer system a step of generating the application intended to execute on the module, this generation being specific to the settings and data previously made or defined and
  • the method which is the subject of the third aspect further comprises a step of selecting a type of communication module, for example through its make and model, the generation of the application intended for executing on the module being, moreover, specific to the choice of the type of module.
  • the method that is the subject of the third aspect further comprises a step of defining an event logic that makes it possible to interact the logical data with one another, the generation of the application intended to execute on the module being in addition, specific to the defined event logic.
  • the method that is the subject of the third aspect further comprises:
  • a step of mapping each logical data to at least one storage means of the computer system a step of defining the event logic for making the logical data of the application of the computer system interact, a configuration step computer system parameters, a step of generating the application intended to run on the computer system, this generation being specific to the settings, choices, and logics previously made or defined and
  • logical devices manipulated by an application are defined, and logic variables representative of their logical characteristics are added to them.
  • an editor is implemented which makes it possible to create, modify and delete logical equipments, without reference to their electronic realization, by defining its variables. , through parameters, this definition of variables and parameters being constrained through the editor by the compatibility with the type of communication module chosen during the selection step.
  • the definition of logical data is done by means of graphic screens guiding the user by proposing him / her choices specific to the type of communication module chosen for certain parameters and leaving him free to use. other.
  • At least one of the communication mapping and definition steps is performed by means of graphic interfaces constraining the user with respect to the type of the communication module that he uses.
  • an editor is implemented which makes it possible to associate each variable defined during the step of defining logical data with an acquisition means, control or storage, this editor limiting the choices according to the parameters, variables and functions offered by the type of communication module that is programmed.
  • At least one event logic definition step is done graphically by selecting the logical data to be controlled, by associating a notion of binary logic and by choosing an action to be executed from among a plurality of actions, the data logic to control, the binary logic relationships and the actions to be executed being represented by specific graphic elements.
  • the dynamic choice of the communication channel to be used according to the states is defined. possible from each other communication channel.
  • the method object of the third aspect does not require writing code in computer language and consists solely in the manipulation of graphical interfaces.
  • FIG. 1 represents, schematically, an implementation of a particular embodiment of the device that is the subject of the present invention
  • FIG. 2 represents, in the form of a logic diagram, a particular embodiment of the method that is the subject of the present invention
  • FIG. 3 represents, in the form of a logic diagram, a particular embodiment of a programming method. of the device object of the present invention.
  • FIG. 1 shows a device to be monitored 100, a communication module 110 associated with the equipment 100 and comprising a controller 115 and, preferably, at least two communication means 120 and 125, two communication channels 130 and 135 , an operating server 140, comprising two communication means 155 and 160, a controller 170 and an information storage means 145, a programming terminal 150 comprising a communication means 165 and a client terminal 180.
  • 110 is, for example, a Q2686 module from Wavecom (registered trademarks) or TC65 from Siemens (registered trademarks).
  • the equipment to be supervised 100 may be stationary, such as, for example, a boiler, an office equipment or an electronic billboard, or mobile, such as a vehicle.
  • the equipment 100 comprises a controller 101 and implements software, in particular for monitoring the state of sensors 102 and / or actuators 104 and for communicating via at least one connector 103.
  • the communication module 110 is adapted to receive, via the connector 103, data from the equipment 100 and in particular signals representative of states or operating parameters of said equipment 100.
  • the communication module 110 is also adapted to send commands to the equipment 100 via the connector 103.
  • the communication means 120 and 125 enable the communication module 110 to communicate, via the two communication channels 130 and 135, with the server 140 and, optionally, with the programming terminal 150, knowing that another channel (not shown) can be used for the communication between the communication module 110 and the programming terminal 150.
  • the communication channels 130 and 135 are, for example, wireless telephony networks, for example of the GSM type. and GPRS, respectively.
  • the communication module 110 is adapted to download software via at least one of the networks 130 and 135 from the server 140 and / or the programming terminal 150, under external control, such as a third-party software or an SMS.
  • the server 140 is of known type and is adapted to interrogate each module 110, to receive its responses, to aggregate the received data and to trigger instructions or alarms, according to the data received or the aggregated data.
  • the server 140 is also adapted to provide data to client terminals by acting as the server of the web.
  • the programming terminal 150 is adapted to program applications for each module 110 and applications for each server 140.
  • the programming terminal 150 implements a development suite detailed later in the description.
  • the communication module 110 and the server 140 and, more precisely, the controllers 115 and 170 are adapted to implement between them the communication method that is the subject of the present invention, as presented with regard to the logic diagram of FIG. 2. , after a programming phase illustrated in Figure 3.
  • the client terminal 180 of any type, a mobile telephone, a personal digital assistant, a personal computer or a network server, for example, enables a user or operator to access the data storage means 145 kept by the server 140 and in particular, the data relating to each of the modules 110, possibly after authentication.
  • the server 140 behaves as server of the web to allow access to data with an interface well known to any user, ie a browser software on the internet.
  • FIG. 2 shows a step 205 of association, according to known techniques, of the communication module 110 equipped with the programmable controller 115 with said equipment 100 in such a way that said communication module 110 receives signals representative of states or of operating parameters of said equipment 100.
  • a communication server application of a type similar to those of the server of the fabric is implemented on the communication module 110.
  • the server Embedded is programmed in Java (registered trademark) and has a very small size. It is observed that this embedded server, characteristic of the present invention, allows the remote supervision and control of the module 110 and the associated equipment 100. It will also be observed that this communication module 110 is not adapted to receive data.
  • the communication module 110 behaves like a communication server, for example a server of the web, or "web" server.
  • a communication server includes software that responds to requests from clients, for example with so-called communication means http (hypertext transfer protocol acronym for hypertext transfer protocol) or minimessages, known as SMS (acronym for Short Message System).
  • http hypertext transfer protocol acronym for hypertext transfer protocol
  • SMS minimessages
  • the communication module 110 does not provide a page but data that the server 140 will integrate into pages that it provides to the clients 180. This data can be provided, for example, in SMS.
  • a communication trigger between the module 110 and the server 140 can take place under different circumstances: in the event of detection of triggering events, by the module 110, for example as a function of thresholds applied to sensors associated with the equipment 100, step 212, according to a predetermined schedule of communications between the module 110 and the server 140, this calendar being able to be managed by the module 110 or by the server 140 (case exposed in FIG. 2, in step 255),
  • steps 250 according to requests transmitted by the client terminal 180, in the case where the data stored in the database 145 would be considered obsolete in view of the request received, steps 250.
  • the server that wants to initiate a communication with the other server determines the best communication medium between the module. communication 110 and the server 140.
  • the following criteria may be considered in the order of decreasing priority: the availability of the communication channels, the urgency of transmission of the data stream to be transmitted, the pricing operators who manage the different communication channels.
  • step 220 the corresponding communication protocol switching, if any, is performed. Then, during a step 225, communicating the communication module 110 and said remote server 140, for example by implementing the hypertext transfer protocol http.
  • the initiator server of the communication transmits a request to the recipient who receives it, for example by implementing the hypertext transfer protocol http.
  • the communication module 110 or the server 140 checks, for security reasons, during step 230, the address of the server issuing the request.
  • the recipient analyzes the received request, retrieves the required data, in particular from the equipment 100 or the data storage means 145, processes this data and sends a response to the initiator of the data request. the request. This response thus encapsulates in particular information representative of the states or parameters of the equipment 100 or the communication module 110.
  • steps 230 and 235 the case where the server 140 initiates the communication has been considered.
  • the step 230 does not take place and, during the step 235, the communication module 110 retrieves the data to be transmitted, especially to the equipment 100, processes this data and sends a message to the server 140.
  • This response thus encapsulates information representative of the states or parameters of the equipment 100 or the communication module 110.
  • the server 140 aggregates and distributes the data collected from the various communications modules 110 to the persons, client terminals, databases and computer applications concerned.
  • This aggregation can comprise the constitution of a state of equipment history 100 associated with the electronic modules 110 and the triggering of alert in case of failure, the need for preventive maintenance, for example the need for supply of consumable.
  • alerts are determined according to the information representative of the states or parameters of the equipment 100 received during the step 235 or aggregated during the step 240.
  • a database or an application during a step 245, it is verified that the sender of this request is authorized to issue it. according to known techniques. It is observed that the request sent by the client terminal 180 is a request sent by a browser, the server 140 then acting server web.
  • a request to the equipment 110 is necessary, according to the request received and the time elapsed since the last update of the data concerning this module and at least a server configuration parameter.
  • the reading of the memory of the equipment module or the memory of the equipment is avoided if there is sufficiently recent information available, for example in the case of a query concerning data whose value and value are known. possible evolution. For example, a refresh of the state of the toner level each week may be sufficient.
  • step 250 If the result of the step 250 is positive, a request to the equipment 100 being necessary, one proceeds to the step 215. Otherwise, one proceeds to the step 255 during which one determines the next expiry of a a request to be sent to the equipment 100, the data required by the user are read in the database 145 and / or extrapolates the recent data stored in the database and provides the client terminal 180, in the form of a web page, the data required by the client terminal.
  • the server 140 aggregates data from databases and physical dynamic data transmitted by the electronic modules 110, for example, to define customer records that it transmits to the issuer.
  • the next request date to be addressed to the communication module is determined and when this date occurs, proceed to step 212.
  • the duration considered sufficient between two updates is configurable.
  • FIG. 3 shows the implementation of a quick and easy software development method for developing, generating and deploying machine-to-machine applications and programming, connecting and managing remote equipment 100 from one or more application servers 140 .
  • the method is implemented in a graphical and powerful development environment to develop, generate and deploy machine-to-machine applications much faster than with a traditional development approach and without knowledge of programming languages. This minimizes development costs and maximizes productivity.
  • the communication module 110 is selected which will be programmed, it being understood that the physical interface of this module with a device 100 has been made beforehand, for example or during its physical installation.
  • a logical data model of the application intended to execute on the communication module 110 is defined. This model is realized by defining logical devices handled by the application and then adding them. variables representative of their logical characteristics. This definition is done by means of a graphic screen guiding the user by offering him choices for certain parameters and leaving him free for others. This logical data model is totally independent of the actual data acquisition physics existing.
  • an alarm center will be represented by a "CentralAlarm” logical device with its logical “State” variables (boolean representing the on or off state of the alarm) and "InAlarm” (boolean representing the triggering or not of the alarm). 'alarm).
  • logical “State” variables boolean representing the on or off state of the alarm
  • InAlarm boolean representing the triggering or not of the alarm. 'alarm.
  • a "mapping" or a mapping is performed so that each logic variable of the logical data model of the application can be acquired (read) and / or controlled (write) on physical media. or software. Moreover, this configuration is achieved by means of graphic interfaces constraining the user with respect to the physical reality of the communication module 110 that he uses.
  • An editor is implemented which makes it possible to associate each logical variable defined during step 310 with an acquisition or control means supported by the environment. This editor limits the choices according to the parameters of the previously defined logical variables and the functionalities offered by the module 110 which is programmed.
  • the logical variable "State" of the alarm center may be associated with the GPIO pin (General Purpose Input Output) No. 4 of the communication module, the user can not choose the pins 0 to 3 because those they do not exist on the module used.
  • GPIO pin General Purpose Input Output
  • the event logic is defined, that is to say the operation of the computer application and the conditions of realization of its actions.
  • this event logic indicates which combinations of states of the equipment cause which actions on the part of the associated communication module.
  • This definition is done graphically by selecting the logical data to control (represented, for example, by rectangles), by associating a notion of binary logic (represented, for example, by relations between the previously selected rectangles) and finally by choosing an action to execute from those available (represented by icons).
  • the logical data to be controlled, the binary logic relations and the actions to be executed are preferably represented by specific graphic elements.
  • the configuration parameters of the communication module 110 are defined which will allow its interface with the equipment 100, as well as the proper operation of the communication module 110 itself.
  • This configuration is achieved through graphical interfaces limiting the user with respect to the physical realities of the components of the communication module 110. for example, it will be possible to configure the communication speed of an existing serial port on the module.
  • steps 330 to 345 the same steps as steps 310 to 325, respectively, are performed for the programming of the communication application to be implemented on the server side considered preselected as common to different modules 110.
  • a logical data model of the application intended to execute on the server 140 is defined.
  • This model is realized by defining logical hardware and software manipulated by the application, then by adding variables representative of their logical characteristics. This definition is done by means of a graphic screen guiding the user by offering him choices for certain parameters and leaving him free for others.
  • This logic model is totally independent of the physics of processing or storing existing real data. This definition of variables and parameters is constrained by the compatibility with the features offered by the editor.
  • a "mapping" or mapping is performed so that each variable of the logical data model of the application can be acquired (read) and / or controlled (written) on physical media or software.
  • this configuration is achieved by means of graphical interfaces constraining the user with respect to the physical reality of the server 140 and its peripherals that it uses.
  • the event logic is defined, that is to say the operation of the computer application and the conditions of realization of its actions.
  • this event logic indicates which state combinations cause which actions on the part of the server 140 or its peripherals.
  • This definition is done graphically by selecting the logical data to control (represented by rectangles), by associating a notion of binary logic (represented by relations between the previously selected rectangles) and finally by choosing an action to execute from those available. (represented by icons).
  • the configuration parameters of the server 140 and its peripherals are defined which will allow its interface with the module 110. This configuration is achieved through graphical interfaces limiting the user with respect to the physical realities of the server 140 and its peripherals. For example, it will be possible to configure the communication speed of an existing serial port on the server.
  • the communication between the module and the server is defined.
  • An editor is implemented which makes it possible to select the communication means according to the communication capabilities offered by the communication module 110.
  • step 365 also makes it possible to organize the dynamic choice of the communication channel to be used. This organization aims to maintain a link between the communication module and the server, even if a means of communication was faulty.
  • the choice depends on the available channels and / or the price of the communication channels.
  • the choices are made graphically thanks to multiple choice boxes, text fields and interfaces refreshing according to the choices made previously.
  • This application is an assembly of bricks or generic software components, for example the server. communication, web server or "web”, or specifically generated by the device described.
  • the bricks and software components are selected according to the choices made previously, in a deterministic manner. These choices made previously also constrain the order of execution of these bricks or components, which ensures the proper functioning of the application generated.
  • the bricks concern one the communication server, web server or SMS server, the other the GPRS communication, ...
  • the generated application intended to be executed on the communication module 110 is generated in the native language thereof.
  • Positioning System for global positioning system
  • a "classic" web server allowing access to the business information of the developed application
  • o application templates, presentation pages, graphic components known as widgets.
  • GSM Global System for Mobile communication
  • GPRS Global Packet Radio Service
  • Edge Wired Fidelity
  • Wifi Wired Fidelity for, in French , Loyalty Wireless
  • LAN Local Area Network
  • 3 / Security through integrated security mechanisms the implementation of the https secure data transfer protocol, personal authentication devices, terminals or applications, management of user profiles; 4 / The performances thanks to: the optimization of embedded codes for a minimal influence on the resources, in particular resources of memory, electronic modules and a maximum reliability and the optimization of bandwidth used on the communication networks, by compression data to minimize the cost of data traffic between the electronic modules 110 and the servers 140; 5 / Maintenance and update: provision, diagnosis, maintenance and download of applications remotely, thanks to remote communication capabilities provided by the module 110 and 6 / Data recovery from the remote electronic modules 110 for storage in the information processing system (server 140), for reporting, billing, knowledge base, for example.
  • server 140 information processing system
  • the elements and the programming are stored in the memory of the programming terminal 150 and can be edited and remotely downloaded to the module 110 and / or the server 140 at any time.
  • the graphical macro-language and the graphical environment thus use, at the same time, generic parts and specific parts for particular modules. Thanks to these characteristics, the programming language is independent of the communication module and its provider, the BSP (acronym for Board Support Package for, in French, card support package) or MSP (module support package for, in French, module support package) or the set of drivers for their command.

Abstract

Le dispositif de communication entre un module électronique (110) doté d'un contrôleur programmable et un serveur distant (140), comporte : un moyen d'association du module électronique avec un équipement (100) de telle manière que ledit module reçoive des signaux représentatifs d'états ou de paramètres de fonctionnement dudit équipement au travers d'au moins un connecteur (103), une application de serveur de communication sur ledit module électronique, ladite application de serveur de communication étant adaptée à communiquer de manière automatique avec ledit équipement ainsi qu'avec ledit serveur distant au travers d'au moins un moyen de communication (120, 125) et une application de serveur de communication sur ledit serveur distant pour l'adapter à communiquer de manière automatique avec ledit module électronique au travers d'au moins un canal de communication au travers d'au moins un moyen de communication (155, 160). Chacune des applications de serveur est adaptée : - à décider la transmission d'une requête à l'autre application de serveur, en fonction d'un critère prédéterminé, ledit serveur distant et ledit module étant ainsi adaptés à transmettre une requête à destination dudit module ou dudit serveur distant, respectivement, à la suite de ladite décision et - à réception de ladite requête, à faire transmettre une réponse à l'autre application de serveur, ledit module et ledit serveur distant étant ainsi adaptés à transmettre à destination dudit serveur distant ou dudit module, respectivement, ladite réponse encapsulant des informations représentatives desdits états ou paramètres dudit équipement.

Description

PROCEDE ET DISPOSITIF DE COMMUNICATION ENTRE UN EQUIPEMENT ET UN
SERVEUR
La présente invention concerne un procédé et un dispositif de programmation d communication entre un équipement et un serveur au travers d'un module de communicatio et un procédé de programmation d'un tel dispositif. Elle s'applique, en particulier, au contrôl et à la commande, à distance, d'équipements bureautiques, domestiques ou industriels, e de véhicules ou de bâtiments. Traditionnellement, ces équipements ne sont pas muni d'interfaces de communication vers des éléments distants (de type Ethernet ou Wi-Fi) mai plutôt de bus de communication (Série, RS485, ...) et entrées/sorties permettant I communication vers des éléments proches de l'équipement.
Dans le domaine du contrôle et de la commande à distance d'un équipemen généralement, un opérateur de surveillance fait régulièrement un passage de maintenanc pour vérifier le bon fonctionnement de l'équipement et, en cas de défaut, alerter un servie technique. Cette procédure présente de nombreux inconvénients. D'une part, le délai d détection d'une panne peut être important et, d'autre part, la qualité d'intervention du servie technique est soumise à la qualité du rapport transmis par l'opérateur de surveillance.
Dans des systèmes plus automatisés, il est connu de munir l'équipement d'un modul de communication à distance qui surveille l'état de l'équipement et qui, en fonction d franchissement de seuils, déclenche une alarme sur un terminal distant, par exemple e émettant un mini-message, connu sous le nom de SMS (pour short message System o système de message court) à destination du téléphone mobile d'un responsable d'entretier Ces systèmes présentent de nombreux inconvénients. D'une part, ils ne permettent pas un gestion centralisée d'un ensemble d'équipements. D'autre part, ils sont soumis à I disponibilité du réseau de communication de l'alarme. De plus, ils demandent, pour lei programmation, l'intervention d'un informaticien qualifié. Enfin, ils ne peuvent pas êtr reprogrammés à distance.
La présente invention vise à remédier à ces inconvénients. A cet effet, la présente invention vise, selon un premier aspect, un dispositif d - un moyen d'association dudit module électronique avec un équipement de telle manière que ledit module reçoive des signaux représentatifs d'états ou de paramètres de fonctionnement dudit équipement au travers d'au moins un connecteur, - une application de serveur de communication sur ledit module électronique, ladite application de serveur de communication étant adaptée à communiquer de manière automatique avec ledit équipement ainsi qu'avec ledit serveur distant au travers d'au moins un moyen de communication et une application de serveur de communication sur ledit serveur distant pour l'adapter à communiquer de manière automatique avec ledit module électronique au travers d'au moins un canal de communication au travers d'au moins un moyen de communication ; chacune des dites applications de serveur étant adaptée : à décider la transmission d'une requête à l'autre application de serveur, en fonction d'un critère prédéterminé, ledit serveur distant et ledit module étant ainsi adaptés à transmettre une requête à destination dudit module ou dudit serveur distant, respectivement, à la suite de ladite décision et à réception de ladite requête, à faire transmettre une réponse à l'autre application de serveur, ledit module et ledit serveur distant étant ainsi adaptés à transmettre à destination dudit serveur distant ou dudit module, respectivement, ladite réponse encapsulant des informations représentatives desdits états ou paramètres dudit équipement.
Grâce à ces dispositions, chacune des deux applications de serveur peut interroger l'autre et obtenir, en retour, des consignes ou des informations d'état. Selon des caractéristiques particulières, au moins une desdites applications de serveur comporte un moyen de sélection automatique d'un canal de communication entre le module électronique et ledit serveur distant, en fonction de caractéristiques des données à transmettre et des canaux de communications disponibles, au moins l'une des étapes de transmission d'une requête et de réponse à ladite requête étant effectuée en mettant en oeuvre le canal de communication sélectionné.
Selon des caractéristiques particulières, au moins une desdites applications comporte un moyen de conservation de l'information à transmettre tant qu'un cycle de requête/réponse complet n'a pas été achevé positivement.
Selon des caractéristiques particulières, l'un des moyens de communication est un réseau sans-fil de type GSM/GPRS.
Selon un deuxième aspect, la présente invention vise un procédé de communication entre un module électronique et un serveur distant, caractérisé en ce qu'il comporte : - une étape d'association dudit module électronique doté d'un contrôleur programmable avec un équipement de telle manière que ledit module reçoive des signaux représentatifs d'états ou de paramètres de fonctionnement dudit équipement au travers d'au moins un connecteur ; - une étape d'implantation d'une application de serveur de communication sur ledit module électronique, ladite application de serveur de communication étant adaptée à communiquer de manière automatique avec ledit équipement ainsi qu'avec ledit serveur distant au travers d'au moins un moyen de communication ; une étape d'implantation d'une application de serveur de communication sur ledit serveur distant pour l'adapter à communiquer de manière automatique avec ledit module électronique au travers d'au moins un canal de communication au travers d'au moins un moyen de communication ;
- une étape de transmission d'une requête depuis ledit serveur distant ou dudit module à destination dudit module ou dudit serveur distant, respectivement, à la suite d'une décision automatique d'utilisation d'un moyen de communication disponible et
- à réception de ladite requête, une étape de transmission d'une réponse, de la part dudit module ou dudit serveur distant et à destination dudit serveur distant ou dudit module, respectivement, ladite réponse encapsulant des informations représentatives desdits états ou paramètres dudit équipement. Selon des caractéristiques particulières, le procédé tel que succinctement exposé ci- dessus comporte une étape de sélection automatique d'un canal de communication entre le module électronique et ledit serveur distant, en fonction de caractéristiques des données à transmettre et des canaux de communications disponibles, au moins l'une des étapes de transmission d'une requête et de réponse à ladite requête étant effectuée en mettant en œuvre le canal de communication sélectionné.
Selon des caractéristiques particulières, le procédé tel que succinctement exposé ci- dessus comporte une étape conservation de l'information à transmettre tant qu'un cycle de requête/réponse complet n'a pas été achevé positivement, afin de pouvoir envoyer, de nouveau, ladite information au travers d'un des autres moyens de communication. Selon des caractéristiques particulières, l'un des moyens de communication est un réseau sans-fil de type GSM/GPRS.
Selon un troisième aspect, la présente invention vise un procédé de développement d'une application machine à machine entre un module de communication destiné à être associé à un équipement et un système informatique, caractérisé en ce qu'il comporte : - une étape de définition de données logiques d'une application destinée à s'exécuter sur le module de communication, les données logiques étant une représentation des fonctionnalités offertes par l'équipement, - une étape de mise en correspondance de chaque donnée logique à au moins un moyen d'acquisition ou de commande en relation avec cette donnée, permettant ainsi la manipulation effective des données,
- une étape de définition de paramètres de configuration du module de communication qui permettent son interfaçage avec l'équipement, de paramétrer des moyens de communication et de définir d'autres paramètres spécifiques au module de communication choisi au cours de l'étape de sélection,
- une étape de définition de la communication entre le module et le système informatique, - une étape de génération de l'application destinée à s'exécuter sur le module, cette génération étant spécifique aux paramétrages et données précédemment effectués ou définis et
- une étape de téléchargement de l'application sur le module.
Selon des caractéristiques particulières, le procédé objet du troisième aspect comporte, en outre, une étape de sélection d'un type de module de communication, par exemple au travers de sa marque et de son modèle, la génération de l'application destinée à s'exécuter sur le module étant, en outre, spécifique au choix du type de module.
Selon des caractéristiques particulières, le procédé objet du troisième aspect comporte, en outre, une étape de définition d'une logique événementielle permettant de faire interagir les données logiques entre elles, la génération de l'application destinée à s'exécuter sur le module étant, en outre, spécifique à la logique événementielle définie.
Selon des caractéristiques particulières, le procédé objet du troisième aspect comporte, en outre :
- une étape de définition de données logiques d'une application destinée à s'exécuter sur le système informatique,
- une étape de mise en correspondance de chaque données logiques à au moins un moyen de stockage du système informatique, une étape de définition de la logique événementielle permettant de faire interagir les données logiques de l'application du système informatique, - une étape de configuration des paramètres du système informatique, une étape de génération de l'application destinée à s'exécuter sur le système informatique, cette génération étant spécifique aux paramétrages, choix, et logiques précédemment effectués ou définis et
- une étape de téléchargement de l'application sur le système informatique. Selon des caractéristiques particulières, au cours d'au moins une étape de définition de données logiques, on définit des équipements logiques manipulés par une application, puis on leur ajoute des variables logiques représentatives de leurs caractéristiques logiques. Selon des caractéristiques particulières, au cours d'au moins une l'étape de définition de données logiques, on met en œuvre un éditeur qui permet de créer, modifier et supprimer des équipements logiques, sans référence à leur réalisation électronique, en définissant ses variables, au travers de paramètres, cette définition de variables et de paramètres étant contrainte au travers de l'éditeur par la compatibilité avec le type de module de communication choisi au cours de l'étape de sélection.
Selon des caractéristiques particulières, avec ledit éditeur, la définition de données logiques se fait au moyen d'écrans graphiques guidant l'utilisateur en lui proposant des choix spécifiques au type de module de communication choisi pour certains paramètres et en le laissant libre pour d'autres.
Selon des caractéristiques particulières, au moins l'une des étapes de mise en correspondance et de définition de communication est réalisée au moyen d'interfaces graphiques contraignant l'utilisateur par rapport au type du module de communication qu'il utilise. Selon des caractéristiques particulières, au cours d'au moins une étape de mise en correspondance, on met en œuvre un éditeur qui permet d'associer chaque variable définie au cours de l'étape de définition de données logiques avec un moyen d'acquisition, de commande ou de stockage, cet éditeur limitant les choix en fonction des paramètres, des variables et des fonctionnalités offertes par le type de module de communication qui est programmé.
Selon des caractéristiques particulières, au moins une étape de définition de logique événementielle se fait de manière graphique en sélectionnant les données logiques à contrôler, en associant une notion de logique binaire et en choisissant une action à exécuter parmi une pluralité d'actions, les données logiques à contrôler, les relations de logique binaire et les actions à exécuter étant représentées par des éléments graphiques spécifiques.
Selon des caractéristiques particulières, au cours de l'étape de définition de la communication entre le module et le système informatique, si au moins deux canaux de communication ont été définis, on définit le choix dynamique du canal de communication à utiliser en fonction des états possibles de chaque autre canal de communication.
Selon des caractéristiques particulières, le procédé objet du troisième aspect ne nécessite pas d'écrire de code en langage informatique et consiste uniquement en la manipulation d'interfaces graphiques.
D'autres avantages, buts et caractéristiques de la présente invention ressortiront de la description qui va suivre, faite, dans un but explicatif et nullement limitatif en regard des dessins annexés dans lesquels : - la figure 1 représente, schématiquement, une implantation d'un mode de réalisation particulier du dispositif objet de Ia présente invention,
- la figure 2 représente, sous forme d'un logigramme, un mode de réalisation particulier du procédé objet de la présente invention et - la figure 3 représente, sous forme d'un logigramme, un mode de réalisation particulier d'un procédé de programmation du dispositif objet de la présente invention.
On observe, en figure 1 , un équipement à superviser 100, un module de communication 110 associé à l'équipement 100 et comportant un contrôleur 115 et, préférentiellement, au moins deux moyens de communication 120 et 125, deux canaux de communication 130 et 135, un serveur d'exploitation 140, comportant deux moyens de communication 155 et 160, un contrôleur 170 et un moyen de stockage de l'information 145, un terminal de programmation 150 comportant un moyen de communication 165 et un terminal client 180. Le module de communication 110 est, par exemple, un module Q2686 de Wavecom (marques déposées) ou TC65 de Siemens (marques déposées). L'équipement à superviser 100 peut être fixe comme, par exemple, une chaudière, un équipement bureautique ou un panneau d'affichage électronique, ou mobile comme, par exemple un véhicule. Ces équipements sont, en général, nombreux et on parle en termes de flotte d'équipements que l'on souhaite surveiller ou contrôler. Préférentiellement, l'équipement 100 comporte un contrôleur 101 et met en oeuvre des logiciels, en particulier pour contrôler l'état de capteurs 102 et/ou d'actionneurs 104 et pour communiquer par l'intermédiaire d'au moins un connecteur 103.
Le module de communication 110 est adapté à recevoir, par l'intermédiaire du connecteur 103, des données de la part de l'équipement 100 et notamment des signaux représentatifs d'états ou de paramètres de fonctionnement dudit équipement 100. Le module de communication 110 est également adapté à envoyer des commandes à l'équipement 100, par l'intermédiaire du connecteur 103.
Par ailleurs, les moyens de communication 120 et 125 permettent au module de communication 110 de communiquer, par l'intermédiaire des deux canaux de communication 130 et 135, avec le serveur 140 et, éventuellement, avec le terminal de programmation 150, sachant qu'un autre canal (non représenté) peut être utilisé pour la communication entre le module de communication 110 et le terminal de programmation 150. Les canaux de communication 130 et 135 sont, par exemple, des réseaux de téléphonie sans fil, par exemple de type GSM et GPRS, respectivement.
Le module de communication 110 est adapté à télécharger des logiciels par l'intermédiaire de l'un, au moins, des réseaux 130 et 135 à partir du serveur 140 et/ou du terminal de programmation 150, sous commande extérieure, telle qu'un logiciel tiers ou un SMS. Le serveur 140 est de type connu et est adapté à interroger chaque module 110, à recevoir ses réponses, à agréger les données reçues et à déclencher des consignes ou des alarmes, en fonction des données reçues ou des données agrégées. Le serveur 140 est aussi adapté à fournir des données à des terminaux clients en se comportant comme serveur de la toile.
Le terminal de programmation 150 est adapté à programmer des applications pour chaque module 110 et des applications pour chaque serveur 140. Le terminal de programmation 150 met en oeuvre une suite de développement détaillée plus loin dans la description. Le module de communication 110 et le serveur 140 et, plus précisément, les contrôleurs 115 et 170 sont adaptés à mettre en œuvre, entre eux, le procédé de communication objet de la présente invention, tel que présenté en regard du logigramme de la figure 2, après une phase de programmation illustrée en figure 3.
Le terminal client 180, de type quelconque, téléphone mobile, assistant personnel numérique, ordinateur personnel ou serveur de réseau, par exemple, permet à un utilisateur, ou opérateur, d'accéder au moyen de stockage de données 145 conservée par le serveur 140 et, en particulier, aux données concernant chacun des modules 110, possiblement après authentification. Dans cette communication, le serveur 140 se comporte comme serveur de la toile pour permettre l'accès aux données avec une interface bien connue de tout utilisateur, c'est à dire un logiciel de navigation sur internet.
On observe, en figure 2, une étape 205 d'association, selon des techniques connues, du module de communication 110 doté du contrôleur programmable 115 avec ledit équipement 100 de telle manière que ledit module de communication 110 reçoive des signaux représentatifs d'états ou de paramètres de fonctionnement dudit équipement 100. Puis, au cours d'une étape 210, on implante une application de serveur de communication, de type similaire à ceux de serveur de la toile, sur le module de communication 110. Par exemple, le serveur embarqué est programmé en Java (marque déposée) et possède une taille très réduite. On observe que ce serveur embarqué, caractéristique de la présente invention, permet la supervision et le contrôle à distance du module 110 et de l'équipement associé 100. On observera par ailleurs que ce module de communication 110 n'est pas adapté à recevoir des composants disponibles sur étagère à l'homme du métier (typiquement, les serveurs de la toile traditionnellement disponibles sur les équipements embarqués), et ce du fait des fortes contraintes imposées par les modules de communication. A partir de l'étape 210, le module de communication 110 se comporte comme un serveur de communication, par exemple un serveur de la toile, ou serveur « web ». On rappelle qu'un serveur de communication comporte un logiciel qui répond à des requêtes provenant de clients, par exemple avec des moyens de communication dits http (acronyme de hypertext transfer protocol pour protocole de transfert hypertexte) ou des minimessages, connus sous le nom de SMS (acronyme de Short Message System, pour système à messages courts). On observe que, préférentiellement, le module de communication 110 ne fournit pas de page mais des données que Ie serveur 140 intégrera dans des pages qu'il fournit aux clients 180. Ces données peuvent être fournies, par exemple, en SMS.
Un déclenchement de communication entre le module 110 et le serveur 140 peut avoir lieu dans différentes circonstances : en cas de détection d'événements déclenchant, par le module 110, par exemple en fonction de seuils appliqués à des capteurs associés à l'équipement 100, étape 212, en fonction d'un calendrier prédéterminé de communications entre le module 110 et le serveur 140, ce calendrier pouvant être gérer par le module 110 ou par le serveur 140 (cas exposé en figure 2, en étape 255),
- en fonction de requêtes transmises par le terminal client 180, au cas où les données conservées dans la base de données 145 seraient considérées comme obsolètes au vu de la requête reçue, étapes 250.
Au cours d'une étape 215, le serveur qui veut initier une communication avec l'autre serveur, c'est à dire soit le serveur de communication du module 110, soit le serveur 140, détermine le meilleur support de communication entre le module de communication 110 et le serveur 140. Au cours de cette étape 215, on pourra notamment considérer les critères suivants dans l'ordre de priorité décroissante : la disponibilité des canaux de communication, l'urgence de transmission du flux de données à transmettre, la tarification des opérateurs qui gèrent les différents canaux de communication.
Grâce à cette étape, on garantit pratiquement le maintien de la capacité de communication entre le module de communication 110 et le serveur 140, même si l'un des canaux est indisponible.
En fonction du canal de communication sélectionné au cours de l'étape 215, au cours de l'étape 220, on effectue Ia commutation de protocole de communication correspondant, Ie cas échéant. Puis, au cours d'une étape 225, on met en communication le module de communication 110 et ledit serveur distant 140, par exemple en mettant en oeuvre le protocole de transfert hypertexte http.
Au cours d'une étape 230, le serveur initiateur de la communication transmet une requête à destination du destinataire qui la reçoit, par exemple en mettant en oeuvre le protocole de transfert hypertexte http. Préférentiellement, pour chaque requête reçue, le module de communication 110 ou le serveur 140 vérifient, pour des raisons de sécurité, au cours de l'étape 230, l'adresse du serveur émetteur de la requête. Au cours d'une étape 235, le destinataire analyse Ia requête reçue, récupère les données requises, notamment auprès de l'équipement 100 ou du moyen de stockage des données 145, traite ces données et émet une réponse à destination de l'initiateur de la requête. Cette réponse encapsule ainsi notamment des informations représentatives des états ou paramètres de l'équipement 100 ou du module de communication 110.
Pour la description des étapes 230 et 235, on a considéré le cas où le serveur 140 initie la communication. Dans l'autre cas, dans lequel c'est le serveur de communication du module de communication 110 qui initie la communication, l'étape 230 n'a pas lieu et, au cours de l'étape 235, le module de communication 110 récupère les données à transmettre, notamment auprès de l'équipement 100, traite ces données et émet un message à destination du serveur 140. Cette réponse encapsule ainsi des informations représentatives des états ou paramètres de l'équipement 100 ou du module de communication 110.
Au cours d'une étape 240, le serveur 140 agrège et distribue les données collectées depuis les différents modules de communications 110 vers les personnes, terminaux clients, bases de données et applications informatiques concernées. Cette agrégation peut comporter la constitution d'un historique d'états des équipements 100 associés aux modules électroniques 110 et le déclenchement d'alerte en cas de panne, de besoin de maintenance préventive, par exemple de besoin de fourniture de consommable. Ces alertes sont déterminées en fonction des informations représentatives des états ou paramètres de l'équipement 100 reçues au cours de l'étape 235 ou agrégées au cours de l'étape 240.
Lors d'une requête arrivant au serveur 140 de la part d'un terminal client 180, une base de données ou une application, au cours d'une étape 245, on vérifie que l'émetteur de cette requête est autorisé à l'émettre, selon des techniques connues. On observe que la requête émise par le terminal client 180 est une requête émise par un navigateur, Ie serveur 140 agissant alors en serveur de la toile.
Puis, au cours d'une étape 250, on détermine si une requête à l'équipement 110 est nécessaire, en fonction de la requête reçue et de Ia durée écoulée depuis la dernière mise à jour des données concernant ce module et d'au moins un paramètre de configuration du serveur. Ainsi, on évite la lecture de la mémoire du module de l'équipement ou la mémoire de l'équipement si on dispose d'information suffisamment récente, par exemple dans le cas d'une requête concernant des données dont on connaît la valeur et l'évolution possible. Par exemple, un rafraîchissement de l'état du niveau de toner chaque semaine peut suffire.
Si le résultat de l'étape 250 est positif, une requête à l'équipement 100 étant nécessaire, on passe à l'étape 215. Sinon, on passe à l'étape 255 au cours de laquelle on détermine la prochaine échéance d'une requête à adresser à l'équipement 100, on effectue la lecture des données requises par l'utilisateur, dans la base de données 145 et/ou on réalise une extrapolation des données récentes conservées dans la base de données et on fournit au terminal client 180, sous forme d'une page de Ia toile, les données requises par le terminal client.
En réponse aux requêtes qu'il reçoit, le serveur 140 agrège des données provenant de bases de données et des données dynamiques physiques transmises par les modules électroniques 110, pour, par exemple, définir des fiches clients qu'il transmet à l'émetteur de Ia requête reçue au cours de l'étape 245. >
Au cours d'une étape 255, on détermine la prochaine date de requête à adresser au module de communication et lorsque cette date survient, on passe à l'étape 212. Préférentiellement, la durée considérée comme suffisante entre deux mises à jour est paramétrable.
On observe, en figure 3, la mise en œuvre d'un procédé de développement de logiciel rapide et facile pour développer, générer et déployer des applications machine à machine et programmer, connecter et gérer les équipements lointains 100 depuis un ou plusieurs serveurs applicatifs 140.
Le procédé est mis en œuvre dans un environnement de développement graphique et puissant afin de développer, générer et déployer des applications machine à machine beaucoup plus rapidement qu'avec une approche développement traditionnel et sans connaissance des langages de programmation. On minimise ainsi les coûts de développement et on maximise Ia productivité.
Au cours d'une étape 305 optionnelle, on sélectionne le module de communication 110 qui va être programmé, étant entendu que l'interfaçage physique de ce module avec un équipement 100 a été réalisé préalablement, par exemple ou cours de son installation physique. Au cours d'une étape 310, on définit un modèle de données logiques de l'application destinée à s'exécuter sur le module de communication 110. Ce modèle se réalise en définissant des équipements logiques manipulés par l'application, puis en leur ajoutant des variables représentatives de leurs caractéristiques logiques. Cette définition se fait au moyen d'écran graphique guidant l'utilisateur en lui proposant des choix pour certains paramètres et en le laissant libre pour d'autres. Ce modèle de données logiques est totalement indépendant de la physique d'acquisition des données réelles existantes. Par exemple une centrale d'alarme sera représentée par un équipement logique « CentraleAlarme » avec ses variables logiques « Etat » (booléen représentant l'état marche ou arrêt de l'alarme) et « EnAlarme » (booléen représentant le déclenchement ou non de l'alarme). On met en œuvre un éditeur qui permet de créer, modifier et supprimer des équipements logiques (sans référence à sa réalisation électronique) en définissant ses variables, au travers de paramètres tels que type de données (chaîne de caractère, numérique ou booléen), mode d'accès (écriture et/ou lecture), limites de variation (valeur ou longueur maximum et minimum).
Cette définition de variables et paramètres est contrainte par la compatibilité avec les fonctionnalités offertes par l'éditeur. Par exemple, le type de données peut être limité aux trois exemples donnés ci-dessus et donc ne pas permettre un tableau.
Au cours d'une étape 315, on effectue un « Mapping » ou une mise en correspondance pour que chaque variable logique du modèle de données logiques de l'application puisse être acquis (lecture) et/ou commandé (écriture) sur des supports physiques ou logiciels. Par ailleurs, cette configuration se réalise au moyen d'interfaces graphiques contraignant l'utilisateur par rapport à la réalité physique du module de communication 110 qu'il utilise.
On met en œuvre un éditeur qui permet d'associer chaque variable logique définie au cours de l'étape 310 avec un moyen d'acquisition ou de commande supporté par l'environnement. Cet éditeur limite les choix en fonction des paramètres des variables logiques précédemment définies et des fonctionnalités offertes par le module 110 qui est programmé.
Par exemple, la variable logique « Etat » de Ia centrale d'alarme pourra être associée à la broche GPIO (General Purpose Input Output) n°4 du module de communication, l'utilisateur ne pouvant pas choisir les broches 0 à 3 car celles-ci n'existent pas sur le module utilisé. On constitue donc, ici, une association spécifique au module de communication et équipements concernés par la programmation.
Au cours d'une étape 320, on définit la logique événementielle, c'est-à-dire le fonctionnement de l'application informatique et les conditions de réalisation de ses actions. Par exemple, cette logique événementielle indique quelles combinaisons d'états de l'équipement provoquent quelles actions de la part du module de communication associé. Cette définition se fait de manière graphique en sélectionnant les données logiques à contrôler (représentées, par exemple, par des rectangles), en associant une notion de logique binaire (représentées, par exemple, par des relations entre les rectangles précédemment sélectionnés) et finalement en choisissant une action à exécuter parmi celles disponibles (représentées par des icônes). Ainsi, les données logiques à contrôler, les relations de logique binaire et les actions à exécuter sont préférentiellement représentées par des éléments graphiques spécifiques.
Au cours d'une étape 325, on définit les paramètres de configuration du module de communication 110 qui permettront son interfaçage avec l'équipement 100, ainsi que le bon fonctionnement du module de communication 110 lui même.
Cette configuration se réalise au travers d'interfaces graphiques limitant l'utilisateur par rapport aux réalités physiques des composants du module de communication 110. Par exemple, on pourra configurer la vitesse de communication d'un port série existant sur le module.
Au cours des étapes 330 à 345, on effectue les mêmes étapes que les étapes 310 à 325, respectivement, pour la programmation de l'application de communication à implanter du côté serveur considéré comme présélectionné car commun à différents modules 110.
Ainsi, au cours de l'étape 330, on définit un modèle de données logiques de l'application destinée à s'exécuter sur le serveur 140. Ce modèle se réalise en définissant des matériels et logiciels logiques manipulés par l'application, puis en leur ajoutant des variables représentatives de leurs caractéristiques logiques. Cette définition se fait au moyen d'écran graphique guidant l'utilisateur en lui proposant des choix pour certains paramètres et en le laissant libre pour d'autres. Ce modèle logique est totalement indépendant de la physique de traitement ou de stockage des données réelles existantes. Cette définition de variables et paramètres est contrainte par la compatibilité avec les fonctionnalités offertes par l'éditeur. Au cours d'une étape 335, on effectue un « Mapping » ou une mise en correspondance pour que chaque variable du modèle de données logiques de l'application puisse être acquis (lecture) et/ou commandé (écriture) sur des supports physiques ou logiciels. Par ailleurs, cette configuration se réalise au moyen d'interfaces graphiques contraignant l'utilisateur par rapport à la réalité physique du serveur 140 et de ses périphériques qu'il utilise.
On met en œuvre un éditeur qui permet d'associer chaque variable définie au cours de l'étape 330 avec un moyen d'acquisition ou de commande supporté par l'environnement. Cet éditeur limite les choix en fonction des paramètres des variables prédéfinis et des fonctionnalités offertes par le serveur 140 qui est programmé. On constitue donc, ici, une association spécifique au serveur 140 et à ses périphériques concernés par la programmation.
Au cours d'une étape 340, on définit la logique événementielle, c'est-à-dire le fonctionnement de l'application informatique et les conditions de réalisation de ses actions. Par exemple, cette logique événementielle indique quelles combinaisons d'états provoquent quelles actions de la part du serveur 140 ou de ses périphériques. Cette définition se fait de manière graphique en sélectionnant les données logiques à contrôler (représentées par des rectangles), en associant une notion de logique binaire (représentées par des relations entre les rectangles précédemment sélectionnés) et finalement en choisissant une action à exécuter parmi celles disponibles (représentées par des icônes). Au cours d'une étape 345, on définit les paramètres de configuration du serveur 140 et de ses périphériques qui permettront son interfaçage avec le module 110. Cette configuration se réalise au travers d'interfaces graphiques limitant l'utilisateur par rapport aux réalités physiques du serveur 140 et de ses périphériques. Par exemple, on pourra configurer la vitesse de communication d'un port série existant sur le serveur.
Puis, au cours d'une étape 365, on définit la communication entre le module et le serveur. On met en œuvre un éditeur qui permet de sélectionner les moyens de communication en fonction des capacités de communication offertes par le module de communication 110.
Si au moins deux canaux de communication ont été définis, l'étape 365 permet également d'organiser le choix dynamique du canal de communication à utiliser. Cette organisation vise à conserver un lien entre le module de communication et le serveur, même si un moyen de communication était défaillant.
Par exemple, le choix dépend des canaux disponibles et/ou des prix des canaux de communication. Au cours de cette étape, les choix sont effectués graphiquement grâce notamment à des boites à choix multiples, des champs textes et des interfaces se rafraîchissant en fonction des choix faits précédemment.
Puis, au cours d'une étape 370, on génère l'application qui s'exécutera sur le module 110 et celle qui s'exécutera sur le serveur 140. Cette application est un assemblage de briques ou composants logicielles génériques, par exemple le serveur de communication, de serveur de la toile ou « web », ou spécifiquement généré par le dispositif décrit. Les briques et composants logiciels sont sélectionnés en fonction des choix effectués précédemment, de manière déterministe. Ces choix faits précédemment contraignent aussi l'ordre d'exécution de ces briques ou composants, ce qui assure le bon fonctionnement de l'application générée.
Par exemple, les briques concernent l'une le serveur de communication, serveur de la toile ou serveur SMS, l'autre la communication GPRS, ...
L'application générée destinée à être exécutée sur le module de communication 110 est générée dans le langage natif de celui-ci.
Au cours d'une étape 375 on télécharge chacune des applications sur le module et le serveur, on lance ses applications, avec ou sans réinitialisation. Les avantages principaux de ce procédé de développement sont les suivants :
1/ sa facilité d'utilisation : une approche de programmation graphique guidant les choix de développement de l'utilisateur ;
- une approche de programmation de haut niveau : o utilisation de briques de modèle de données efficaces pour définir la logique de l'application et la lier à un dispositif de communication ; o utilisation d'un dispositif d'association des paramètres logiques et physiques
(moyen d'acquisition) de l'application ; o mise à disposition d'un assistant de configuration pour définir tous les paramètres de communication entre le module 110 et le serveur 140 ; - une génération de code informatique automatique ; un ensemble de composants d'application prêts à l'emploi : o un serveur web embarqué ; o une librairie de protocoles applicatifs (Modbus, Nmea, par exemple) pour une interconnexion aisée avec des équipements spécifiques tels que PLC (acronyme de Programmable Logic Controller pour, en français, automate programmable), dispositif de télémétrie, modules GPS (acronyme de Global
Positioning System pour système de positionnement global), par exemple ; o un serveur web « classique » permettant d'accéder aux informations métier de l'application développée ; o des modèles d'applications, des pages de présentation, des composants graphiques (connus sous le nom de widgets).
2/ Une connexion d'une extrémité à l'autre pour développer et déployer une solution machine à machine complète depuis les équipements éloignés jusqu'aux serveurs applicatifs, permettant la communication par l'intermédiaire de réseaux, par exemple GSM (acronyme de Global System for Mobile communication pour, en français, système de communication globale pour équipements mobiles), GPRS (acronyme de Global Packet Radio Service pour, en français, système de communication radio par paquets), Edge, Wifi (acronyme de Wireless Fidelity pour, en français, Fidélité sans fil), LAN (Local Area Network pour, en français réseau local). 3/ La sécurité par le biais de mécanismes de sécurité intégrés : la mise en œuvre du protocole de transfert de données sécurisé https, de dispositifs d'authentification de personnes, de terminaux ou d'applications, de gestion de profils d'utilisateurs ; 4/ Les performances grâce à : l'optimisation de codes embarqués pour une emprise minimale sur les ressources, en particulier ressources de mémoire, des modules électroniques et une fiabilité maximale et l'optimisation de bande passante utilisé sur les réseaux de communication, par compression de données pour minimiser les coûts de trafic de données entre les modules électroniques 110 et les serveurs 140 ; 5/ Maintenance et mise à jour : fourniture, diagnostic, maintenance et téléchargement d'applications à distance, grâce à des capacités de communication à distance fournies par le module 110 et 6/ Récupération de données depuis les modules électroniques distants 110 pour stockage dans le système de traitement d'information (serveur 140), pour réalisation de rapports, facturation, base de connaissance, par exemple.
Grâce à la mise en œuvre de cet environnement de développement, on développe une solution globale et centralisée. Pratiquement, la suite de développement organise le développement et s'abstrait de la forme d'exécution. Un macro-langage graphique permet de s'affranchir de connaissance de langage informatique.
On observe que les éléments et la programmation sont conservés en mémoire du terminal de programmation 150 et peuvent être édités et téléchargés à distance sur le module 110 et/ou sur le serveur 140 à tout moment.
Le macro-langage graphique et l'environnement graphique utilisent ainsi, à la fois, des parties génériques et des parties spécifiques pour des modules particuliers. Grâce à ces caractéristiques, le langage de programmation est indépendant du module de communication et de son fournisseur, des BSP (acronyme de Board Support Package pour, en français, ensemble de support de carte) ou MSP (module support package pour, en français, ensemble de support de module) ou de l'ensemble de pilotes permettant leur commande.

Claims

REVENDICATIONS
1 - Dispositif de communication entre un module électronique (110) doté d'un contrôleur programmable et un serveur distant (140), caractérisé en ce qu'il comporte : - un moyen d'association dudit module électronique avec un équipement (100) de telle manière que ledit module reçoive des signaux représentatifs d'états ou de paramètres de fonctionnement dudit équipement au travers d'au moins un connecteur (103), une application de serveur de communication sur ledit module électronique, ladite application de serveur de communication étant adaptée à communiquer de manière automatique avec ledit équipement ainsi qu'avec ledit serveur distant au travers d'au moins un moyen de communication (120, 125) et une application de serveur de communication sur ledit serveur distant pour l'adapter à communiquer de manière automatique avec ledit module électronique au travers d'au moins un canal de communication au travers d'au moins un moyen de communication (155, 160) ; chacune des dites applications de serveur étant adaptée :
- à décider la transmission d'une requête à l'autre application de serveur, en fonction d'un critère prédéterminé, ledit serveur distant et ledit module étant ainsi adaptés à transmettre une requête à destination dudit module ou dudit serveur distant, respectivement, à la suite de ladite décision et
- à réception de ladite requête, à faire transmettre une réponse à l'autre application de serveur, ledit module et ledit serveur distant étant ainsi adaptés à transmettre à destination dudit serveur distant ou dudit module, respectivement, ladite réponse encapsulant des informations représentatives desdits états ou paramètres dudit équipement.
2 - Dispositif selon la revendication 1, caractérisé en ce qu'au moins une desdites applications de serveur comporte un moyen de sélection automatique d'un canal de communication entre le module électronique et ledit serveur distant, en fonction de caractéristiques des données à transmettre et des canaux de communications disponibles, au moins l'une des étapes de transmission d'une requête et de réponse à ladite requête étant effectuée en mettant en oeuvre le canal de communication sélectionné.
3 - Dispositif selon l'une quelconque des revendications 1 ou 2, caractérisé en ce qu'au moins une desdites applications comporte un moyen de conservation de l'information à transmettre tant qu'un cycle de requête/réponse complet n'a pas été achevé positivement.
4 - Dispositif selon l'une quelconque des revendications 1 à 3, caractérisé en ce que l'un des moyens de communication est un réseau sans-fil de type GSM/GPRS. 5 - Procédé de communication entre un module électronique (110) et un serveur distant (140), caractérisé en ce qu'il comporte :
- une étape d'association dudit module électronique doté d'un contrôleur programmable avec un équipement (100) de telle manière que ledit module reçoive des signaux représentatifs d'états ou de paramètres de fonctionnement dudit équipement au travers d'au moins un connecteur (103) ;
- une étape d'implantation d'une application de serveur de communication sur ledit module électronique, ladite application de serveur de communication étant adaptée à communiquer de manière automatique avec ledit équipement ainsi qu'avec ledit serveur distant au travers d'au moins un moyen de communication (120, 125) ;
- une étape d'implantation d'une application de serveur de communication sur ledit serveur distant pour l'adapter à communiquer de manière automatique avec ledit module électronique au travers d'au moins un canal de communication au travers d'au moins un moyen de communication (155, 160) ; - une étape de transmission d'une requête depuis ledit serveur distant ou dudit module à destination dudit module ou dudit serveur distant, respectivement, à la suite d'une décision automatique d'utilisation d'un moyen de communication disponible et
- à réception de ladite requête, une étape de transmission d'une réponse, de la part dudit module ou dudit serveur distant et à destination dudit serveur distant ou dudit module, respectivement, ladite réponse encapsulant des informations représentatives desdits états ou paramètres dudit équipement.
6 - Procédé selon la revendication 5, caractérisé en ce qu'il comporte une étape de sélection automatique d'un canal de communication entre le module électronique et ledit serveur distant, en fonction de caractéristiques des données à transmettre et des canaux de communications disponibles, au moins l'une des étapes de transmission d'une requête et de réponse à ladite requête étant effectuée en mettant en œuvre le canal de communication sélectionné.
7 - Procédé selon l'une quelconque des revendications 5 ou 6, caractérisé en ce qu'il comporte une étape conservation de l'information à transmettre tant qu'un cycle de requête/réponse complet n'a pas été achevé positivement, afin de pouvoir envoyer, de nouveau, ladite information au travers d'un des autres moyens de communication.
8 - Procédé selon l'une quelconque des revendications 5 à 7, caractérisé en ce que l'un des moyens de communication est un réseau sans-fil de type GSM/GPRS.
EP07731145A 2006-03-15 2007-03-15 Procede et dispositif de communication entre un equipement et un serveur Withdrawn EP2010975A2 (fr)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
FR0602287A FR2898698B1 (fr) 2006-03-15 2006-03-15 Procede de developpement d'une application machine a machine
FR0602286A FR2898697B1 (fr) 2006-03-15 2006-03-15 Procede et dispositif de communication entre un equipement et un serveur
PCT/FR2007/000453 WO2007104868A2 (fr) 2006-03-15 2007-03-15 Procede et dispositif de communication entre un equipement et un serveur

Publications (1)

Publication Number Publication Date
EP2010975A2 true EP2010975A2 (fr) 2009-01-07

Family

ID=38445760

Family Applications (1)

Application Number Title Priority Date Filing Date
EP07731145A Withdrawn EP2010975A2 (fr) 2006-03-15 2007-03-15 Procede et dispositif de communication entre un equipement et un serveur

Country Status (3)

Country Link
US (1) US8484285B2 (fr)
EP (1) EP2010975A2 (fr)
WO (1) WO2007104868A2 (fr)

Families Citing this family (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7596439B2 (en) * 2005-01-20 2009-09-29 General Motors Corporation Method for controlling a remote monitoring device
US8762963B2 (en) * 2008-12-04 2014-06-24 Beck Fund B.V. L.L.C. Translation of programming code
US20100180711A1 (en) 2009-01-19 2010-07-22 Comau, Inc. Robotic end effector system and method
WO2010107872A2 (fr) * 2009-03-17 2010-09-23 Comau, Inc. Système et procédé de communication industriels
KR101850817B1 (ko) 2011-11-17 2018-04-23 삼성전자주식회사 서로 다른 단말에 어플리케이션을 자동으로 설치하는 장치 및 방법
DE102012016824A1 (de) * 2012-06-19 2013-12-19 Robert Bosch Gmbh Verfahren und Vorrichtung zur Erzeugung von Ansteuerbefehlen für eine Automatisierungsvorrichtung
JP5980037B2 (ja) * 2012-08-06 2016-08-31 キヤノン株式会社 管理システム、サーバー、クライアント、及びその方法
JP6054238B2 (ja) * 2013-04-26 2016-12-27 株式会社東芝 電子機器および通信制御方法
US9774982B2 (en) 2013-10-30 2017-09-26 AT&T Intellectual Propetry I, L.P. Long term evolution machine to machine privacy protection
DE102014105075B4 (de) * 2014-04-09 2023-12-07 Krohne Messtechnik Gmbh Verfahren und Kommunikationsanordnung zur Datenkommunikation
US10437241B2 (en) 2016-12-16 2019-10-08 General Electric Company Systems and methods for generating maintenance packages
EP3376319B1 (fr) 2017-03-14 2021-01-06 CODESYS Holding GmbH Procédé et système de configuration automatique d'un contrôleur industriel

Family Cites Families (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2807254B1 (fr) 2000-03-31 2004-08-27 Schneider Automation Systeme d'acces a un ensemble d'automatisme programmable sur une architecture wap
US6640140B1 (en) * 2000-10-10 2003-10-28 Schneider Automation Inc. PLC executive with integrated web server
US7228129B1 (en) * 2001-03-20 2007-06-05 Logical Concepts, Inc. Expert system for monitoring, recording and controlling remote equipment that minimizes wireless telephone airtime
FR2831969B1 (fr) 2001-11-08 2004-01-16 Schneider Automation Systeme de telechargement et de telemaintenance d'une carte electronique
FI20015050A (fi) * 2001-12-13 2003-06-14 Nokia Corp Järjestelmä langattomassa tiedonsiirtoverkossa informaation siirtämiseksi
US8116889B2 (en) * 2002-06-27 2012-02-14 Openpeak Inc. Method, system, and computer program product for managing controlled residential or non-residential environments
US20050021839A1 (en) 2003-06-23 2005-01-27 Russell Thomas C. Method and apparatus for providing a selectively isolated equipment area network for machine elements with data communication therebetween and with remote sites
US20080027679A1 (en) * 2004-07-21 2008-01-31 Dror Shklarski Wearable Device, System and Method for Measuring Physiological and/or Environmental Parameters
FR2881594B1 (fr) 2005-02-01 2007-03-23 Awox Sa Procede et dispositif d'echange de donnees
US8316152B2 (en) * 2005-02-15 2012-11-20 Qualcomm Incorporated Methods and apparatus for machine-to-machine communications
US7224960B2 (en) * 2005-07-12 2007-05-29 Kyocera Wireless Corp. System and method for updating wireless applications

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO2007104868A2 *

Also Published As

Publication number Publication date
US8484285B2 (en) 2013-07-09
WO2007104868A2 (fr) 2007-09-20
US20090216344A1 (en) 2009-08-27
WO2007104868A3 (fr) 2007-11-01

Similar Documents

Publication Publication Date Title
EP2010975A2 (fr) Procede et dispositif de communication entre un equipement et un serveur
US20200413320A1 (en) Management of applications for a device located at a premises
US11227080B2 (en) Industrial automation information contextualization method and system
US11900790B2 (en) Method, system and apparatus for automated reporting of account and sensor zone information to a central station
US8132127B2 (en) System and methodology providing adaptive interface in an industrial controller environment
EP1164756B1 (fr) Système d'accès à un équipement d'automatisme via un réseau de proximité sans fil
EP2728428B1 (fr) Solution de surveillance en nuage
CA2342129C (fr) Systeme d'acces a un ensemble d'automatisme programmable base sur une architecture wap
CN113075909A (zh) 工业数据服务平台
CA2992429A1 (fr) Modele de donnees pour la domotique
EP1726124A1 (fr) Systeme et procede de controle d'equipements a distance a l'aide de commandes at, dispositif, module de radiocommunication et programme correspondants
EP1420316A1 (fr) Communication par messages instantanés (Instant Messaging) pour notification d'événements et l'échange de données en milieu des automates programmables industriels
EP1289226A2 (fr) Equipement d'automatisme connecte a un reseau TCP/IP
FR2898698A1 (fr) Procede de developpement d'une application machine a machine
FR2898697A1 (fr) Procede et dispositif de communication entre un equipement et un serveur
US20170302512A1 (en) Universal control and monitoring of security systems and security components
US11656610B2 (en) Quick connection techniques for skid communicator tool
FR2835673A1 (fr) Equipement d'automatisme communiquant par messagerie instantanee
FR2902271A1 (fr) Procede de commande d'un module electronique de radiocommunication par un equipement, equipement, module, signal et fichier de description correspondants.
FR3038401A1 (fr) Procede de configuration et procede de commande d’un systeme de modules d’execution interconnectes.
EP2086282B1 (fr) Système de communication autoadaptatif
CA3171907A1 (fr) Dispositif monde ouvert de communication avec un systeme avionique, systeme de communication et procede de communication associes
FR2896049A1 (fr) Systeme de teleassistance d'une machine
EP3471346A1 (fr) Procede de generation de requetes pour la segmentation de la surveillance d'un reseau d'interconnexion et materiel associe
FR2955680A1 (fr) Automate de gestion de controle d'acces

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20081010

AK Designated contracting states

Kind code of ref document: A2

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LI LT LU LV MC MT NL PL PT RO SE SI SK TR

AX Request for extension of the european patent

Extension state: AL BA HR MK RS

17Q First examination report despatched

Effective date: 20090610

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20091001