EP3238383A1 - Procédé de traitement de messages montants ou descendants applicatifs en provenance ou à destination d'une unité électronique de contrôle d'une installation domotique par un serveur - Google Patents

Procédé de traitement de messages montants ou descendants applicatifs en provenance ou à destination d'une unité électronique de contrôle d'une installation domotique par un serveur

Info

Publication number
EP3238383A1
EP3238383A1 EP15823712.3A EP15823712A EP3238383A1 EP 3238383 A1 EP3238383 A1 EP 3238383A1 EP 15823712 A EP15823712 A EP 15823712A EP 3238383 A1 EP3238383 A1 EP 3238383A1
Authority
EP
European Patent Office
Prior art keywords
message
electronic control
control unit
application
server
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
EP15823712.3A
Other languages
German (de)
English (en)
Inventor
Sylvain POGNANT
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.)
Overkiz SAS
Original Assignee
Overkiz SAS
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 Overkiz SAS filed Critical Overkiz SAS
Publication of EP3238383A1 publication Critical patent/EP3238383A1/fr
Withdrawn legal-status Critical Current

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/50—Network services
    • H04L67/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
    • H04L67/63—Routing a service request depending on the request content or context
    • 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/2816—Controlling appliance services of a home automation network by calling their functionalities
    • 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/2816—Controlling appliance services of a home automation network by calling their functionalities
    • H04L12/282—Controlling appliance services of a home automation network by calling their functionalities based on user interaction within the home
    • 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/2823—Reporting information sensed by appliance or service execution status of appliance services in a home automation network
    • H04L12/2827—Reporting to a device within the home network; wherein the reception of the information reported automatically triggers the execution of a home appliance functionality
    • 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/283—Processing of data at an internetworking point of a home automation network
    • H04L12/2832—Interconnection of the control functionalities between home networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/12—Applying verification of the received information
    • H04L63/123—Applying verification of the received information received data contents, e.g. message integrity
    • 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/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
    • 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/14—Session management
    • H04L67/141—Setup of application sessions
    • 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/14—Session management
    • H04L67/143—Termination or inactivation of sessions, e.g. event-controlled end of session
    • 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
    • H04L2012/2847—Home automation networks characterised by the type of home appliance used
    • H04L2012/285—Generic home appliances, e.g. refrigerators
    • 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/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
    • H04L67/125—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks involving control of end-device applications over a network

Definitions

  • the present invention relates to a method for processing application upstream messages and application downstream messages between a server and an electronic control unit of a home automation system.
  • connection mechanism between the electronic unit and the server, in order to route the data from the server to the electronic control unit and vice versa.
  • the present invention aims to solve all or part of the disadvantages mentioned above.
  • the present invention relates to a method for processing application uplink messages from an electronic control unit of a home automation installation by a server comprising the following steps:
  • a step of posting an incoming message in the case where the message amount application contains useful data, the incoming message being posted on an incoming queue for processing by an application module, the incoming message comprising useful data determined according to the useful data of the application amount message and an identifier of the electronic control unit;
  • the first processing time of each request varies little as the useful data are posted on a queue for a second asynchronous processing. Following the first processing, or in a maximum predictable or bounded delay, the connection corresponding to the request is released.
  • a large number of electronic control units can communicate with the processing instances of the server that supports the connections, also called connectors, because the connections are released quickly, without waiting for the end of the processing performed asynchronously, which allows to limit the number of concurrent connections and therefore the corresponding resources on the server.
  • This mode of communication is particularly suitable for home automation applications in which a large number of electronic control units are connected to a server with a small volume of data to be exchanged therewith.
  • the term amount relates to the messages transmitted by the electronic unit to the server and that the term descendant concerns the messages transmitted by the server to the electronic control unit.
  • the release of the connection can be made according to the case on the initiative of the server or the electronic control unit.
  • immediate release is meant a release after a complete transmission step.
  • the release also includes the management of the acknowledgment message requested by most connected protocols (acknowledgment or "acknowledge", ACK).
  • acknowledgement for example, in the case of receipt of useful data, after sending the ACK message; in the case of a broadcast, after the receipt of the ACK message.
  • a maximum delay Tmax may be provided before the connection is released, this delay making it possible, for example, to wait for a return of an application module to the incoming message, in the form of a descending message for which a message Application descendant could be transmitted by the server to the electronic control unit.
  • the calculation of the delay Tmax can in particular be performed from the step of establishing a connection, from the posting step, or from a step of receiving an application amount message.
  • an empty response may be sent at the end of the delay Tmax and prior to the release of the connection.
  • An empty response does not contain useful data, but may contain the acknowledgment type (ACK) message relating to the request formed by the amount message.
  • ACK acknowledgment type
  • the application response to the amount message may be communicated during a subsequent connection.
  • the uplink message further comprises an identifier of the processing instance or connector.
  • the method comprises a step of reserving resources by the server for managing the connection.
  • the application amount message corresponds to a request from the electronic control unit.
  • the incoming message includes a processing priority attribute, the posting step being performed in a position different from the queue based on the value of the priority attribute.
  • the method comprises a step of transmitting a descending message to the electronic control unit in response to the application amount message, the descending message comprising previously received useful data or no useful data.
  • the method comprises a step of determining an incoming queue on which the incoming message must be posted, prior to the posting step, the determining step taking into account the identifier of the electronic control unit.
  • the determination step implements for example the use of a hash function.
  • the method comprises a preliminary step of routing the application upstream messages and / or of the connection as a function of the electronic control unit to a processing instance, the correspondence between a processing instance and a electronic control unit being stored in a repository.
  • the routing is performed according to an identifier of the electronic control unit, such as an IP address.
  • the method comprises a subsequent step of collecting at least one message on an incoming queue by a listener in connection with the application module.
  • the method comprises:
  • a second step of receiving a second application amount message subsequently to the first step of receiving a first application amount message by the server from the electronic control unit, prior to the transmission step of an application descendant message, the second application amount message comprising useful data or no useful data;
  • the application downlink message comprising useful data corresponding to a response to a reception of the first application amount message from the electronic control unit.
  • the first step of receiving the first application amount message is performed between a first step establishing a connection between the server and the electronic control unit and a first step of releasing the connection;
  • the second step of receiving the first application amount message and the step of transmitting the application downlink message are performed between a second step of establishing a connection between the server and the electronic control unit, after the first step of releasing the connection and a second releasing step of the connection;
  • the present invention also relates to a method for processing downstream messages to an electronic control unit of a home automation installation by a server comprising the following steps:
  • the step of releasing the connection is performed at the initiative of the server.
  • immediate release means a release after a complete transmission step.
  • the release also includes the management of the acknowledgment message requested by most connected protocols (acknowledgment or "acknowledge", ACK).
  • acknowledgement for example, in the case of receipt of useful data, after sending the ACK message; in the case of a broadcast, after the receipt of the ACK message.
  • a maximum delay Tmax may be provided before the connection is released.
  • the calculation of the delay Tmax can in particular be carried out from the step of establishing a connection, or from a possible step of posting a message on an incoming queue, or even counting a step of receiving a message applicative amount possible.
  • the method comprises a step of transmission by the server to an electronic control unit, according to a first communication protocol, of a connection opening request message to the server ; then a step of accepting the establishment of a connection by the server at the initiative of the electronic control unit according to a second connection protocol;
  • the step of establishing the connection at the initiative of the electronic control unit occurs later in response to the request to open a connection according to a second communication protocol.
  • the establishment of the connection according to the second communication protocol is carried out at the initiative of the electronic control unit to the server, following the request for connection opening formulated by the server according to the first protocol.
  • connection will be authorized by the firewall because it is the initiative of the electronic control unit.
  • the server can then use the connection according to the second protocol to communicate the useful data corresponding to its request to open a connection in the message down.
  • the use of two communication protocols makes it possible to use a simpler first protocol involving a low use of resources on the server, and a second connected protocol involving a greater use of resources only when information must be communicated by the server.
  • the first protocol is a non-connected mode protocol.
  • the second protocol corresponds to a communication in connected mode.
  • the first communication protocol is the UDP protocol.
  • the second communication protocol is the TCP protocol.
  • the first and / or the second protocol may be of the Raw IP or other protocol type above IP.
  • the first protocol used may be of various other types so as not to be subject to the constraints imposed by the firewall.
  • the first communication protocol is a protocol comprising sending a message from the server to the electronic control unit, in particular an SMS message.
  • the first protocol corresponds to data provided in an audio and / or video stream, for example an MPEG stream.
  • the step of transmitting an application downward message to the electronic control unit is performed according to the second communication protocol.
  • the method further comprises a first step of periodically receiving a rising message according to the first communication protocol by the server from the electronic control unit; the first transmission step according to the first communication protocol of a connection opening request message comprising a step of transmitting at least one downward message subsequent to the first reception step.
  • the method further comprises, prior to the first step of transmitting a connection opening request, a step of transmission by the server to the electronic control unit of a server. downlink message corresponding to an accessibility response;
  • the method comprises a step of receiving an application amount message by the server from the electronic control unit, prior to the step of transmitting an application descendant message, the message application amount comprising useful data or no useful data;
  • the application downlink message is accepted by the "firewall" protecting the private network on which the electronic control unit is located because said downstream message is interpreted as a response to a rising message of the electronic control unit. .
  • HTTP HyperText Transfer Protocol
  • HTTPS HyperText Transfer Protocol
  • the server may in a response in the form of a descending message according to the second protocol to communicate the useful data corresponding to its request to open a connection.
  • the method comprises a step of storing useful data included in at least one outgoing message and the identifier of the electronic control unit;
  • the storage step is performed by storing the useful data of one or more outgoing messages corresponding to an identifier of an electronic control unit, the useful data then being transmitted during the step of transmission to the electronic control unit corresponding to the identifier.
  • the storage step is performed until a waiting period or receipt of an application amount message or an establishment of a connection with the electronic control unit.
  • a connection request may be sent by the server to communicate the useful data to the electronic control unit if no connection has been established on the initiative of the latter.
  • the method comprises
  • the downlink application comprising downward payload corresponding to a response to the first application amount message from the electronic control unit.
  • the useful data exchanged up and down during a request and response exchange are not necessarily related to the same application exchange or application transaction between the electronic unit control and an application module, but with different exchanges or transactions.
  • this system makes it possible to take advantage of the exchanges to communicate the present data to be transferred from one side to the other, and to simulate a data exchange in the form of a request and a response, which is a mode of communication accepted by the firewall.
  • the first step of receiving the first application amount message is performed between a first step of establishing a connection between the server and the electronic control unit and a first step of releasing the connection ;
  • the second step of receiving the first application amount message and the step of transmitting the application downlink message are performed between a second step of establishing a connection between the server and the electronic control unit, after the first step of release of the connection and a second step of releasing the connection.
  • the outgoing message comprises useful data generated by an application module following an external event.
  • this system makes it possible to take advantage of the exchanges to communicate the present data to be transferred from one side to the other, and to simulate a data exchange in the form of a request and a response, which is a mode of communication accepted by the firewall.
  • the present invention also relates to a method for processing application uplink messages by an electronic control unit of a home automation installation intended for a server, comprising the following steps:
  • the method comprises a step of receiving an application downlink message by the electronic control unit in from the server, the application downlink message including useful data or no useful data.
  • the application amount message corresponds to a request from the electronic control unit, or else information from a sensor, a log, a response to an order or a request from the server.
  • the present invention also relates to a method of processing application downstream messages by an electronic control unit of a home automation installation from the server comprising the following steps:
  • the method comprises a step of transmitting an application amount message by the electronic control unit to the server, the application amount message comprising useful data or no useful data.
  • the method comprises a first reception step according to a first communication protocol by the electronic control unit of a connection opening request message from the server; the step of establishing a connection to the server being performed at the initiative of the electronic control unit according to a second connection protocol.
  • the method comprises a first step of periodically transmitting a rising message according to the first communication protocol by the electronic control unit to the server, the first step of receiving a message of request to open a connection comprising a reception step according to the first protocol of at least one downlink message subsequent to the first periodic transmission step according to the first communication protocol;
  • the sending of a rising message enables the server to respond to this message with a message that can reach the message.
  • electronic unit as it will be considered as a response to the message amount.
  • the periodic sending of the amount message offers windows of time to the server to communicate connection opening requests.
  • a periodicity of the messages below the window of time allowed by the firewall to respond to a rising message it is possible to permanently maintain a possibility of communication from the server to the electronic control unit, ie ie an open communication channel.
  • a periodic sending makes it possible to know the state of the network link between the electronic control unit and the server.
  • the method comprises, prior to the first step of receiving a connection opening request, a reception step according to the first communication protocol by the electronic control unit of a message. descending from the server corresponding to an accessibility response;
  • the preliminary step and the second step can be simultaneous, successive and / or have a time recovery period.
  • the prior reception step corresponds to the reception of an accessibility response according to a first delay after the transmission step, in order to maintain the possibility of receiving a second frame according to a second delay.
  • the second step corresponds to receiving a connection request during said second delay.
  • the method comprises a step of monitoring at least a delay of reception of a downlink message from the server following the first transmission step, the triggering a new first transmission step being performed in case of exceeding the at least one reception period.
  • the method comprises a step of transmitting an encryption key by the electronic control unit to the server, so as to enable a signature of the upstream and / or downstream messages according to the first communication protocol and / or according to the second communication protocol.
  • the method comprises a step of receiving an invalid or expired key indication from the server, and in response a new step of transmitting an encryption key.
  • the present invention also relates to a computer program product comprising portions of program code for executing the steps of a method for processing upstream messages or downstream messages by a server as described above.
  • the present invention also relates to an electronic control unit of a home automation installation comprising a processing unit arranged to contain and execute the computer program product implementing the steps of the method, the electronic control unit further comprising at least a communication interface for controlling and / or controlling at least one actuator, in particular a movable element of a building, or other equipment that can be controlled or controlled electrically or electronically, such as for example a control system. alarm, or at least one sensor, and a communication interface for communication with a server.
  • the present invention also relates to a computer program product comprising portions of program code for executing the steps of a method for processing upstream messages or downstream messages by an electronic control unit as described above.
  • the present invention also relates to a server for controlling and / or remote control of at least one electronic control unit of a home automation installation comprising a processing unit arranged to contain and execute the computer program product implementing the steps of the method, the server further comprising at least one communication interface intended in particular for the communication according to the first communication protocol or the second communication protocol with at least one electronic control unit.
  • the server may also include a communication interface for communication with a user interface.
  • the user interface may for example be formed by a web server communicating with a user terminal, for example a computer, a mobile phone or a tablet.
  • the present invention also relates to a distributed system comprising at least one server and a plurality of electronic control units arranged to communicate with the server so as to implement the method as described above.
  • Figure 1 is a diagram illustrating the structure of a system for implementing a method of processing application upstream and downstream messages between a server and a set of electronic control units home automation systems.
  • Figure 2 is a diagram illustrating the components of the server processing unit and their interactions.
  • FIG. 3 is a diagram illustrating a mode of implementation of a method for processing the upstream messages.
  • FIG. 4 is a diagram illustrating a mode of implementation of a method of processing the application downstream messages.
  • FIG. 4bis is a diagram illustrating a mode of implementation of a method of processing a plurality of downstream messages and application amounts.
  • Figure 5 is a diagram illustrating a mode of implementation of a data transmission method.
  • Fig. 6 is a diagram illustrating an additional step of the method of Fig. 5.
  • Figure 7 is a diagram illustrating the structure of a second system for implementing a method of data transmission between a server and a set of electronic control units home automation systems.
  • a distributed system comprises at least one server S and a plurality of electronic control units U of home automation installations arranged to communicate with the server S so as to implement a transmission method of data.
  • Each electronic control unit of a home automation system is disposed on a private network PN, PN ', whose access is generally protected by a firewall FW.
  • the server S is also arranged on a private network NS.
  • the private networks PN, PN ', SN are connected to an extended network N, for example the Internet.
  • an electronic control unit U of a home automation installation comprises a processing unit 2 arranged to contain and execute a first computer program or a first set of computer programs.
  • the processing unit 2 comprises a processor, a storage flash memory and a random access memory, and an Ethernet chip PHY.
  • the electronic control unit U furthermore comprises at least one communication interface 3 intended for the control / control of movable element actuators of a building, sensors, or other equipment with electrical or electronic control such as an alarm system.
  • the communication interface 3 allows the control and the control of at least one actuator 5, 5 'of a movable element of a building, for example a roller shutter 6 or a sunshade 6'or still the reception of information of a sensor 7 providing information of a user's presence or values of surrounding parameters such as temperature, humidity, brightness.
  • the interface can allow the control / command of an alarm system 8.
  • the communication interface may comprise a lo-homecontrol and / or Zwave and / or WM-Bus radiofrequency chip communicating at a frequency of 868 MHz, and / or an RTS / RTD / RTD + radio frequency chip communicating at a frequency of 433 MHz. Mhz.
  • the electronic control unit U furthermore comprises a battery and / or a mains power supply, as well as physical connection ports such as, for example, USB host, RJ45 and micro-USB.
  • the electronic control unit U also includes interface elements such as reset buttons, configuration buttons, launch buttons representedrii, and operating indicators, such as LEDs.
  • the electronic control unit U furthermore comprises a communication interface 4 intended for communication according to the first communication protocol PI or the second communication protocol P2 with a server S, such as in particular a network card that can be the Ethernet chip PHY.
  • the server that allows the remote control and / or control of the plurality of electronic control units U of a home automation installation comprises a processing unit 102 arranged to contain and execute a second program or a set of second programs.
  • the server s further comprises at least one communication interface 104 intended for communication according to the first communication protocol PI or the second communication protocol P2 with the plurality of electronic control units U.
  • the server s may also comprise a communication interface 106 intended for communication with a user interface 107.
  • the user interface 107 may for example be formed by a web server communicating with a user terminal 108 via the network N, for example a computer , a cell phone or a tablet.
  • Figure 2 illustrates the components of the server processing unit 102 and their interactions.
  • server is a logical designation that may cover the use of multiple physical servers to distribute the computing load to be performed.
  • One or more MA application modules are running on the server.
  • the application modules MA are intended to process requests from the electronic control units U or to generate commands for the units electronic control U based on external events, such as an order communicated by a user through the terminal 108 connected to the web server 107.
  • the architecture for processing the upstream and downstream messages between the communication interface 104 and the application modules MA comprises a plurality of components, and in particular:
  • a first routing component Rt is a first routing component
  • a Q.M queue manager for managing a plurality of input queues Q.e and an output queue Q.s;
  • a Reg repository for storing associations defined between C-connector instances and U-control electronic units for routing communications.
  • the first routing component is intended to route the messages of the electronic control units U to a connector instance C, in particular according to an identifier of the electronic control unit, such as an IP address.
  • Each connector C makes it possible to manage the connection Cnx and the exchange of data with a plurality of electronic control units U synchronously and to communicate asynchronously by posting or by collecting messages on the incoming queues Qe, and respectively outgoing Qs queue manager Qs.
  • the message handlers H interface between the queues and the application modules MA input and output.
  • the different types of components can be distributed on different physical servers in order to distribute the processing load and to adapt to the number of connections to be processed.
  • an NC number of connector instances an NQ.e number of incoming queues on a queue manager QM, an NH number of message handlers each comprising NLT instances of listeners or LT listener threads on Qe incoming queues, and a NMA number of application modules or application module instances. Since the application concerned must ensure that the sequence of messages from an electronic control unit U is respected, the routing component ensures that communications from an electronic control unit are always routed. to the same C connector instance among the NC connector instances. Similarly, each connector instance C posts the messages in connection with an electronic control unit on the same queues Qe among the NQ.e queues. In this case, a listener or a listener thread must listen on a single queue, to then feed the application modules.
  • the set of connector instances C collect messages on said queue Qs by selecting the messages assigned to them, that is to say containing for example their identifier.
  • FIG. 3 represents the steps of a process for processing application messages Mm originating from an electronic control unit U of a home automation installation by a server S.
  • An application amount message Mm may correspond to a request from the electronic control unit, or information from a sensor, a log, a response to an order or a request from the server.
  • a storing step EMU0 identification data Rqid of useful data PIm is performed by the electronic control unit U in order to correlate the said PIm payload with payload Pld of a subsequent downstream message. If the amount message does not correspond to a request to be answered by the server S, this step can be omitted.
  • An establishment step EMU1 of a connection Cnx to the server S is then performed at the initiative of the electronic control unit U accepted by the server s in a step EMC1.
  • This connection is for example made according to the TCP communication protocol.
  • a resource reservation is performed by the server S for the management of the connection.
  • a routing step ERtM1 of the communication to a connector instance C as a function of the electronic control unit U is performed, the correspondence between a processing instance C and a electronic control unit U being stored in the repository Reg.
  • the routing is performed according to an identifier of the electronic control unit, such as an IP address.
  • an EMU2 transmission step of an application amount message Mm is performed by the electronic control unit U, the message being received by a connector instance C in a step EMC2.
  • the rising message Mm comprises useful data Plm and an identifier Uid of the electronic control unit U.
  • the connector instance C then performs a step EMC3 determination of an incoming queue Q.e, on which an incoming message Me must be posted.
  • This determination step takes into account the identifier of the electronic control unit Uid, for example by implementing the use of a hash function on the basis of the identifier Uid.
  • an EMC4 posting step of an incoming message Me is performed.
  • the useful data Plm of the incoming message Me are determined according to the useful data Plm, the application amount message Mm. In particular, it can be a copy of this useful data Plm.
  • the posting is performed on the incoming queue Q.e for processing by an application module MA.
  • the incoming message Me comprises, in addition to the useful data Plm, an identifier of the electronic control unit Uid and an identifier Cid of the connector instance C.
  • the incoming message may also include a processing priority attribute, the posting step being performed in a position different from the Q.e queue depending on the value of the priority attribute in order to change its processing order.
  • An EMC7 monitoring step of maximum delay Tmax is performed by the connector before the release of the Cnx connection, this delay allowing, for example, waiting for an application module to return to the incoming message, in the form of a message downlink for which an application downlink message could be transmitted by the server to the electronic control unit.
  • the calculation of the delay Tmax can notably be carried out starting from the step of establishing an EMC1 connection, starting from the posting step EMC3, or starting from a step of receiving an application amount message. EMC2.
  • the delay Tmax is counted from the posting step EMC4.
  • the connector performs a step EMC8 transmission of a Md downlink message to the electronic control unit U which receives it in a step EMU8, in response to the message Mm application amount.
  • the downlink message Md can include:
  • the downlink message will include either payload data Pld corresponding to another application exchange than that involving the amount message; or no useful data.
  • An EMC9 release step of the connection Cnx is then performed by the connector C and found in a step EMU9 by the electronic control unit U.
  • a listener instance H performs an EMH5 collection of at least one incoming message Me on an incoming queue Q.e.
  • the listener H can then communicate the content of the message to an application module MA in an EMMA6 step.
  • the application module then performs the processing of the incoming message Me.
  • the application modules MA are intended to process the requests coming from the electronic control units U or to generate commands intended for the electronic control units U on the external events database, such as an order communicated by a user via the terminal 108 connected to the web server 107.
  • the application modules MA communicate in a step EDMAl data useful to a transmission thread AND a message manager H, specifying the electronic control unit U recipient of this payload data Pld.
  • the message manager H sets on the outgoing queue Qs of the queue manager QM an outgoing message Ms comprising an identifier of an electronic control unit Uid, an identifier of a connector Cid and useful data Pld.
  • Determining the identifier of the connector Cid is performed by interrogating the repository Reg to determine if the electronic control unit is associated with a connector or a connector instance C.
  • the outgoing message Ms may also include a processing priority attribute Pr, the posting step being performed in a position different from the queue Qs according to the value of the priority attribute in order to modify its order of priority. treatment.
  • the method then comprises an EDC3 collection step of an outgoing message Ms on an outgoing queue Q.s coming from an application module MA.
  • the outgoing Ms messages may include useful data Pld corresponding to a response to a previous incoming message Me posted following receipt of a message amount Mm from the electronic control unit U or the payload data Pld generated by a application module MA following an external event.
  • the storage step EDC4 is performed by storing the user data Pld of one or more outgoing Ms messages corresponding to a Uid identifier of an electronic control unit U until a waiting time expires Twait or reception an application amount message Mm.
  • an EDU5 / EDC5 establishment step of a connection Cnx between the server S and the electronic unit of U control corresponding to the identifier of the electronic unit of Uid control included in the Ms outgoing message is performed.
  • This step corresponds either to the establishment of a connection at the initiative of the electronic control unit which has useful data to transmit or to the establishment of a connection at the initiative of the electronic unit. control after a request to establish a connection by the connector as will be detailed later,
  • a rising message Mm is transmitted in a step EDU6 by the electronic control unit U and received by the server s in a step EDC6, the rising message Mm comprising useful data Plm or none useful data.
  • An application downlink message Md is then transmitted in a step EDC8 to the electronic control unit U which receives it in a step EDU8, the application downlink message Md comprising useful data PLd determined from the payload data Pld of the outgoing message (s). Ms stored in step EDC4.
  • An EDC7 monitoring step of maximum delay Tmax can be optionally performed by the connector before the release of the Cnx connection.
  • the calculation of the delay Tmax can in particular be carried out from the step of establishing an EDC5 connection, from a possible postage step to an incoming queue, or from a reception step of an EDC6 application amount message.
  • the delay T max is counted from the step of receiving an application amount message EDC 6.
  • the release of the connection can be provided immediately.
  • an EDC9 release step of the connection Cnx is performed, for example at the initiative of the server.
  • the control unit U can then carry out a verification step EDU10 of the correspondence of the payload data P1 received with a prior request corresponding to a transmission of a rising message Md by using identification data Rqid of the stored payload data Plm.
  • EMU1 / EMC1 or EDU5 / EDC5 connection establishment steps EMU2 / EMC2, EDU6 / EDC6 upstream application message exchange and EMU8 / EMC8, EDU8 / EDC8, and EMU9 connection release transactions, EMC9 may be common to both processes.
  • EMC9 may be common to both processes.
  • several EDC3 and EDC4 storage steps can be performed while waiting for the establishment of a Cnx connection.
  • upstream and downstream useful data flowing during a request and response exchange do not necessarily correspond to the same application exchange between the electronic control unit.
  • U and an application module MA do not necessarily correspond to the same application exchange between the electronic control unit.
  • U and an application module MA do not necessarily correspond to the same application exchange between the electronic control unit.
  • U and an application module MA but with different exchanges.
  • this system makes it possible to take advantage of the exchanges to communicate the present data to be transferred from one side to the other, and to simulate a data exchange in the form of a request and a response, which is a mode of communication accepted by the FW firewall.
  • FIG. 4bis shows a method of processing application upstream and downstream messages in which several connection steps EDU5a / EDC5a, EDU5b / EDC5b and EDU5c / EDC5c and several disconnection steps EDU9a / EDC9a, EDU9b / EDC9b and EDU9c / EDC9c are carried out, an upstream message Mml, Mm2, Mm3 and an application downlink message Md1, Md2, Md3 being exchanged as part of each of these connections during transmission steps EDU6a, EDU6b, EDU6c and reception EDC6a, EDC6b, EDC6c messages application and reception amounts EDU8a, EDU8b, EDU8c and EDC8a, EDC8b, EDC8c transmission of respective downstream messages.
  • FIG. 4bis illustrates an example in which two X, Y application transactions involving a request and an application response are performed.
  • the X and Y transactions correspond to requests from the electronic control unit to which the server must respond.
  • the first application message amount Mml includes useful data PlmX corresponding to the request of the transaction X.
  • the first downlink message Md1 does not include any useful data or empty payload represented by PldO.
  • the second application message amount Mm2 includes useful data PlmY corresponding to the request of the transaction Y.
  • the second downlink message Md2 comprises useful data PldX corresponding to the response of the transaction X.
  • the third application message amount Mm3 does not include useful data, which is represented by Plmfl.
  • the downlink message Md2 comprises useful data PldX corresponding to the response of the transaction X.
  • the useful data exchanged upstream and downstream during an upstream and downstream message exchange are not necessarily relative to the same application exchange or transaction between the electronic control unit and an application module, but with different exchanges or transactions.
  • the correlation can be performed on the side of the electronic control unit with the identification data Rqid useful data Plm corresponding to an application transaction.
  • the two methods of processing the upstream and downstream application messages involve the establishment of a connection Cnx between one of the electronic control units U and the server S. Since the electronic control unit U is located on a network Private PN protected by a firewall, the exchange of data between the server and the plurality of electronic control units must take into account the presence of this firewall. In particular, the establishment of a connection at the initiative of a server outside the private network is usually prohibited by a firewall or can be made difficult by the use of address translation mechanism (NAT ).
  • NAT address translation mechanism
  • the present invention implements a method of data transmission allowing in particular the transmission of application messages from the server S to an electronic control unit U.
  • FIG. 5 represents a diagram of implementation of the data transmission methods executed on the server S, in particular by a connector C and on an electronic control unit U of a home automation system I.
  • the method comprises a first phase PhO for negotiating a secret key, a second phase Phi produced according to the first communication protocol intended to collect a connection request from the client. server S and a third phase Ph2 data transmission following the establishment of a connection according to the second communication protocol at the initiative of the electronic control unit.
  • the negotiation phase of a secret key PhO comprises a step EO transmission of an encryption key in a message Mkey by the electronic control unit U to the server S which receives it during a step EO ', so to enable a signature of the upstream and / or downstream messages according to the first communication protocol PI and / or according to the second communication protocol P2.
  • the encryption key may in particular be chosen randomly by the electronic control unit U.
  • the server acknowledges receipt of the key and validates that it has taken into account the new key by a MkeyAck downlink message transmitted in a step ⁇ which is received by the electronic control unit U during a reception step El.
  • the exchanges between the electronic control unit U during the negotiation phase can be performed according to a communication protocol that is different from or similar to the first communication protocol and the second communication protocol PI and P2.
  • a communication protocol that is different from or similar to the first communication protocol and the second communication protocol PI and P2.
  • HTTPS type protocol can be chosen which makes it possible to communicate the key in a secure manner.
  • this exchange is not carried out frequently, and therefore does not represent a significant consumption of resources. For example, a periodicity of several days can be provided for the validity of the keys.
  • the second phase of communication Phi according to the first protocol PI comprises a first step E2 periodic transmission of a message Mping up according to the first communication protocol PI by the electronic control unit U to the server S which receives it in a step E2 '.
  • a periodicity of the order of ten seconds can be provided for the periodicity of the transmission, and in particular of the order of 20s.
  • the server S transmits in a step E4 'a Mpong downlink message to the electronic control unit U which is received in a prior reception step E4 within a first delay Drl short after transmission of the Mping amount message.
  • the delay Drl can be of the order of a few seconds, and in particular of the order of 5 s.
  • This first message Mpong down keeps the communication channel open for a second delay Dr2 greater than the first delay Drl. It appears that the operation of a conventional firewall can prevent the passage of a downlink message to the extent that it is received beyond a first time after sending a rising message. Also in the usual way, since a first descendant message is received, a second, larger delay is allowed to receive one or more other descendant messages. In particular, it is possible to choose to trigger a new transmission of the message Mping before the expiry of the delay Dr2.
  • the server S transmits according to the first communication protocol PI during a step E5 'a request message D Mopen connection opening, which is received by the electronic control unit U during a step E5.
  • the second communication phase Phi according to the first protocol PI comprises a monitoring step E3 of a reception delay Dr of a downlink message from the server S following the first transmission step Mping, the triggering of a new first E2 transmission step being performed in case of exceeding the reception time.
  • the server can perform a transmission step ERO 'of an invalid or expired key indication Minvalidkey from the server S , and in response a new step of transmitting an encryption key E0.
  • this situation can occur during the transmission of a message amount MPing, the server having found that the message has a correct format but is not signed with a valid key. It should be noted that in case of restart of the electronic control unit, the first phase of communication PhO with communication of the key is carried out again.
  • the first communication protocol may in particular be the UDP protocol.
  • the third phase Ph2 of the method is performed following the reception of the connection opening request received by the electronic control unit in the second phase in step E5.
  • an establishment step E6 of a connection Cnx to the server S which accepts this connection in a corresponding step E6 'is performed, on the initiative of the electronic control unit U according to a second protocol of P2 connection.
  • the communication protocol may be the TCP protocol.
  • the establishment step E6 may comprise several exchanges between the server and the unit U, and in particular exchanges of connection management messages, such as the TCP SYN, SYN / ACK, ACK protocol messages.
  • a transmission step E7 of an amount message Mm is carried out according to the second communication protocol P2 intended for the server S which receives this message in a step E7 '.
  • the message Mm may be a message without useful data but constituting an amount message to which a response will be provided by the server.
  • the server transmits a downlink message Md in a transmission step E8 'to the electronic control unit U.
  • This downward message contains the payload data Pld that the server was to transmit to the electronic control unit U.
  • the second communication protocol used may be in particular the TCP protocol.
  • the exchanges of the steps E7 / E7 'and E8 / E8' can in particular be made in the form of a request and a response according to the HTTPS protocol that uses TCP.
  • the release of the connection can take place after several exchanges of uplink messages and / or messages receiving messages according to the second communication protocol or after a specified delay after the step of establishing the connection. E6 communication.
  • the steps of establishing the connection E6 and accepting this connection E6 'can respectively correspond to the steps of establishing an EDU5 and EDC5 connection described with reference to FIG. 4 for the method of transmitting application downstream messages.
  • the transmission steps of an application amount message E7 and reception E7 'can respectively correspond to the transmission and reception steps EDU6 and EDC6 described with reference to FIG. 4 for the method for transmitting application downstream messages.
  • the transmission steps of an Md E8 and E8 'downstream application message may respectively correspond to the transmission and reception steps EDC8 and EDU8 described with reference to FIG. 4 for the method for transmitting application downstream messages.
  • the first communication protocol is an SMS-type protocol comprising sending a message from the server to the electronic unit.
  • U control identified in this case by a telephone number.
  • This second protocol is used on a N2 type telephone network, for example a GSM network or wired telephony over the Internet, with a digital message management function.
  • the server s comprises for this purpose a communication interface 107 on the network N2, such as for example a GSM card, just like the electronic control unit, which also comprises a communication interface 7 on the network N2, such as a GSM card. or an internet telephony hardware and software module that can be integrated into the firewall or the electronic control unit U.
  • a communication interface 107 on the network N2 such as for example a GSM card, just like the electronic control unit, which also comprises a communication interface 7 on the network N2, such as a GSM card. or an internet telephony hardware and software module that can be integrated into the firewall or the electronic control unit U.
  • the exchange according to the first protocol and the step of receiving a connection opening request corresponds to a simple sending of SMS between the server S and the electronic control unit U.
  • FIG. 7 represents only an electronic control unit, but this second embodiment of course applies to communication with a multitude of electronic control units.
  • the first protocol used may be of various types making it possible not to be subject to the constraints imposed by the firewall.
  • the first protocol corresponds to data provided in an audio and / or video stream, for example an MPEG stream.
  • the electronic control unit U comprises or is associated with a decoding interface of the corresponding audio and / or video stream.
  • the first and / or the second protocol may be Raw IP type or other protocol above IP.
  • the application exchanges may follow the transaction model, comprising a request and a response. Queries are sent as upstream messages, and responses as descendant messages. So, in a request and response exchange in the form of a rising or falling message, only the response or only the request may contain useful data. A rising message and the downstream message sent back may contain useful data that does not necessarily correspond to the same transaction. For example, a request in progress requiring an application processing is transmitted in the form of a rising message, and may trigger the transmission of a downlink message without useful data, or containing useful data relating to a previous request. In the same way, the application response corresponding to the current request can be sent during a subsequent message sinking message / subsequent message exchange. This exchange may include a rising message without useful data.
  • the transmission of data in the sense of the electronic control unit to the server can be achieved for example according to the second communication protocol without difficulty since it is possible to establish a connection directly at the initiative of the electronic control unit.
  • a request and a response according to the HTTPS protocol can be performed, then the established connection released to limit the use of server resources.
  • IP network layer
  • This protocol must provide the application a reliable "transport” service in so-called “connected” mode between the server and each of the electronic control units.
  • the resources reserved to provide a transport service in connected mode are important, because for each connection it is necessary to reserve buffers for the incoming data, but also for the outgoing data, because it is necessary to keep messages already transmitted, but not yet paid, to avoid their loss and to allow their eventual retransmission.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Automation & Control Theory (AREA)
  • Computing Systems (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Human Computer Interaction (AREA)
  • Health & Medical Sciences (AREA)
  • General Health & Medical Sciences (AREA)
  • Medical Informatics (AREA)
  • Computer And Data Communications (AREA)

Abstract

La présente invention concerne un procédé de traitement de messages montants applicatifs en provenance d'une unité électronique de contrôle (U) d'une installation domotique par un serveur(S) comprenant les étapes suivantes: -une étape d'établissement(EMC1) d'une connexion (Cnx) entre le serveur(S) et l'unité électronique de contrôle(U);une étape de réception (EMC2) d'un message montant applicatif (Mm) par le serveur(S) en provenance de l'unité électronique de contrôle(U); -une étape de postage(EMC4) d'un message entrant(Me), dans le cas ou le message montant applicatif contient des données utiles(Plm), le message entrant(Me) étant posté sur une file d'attente entrante(Qe) en vue d'un traitement par un module applicatif (MA), le message entrant(Me) comprenant des données utiles(Plm) déterminées en fonction des données utiles(Pld) du message montant applicatif (Mm) et un identifiant de l'unité électronique de contrôle(Uid); -une étape de libération(EMC9) de la connexion(Cnx) de façon immédiate ou suite à un délai maximal(Tmax);

Description

Procédé de traitement de messages montants ou descendants applicatifs en provenance ou à destination d'une unité électronique de contrôle d'une installation domotique par un serveur
La présente invention concerne un procédé de traitement de messages montants applicatifs et de messages descendants applicatifs entre un serveur et une unité électronique de contrôle d'une installation domotique.
Il est connu de procéder à des échanges de données entre un serveur et un ensemble d'unité électronique de contrôle d'une installation domotique. Il peut être souhaitable de procéder à ces échanges de données notamment pour opérer un contrôle à distance des installations par le serveur, par exemple dans le cas où le serveur reçoit des instructions d'une interface utilisateur permettant à l'utilisateur de contrôler à distance son installation.
En conséquence, il est possible d'utiliser un mécanisme de connexion entre l'unité électronique et le serveur, afin d'acheminer les données du serveur à l'unité électronique de contrôle et inversement. Il apparaît toutefois que dans le cas d'applications domotiques dans lequel un nombre très important d'unité électroniques de contrôle communiquent avec un serveur, cela conduit à une utilisation importante de ressources réseau ou ressources mémoire sur le serveur qui doit maintenir les données relatives à l'ensemble des connexions correspondant à chaque unité électronique.
La présente invention a pour but de résoudre tout ou partie des inconvénients mentionnés ci-dessus.
A cet effet, la présente invention concerne un procédé de traitement de messages montants applicatifs en provenance d'une unité électronique de contrôle d'une installation domotique par un serveur comprenant les étapes suivantes :
une étape d'établissement d'une connexion entre le serveur et l'unité électronique de contrôle ;
- une étape de réception d'un message montant applicatif par le serveur en provenance de l'unité électronique de contrôle;
une étape de postage d'un message entrant, dans le cas ou le message montant applicatif contient des données utiles, le message entrant étant posté sur une file d'attente entrante en vue d'un traitement par un module applicatif, le message entrant comprenant des données utiles déterminées en fonction des données utiles du message montant applicatif et un identifiant de l'unité électronique de contrôle ;
une étape de libération de la connexion de façon immédiate ou suite à un délai maximal ;
Grâce aux dispositions selon l'invention, le temps de premier traitement de chaque requête varie peu étant donné que les données utiles sont postées sur une file d'attente en vue d'un deuxième traitement asynchrone. Suite au premier traitement, ou dans un délai maximal prévisible ou borné, la connexion correspondant à la requête est libérée.
Ainsi, un nombre important d'unité électroniques de commandes peuvent communiquer avec les instances de traitement du serveur prenant en charge les connexions encore appelé connecteurs, car les connexions sont libérées rapidement, sans attendre la fin du traitement réalisé de façon asynchrone, ce qui permet de limiter le nombre de connexions concurrentes et donc les ressources correspondantes sur le serveur.
Ce mode de communication est notamment adapté aux applications domotiques dans lesquelles un grand nombre d'unités de contrôle électronique sont connectées à un serveur avec un faible volume de données à échanger avec celui-ci.
Il est à noter que le terme montant concerne les messages transmis par l'unité électronique vers le serveur et que le terme descendant concerne les messages transmis par le serveur vers l'unité électronique de contrôle.
La libération de la connexion peut être réalisée selon les cas à l'initiative du serveur ou de l'unité électronique de contrôle.
On entend par libération immédiate, une libération après une étape complète de transmission. En particulier, la libération comprend aussi la gestion du message d'acquittement demandé par la plupart des protocoles connectés (accusé de réception ou « acknowledge », ACK). Ainsi, a titre d'exemple, dans le cas d'une réception de données utiles, après l'envoi du message ACK ; dans le cas d'une émission, après la réception du message ACK.
Selon une autre possibilité, un délai maximal Tmax peut être prévu avant la libération de la connexion, ce délai permettant par exemple d'attendre un retour d'un module applicatif au message entrant, sous la forme d'un message descendant pour lequel un message descendant applicatif pourrait être transmis par le serveur à destination de l'unité électronique de commande. Le calcul du délai Tmax peut être notamment réalisé à partir de l'étape d'établissement d'une connexion, à partir de l'étape de postage, ou encore à compter d'une étape de réception d'un message montant applicatif.
Si le protocole applicatif prévoit l'envoi d'un message descendant en réponse au message entrant, une réponse vide peut être envoyée au terme du délai Tmax et préalablement à la libération de la connexion. Une réponse vide ne contient pas de données utiles, mais peut contenir le message de type accusé de réception (ACK) relatif à la requête formée par le message montant.
Dans le cas d'un message montant correspondant à une requête, la réponse applicative au message montant pourra être communiquée lors d'une connexion ultérieure.
Selon un aspect de l'invention, le message montant comprend en outre un identifiant de l'instance de traitement ou connecteur.
Selon un aspect de l'invention, le procédé comprend une étape de réservation de ressources par le serveur pour la gestion de la connexion.
Selon un aspect de l'invention, le message montant applicatif correspond à une requête en provenance de l'unité électronique de contrôle.
Selon un aspect de l'invention, le message entrant comprend un attribut de priorité de traitement, l'étape de postage étant réalisée dans une position différente de la file d'attente en fonction de la valeur de l'attribut de priorité.
Selon un aspect de l'invention, le procédé comprend une étape de transmission d'un message descendant à l'unité électronique de contrôle en réponse au message montant applicatif, le message descendant comprenant des données utiles reçues préalablement ou aucunes données utiles.
Ces dispositions permettent de tirer partie de la connexion établie pour communiquer des données utiles à l'unité électronique de contrôle.
Selon un aspect de l'invention, le procédé comprend une étape de détermination d'une file d'attente d'entrante sur laquelle le message entrant doit être posté, préalablement à l'étape de postage, l'étape de détermination prenant en compte l'identifiant de l'unité électronique de contrôle.
Ces dispositions permettent de répartir les messages entrants sur plusieurs files d'attentes entrantes, tout en garantissant que les messages en provenance d'une même unité électronique de contrôle sont traités sur une même file d'attente, et que la séquence des messages en provenant de ladite unité électronique de contrôle est ainsi respectée. Selon un aspect de l'invention, l'étape de détermination met en œuvre par exemple l'utilisation d'une fonction de hachage.
Selon un aspect de l'invention, le procédé comprend une étape préalable de routage des messages montants applicatifs et/ou de la connexion en fonction de l'unité électronique de contrôle vers une instance de traitement, la correspondance entre une instance de traitement et une unité électronique de contrôle étant mémorisée dans un référentiel.
Ces dispositions permettent de répartir les messages montants en provenance de la pluralité d'unité électroniques de commandes sur une pluralité d'instances de traitement ou plusieurs instances de connecteurs.
Selon un aspect de l'invention le routage est effectué en fonction d'un identifiant de l'unité électronique de contrôle, comme par exemple une adresse IP.
Selon un aspect de l'invention, le procédé comprend une étape postérieure de collecte d'au moins un message sur une file d'attente entrante par un écouteur en lien avec module applicatif.
Ces dispositions permettent de réaliser un traitement asynchrone des messages montants, même dans le cas où il s'agit d'une requête en provenance d'une unité électronique de contrôle.
Selon un aspect de l'invention, le procédé comprend :
- une première étape de réception d'un premier message montant applicatif par le serveur en provenance de l'unité électronique de contrôle, préalablement à l'étape de transmission d'un message descendant applicatif, le premier message montant applicatif comprenant des données utiles; et
- une deuxième étape de réception d'un second message montant applicatif, ultérieurement à la première étape de réception d'un premier message montant applicatif par le serveur en provenance de l'unité électronique de contrôle, préalablement à l'étape de transmission d'un message descendant applicatif, le second message montant applicatif comprenant des données utiles ou aucune donnée utile;
le message descendant applicatif comprenant des données utiles correspondant à une réponse à une réception du premier message montant applicatif en provenance de l'unité électronique de contrôle.
Selon un aspect de l'invention, la première étape de réception du premier message montant applicatif est réalisée entre une première étape d'établissement d'une connexion entre le serveur et l'unité électronique de contrôle et une première étape de libération de la connexion ;
la deuxième étape de réception du premier message montant applicatif et l'étape de transmission du message descendant applicatif sont réalisées entre une seconde étape d'établissement d'une connexion entre le serveur et l'unité électronique de contrôle, postérieure à la première étape de libération de la connexion et une seconde étape de libération de la connexion ;
La présente invention a également pour objet un procédé de traitement de messages descendants à destination d'une unité électronique de contrôle d'une installation domotique par un serveur comprenant les étapes suivantes :
Une étape de collecte d'un message sortant sur une file d'attente sortante en provenance d'un module applicatif, le message sortant comprenant un identifiant d'une unité électronique de contrôle et des données utiles ;
- une étape d'établissement d'une connexion entre le serveur et l'unité électronique de contrôle correspondant à l'identifiant de l'unité électronique de contrôle comprise dans le message sortant ;
une étape de transmission d'un message descendant applicatif à l'unité électronique de contrôle, le message descendant applicatif (Md) comprenant des données utiles déterminées à partir des données utiles du message sortant ;
une étape de libération de la connexion de façon immédiate ou suite à un délai maximal ;
Selon un aspect de l'invention, l'étape de libération de la connexion est réalisée à l'initiative du serveur.
Comme nous l'avons détaillé précédemment, on entend par libération immédiate, une libération après une étape complète de transmission. En particulier, la libération comprend aussi la gestion du message d'acquittement demandé par la plupart des protocoles connectés (accusé de réception ou « acknowledge », ACK). Ainsi, a titre d'exemple, dans le cas d'une réception de données utiles, après l'envoi du message ACK ; dans le cas d'une émission, après la réception du message ACK.
Selon une autre possibilité, un délai maximal Tmax peut être prévu avant la libération de la connexion. Le calcul du délai Tmax peut être notamment réalisé à partir de l'étape d'établissement d'une connexion, ou encore à partir d'une étape éventuelle de postage d'un message sur une file d'attente entrante, ou encore à compter d'une étape de réception d'un message montant applicatif éventuel. Selon un aspect de l'invention, le procédé comprend une étape de transmission par le serveur à destination d'une unité électronique de contrôle, selon un premier protocole de communication, d'un message de demande d'ouverture de connexion à destination du serveur ; puis une étape d'acceptation de l'établissement d'une connexion par le serveur à l'initiative de l'unité électronique de contrôle selon un deuxième protocole de connexion ;
Ainsi, l'étape d'établissement de la connexion à l'initiative de l'unité électronique de contrôle intervient ultérieurement en réponse à la demande d'ouverture de connexion selon un second protocole de communication.
Grâce à ces dispositions, l'établissement de la connexion selon le deuxième protocole de communication est réalisé à l'initiative de l'unité électronique de contrôle vers le serveur, suite à la demande d'ouverture de connexion formulée par le serveur selon le premier protocole.
Ainsi, l'établissement de la connexion sera autorisé par le pare-feu, car elle est à l'initiative de l'unité électronique de contrôle. Le serveur pourra ensuite utiliser la connexion selon le deuxième protocole pour communiquer les données utiles correspondant à sa demande d'ouverture de connexion dans le message descendant.
Ces dispositions permettent de réaliser la communication d'informations entre le serveur et l'unité électronique de façon descendante en utilisant uniquement un établissement de connexion à l'initiative de l'unité électronique de contrôle.
Par ailleurs, l'utilisation de deux protocoles de communication permet d'utiliser un premier protocole plus simple impliquant une utilisation de ressources faible sur le serveur, et un deuxième protocole connecté impliquant une utilisation plus importante de ressource uniquement lorsque des informations doivent être communiquées par le serveur.
En particulier, le premier protocole est un protocole en mode non connecté. Le deuxième protocole correspond à une communication en mode connecté.
Selon un aspect de l'invention, le premier protocole de communication est le protocole UDP.
Selon un aspect de l'invention, le deuxième protocole de communication est le protocole TCP.
Selon un autre aspect de l'invention, le premier et/ou le deuxième protocole peuvent être de type Raw IP ou autre protocole au dessus d'IP. Le premier protocole utilisé peut être de divers autres types permettant de ne pas être soumis aux contraintes imposées par le pare-feu.
Selon un mode de réalisation, le premier protocole de communication est un protocole comprenant l'envoi d'un message du serveur vers l'unité électronique de contrôle, notamment un message SMS.
Selon un autre mode de réalisation, le premier protocole correspond à une donnée fournie dans un flux audio et/ou vidéo, par exemple un flux MPEG.
Selon un aspect de l'invention, l'étape de transmission d'un message descendant applicatif à l'unité électronique de contrôle est réalisée selon le deuxième protocole de communication.
Selon un aspect de l'invention, le procédé comprend en outre une première étape de réception périodique d'un message montant selon le premier protocole de communication par le serveur en provenance de l'unité électronique de contrôle ; la première étape de transmission selon le premier protocole de communication d'un message de demande d'ouverture de connexion comprenant une étape de transmission d'au moins un message descendant ultérieur à la première étape de réception.
Selon un aspect de l'invention, le procédé comprend en outre, préalablement à la première étape de transmission d'une demande d'ouverture de connexion, une étape de transmission par le serveur à destination de l'unité électronique de contrôle d'un message descendant correspondant à une réponse d'accessibilité ;
Selon un aspect de l'invention, le procédé comprend une étape de réception d'un message montant applicatif par le serveur en provenance de l'unité électronique de contrôle, préalablement à l'étape de transmission d'un message descendant applicatif, le message montant applicatif comprenant des données utiles ou aucune donnée utile;
Ces dispositions permettent de tirer partie de la connexion établie pour communiquer des données utiles à l'unité électronique de contrôle.
Par ailleurs, le message descendant applicatif est accepté par le « pare- feu » protégeant le réseau privé sur lequel se trouve l'unité électronique de contrôle car ledit message descendant est interprété comme une réponse à un message montant de l'unité électronique de contrôle.
Ces dispositions permettent de réaliser la communication d'informations entre le serveur et l'unité électronique de façon descendante en utilisant un mode de requêtes et réponses sous formes de messages montants et descendants à l'initiative de l'unité électronique de contrôle.
A titre d'exemple, une communication de type HTTP ou HTTPS peut être mise en œuvre.
II est à noter que les messages montants ne contiennent pas tous nécessairement des données utiles. Ainsi, dans un échange de requête et réponse sous forme d'un message montant et descendant, seule la réponse peut contenir des données utiles.
Ainsi, en réponse au message montant (éventuellement vide) de l'unité de contrôle électronique, le serveur pourra dans une réponse sous forme de message descendant selon le deuxième protocole communiquer les données utiles correspondant à sa demande d'ouverture de connexion.
Selon un aspect de l'invention, le procédé comprend une étape de mémorisation de données utiles comprises dans au moins un message sortant et de l'identifiant de l'unité électronique de contrôle ;
Selon un aspect de l'invention, l'étape de mémorisation est réalisée en mémorisant les données utiles d'un ou de plusieurs messages sortant correspondant à un identifiant d'une unité électronique de contrôle, les données utiles étant ensuite transmises lors de l'étape de transmission à l'unité électronique de contrôle correspondant à l'identifiant.
Selon un aspect de l'invention, l'étape de mémorisation est réalisée jusqu'à expiration d'un délai d'attente ou réception d'un message montant applicatif ou à un établissement d'une connexion avec l'unité électronique de contrôle. A l'expiration du délai d'attente, une demande de connexion peut être envoyée par le serveur pour communiquer les données utiles à l'unité électronique de commande si aucune connexion n'a été établie à l'initiative de celle-ci.
Selon un aspect de l'invention, le procédé comprend
une première étape de réception (EDC6a) d'un premier message montant applicatif par le serveur en provenance de l'unité électronique de contrôle, préalablement à l'étape de transmission d'un message descendant applicatif, le premier message montant applicatif comprenant des premières données utiles montantes; et une deuxième étape de réception (EDC6b) d'un second message montant applicatif, ultérieurement à la première étape de réception d'un premier message montant applicatif par le serveur en provenance de l'unité électronique de contrôle, préalablement à l'étape de transmission d'un message descendant applicatif, le second message montant applicatif comprenant des secondes données utiles montantes ou aucune donnée utile;
le message descendant applicatif comprenant des données utiles descendantes correspondant à une réponse au premier message montant applicatif en provenance de l'unité électronique de contrôle.
Grâce à ces dispositions, les données utiles échangées montantes et descendantes lors d'un échange de requête et de réponse, par exemple selon le protocole http(S), ne sont pas nécessairement relatives au même échange applicatif ou transaction applicative entre l'unité électronique de contrôle et un module applicatif, mais à des échanges ou transactions différentes.
L'utilisation de ce système permet de tirer partie des échanges pour communiquer les données présentes à transférer de part et d'autre, et de simuler un échange de données sous forme de requête et de réponse, ce qui est un mode de communication accepté par le pare-feu.
Selon un aspect de l'invention, la première étape de réception du premier message montant applicatif est réalisée entre une première étape d'établissement d'une connexion entre le serveur et l'unité électronique de contrôle et une première étape de libération de la connexion ; la deuxième étape de réception du premier message montant applicatif et l'étape de transmission du message descendant applicatif sont réalisées entre une seconde étape d'établissement d'une connexion entre le serveur et l'unité électronique de contrôle, postérieure à la première étape de libération de la connexion et une seconde étape de libération de la connexion.
Selon un aspect de l'invention, le message sortant comprend des données utiles générées par un module applicatif suite à un événement extérieur.
Il est à noter que selon les deux procédés de traitement des messages montants et descendants selon l'invention décrit ci-dessus, certaines étapes peuvent être partagées. En particulier, les étapes d'établissement de connexion, d'échange de messages applicatifs montants et descendants, et de libération de la connexion peuvent être communes aux deux procédés.
Ainsi, dans le premier procédé de traitement des messages descendants, plusieurs étapes de collecte et de mémorisation peuvent être réalisées en attendant l'établissement d'une connexion. Cette connexion peut-être réalisée à l'initiative de l'unité électronique de contrôle, dans le cadre de la transmission d'un message montant applicatif correspondant à un procédé de traitement d'un message montant applicatif.
Ainsi, il est à remarquer que les données utiles échangées montantes et descendantes lors d'un échange de requête et de réponse, et notamment selon le protocole http(S), ne sont pas nécessairement relatives au même échange applicatif entre l'unité électronique de contrôle et un module applicatif, mais à des échanges différents.
L'utilisation de ce système permet de tirer partie des échanges pour communiquer les données présentes à transférer de part et d'autre, et de simuler un échange de données sous forme de requête et de réponse, ce qui est un mode de communication accepté par le pare-feu.
La présente invention concerne également un procédé de traitement de messages montants applicatifs par une unité électronique de contrôle d'une installation domotique à destination d'un serveur comprenant les étapes suivantes :
une étape de mémorisation de données d'identification de données utiles correspondant à un message montant applicatif afin de pouvoir corréler lesdites données utiles avec les données utiles d'un message descendant applicatif ultérieur.
- une étape d'établissement d'une connexion vers le serveur à l'initiative de l'unité électronique de contrôle ;
une étape de transmission d'un message montant applicatif par l'unité électronique de contrôle à destination du serveur comprenant les données utiles et un identifiant de l'unité électronique de contrôle,
une étape d'acceptation de la libération de la connexion de façon immédiate ou suite à un délai maximal ;
Grâce aux dispositions selon l'invention, il est possible de procéder à la corrélation d'une requête à destination du serveur et de la réponse correspondante sans conserver la connexion, et en libérant donc les ressources correspondantes.
En particulier, il est possible de reconstituer la corrélation des réponses et des requêtes même si la séquence des réponses ne correspond pas à la séquence des requêtes applicatives
Selon un aspect de l'invention, le procédé comprend une étape de réception d'un message descendant applicatif par l'unité électronique de contrôle en provenance du serveur, le message descendant applicatif comprenant des données utiles ou aucune donnée utile.
Selon un aspect de l'invention, le message montant applicatif correspond à une requête de l'unité électronique de contrôle, ou encore une information provenant d'un capteur, un journal, une réponse à un ordre ou à une requête du serveur.
Selon un aspect de l'invention, on mémorise si une réponse applicative est attendue dans le cas d'une requête;
La présente invention concerne également un procédé de traitement de messages descendants applicatifs par une unité électronique de contrôle d'une installation domotique en provenance du serveur comprenant les étapes suivantes :
une étape d'établissement d'une connexion entre le serveur et l'unité électronique de contrôle ;
une étape de réception d'un message descendant applicatif à l'unité électronique de contrôle, le message descendant applicatif comprenant des données utiles descendantes ;
une étape d'acceptation de la libération de la connexion de façon immédiate ou suite à un délai maximal ;
une étape de vérification de la correspondance des données utiles descendantes avec des données utiles montantes d'un message montant applicatif précédent en utilisant des données d'identification de données utiles mémorisées;
Selon un aspect de l'invention, le procédé comprend une étape de transmission d'un message montant applicatif par l'unité électronique de contrôle vers le serveur, le message montant applicatif comprenant des données utiles ou aucune donnée utile.
Selon un aspect de l'invention, le procédé comprend une première étape de réception selon un premier protocole de communication par l'unité électronique de contrôle d'un message de demande d'ouverture de connexion en provenance du serveur ; l'étape d'établissement d'une connexion vers le serveur étant réalisée à l'initiative de l'unité électronique de contrôle selon un deuxième protocole de connexion.
Selon un aspect de l'invention, le procédé comprend une première étape de transmission périodique d'un message montant selon le premier protocole de communication par l'unité électronique de contrôle à destination du serveur, la première étape de réception d'un message de demande d'ouverture de connexion comprenant une étape de réception selon le premier protocole d'au moins un message descendant ultérieur à la première étape de transmission périodique selon le premier protocole de communication ;
L'unité électronique étant disposée sur un réseau privé dont l'accès est de façon usuelle protégé par un pare-feu, l'émission d'un message montant permet au serveur de répondre à ce message par un message descendant qui pourra atteindre l'unité électronique car il sera considéré comme une réponse au message montant.
Ainsi, l'envoi périodique de message montant offre des fenêtres de temps au serveur pour communiquer des demandes d'ouverture de connexion. En choisissant une périodicité des messages inférieurs à la fenêtre de temps autorisée par le pare-feu pour répondre à un message montant, il est possible de maintenir en permanence une possibilité de communication du serveur vers l'unité de contrôle électronique, c'est-à-dire un canal de communication ouvert.
Par ailleurs, un envoi périodique permet de connaître l'état du lien réseau entre l'unité électronique de contrôle et le serveur.
Selon un aspect de l'invention, le procédé comprend, préalablement à la première étape de réception d'une demande d'ouverture de connexion, une étape de réception selon le premier protocole de communication par l'unité électronique de contrôle d'un message descendant en provenance du serveur correspondant à une réponse d'accessibilité ;
L'étape préalable et la deuxième peuvent être simultanées, successives et/ou présenter une période de recouvrement temporel. En particulier, l'étape préalable de réception correspond à la réception d'une réponse d'accessibilité selon un premier délai après l'étape de transmission, afin de maintenir la possibilité de réception d'une deuxième trame selon un deuxième délai.
La deuxième étape correspond à la réception d'une demande de connexion pendant ledit deuxième délai.
Il apparaît en effet que le fonctionnement d'un pare-feu usuel peut empêcher le passage d'un message descendant dans la mesure où celui-ci est reçu au- delà d'un premier délai après l'envoi d'un message montant. Egalement de façon usuelle, dans la mesure où un premier message descendant est reçu, un deuxième délai plus important est accordé pour recevoir un ou plusieurs autres messages descendants.
Selon un aspect de l'invention, le procédé comprend une étape de surveillance d'au moins un délai de réception d'un message descendant en provenance du serveur suite à la première étape de transmission, le déclenchement d'une nouvelle première étape de transmission étant réalisé en cas de dépassement de l'au moins un délai de réception.
Ces dispositions permettent de maintenir des fenêtres de communication ouvertes afin que le serveur puisse communiquer.
Selon un aspect de l'invention, le procédé comprend une étape de transmission d'une clé de chiffrement par l'unité de contrôle électronique au serveur, de façon à permettre une signature des messages montants et/ou descendants selon le premier protocole de communication et/ou selon le deuxième protocole de communication.
Ces dispositions permettent de réaliser une signature des échanges entre le serveur et l'unité de contrôle électronique afin d'authentifier les deux entités en présence, à savoir le serveur et l'unité de contrôle électronique.
Selon un aspect de l'invention, le procédé comprend une étape de réception d'une indication de clef invalide ou expirée en provenance du serveur, et en réponse une nouvelle étape de transmission d'une clef de chiffrement.
Ces dispositions permettent de rétablir une communication par le premier mode de communication en cas d'expiration de la clé de chiffrement.
La présente invention concerne également un produit programme d'ordinateur comprenant des portions de code de programme pour l'exécution des étapes d'un procédé de traitement de messages montant ou de messages descendant par un serveur tel que décrit précédemment.
La présente invention concerne également une unité électronique de contrôle d'une installation domotique comprenant une unité de traitement agencée pour contenir et exécuter le produit programme d'ordinateur mettant en œuvre les étape du procédé, l'unité électronique de contrôle comprenant en outre au moins une interface de communication destinée à la commande et/ou au contrôle d'au moins un actionneur, notamment d'un élément mobile d'un bâtiment, ou d'un autre équipement commandable ou contrôlable électriquement ou électroniquement, comme par exemple un système d'alarme, ou d'au moins un capteur, et une interface de communication destinée à la communication avec un serveur.
La présente invention concerne également un produit programme d'ordinateur comprenant des portions de code de programme pour l'exécution des étapes d'un procédé de traitement de messages montant ou de messages descendant par une unité électronique de contrôle tel que décrit précédemment.
La présente invention concerne également un serveur de commande et ou de contrôle à distance d'au moins une unité électronique de contrôle d'une installation domotique comprenant une unité de traitement agencée pour contenir et exécuter le produit programme d'ordinateur mettant en œuvre les étape du procédé, le serveur comprenant en outre au moins une interface de communication destinée notamment à la communication selon le premier protocole de communication ou le deuxième protocole de communication avec au moins une unité de commande électronique.
Selon un aspect de l'invention, le serveur peut comprendre également une interface de communication destiné à la communication avec une interface utilisateur.
Ces dispositions permettent un contrôle à distance de l'installation domotique par l'utilisateur, et l'envoi d'ordres par l'intermédiaire du serveur vers l'unité électronique de contrôle, ou l'obtention de données sur l'état de l'installation.
L'interface utilisateur peut par exemple être formée par un serveur web communiquant avec un terminal utilisateur, par exemple un ordinateur, un téléphone portable ou une tablette.
La présente invention concerne également un système distribué comprenant au moins un serveur et une pluralité d'unités électroniques de contrôle agencées pour communiquer avec le serveur de façon à mettre en œuvre le procédé tel que décrit précédemment.
L'invention sera mieux comprise à l'aide de la description détaillée qui est exposée ci-dessous en regard du dessin annexé dans lequel :
La figure 1 est un schéma illustrant la structure d'un système destiné à la mise en œuvre d'un procédé de traitement de messages montants et descendants applicatifs entre un serveur et un ensemble d'unités électroniques de contrôle d'installations domotiques.
La figure 2 est un schéma illustrant les composants de l'unité de traitement du serveur et leurs interactions.
La figure 3 est un schéma illustrant un mode de mise en œuvre d'un procédé de traitement des messages montants applicatifs.
La figure 4 est un schéma illustrant un mode de mise en œuvre d'un procédé de traitement des messages descendants applicatifs.
La figure 4bis est un schéma illustrant un mode de mise en œuvre d'un procédé de traitement d'une pluralité de messages descendants et montants applicatifs.
La figure 5 est un schéma illustrant un mode de mise en œuvre d'un procédé de transmission de données. La figure 6 est un schéma illustrant une étape additionnelle du procédé de figure 5.
La figure 7 est un schéma illustrant la structure d'un deuxième système destiné à la mise en œuvre d'un procédé de transmission de données entre un serveur et un ensemble d'unités électroniques de contrôle d'installations domotiques.
Dans la description détaillée qui va suivre des figures définies ci-dessus, les mêmes éléments ou les éléments remplissant des fonctions identiques pourront conserver les mêmes références de manière à simplifier la compréhension de l'invention.
Comme cela est représenté sur la figure 1, un système distribué comprend au moins un serveur S et une pluralité d'unités électroniques de contrôle U d'installations domotiques agencées pour communiquer avec le serveur S de façon à mettre en œuvre un procédé de transmission de données.
Chaque unité de contrôle électronique d'une installation domotique est disposée sur un réseau privé PN, PN', dont l'accès est en général protégé par un pare- feu FW. Le serveur S est également disposé sur un réseau privé NS.
Les réseaux privés PN, PN', SN sont reliés à un réseau étendu N, par exemple Internet.
En particulier, une unité électronique de contrôle U d'une installation domotique comprend une unité de traitement 2 agencée pour contenir et exécuter un premier programme d'ordinateur ou un premier ensemble de programmes d'ordinateur.
A titre d'exemple, l'unité de traitement 2 comprend un processeur, une mémoire flash de stockage ainsi d'un mémoire vive, et d'une puce Ethernet PHY.
L'unité électronique de contrôle U comprend en outre au moins une interface de communication 3 destinée au contrôle/commande d'actionneurs d'éléments mobiles d'un bâtiment, de capteurs, ou encore d'autres équipements à commande électrique ou électronique tels qu'un système d'alarme.
A titre d'exemple, comme cela est représenté sur la figure 1, l'interface de communication 3 permet le contrôle et la commande d'au moins un actionneur 5, 5' d'un élément mobile d'un bâtiment, comme par exemple un volet roulant 6 ou un brise-soleil orientable 6'ou encore la réception d'informations d'un capteur 7 fournissant des informations de présence d'un utilisateur ou des valeurs des paramètres environnants comme la température, l'humidité, la luminosité. De la même, façon l'interface peut permettre le contrôle/commande d'un système d'alarme 8. En particulier, l'interface de communication peut comprendre une puce radiofréquence lo-homecontrol et/ou Zwave et/ou WM-Bus communiquant à une fréquence de 868Mhz, et/ou une puce radiofréquence RTS/RTD/RTD+ communiquant à une fréquence de 433 Mhz.
L'unité électronique de contrôle U comprend par ailleurs une batterie et/ou une alimentation secteur, ainsi que des ports de connexion physique tels que par exemple USB host, RJ45 et micro-USB.
L'unité électronique de contrôle U comprend également des éléments d'interface comme des boutons de réinitialisation, de configuration, des boutons tactiles de lancement de scenarii, et des indicateurs lumineux de fonctionnement, comme par exemple des LED.
L'unité électronique de contrôle U comprend par ailleurs une interface de communication 4 destinée à la communication selon le premier protocole de communication PI ou le deuxième protocole de communication P2 avec un serveur S, comme notamment une carte réseau pouvant être la puce Ethernet PHY.
Le serveur s qui permet la commande et/ou le contrôle à distance de la pluralité d'unités électroniques de contrôle U d'une installation domotique comprend une unité de traitement 102 agencée pour contenir et exécuter un deuxième programme ou un ensemble de deuxièmes programmes.
Le serveur s comprend en outre au moins une interface de communication 104 destinée à la communication selon le premier protocole de communication PI ou le deuxième protocole de communication P2 avec la pluralité d'unités électroniques de contrôle U.
Le serveur s peut comprendre également une interface de communication 106 destiné à la communication avec une interface utilisateur 107. L'interface utilisateur 107 peut par exemple être formée par un serveur web communiquant avec un terminal utilisateur 108 par le réseau N, par exemple un ordinateur, un téléphone portable ou une tablette.
La figure 2 illustre les composants de l'unité de traitement 102 du serveur et leurs interactions.
Il est à noter que le terme serveur est une désignation logique qui peut recouvrir l'utilisation de plusieurs serveurs physiques pour répartir la charge de traitement informatique à réaliser.
Un ou plusieurs modules applicatifs MA sont exécutés sur le serveur. Les modules applicatifs MA sont destinés à traiter les requêtes en provenance des unités électroniques de contrôle U ou à générer des commandes à destination des unités électroniques de contrôle U sur la base d'événements extérieurs, comme par exemple un ordre communiqué par un utilisateur par l'intermédiaire du terminal 108 relié au serveur web 107.
L'architecture permettant le traitement des messages montants et descendant entre l'interface de communication 104 et les modules applicatifs MA comprend une pluralité de composants,, et notamment :
Un premier composant de routage Rt ;
Une ou plusieurs instances de connecteur C ;
Un gestionnaire de files d'attente Q.M permettant la gestion d'une pluralité de files d'attente d'entrée Q.e et d'une file d'attente de sortie Q.s;
Une ou plusieurs instances de gestionnaires de messages H provenant des files d'attentes ; et
Un référentiel Reg destiné à mémoriser les associations définies entre les instances de connecteur C et les unités électroniques de contrôle U pour le routage des communications.
Le premier composant de routage est destiné à router les messages des unités électroniques de contrôle U vers une instance de connecteur C, notamment en fonction d'un identifiant de l'unité électronique de contrôle, comme par exemple une adresse IP.
Chaque connecteur C permet de gérer la connexion Cnx et l'échange de données avec une pluralité d'unités électroniques de contrôle U de façon synchrone et de communiquer de façon asynchrone en postant ou en collectant des messages sur les files d'attentes entrante Q.e, et respectivement sortante Q.s du gestionnaire de files d'attentes Qs.
Les gestionnaires de messages H réalisent une interface entre les files d'attentes et les modules applicatifs MA en entrée et en sortie.
Les différents types de composants peuvent être distribués sur différents serveurs physiques de façon à répartir la charge de traitement et à permettre une adaptation au nombre de connexion à traiter.
A titre d'exemple, il est possible de prévoir un nombre NC d'instances de connecteurs, un nombre NQ.e de files d'attentes entrantes sur un gestionnaire de files d'attente Q.M, un nombre NH de gestionnaires de messages comprenant chacun NLT instances d'écouteurs ou threads d'écouteur LT sur les files d'attentes entrantes Q.e, et un nombre NMA de modules applicatifs ou d'instances de modules applicatifs. Dans la mesure où l'application concernée doit assurer que la séquence des messages en provenance d'une unité électronique de contrôle U est respectée, le composant de routage s'assure que les communications en provenance d'une unité électronique de commande sont toujours routées vers la même instance de connecteur C parmi les NC instances de connecteur. De la même façon, chaque instance de connecteur C poste les messages en lien avec une unité électronique de commande sur une même files d'attente Qe parmi les NQ.e files d'attentes. Un écouteur ou un thread d'écouteurs doit dans ce cas écouter sur une seule file d'attente, pour alimenter ensuite les modules applicatifs.
Ainsi, on a dans ce cas une relation : NH*NLT=NQ.e.
Pour les messages descendants en provenance des modules applicatifs, dans les applications courantes, un seul thread d'émission ET par gestionnaire de message H sur une seule file d'attente de sortie Q.s est en général nécessaire, étant donné que le trafic descendant est bien inférieur au trafic montant. Il serait toutefois possible de prévoir plusieurs files d'attentes descendantes avec un mécanisme similaire aux files d'attente montantes.
Dans le cas d'une seule file d'attente descendante, l'ensemble des instances de connecteurs C collectent des messages sur ladite file d'attente Q.s en sélectionnant les messages qui leurs sont affectés, c'est-à-dire contenant par exemple leur identifiant.
La figure 3 représente les étapes d'un procédé de traitement de messages montants applicatifs Mm en provenance d'une unité électronique de contrôle U d'une installation domotique par un serveur S.
Un message montant applicatif Mm peut correspondre à une requête de l'unité électronique de contrôle, ou encore une information provenant d'un capteur, un journal, une réponse à un ordre ou à une requête du serveur.
Dans le cas où le message montant Mm correspond à une requête de l'unité électronique de contrôle, une étape de mémorisation EMU0 de données d'identification Rqid de données utiles PIm est réalisée par l'unité électronique de contrôle U afin de pouvoir corréler lesdites données utiles PIm avec les données utiles Pld d'un message descendant ultérieur. Si le message montant ne correspond pas à une requête devant donner lieu à une réponse du serveur S, cette étape peut être omise.
Une étape d'établissement EMU1 d'une connexion Cnx vers le serveur S est ensuite réalisée à l'initiative de l'unité électronique de contrôle U acceptée par le serveur s dans une étape EMC1. Cette connexion est par exemple réalisée selon le protocole de communication TCP. Une réservation de ressources est réalisée par le serveur S pour la gestion de la connexion.
Préalablement à l'étape d'établissement de la connexion Cnx, une étape de routage ERtMl de la communication vers une instance de connecteur C en fonction de l'unité électronique de contrôle U est réalisée, la correspondance entre une instance de traitement C et une unité électronique de contrôle U étant mémorisée dans le référentiel Reg. Le routage est effectué en fonction d'un identifiant de l'unité électronique de contrôle, comme par exemple une adresse IP.
Une fois la connexion Cnx établie, une étape de transmission EMU2 d'un message montant applicatif Mm est réalisée par l'unité électronique de contrôle U, le message étant réceptionné par une instance de connecteur C dans une étape EMC2. Le message montant Mm comprend des données utiles Plm et un identifiant Uid de l'unité électronique de contrôle U.
L'instance de connecteur C réalise ensuite une étape de détermination EMC3 d'une file d'attente d'entrante Q.e, sur laquelle un message entrant Me doit être posté. Cette étape de détermination prend en compte l'identifiant de l'unité électronique de contrôle Uid, par exemple en mettant en œuvre l'utilisation d'une fonction de hachage sur la base de l'identifiant Uid.
Une fois la file d'attente déterminée, une étape de postage EMC4 d'un message entrant Me est réalisée. Les données utiles Plm du message entrant Me sont déterminées en fonction des données utiles Plm, du message montant applicatif Mm. En particulier, il peut s'agir d'une copie de ces données utiles Plm. Le postage est réalisé sur la file d'attente entrante Q.e en vue d'un traitement par un module applicatif MA. Le message entrant Me comprend, en plus des données utiles Plm, un identifiant de l'unité électronique de contrôle Uid et un identifiant Cid de l'instance de connecteur C.
Le message entrant peut également comprendre un attribut de priorité de traitement, l'étape de postage étant réalisée dans une position différente de la file d'attente Q.e en fonction de la valeur de l'attribut de priorité afin de modifier son ordre de traitement.
Une étape de surveillance EMC7 d'un délai maximal Tmax est réalisée par le connecteur avant la libération de la connexion Cnx, ce délai permettant par exemple d'attendre un retour d'un module applicatif au message entrant, sous la forme d'un message descendant pour lequel un message descendant applicatif pourrait être transmis par le serveur à destination de l'unité électronique de commande. Le calcul du délai Tmax peut être notamment réalisé à partir de l'étape d'établissement d'une connexion EMC1, à partir de l'étape de postage EMC3, ou encore à compter d'une étape de réception d'un message montant applicatif EMC2.
Dans l'exemple représenté sur la figure 3, le délai Tmax est compté à partir de l'étape de postage EMC4.
A l'expiration du délai Tmax ou préalablement, le connecteur réalise une étape de transmission EMC8 d'un message descendant Md à l'unité électronique de contrôle U qui le reçoit dans une étape EMU8, en réponse au message montant applicatif Mm.
Le message descendant Md peut comprendre :
des données utiles Pld correspondant à une réponse applicative au message montant applicatif Mm si cette réponse est rendue disponible par le module applicatif, puis postée sur la file de sortie et collectée par le connecteur C avant l'expiration du délai Tmax ;
- Des données utiles Pld correspondant à un autre échange applicatif que celui impliquant le message montant ;
ou aucune donnée utile si le connecteur C n'a pas de données à transmettre à l'unité électronique de contrôle U.
Dans le cas représenté à la figure 3, aucune réponse applicative correspondant au message montant Mm n'a été reçue à l'expiration du délai Tmax. En conséquence, le message descendant comprendra soit des données utiles Pld correspondant à un autre échange applicatif que celui impliquant le message montant ; ou aucune donnée utile. Une étape de libération EMC9 de la connexion Cnx est ensuite réalisée par le connecteur C et constatée dans une étape EMU9 par l'unité électronique de contrôle U.
Postérieurement à l'étape de postage EMC4, une instance d'écouteur H réalise une collecte EMH5 d'au moins un message entrant Me sur une file d'attente entrante Q.e. L'écouteur H peut ensuite communiquer le contenu du message à un module applicatif MA dans une étape EMMA6. Le module applicatif réalise ensuite le traitement du message entrant Me.
Un procédé de traitement de messages descendants à destination d'une unité électronique de contrôle U d'une installation domotique par un serveur S va être à présent décrit en référence à la figure 4.
Comme cela a été précédemment décrit, les modules applicatifs MA sont destinés à traiter les requêtes en provenance des unités électroniques de contrôle U ou à générer des commandes à destination des unités électroniques de contrôle U sur la base d'événements extérieurs, comme par exemple un ordre communiqué par un utilisateur par l'intermédiaire du terminal 108 relié au serveur web 107.
Suite à ces différents traitements, les modules applicatifs MA communiquent dans une étape EDMAl des données utiles à un thread d'émission ET d'un gestionnaire de message H, en spécifiant l'unité électronique de contrôle U destinataire de ces données utiles Pld.
Dans une étape ultérieure EDH2, le gestionnaire de message H poste sur la file d'attente sortante Q.s du gestionnaire de files d'attentes Q.M un message sortant Ms comprenant un identifiant d'une unité électronique de contrôle Uid, un identifiant d'un connecteur Cid et des données utiles Pld.
La détermination de l'identifiant du connecteur Cid est réalisée en interrogeant le référentiel Reg afin de déterminer si l'unité électronique de commande est associée à un connecteur ou à une instance de connecteur C.
Le message sortant Ms peut également comprendre un attribut de priorité de traitement Pr, l'étape de postage étant réalisée dans une position différente de la file d'attente Q.s en fonction de la valeur de l'attribut de priorité afin de modifier son ordre de traitement.
Le procédé comprend ensuite une étape de collecte EDC3 d'un message sortant Ms sur une file d'attente sortante Q.s en provenance d'un module applicatif MA.
Les messages sortant Ms peuvent comprendre des données utiles Pld correspondant à une réponse à un précédent message entrant Me posté suite à une réception d'un message montant Mm en provenance de l'unité électronique de contrôle U ou encore des données utiles Pld générées par un module applicatif MA suite à un événement extérieur.
Par la suite, une étape de mémorisation EDC4 de données utiles Pld comprises dans au moins un message sortant Ms et de l'identifiant de l'unité électronique de contrôle Uid est réalisée.
L'étape de mémorisation EDC4 est réalisée en mémorisant les données utiles Pld d'un ou de plusieurs messages sortant Ms correspondant à un identifiant Uid d'une unité électronique de contrôle U jusqu'à expiration d'un délai d'attente Twait ou réception d'un message montant applicatif Mm.
Par la suite, à l'issu du délai d'attente Twait ou préalablement à la réception d'un message montant applicatif Mm, une étape d'établissement EDU5/EDC5 d'une connexion Cnx entre le serveur S et l'unité électronique de contrôle U correspondant à l'identifiant de l'unité électronique de contrôle Uid comprise dans le message sortant Ms est réalisée. Cette étape correspond soit à l'établissement d'une connexion à l'initiative de l'unité électronique de commande qui dispose de données utiles à transmettre, soit à une l'établissement d'une connexion à l'initiative de l'unité électronique de contrôle suite à une demande d'établissement d'une connexion par le connecteur comme cela sera détaillé ultérieurement,
Suite à l'établissement de la connexion Cnx, un message montant Mm est transmis dans une étape EDU6 par l'unité électronique de contrôle U et reçu par le serveur s dans une étape EDC6, le message montant Mm comprenant des données utiles Plm ou aucune donnée utile.
Un message descendant applicatif Md est ensuite transmis dans une étape EDC8 à l'unité électronique de contrôle U qui le reçoit dans une étape EDU8, le message descendant applicatif Md comprenant des données utiles PLd déterminées à partir des données utiles Pld du ou des messages sortant Ms mémorisées lors de l'étape EDC4.
Une étape de surveillance EDC7 d'un délai maximal Tmax peut être optionnellement réalisée par le connecteur avant la libération de la connexion Cnx. Le calcul du délai Tmax peut être notamment réalisé à partir de l'étape d'établissement d'une connexion EDC5, à partir d'une étape de postage éventuelle vers une file entrante, ou encore à compter d'une étape de réception d'un message montant applicatif EDC6. Dans l'exemple représenté sur la figure 3, le délai Tmax est compté à partir de l'étape de réception d'un message montant applicatif EDC6. Alternativement, la libération de la connexion peut être prévue de façon immédiate.
Ainsi, suite à la transmission de l'étape EDC8, une étape de libération EDC9 de la connexion Cnx est réalisée, par exemple à l'initiative du serveur.
L'unité de commande U peut ensuite réaliser une étape de vérification EDUlO de la correspondance des données utiles Pld reçues avec une requête préalable correspondant à une transmission d'un message montant Md en utilisant des données d'identification Rqid de données utiles Plm mémorisées.
II est à noter que selon les deux modes de mise en œuvre d'un procédé de traitement des messages montants et descendants selon l'invention décrit ci- dessus, certaines étapes peuvent être partagées. En particulier, les étapes d'établissement de connexion EMUl / EMCl ou EDU5 / EDC5, d'échange de messages applicatifs montants EMU2 / EMC2, EDU6 / EDC6 et descendants EMU8 / EMC8, EDU8 / EDC8, et de libération de la connexion EMU9, EMC9 peuvent être communes aux deux procédés. Ainsi, dans le premier procédé décrit en référence à la figure 4, plusieurs étapes de collecte EDC3 et de mémorisation EDC4 peuvent être réalisées en attendant l'établissement d'une connexion Cnx.
Cette connexion peut-être réalisée à l'initiative de l'unité électronique de contrôle U, dans le cadre de la transmission d'un message montant applicatif Mm correspondant à un procédé de traitement d'un message montant applicatif.
Ainsi, il est à remarquer que les données utiles montantes et descendantes circulant lors d'un échange de requête et de réponse, et notamment selon le protocole http(S), ne correspondent pas nécessairement au même échange applicatif entre l'unité électronique de contrôle U et un module applicatif MA, mais à des échanges différents.
L'utilisation de ce système permet de tirer partie des échanges pour communiquer les données présentes à transférer de part et d'autre, et de simuler un échange de données sous forme de requête et de réponse, ce qui est un mode de communication accepté par le pare-feu FW.
La figure 4bis présente un procédé de traitement de messages montants et descendants applicatif dans lequel plusieurs étapes de connexion EDU5a / EDC5a, EDU5b / EDC5b et EDU5c / EDC5c et plusieurs étapes de déconnexion EDU9a / EDC9a, EDU9b / EDC9b et EDU9c / EDC9c sont effectuées, un message montant Mml, Mm2, Mm3 et un message descendant applicatif Mdl, Md2, Md3 étant échangés dans le cadre de chacune de ces connexions au cours d'étapes de transmission EDU6a, EDU6b, EDU6c et de réception EDC6a, EDC6b, EDC6c de messages montants applicatifs et de réception EDU8a, EDU8b, EDU8c et de transmission EDC8a, EDC8b, EDC8c de messages descendant respectives.
Seules les étapes réalisées par l'unité électronique de commande U et le connecteur sont représentées sur la figure, les étapes internes au serveur S et à l'unité électronique de commande U étant conformes à celles décrites précédemment.
La figure 4bis illustre un exemple, dans lequel deux transactions applicatives X, Y impliquant une requête et une réponse applicative sont réalisées.
En particulier, les transactions X et Y correspondent à des requêtes de l'unité électronique de commande auxquelles le serveur doit apporter une réponse.
Dans le cadre de la première connexion Cnx, le premier message applicatif montant Mml comprend des données utiles PlmX correspondant à la requête de la transaction X. Le premier message descendant Mdl ne comprend aucunes données utiles ou des données utiles vides représentées par PldO. Dans le cadre de la seconde connexion Cnx, le deuxième message applicatif montant Mm2 comprend des données utiles PlmY correspondant à la requête de la transaction Y. Le second message descendant Md2 comprend des données utiles PldX correspondant à la réponse de la transaction X.
Dans le cadre de la troisième connexion Cnx, le troisième message applicatif montant Mm3 ne comprend pas de données utile, ce qui est représenté par Plmfl . Le message descendant Md2 comprend des données utiles PldX correspondant à la réponse de la transaction X.
Ainsi, les données utiles échangées montantes et descendantes lors d'un échange de messages montant et descendant, par exemple dans un échange requête/réponse selon le protocole http(S), ne sont pas nécessairement relatives au même échange applicatif ou transaction entre l'unité électronique de contrôle et un module applicatif, mais à des échanges ou transaction différentes.
La corrélation peut être réalisée du côté de l'unité électronique de commande grâce aux données d'identification Rqid de données utiles Plm correspondant à une transaction applicative.
Les deux procédés de traitement des messages applicatifs montants et descendants impliquent l'établissement d'une connexion Cnx entre l'une des unités électroniques de contrôle U et le serveur S. Etant donné que l'unité électronique de contrôle U est située sur un réseau privé PN protégé par un pare-feu, l'échange de données entre le serveur et la pluralité d'unités électroniques de contrôle doit prendre en compte la présence de ce pare-feu. En particulier, l'établissement d'une connexion à l'initiative d'un serveur extérieur au réseau privé est de façon usuelle interdite par un pare-feu ou peut être rendue difficile par l'utilisation de mécanisme de traduction d'adresse (NAT).
En conséquence, dans le cas où l'unité électronique de contrôle U ne procède pas à une connexion en vue de communiquer des données utiles dans le sens montant, il est souhaitable de disposer d'un mécanisme permettant au serveur de solliciter l'établissement d'une telle connexion.
A cet effet, la présente invention met en œuvre un procédé de transmission de données permettant notamment la transmission de messages applicatifs du serveur S vers une unité électronique de contrôle U.
La figure 5 représente un schéma de mise en œuvre des procédés de transmission de données exécutés sur le serveur S, en particulier par un connecteur C et sur une unité électronique de contrôle U d'une installation domotique I. Selon le mode de mise en œuvre décrit sur la figure 5, le procédé comprend une première phase PhO de négociation d'une clef secrète, une deuxième phase Phi réalisée selon le premier protocole de communication destiné à recueillir une demande de connexion de la part du serveur S et une troisième phase Ph2 de transmission de données suite à l'établissement d'une connexion selon le deuxième protocole de communication à l'initiative de l'unité électronique de contrôle.
La phase de négociation d'une clef secrète PhO comprend une étape de transmission EO d'une clé de chiffrement dans un message Mkey par l'unité de contrôle électronique U au serveur S qui le reçoit lors d'une étape EO', de façon à permettre une signature des messages montants et/ou descendants selon le premier protocole de communication PI et/ou selon le deuxième protocole de communication P2. La clef de chiffrement peut notamment être choisie de façon aléatoire par l'unité électronique de contrôle U.
Le serveur accuse réception de la clé et valide qu'il a bien pris en compte la nouvelle clef par un message descendant MkeyAck transmis dans une étape Ε qui est reçu par l'unité électronique de contrôle U lors d'une étape de réception El.
Les échanges entre l'unité électronique de contrôle U lors de la phase de négociation peuvent être réalisées selon un protocole de communication distinct ou similaire au premier protocole de communication et au deuxième protocole de communication PI et P2. A titre d'exemple, un protocole de type HTTPS peut être choisi qui permet de communiquer la clef de façon sécurisée.
Il est à noter que cet échange n'est pas réalisé fréquemment, et en conséquence ne représente pas une consommation de ressources significative. A titre d'exemple, une périodicité de plusieurs jours peut être prévue pour la validité des clefs.
La deuxième phase de communication Phi selon le premier protocole PI comprend une première étape de transmission E2 périodique d'un message montant Mping selon le premier protocole de communication PI par l'unité électronique de contrôle U à destination du serveur S qui le reçoit dans une étape E2'. A titre d'exemple, une périodicité de l'ordre d'une dizaine de secondes peut être prévue pour la périodicité de la transmission, et notamment de l'ordre de 20s.
En réponse à ce message montant, le serveur S transmet dans une étape E4' un message descendant Mpong à destination de l'unité électronique de contrôle U qui est reçu dans une étape préalable de réception E4 dans un premier délai Drl court après la transmission du message montant Mping. A titre d'exemple, le délai Drl peut être de l'ordre de quelques secondes, et notamment de l'ordre de 5 s. Ce premier message Mpong descendant permet de maintenir le canal de communication ouvert pendant un deuxième délai Dr2 supérieur au premier délai Drl. Il apparaît en effet que le fonctionnement d'un pare-feu usuel peut empêcher le passage d'un message descendant dans la mesure où celui-ci est reçu au-delà d'un premier délai après l'envoi d'un message montant. Egalement de façon usuelle, dans la mesure où un premier message descendant est reçu, un deuxième délai plus important est accordé pour recevoir un ou plusieurs autres messages descendants. Il est notamment possible de choisir de déclencher une nouvelle transmission du message Mping avant l'expiration du délai Dr2.
Par la suite, dans le cas où le serveur S a des données utiles DU à transmettre à l'unité électronique de contrôle U, celui-ci transmet selon le premier protocole de communication PI lors d'une étape E5' un message de demande d'ouverture de connexion Mopen, qui est reçu par l'unité électronique de contrôle U lors d'une étape E5.
La deuxième phase Phi de communication selon le premier protocole PI comprend une étape de surveillance E3 d'un délai de réception Dr d'un message descendant en provenance du serveur S suite à la première étape de transmission Mping, le déclenchement d'une nouvelle première étape de transmission E2 étant réalisé en cas de dépassement du délai de réception.
Lors de cette phase, les échanges sont signés avec la clé secrète communiquée lors de la première phase de communication PhO.
Comme cela est illustré sur la figure 6, lors de la deuxième phase Phi de communication selon le premier protocole de communication PI, le serveur peut réaliser une étape de transmission ERO' d'une indication de clef invalide ou expirée Minvalidkey en provenance du serveur S, et en réponse une nouvelle étape de transmission d'une clef de chiffrement E0. Typiquement, cette situation peut intervenir lors de la transmission d'un message montant MPing, le serveur ayant constaté que le message présente un format correct mais n'est pas signé avec une clé valide. Il est à noter qu'en cas de redémarrage de l'unité électronique de contrôle, la première phase de communication PhO avec communication de la clé est réalisée à nouveau.
Lors de la deuxième phase de communication Phi, Le premier protocole de communication peut notamment être le protocole UDP.
La troisième phase Ph2 du procédé est réalisée suite à la réception de la demande d'ouverture de connexion reçue par l'unité électronique de contrôle dans la deuxième phase à l'étape E5. Dans un premier temps, une étape d'établissement E6 d'une connexion Cnx vers le serveur S qui accepte cette connexion dans une étape correspondante E6' est réalisée, à l'initiative de l'unité électronique de contrôle U selon un deuxième protocole de connexion P2. En particulier, le protocole de communication peut être le protocole TCP. Dans ce cas, l'étape d'établissement E6 peut comprendre plusieurs échanges entre le serveur et l'unité U, et en particulier des échanges de messages de gestion de connexion, comme les messages du protocole TCP SYN, SYN/ACK, ACK.
Une fois la connexion Cnx établie, une étape de transmission E7 d'un message montant Mm est réalisée selon le deuxième protocole de communication P2 à destination du serveur S qui reçoit ce message dans un étape E7'.
En particulier, le message Mm peut être un message sans données utiles mais constituant un message montant auquel une réponse sera apportée par le serveur.
Ainsi, le serveur transmet un message descendant Md dans une étape de transmission E8' à destination de l'unité électronique de contrôle U. Ce message descendant contient les données utiles Pld que le serveur devait transmettre à l'unité électronique de contrôle U.
Suite à cet échange, une étape de libération ou d'acceptation de la libération E9, E9' de la connexion Cnx est réalisée.
Le deuxième protocole de communication utilisé peut être en particulier le protocole TCP. Les échanges des étapes E7/E7' et E8/E8' peuvent notamment être réalisés sous forme d'une requête et d'une réponse selon le protocole HTTPS qui utilise TCP.
Selon des variantes de mise en œuvre, la libération de la connexion peut intervenir après plusieurs échanges de messages montants et/ou de réception de messages descendantes selon le deuxième protocole de communication ou encore après un délai déterminé après l'étape d'établissement de la communication E6.
Les étapes d'établissement de la connexion E6 et d'acceptation de cette connexion E6' peuvent respectivement correspondre aux étapes d'établissement d'une connexion EDU5 et EDC5 décrites en référence à la figure 4 pour le procédé de transmission de messages descendants applicatifs.
Les étapes de transmission d'un message montant applicatif E7 et de réception E7' peuvent respectivement correspondre aux étapes de transmission et de réception EDU6 et EDC6 décrites en référence à la figure 4 pour le procédé de transmission de messages descendants applicatifs. Les étapes de transmission d'un message descendant applicatif Md E8 et de réception E8' peuvent respectivement correspondre aux étapes de transmission et de réception EDC8 et EDU8 décrites en référence à la figure 4 pour le procédé de transmission de messages descendants applicatifs.
Selon un deuxième mode de mise en œuvre d'un système mettant en œuvre l'invention représenté sur la figure 7, le premier protocole de communication est un protocole de type SMS comprenant l'envoi d'un message du serveur vers l'unité électronique de contrôle U identifiée dans ce cas par un numéro téléphonique. Ce deuxième protocole est utilisé sur un réseau de type téléphonique N2, par exemple un réseau GSM ou téléphonie filaire sur Internet, avec une fonction de gestion de messages numériques.
Le serveur s comprend à cet effet une interface de communication 107 sur le réseau N2, comme par exemple une carte GSM, tout comme l'unité électronique de contrôle, qui comprend également une interface de communication 7 sur le réseau N2, comme une carte GSM ou un module matériel et logiciel de téléphonie sur Internet, pouvant être intégré au pare-feu ou à l'unité électronique de contrôle U.
Ainsi, l'échange selon le premier protocole et l'étape de réception d'une demande d'ouverture de connexion correspond à un simple envoi de SMS entre le serveur S et l'unité électronique de contrôle U.
La figure 7 ne représente qu'une unité électronique de contrôle, mais ce deuxième mode de réalisation s'applique bien entendu à la communication avec une multitude d'unités électroniques de contrôles.
Selon des variantes de mise en œuvre, le premier protocole utilisé peut être de divers types permettant de ne pas être soumis aux contraintes imposées par le pare-feu.
Selon une deuxième variante, le premier protocole correspond à une donnée fournie dans un flux audio et/ou vidéo, par exemple un flux MPEG. Selon cette variante, l'unité électronique de contrôle U comprend ou est associée à une interface de décodage du flux audio et/ou vidéo correspondant.
Selon une autre variante, le premier et/ou le deuxième protocole peuvent être de type Raw IP ou autre protocole au dessus d'IP.
Selon des variantes de la troisième phase de communication Ph2, il est possible que les échanges applicatifs suivent le modèle des transactions, comprenant une requête et une réponse. Les requêtes sont envoyées sous forme de messages montants, et les réponses sous forme de messages descendants. Ainsi, dans un échange de requête et réponse sous forme d'un message montant, respectivement descendant, seule la réponse ou seule la requête peut contenir des données utiles. Un message montant et le message descendant émis en retour peuvent contenir des données utiles qui ne correspondent pas nécessairement à la même transaction. Par exemple une requête en cours nécessitant un traitement applicatif est transmise sous forme de message montant, et peut déclencher la transmission d'un message descendant sans données utiles, ou contenant des données utiles relatives à une requête antérieure. De la même manière, la réponse applicative correspondant à la requête en cours peut être envoyée lors d'un échange message montant/message descendant ultérieur. Cet échange peut comprendre un message montant sans données utiles.
Selon une variante de la troisième phase de communication Ph2, il est possible que suite à l'établissement de la connexion E6, seul un message descendant soit transmis par le serveur S, sans transmission d'un message montant par l'unité de contrôle électronique. Dans ce cas, un protocole distinct de HTTPS peut être utilisé, tout en s'appuyant sur les services fiables fournis par un protocole transport fonctionnant en mode connecté, comme TCP
Il est à noter que la description ci-dessus décrit des procédés permettant la transmission de données du serveur S vers l'unité électronique de contrôle U.
La transmission de données dans le sens de l'unité électronique de contrôle vers le serveur peut être réalisée par exemple selon le deuxième protocole de communication sans difficulté étant donné qu'il est possible d'établir directement une connexion à l'initiative de l'unité électronique de contrôle.
A titre d'exemple une requête et une réponse selon le protocole HTTPS peuvent être réalisée, puis la connexion établie libérée afin de limiter l'utilisation de ressources du serveur.
Il est à noter que l'optimisation des ressources réseau permise par l'invention est important dans le cas de figure d'un système de connexion d'une pluralité d'unité électronique de contrôle vers un serveur.
Les ressources réseau sont notamment nécessaires au maintien d'une connexion au niveau de la couche logicielle « transport », au dessus de la couche réseau (IP). Ce protocole doit fournir à l'application un service « transport » fiable, en mode dit « connecté » entre le serveur et chacune des unités électroniques de contrôle. Les ressources réservées pour assurer un service transport en mode connecté sont importantes, car pour chaque connexion il faut réserver des mémoires tampon pour les données entrantes, mais aussi pour les données sortantes, car il faut garder des messages déjà transmis, mais pas encore acquittés, afin d'éviter leur perte et de permettre leur éventuelle retransmission. Comme le mode connecté assure une communication point à point, il y a une connexion par unité électronique de contrôle.

Claims

REVENDICATIONS
1. Procédé de traitement de messages montants applicatifs en provenance d'une unité électronique de contrôle (U) d'une installation domotique par un serveur (S) comprenant les étapes suivantes :
- une étape d'établissement (EMC1) d'une connexion (Cnx) entre le serveur (S) et l'unité électronique de contrôle (U) ;
une étape de réception (EMC2) d'un message montant applicatif (Mm) par le serveur (S) en provenance de l'unité électronique de contrôle (U);
- une étape de postage (EMC4) d'un message entrant (Me), dans le cas ou le message montant applicatif contient des données utiles (Plm), le message entrant (Me) étant posté sur une file d'attente entrante (Qe) en vue d'un traitement par un module applicatif (MA), le message entrant (Me) comprenant des données utiles (Plm) déterminées en fonction des données utiles (Pld) du message montant applicatif (Mm) et un identifiant de l'unité électronique de contrôle (Uid) ;
une étape de libération (EMC9) de la connexion (Cnx) de façon immédiate ou suite à un délai maximal (Tmax) ;
2. Procédé selon la revendication précédente, comprenant une étape de transmission (EMC8) d'un message descendant (Md) à l'unité électronique de contrôle (U) en réponse au message montant applicatif (Mm), le message descendant (Md) comprenant des données utiles (PLd) reçues préalablement ou aucunes données utiles.
3. Procédé selon l'une des revendications précédentes, comprenant une étape de détermination (EMC3) d'une file d'attente d'entrante (Q.e) sur laquelle le message entrant (Me) doit être posté, préalablement à l'étape de postage (EMC4), l'étape de détermination prenant en compte l'identifiant de l'unité électronique de contrôle (Uid).
4. Procédé selon l'une des revendications précédentes, comprenant une étape préalable de routage (ERtMl) des messages montants applicatifs et/ou de la connexion (Cnx) en fonction de l'unité électronique de contrôle (U) vers une instance de traitement (C), la correspondance entre une instance de traitement (C) et une unité électronique de contrôle (U) étant mémorisée dans un référentiel (Reg).
5. Procédé selon l'une des revendications précédentes, comprenant une étape postérieure de collecte (EMH5, EMMA6) d'au moins un message sur une file d'attente entrante (Q.e) par un écouteur (H) en lien avec module applicatif (MA).
6. Procédé de traitement de messages descendants à destination d'une unité électronique de contrôle (U) d'une installation domotique par un serveur (S) comprenant les étapes suivantes :
Une étape de collecte (EDC3) d'un message sortant (Ms) sur une file d'attente sortante (Q.s) en provenance d'un module applicatif (MA), le message sortant (Ms) comprenant un identifiant d'une unité électronique de contrôle (Uid) et des données utiles (Pld) ;
une étape d'établissement (EDC5) d'une connexion (Cnx) entre le serveur (S) et l'unité électronique de contrôle (U) correspondant à l'identifiant de l'unité électronique de contrôle (Uid) comprise dans le message sortant (Ms) ;
une étape de transmission (EDC8) d'un message descendant applicatif (Md) à l'unité électronique de contrôle (U), le message descendant applicatif (Md) comprenant des données utiles (PLd) déterminées à partir des données utiles (Pld) du message sortant (Ms) ;
une étape de libération (EDC9) de la connexion (Cnx) de façon immédiate ou suite à un délai maximal (Tmax) ;
7. Procédé selon la revendication précédente, comprenant une étape de réception (EDC6) d'un message montant applicatif (Mm) par le serveur (S) en provenance de l'unité électronique de contrôle (U), préalablement à l'étape de transmission (EDC8) d'un message descendant applicatif (Md), le message montant applicatif (Mm) comprenant des données utiles (PLm) ou aucune donnée utile;
8. Procédé selon l'une quelconque des revendications 6 ou 7 comprenant une étape de mémorisation (EDC4) de données utiles (Pld) comprises dans au moins un message sortant (Ms) et de l'identifiant de l'unité électronique de contrôle (Uid) ;
9. Procédé selon la revendication 8, dans lequel l'étape de mémorisation (EDC4) est réalisée en mémorisant les données utiles (Pld) d'un ou de plusieurs messages sortant (Ms) correspondant à un identifiant (Uid) d'une unité électronique de contrôle (U), les données utiles (Pld) étant ensuite transmises lors de l'étape de transmission (EDC8) à l'unité électronique de contrôle (U) correspondant à l'identifiant (Uid).
10. Procédé selon l'une quelconque des revendications 6 à 9, comprenant :
une première étape de réception (EDC6a) d'un premier message montant applicatif (Mml) par le serveur (S) en provenance de l'unité électronique de contrôle (U), préalablement à l'étape de transmission (EDC8) d'un message descendant applicatif (Md2), le premier message montant applicatif (Mml) comprenant des premières données utiles montantes (PLmX); et
une deuxième étape de réception (EDC6b) d'un second message montant applicatif (Mm2), ultérieurement à la première étape de réception d'un premier message montant applicatif par le serveur (S) en provenance de l'unité électronique de contrôle (U), préalablement à l'étape de transmission (EDC8b) d'un message descendant applicatif (Md2), le second message montant applicatif (Mm2) comprenant des secondes données utiles montantes (PLmY) ou aucune donnée utile;
le message descendant applicatif (Md2) comprenant des données utiles descendantes (PldX) correspondant à une réponse au premier message montant applicatif (Mml) en provenance de l'unité électronique de contrôle (U).
11. Procédé selon l'une quelconque des revendications 6 à 10, dans lequel le message sortant (Ms) comprend des données utiles (Pld) générées par un module applicatif (MA) suite à un événement extérieur.
12. Procédé de traitement de messages montants applicatifs par une unité électronique de contrôle (U) d'une installation domotique à destination d'un serveur (S) comprenant les étapes suivantes :
- une étape de mémorisation (EMU0) de données d'identification (Rqid) de données utiles (PlmX, PlmY) correspondant à un message montant applicatif (Mml, Mm2) afin de pouvoir corréler lesdites données utiles (PlmX, PlmY) avec les données utiles (PldX) d'un message descendant applicatif ultérieur (Md2, Md3).
une étape d'établissement (EMU1) d'une connexion (Cnx) vers le serveur (S) à l'initiative de l'unité électronique de contrôle (U) ;
une étape de transmission (EMU2) d'un message montant applicatif (Mml, Mm2) par l'unité électronique de contrôle (U) à destination du serveur (S) comprenant les données utiles (PlmX, PlmY) et un identifiant (Uid) de l'unité électronique de contrôle (U), une étape d'acceptation de la libération (EMU9) de la connexion (Cnx) de façon immédiate ou suite à un délai maximal (Tmax) ;
13. Procédé selon la revendication précédente comprenant une étape de réception (EMU8) d'un message descendant applicatif (Mdl, Md2, Md3) par l'unité électronique de contrôle (U) en provenance du serveur (S), le message descendant applicatif (Md) comprenant des données utiles (PldX, PldY) ou aucune donnée utile.
14. Procédé de traitement de messages descendants applicatifs par une unité électronique de contrôle (U) d'une installation domotique en provenance du serveur (S) comprenant les étapes suivantes :
une étape d'établissement (EDU5) d'une connexion (Cnx) entre le serveur (S) et l'unité électronique de contrôle (U) ;
une étape de réception (EDU8) d'un message descendant applicatif (Mdl, Md2, Md3) à l'unité électronique de contrôle (U), le message descendant applicatif comprenant des données utiles descendantes (PldX, PldY) ;
une étape d'acceptation de la libération (EDU9) de la connexion (Cnx) de façon immédiate ou suite à un délai maximal (Tmax) ;
une étape de vérification (EDU10) de la correspondance des données utiles descendantes (PldX, PldY) avec des données utiles montantes (PldX, PldY) d'un d'un message montant applicatif (Mml, Mm2, Mm3) précédent en utilisant des données d'identification (Rqid) de données utiles (PlmX, PlmY) mémorisées;
15. Procédé selon la revendication précédente comprenant une étape de transmission (EDU6) d'un message montant applicatif (Mm) par l'unité électronique de contrôle (U) vers le serveur (S), le message montant applicatif (Md) comprenant des données utiles (Plm) ou aucune donnée utile.
EP15823712.3A 2014-12-24 2015-12-23 Procédé de traitement de messages montants ou descendants applicatifs en provenance ou à destination d'une unité électronique de contrôle d'une installation domotique par un serveur Withdrawn EP3238383A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1463301A FR3031261B1 (fr) 2014-12-24 2014-12-24 Procede de traitement de messages montants ou descendants applicatifs en provenance ou a destination d’une unite electronique de controle d’une installation domotique par un serveur
PCT/FR2015/053739 WO2016102902A1 (fr) 2014-12-24 2015-12-23 Procédé de traitement de messages montants ou descendants applicatifs en provenance ou à destination d'une unité électronique de contrôle d'une installation domotique par un serveur

Publications (1)

Publication Number Publication Date
EP3238383A1 true EP3238383A1 (fr) 2017-11-01

Family

ID=52627479

Family Applications (1)

Application Number Title Priority Date Filing Date
EP15823712.3A Withdrawn EP3238383A1 (fr) 2014-12-24 2015-12-23 Procédé de traitement de messages montants ou descendants applicatifs en provenance ou à destination d'une unité électronique de contrôle d'une installation domotique par un serveur

Country Status (4)

Country Link
US (1) US20170366645A1 (fr)
EP (1) EP3238383A1 (fr)
FR (1) FR3031261B1 (fr)
WO (1) WO2016102902A1 (fr)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11909849B2 (en) * 2018-09-11 2024-02-20 Stmicroelectronics S.R.L. Method of communicating information and corresponding device and system

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5812951A (en) * 1994-11-23 1998-09-22 Hughes Electronics Corporation Wireless personal communication system
US7006530B2 (en) * 2000-12-22 2006-02-28 Wi-Lan, Inc. Method and system for adaptively obtaining bandwidth allocation requests
TW200408242A (en) * 2002-09-06 2004-05-16 Matsushita Electric Ind Co Ltd Home terminal apparatus and communication system
BRPI0509010A (pt) * 2004-03-26 2007-08-07 Jolla Networks Inc método e sistema de comunicação de rede multifuncional escalonável entre dispositivos de apresentação e provedores de serviços, unidade de extremidade de cabeça para comunicação de rede multifuncional escalonável entre unidades de cpe acopladas entre dispositivos de apresentação e provedores de serviço, e, unidade de equipamento de premissa de consumidor para comunicação de rede multifuncional escalonável entre dispositivos de apresentação e provedores de serviço
US7421501B2 (en) * 2005-02-04 2008-09-02 Microsoft Corporation Queued sessions for communicating correlated messages over a network
US7706368B2 (en) * 2007-04-06 2010-04-27 Research In Motion Limited System and method for correlating messages within a wireless transaction
FR3000336A1 (fr) * 2012-12-20 2014-06-27 France Telecom Mecanisme de gestion d'une session de communication
US9544235B2 (en) * 2013-10-17 2017-01-10 North Carolina State University Scaling WiFi performance for large-audience environments via access points

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
None *
See also references of WO2016102902A1 *

Also Published As

Publication number Publication date
FR3031261B1 (fr) 2017-01-13
FR3031261A1 (fr) 2016-07-01
US20170366645A1 (en) 2017-12-21
WO2016102902A1 (fr) 2016-06-30

Similar Documents

Publication Publication Date Title
EP3238384A1 (fr) Procédé de transmission de données entre un serveur et une unité électronique de contrôle d'une installation domotique
EP2885899B1 (fr) Dispositif et procédé de transfert unidirectionnel de données
WO2012131275A2 (fr) Mécanisme de redirection entrante sur un proxy inverse
BE1023440B1 (fr) Système de portier vidéo à canaux multiples avec accès à des services numériques avancés
WO2018122508A1 (fr) Procédé de configuration d'accès, de commande et de supervision à distance d'au moins un dispositif domotique appartenant à une installation domotique
EP3563557A1 (fr) Procédé de configuration d'accès, de commande et de supervision à distance d'au moins un dispositif domotique appartenant à une installation domotique
CN113747192B (zh) 一种直播控制方法、装置、电子设备和存储介质
EP3734901B1 (fr) Procédé de transmission sécurisée de données
WO2016102902A1 (fr) Procédé de traitement de messages montants ou descendants applicatifs en provenance ou à destination d'une unité électronique de contrôle d'une installation domotique par un serveur
FR2946164A1 (fr) Procede de telechargement de donnees de grande taille vers un grand nombre de machines clientes en reseau a partir d'un serveur unique
WO2018206880A1 (fr) Singularisation de trames à émettre par un objet connecté et blocage de trames réémises sur un réseau de communication sans-fil basse consommation
EP4256830A1 (fr) Procédé de gestion d'une demande d'accès à un réseau de communication local, procédé de traitement d'une demande d'accès à un réseau de communication local, procédé de demande d'accès à un réseau de communication local, dispositifs, plateforme de gestion, passerelle, terminal utilisateur, système et programmes d'ordinateur correspondants
EP3709185A1 (fr) Procédé d'optimisation d'échanges de données dans une infrastructure d'objets connectés
EP2614630B1 (fr) Traitement de données pour la notification d'un équipement
EP2808819B1 (fr) Procédé de mise à jour de certificats dans un dispositif portable
EP2525525B1 (fr) Procédé, programme d'ordinateur et dispositif de cooptation permettant à un abonné d'un service de partager ce service avec un autre utilisateur
EP3360293A1 (fr) Moyens de gestion d'accès à des données
EP3224994A1 (fr) Procédé de notification de messages
EP2667574B1 (fr) Procédé et dispositif de sécurisation d'échange de messages transmis dans un réseau d'interconnexions
FR3097666A1 (fr) Procédé de stockage de données d’authentification de documents
EP1858224A1 (fr) Méthode de mise en place des réseaux privés virtuels et contrôle d'accès distant
EP1952599A1 (fr) Procede de diffusion maitrisee d'informations

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: 20170621

AK Designated contracting states

Kind code of ref document: A1

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

AX Request for extension of the european patent

Extension state: BA ME

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)
RIC1 Information provided on ipc code assigned before grant

Ipc: H04L 12/911 20130101ALI20190307BHEP

Ipc: H04L 29/06 20060101ALI20190307BHEP

Ipc: H04L 12/28 20060101AFI20190307BHEP

Ipc: H04L 29/08 20060101ALI20190307BHEP

17Q First examination report despatched

Effective date: 20190514

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: 20190925