WO2009101336A1 - Procede de diffusion de donnees relatives a une consommation d'une ressource au moyen d'un objet communicant - Google Patents

Procede de diffusion de donnees relatives a une consommation d'une ressource au moyen d'un objet communicant Download PDF

Info

Publication number
WO2009101336A1
WO2009101336A1 PCT/FR2009/050183 FR2009050183W WO2009101336A1 WO 2009101336 A1 WO2009101336 A1 WO 2009101336A1 FR 2009050183 W FR2009050183 W FR 2009050183W WO 2009101336 A1 WO2009101336 A1 WO 2009101336A1
Authority
WO
WIPO (PCT)
Prior art keywords
server
data
consumption
installation
resource
Prior art date
Application number
PCT/FR2009/050183
Other languages
English (en)
Inventor
Matthieu Plantey
Pierre Violet
Original Assignee
Poweo
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 Poweo filed Critical Poweo
Publication of WO2009101336A1 publication Critical patent/WO2009101336A1/fr

Links

Classifications

    • G—PHYSICS
    • G01—MEASURING; TESTING
    • G01D—MEASURING NOT SPECIALLY ADAPTED FOR A SPECIFIC VARIABLE; ARRANGEMENTS FOR MEASURING TWO OR MORE VARIABLES NOT COVERED IN A SINGLE OTHER SUBCLASS; TARIFF METERING APPARATUS; MEASURING OR TESTING NOT OTHERWISE PROVIDED FOR
    • G01D4/00—Tariff metering apparatus
    • G01D4/16—Apparatus for indicating or recording maximum or minimum load hours
    • G—PHYSICS
    • G01—MEASURING; TESTING
    • G01D—MEASURING NOT SPECIALLY ADAPTED FOR A SPECIFIC VARIABLE; ARRANGEMENTS FOR MEASURING TWO OR MORE VARIABLES NOT COVERED IN A SINGLE OTHER SUBCLASS; TARIFF METERING APPARATUS; MEASURING OR TESTING NOT OTHERWISE PROVIDED FOR
    • G01D4/00—Tariff metering apparatus
    • G01D4/002—Remote reading of utility meters

Definitions

  • the invention relates to the consumption of a resource such as an energy resource and in particular the dissemination of information concerning this consumption.
  • the occupant of an installation for example a dwelling, is regularly informed of the amount of electric current that he has consumed. This information is communicated to him in the invoices he receives, for example every month or every two months. But many occupants want to better control the amount of power they consume. But the receipt of the invoice with such a periodicity does not allow them to carry out a close control on this subject. In particular, if the invoice reveals that a very high amount of current has been consumed over the corresponding period, it is often difficult to find the exact causes. Faced with this problem, sending bills with greater frequency is not a good solution. Indeed, the generation of more invoices is expensive in itself and leads to a greater number of accounting operations, for both the electricity supplier and the occupant. In addition, it does not seem feasible to provide for a sufficiently high billing frequency to allow the occupant to control his consumption very closely. An object of the invention is to allow the occupant of an installation to better control his consumption of the resource.
  • the supplier of the resource can inform the occupant of his consumption with a particularly small delay. Therefore, if the occupant finds a rise in consumption, he can easily identify what are the causes, or even act on these causes if they persist to reduce this consumption. The occupant can therefore better control his consumption of the resource.
  • the resource is of an energy nature, for example electric current;
  • the installation is a dwelling;
  • the control takes place at a distance from the installation; the data are controlled, the data concerning, for example, the consumption between two predetermined dates;
  • the data relate to different time intervals and a grouping of data relating to the same time interval is controlled; for at least one time interval, a determination of a maximum value of the data relating to the interval is controlled;
  • a first server controls a data record in linearized form
  • a second server controls obtaining the data from the first server and delinearing them.
  • the second server can go as frequently as you want the most recent data on the first server to delineate itself. He is therefore little dependent on the first.
  • the data delinearized by the second server can then be exploited without delay to provide recent information to the client.
  • the service provider associated with this server can therefore inform the occupant of its consumption with a particularly small delay.
  • the invention also provides a method in which a data arrangement is controlled relating to a consumption of a resource consumed directly from a distribution network by an installation, in a form enabling their distribution by means of an object of a predetermined type, without a screen and able, without the intermediary of a computer, to receive information over the Internet and to broadcast them in sound form.
  • a server is also provided according to the invention which comprises means for controlling an arrangement of data relating to a consumption of a resource consumed directly from a distribution network by an installation, in a form permitting their dissemination by means of an object of a predetermined type, without a screen and able, without the intermediary of a computer, to receive information via the Internet and to broadcast them in sound form.
  • a set comprising at least one server according to the invention and a database is provided.
  • a method is also provided according to the invention in which data are received relating to a consumption of a resource consumed directly from of a distribution network by an installation, in a form allowing their dissemination by means of an object of a predetermined type, without a screen and able, without the intermediary of a computer, to receive information via the Internet and to broadcast them in sound form.
  • a computer program comprising instructions able to control the implementation of a method according to the invention, a recording medium comprising such a program and provision of such a program. for download.
  • FIG. 1 is an overall diagram of a system according to the invention
  • FIG. 2 is a flowchart illustrating various stages of collection of consumption data in the method implemented by the system of FIG. 1;
  • FIG. 3 is a flowchart illustrating various data processing steps implemented by the method according to the invention in the system of FIG. 1;
  • FIG. 4 illustrates a screen on which the processed data are presented
  • FIGS. 5 to 8 are views similar to Figure 3 illustrating other series of steps for the data processing in the method according to the invention.
  • FIG. 1 illustrates one embodiment of the system according to the invention.
  • This system makes it possible to process data relating to the consumption of a resource within an installation 4.
  • This resource is here consumed by the installation 4 directly from a distribution network 5.
  • This network is typically a network. regional or national supplying several thousand installations such as installation 4, or even more.
  • the resource is in this case an energy resource. But it could be a resource of another nature such as a fluid such as water.
  • the network would be a network of running water. It could also be a telecommunication network, the resource being for example a connection or communication time or a quantity of data transiting over the network from the installation 4 or to it.
  • This installation is in this case a dwelling. But it could be alternately professional premises such as offices or a factory.
  • At the installation 4 is associated a subscriber or customer identifier of the network 5.
  • the electric current constituting the resource is consumed by the installation 4 directly from the network 5.
  • This resource is consumed by the various devices present in the installation 4, for example household appliances (washing machines). laundry, dishwasher, television, computer, heaters, refrigerator, etc.).
  • this system allows the occupant of the installation 4 to know the details of his power consumption shortly after this consumption has taken place.
  • the system comprises an electrical sensor 6 which constitutes a first module of the system.
  • This sensor is located in the installation 4 and is connected to a teleinformation port of the electronic electricity meter 8 of the client.
  • This first module 6, known in itself, is able to periodically record the value of a consumption index on the counter 8. This index is directly dependent on the amount of electric current consumed.
  • the system comprises a second module formed by a transmitter 10.
  • This transmitter is able to communicate via a wireless link with the first module 6 to obtain the index values recorded by the latter.
  • the transmitter 10 is connected, for example by means of a wired link, to a residential gateway 12 of the installation 4.
  • This gateway is in communication with a telecommunications network which is in this case the Internet network 14.
  • This gateway here is an ADSL gateway.
  • the method according to the invention can be implemented by means of a conventional telephone line.
  • the second module 10 can thus transmit to the network 14 the index values obtained by the first module 6 on the counter 8.
  • the system also comprises a third module 16 constituted by a display.
  • This display is formed by a housing provided with a screen and also able to communicate with the transmitter 10, for example by means of a wireless link.
  • the display 16 can be manipulated and carried in the installation 4 by an occupant thereof. It allows the latter to read data relating to the consumption of the installation on the electricity grid.
  • the first, second and third modules are all present in the installation 4. They each comprise conventional electronic means allowing them to have the operation indicated here and in particular a central unit, means of communication with the other elements of the system, if necessary display means, etc.
  • the first module 6 reads an instantaneous value of the index on the electronic counter and sends it to the second module 10 every ten minutes.
  • the second module 10 stores the indexes thus collected and groups them into a flat file.
  • the indexes are thus linearized and thus unorganized.
  • a device 18 which is in this case a computer such as a server.
  • a server which is in this case a computer such as a server.
  • This server is able to communicate with the installation 4 by means of the network 14.
  • the role of this server is in this case to collect the indexes it receives from the second module 10.
  • the transmission by the module
  • the front-end server thus receives the files of many installations 4, for example from several thousand of these installations.
  • the front-end server 18 saves these newly obtained data with those already available because of the previous receptions in a file 38 illustrated in FIG. 2. In this case, it retains only the data relating to the last 15 rolling days, but it would be possible to choose a different duration (for example between one day and one month).
  • the system further comprises a processing device which is in this case a computer such as a server 20 also connected to the other elements of the system via the network 14.
  • a processing device which is in this case a computer such as a server 20 also connected to the other elements of the system via the network 14.
  • This server has the function of obtaining from the front-end server 18 the indexes collected by the latter and to treat them.
  • the system also comprises a database 22 which records the indexes previously processed by the server 20 and then sent and processed by the latter to the base via the network 14.
  • a database 22 which records the indexes previously processed by the server 20 and then sent and processed by the latter to the base via the network 14.
  • a first step 24 the server 20 connects to the database 22. If the connection proves impossible to establish, the server abandons the execution of this step and issues an alarm according to predetermined procedures relating to a situation of error in the system.
  • the server 20 obtains from the database 22 a list 28 of the customers 4 having subscribed to one of the services associated with the method .
  • This list has been partially illustrated in Figure 2 and includes different lines associated with the respective customers, one per customer.
  • the list includes a URL address of a storage file 38 to be recovered, the address beginning with the words "http: // ".
  • the list includes the last stored index time stamp. Recall that a time stamp or "timestamp” is computer time marker for the number of seconds since January 1, 1970, since in this case a Unix timestamp. For example, the value 1 197116587 corresponds to the date of 08/12/2007 at 12 hours 23 minutes 07 seconds.
  • the list includes the identifier of the domestic elements of the system, that is to say in this case modules 6, 10 and 16 of the installation 4. This identifier is constituted by a sequence of alphanumeric characters.
  • This file is stored in read-only mode on the front-end server 18 in http format.
  • the processing server 20 reaches this file by the address in the column 30. If the connection to the front-end server is impossible or if the file can not be found, the server 20 abandons the execution of this step for this client and emits an alarm according to the error procedures.
  • a next step 40 the processing server 20 proceeds to the complete extraction of the content 42 of this file. If the file is unreadable, the processing server drops the execution of this step and issues an alarm.
  • the server 20 proceeds to delineate the data forming this content. It executes for this purpose an "unserialize" function on this content. This is a standard function in PHP.
  • the step 44 allows the processing server 20 to proceed with an organization of the data it contains. This data has thus become accessible and readable by the processing server. These data cover the past 15 days. The server therefore selects the data which it did not yet have to update and complete a table 46 relating to the indexes. Table 46 is also entirely associated with the client in question.
  • Each line corresponds to an index value.
  • a first column 48 is indicated the time stamp and in a second column 50 is indicated the value of the index corresponding to this time stamp.
  • Most of the data in the table were already there because of the previous iteration of the process. The iteration in question here completes the table with the data of the last three hours or with other data that would be missing. If the organization operation fails, the server drops the execution of this step for that client and issues an alarm.
  • the processing server 20 connects to the database 22 and accesses the index table associated with the client in question. The server 20 proceeds to insert in this table the timbre and index pairs that have just been organized and for which the time stamp is greater than that indicated in column 32 with reference to step 26. Thus, it inserts by the pairs that are already present in the base 22. If this insertion step fails, it is abandoned and the processing server reports an error.
  • the processing server 20 proceeds to the next client of the list 28 and resumes from step 36 the same succession of steps for the next client.
  • the database 22 may be a database of any type and may be managed by any program. In this case, the database is managed using the program known as "MySQL".
  • steps 24 to 54 shown in Figure 2 they are executed for all clients in the list every 30 minutes in this example.
  • this period could vary between a few minutes and several hours, for example one to five hours. But it is again advantageous that this period be as short as possible.
  • the indexes are read every 10 minutes by the module 6 and then once grouped transmitted every 3 hours by the module 10 to the front server 20.
  • the processing server 20 consults the files 38 every thirty minutes and executes with the same period the steps of FIG. 2.
  • the data are thus updated in the base 22 with a delay of only about three thirty.
  • the further processing is very fast, it follows that the data is presented to the customer with a delay of three hours forty maximum. In other words, the customer is aware of his consumption data only three and a half hours after consumption.
  • an interactive object 1 10 comprising a graphic component appearing on a screen 112 of a computer or other digital device, for example in the form of a web page of small format compared to the screen and therefore not completing the entirety of the latter.
  • Many environments and operating systems allow the development and presentation of widgets. This is the case, for example, of the one known as Netvibes.
  • the method according to the invention enables the client to visualize in a widget in graphic form, for example in the form of diagrams or curves, some of its consumption data or the results of a processing of these data. In this case, three curves are presented:
  • a first step 62 the computer 64 on the client's order connects via the network 14 to the application server 60, which connects to the database 22 via the network 14.
  • An identifier-password pair is sent by the computer to the application server 60, then to the database 22 via the network 14. This sending is done here in a transparent manner for the customer, a registration prior to this service has allowed to set up this procedure.
  • the server 60 checks the validity of this identifying pair
  • the server 60 sends an error message to the computer 64 instead of the server. expected image corresponding to the widget.
  • the application server 60 obtains from the database 22 the last time stamp recorded for the client 4.
  • a next step 68 it designates by "second date” or "date_2" the date indicated by the latter time stamp, and "first date” or “date_1” this date less 24 hours.
  • the server 60 sets two dates: the most recent, the second, corresponding to the time stamp and the oldest, the first, preceding the second of 24 hours.
  • the first date is 09/10/07 at 12:15 and the second is 10/10/07 at 12:15.
  • the application server 60 obtains from the database 22 all the index values of the period between these two dates. These values are given in the form of a table 72 shown in Figure 3. Each column corresponds to a date, the leftmost column being the date_1 and the rightmost column the date_2. The columns between these two dates correspond to the intermediate dates. In the present example, knowing that the first module 6 obtains the index value on the counter 8 every ten minutes, the successive dates are spaced from each other by ten minutes.
  • the application server 60 obtains from the database 22 a maximum value of each index before the first date. In this case, it obtains a maximum value for each of the horosaisonnality, that is to say each of the possible tariffs (here in number of three). It operates a selection of these maximum values 80 in a table 76 of the base 22. If no maximum value can be determined, for example if all the indexes are at 0, the maximum value is then set to 0.
  • a subsequent step 82 the server 60 performs the division into several successive time slots of the period defined by the two dates. In this case, these tranches each correspond to one hour. It groups together the indexes that are within the same time slot.
  • This processing leads to the production of table 89.
  • a first column 84 distinguishes the number of the slices thus cut, in a second column 86 the time stamps corresponding to the slice, then in the following columns the respective tariffs with the values of index for each time stamp. It is observed that each slice of the column 84 covers several time stamps, that is to say several lines of the other columns. In the present case, these lines are logically six in each slot, the indexes being read every ten minutes.
  • the first installment thus concerns the index statements that took place on October 9, 2007 from 12:15 pm to 1:05 pm inclusive.
  • the application server 60 determines the maximum value of the index in each slot for each rate. In Table 89, these values have been surrounded. It can thus be observed that, for the first tranche, the maximum value of the index in peak hours is 13 and the maximum value of the index in off-peak is 30. For the basic tariff, all the indices being at 0 , the maximum value is 0. In fact, if all the indexes are at 0 for a certain tariff in a slice, the corresponding maximum value is set to 0. At a later step 90, the server 60 proceeds to the concatenation of the Board
  • a table 92 is thus obtained in which the first row corresponds to the maximum values of the indexes before the first date and the following lines correspond to the successive slices. For each line, an index value is shown for the base rate, a value for the peak hour rate and a value for the off-peak rate.
  • the server 60 replaces each null index value, if any, by the value of the previous slice.
  • the index was at 0 for slot 3 in off-peak hours while it was at 33 for slot 2 at the same hourly rate. As a result, there was no power consumption during Unit 3 for this tariff. The index remains in fact unchanged and is thus set to 33.
  • the server 60 calculates the consumption values for each slot and for each hourly rate.
  • the consumption for each slice n is equal to the value of the index for that slice minus the index value for the previous slice n-1.
  • the server 60 calculates the maximum consumption between the two dates defining the period in question for each hourly rate.
  • the calculation of this maximum consumption value will make it possible to adapt the scale of the ordinate axis of the graphical representation in order to make it as clear as possible for its consultation by the customer. For example, one will choose this scale to interrupt the ordinate axis at this maximum value or just above.
  • the server 60 proceeds to generate the image by representing in a diagram 102 each slice by a vertical bar.
  • each bar is subdivided into different fractions stacked corresponding to consumption for different hourly rates.
  • 24 bars have thus been displayed successively, the abscissa axis presenting the time divided in 24 hours and the ordinate axis presenting the value of the consumption of electric current.
  • Most of the bars such as the bar 104 are represented with a single color or in one way because they refer to a single hourly rate while other bars such as the bars 106 correspond to the periods during which the hourly rate has changed so that their consumption is fragmented into two parts visualized so different. The customer will be able to visualize the amount of current consumed for each rate during this time.
  • This diagram is displayed in the widget 110, itself displayed on the screen 1 12 of the computer 64.
  • FIG. 5 illustrates the steps implemented by the system for generating in the widget a curve corresponding this time to weekly consumption, that is to say over the last seven days until the day before. midnight compared to the day of the consultation.
  • the steps implemented are identical or similar to those of FIG. 3. Only the steps that vary will be presented hereinafter.
  • this time at step 68 the date_1 is chosen to be one week before the second date, date_2, equal to midnight of the previous day.
  • Table 76 is unchanged from that of Figure 3.
  • step 82 the division of the period is done this time in daily slices and no longer in time slots.
  • Table 1 10 Similar to Table 89.
  • the first installment covers the time interval between the date of 3/10/07 at 12:15 and 4/10/07 at 12:05.
  • the second installment covers the time interval between 4/10/07 at 12.15 and 5/10/07 at 12.05.
  • Table 92 is similar to that of Figure 3. The same is true for the following table.
  • a table 98 similar to that of FIG. 3 is obtained, each slice however being here a daily slice.
  • Diagram 112 that is obtained is presented in the same way as diagram 102. However, each bar represents here the consumption of a day of the week considered. Each bar can be subdivided into different successive parts stacked one above the other, these different parts referring to consumption obeying different hourly rates.
  • the consumption curves are sent to a portable digital pocket device such as a mobile phone 120 or PDA PDA.
  • This sending can be done via a mobile telephone network by means of at least one antenna 22, this network communicating with the network 14.
  • the device 120 being a handheld device, the customer associated with the installation 4 can be informed its electrical power consumption even if it is in a place far from this installation.
  • This information can be done at the customer's request sent from this phone or on regular dates, the server 60 transmitting to the client on his device 120 spontaneously the aforementioned curves.
  • This sending can be done for example by means of the technology of third-generation mobile telephony called UMTS (Universal Mobile Telecommunications System).
  • UMTS Universal Mobile Telecommunications System
  • the consumption information is communicated to the client 4 via an object 122.
  • This is a communicating object of a type known in itself.
  • This object has for example the appearance of a character or an animal. It is without screen. It comprises means making it suitable, without the intermediary of a computer, to receive information via the Internet and thus in this case from the network 14 and via the gateway 12. In particular, it can connect directly to this gateway through a wireless link. Having received this information in the form of a message, he is able to broadcast it in sound form by means of a loudspeaker. It can also send light signals to its immediate environment. It can also have moving parts to simulate gestures. Such an object is for example known as "Nabaztag" in the form of a stylized rabbit capable of shaking the ears. Naturally, the method can be implemented by means of communicating objects other than that of the latter example.
  • the object 122 may include a screen and / or a computer.
  • the system prepares a set of voice messages and the address to the communicating object 122.
  • the manufacturer of this type of object makes available one or more programming interfaces making it possible to exploit the features. These interfaces are known in themselves and will not be described in more detail.
  • two types of messages can be provided. It may be a daily message consisting of a voice announcement by the purpose of the summary of the power consumption of the day before, for example from midnight to midnight. It can also be a weekly message consisting of the verbal announcement by object 122 of the comparison of last week's power consumption (for example the previous seven days) with the power consumption of the previous week (from seven previous fourteen days).
  • step 124 the application server 60 connects to the database 22. If this connection is impossible, the server issues an error message to the system operators.
  • the server 60 retrieves from the database the list 128 of the customers having subscribed to the daily messaging service by this type of object as well as the data concerning them. These data are grouped together in the different columns of the table 128.
  • the identifier of the object 122 in the second column 132 the desired time for the voice announcement, and in the column 134 the desired days for this voice announcement.
  • the time and days will have been previously chosen by the client 4 concerned. This shows that the customer associated with the object of the first line wants a voice announcement at 10 am every day from Monday to Sunday.
  • the customer associated with the subject of the second line wishes a voice announcement at 9:00 pm on Saturday and Sunday only.
  • the customer associated with the third line wants a voice announcement at 7 am from Monday to Friday only. Knowing that the same customer 4 can hold several objects 122, several lines of the table 128 may concern the same customer 4.
  • a subsequent step 136 the server 60 checks a row of the array 128 if the current day and time correspond to the day and time configured for the announcement. If not, which will be the most common case, the server 60 goes to the next line and performs the same check. Once the array 128 has been traversed in this way, the server goes back to the first line of the table. The subsequent step 138 therefore only concerns the case where it has been found that the current date and time correspond to those configured for the announcement.
  • the server 60 determines the two deadlines between which the indexes will be retrieved. It associates with the date_2 the date of the current day at midnight and the first date the date_2 minus 24 hours. The first date then precedes 24 hours the second. In this example, the date_1 is October 9, 2007 at midnight and the date_2 is October 10, 2007 at midnight.
  • the server 60 obtains from the base 22 the maximum index values of each hourly rate for the time interval between these two dates.
  • Table 142 shows that the maximum index value is 0 for the base rate, 38 for the peak hour rate and 47 for the off-peak rate. This obtaining of the maximum values is done in the same way as in step 74 of FIG.
  • the server 60 obtains from the database 22 the maximum value of the indexes for each hourly rate before the first date.
  • the maximum for the full-time rate is 14 and the maximum for the off-peak rate is 18, the maximum being 0 for the basic rate.
  • the server 60 calculates a consumption value for each tariff. For this, for each tariff, it subtracts from the maximum index value of the period the maximum index value before the period. Thus, in Table 150, the index remains at 0 for the base rate. The maximum 14 in Table 146 is removed from maximum 38 of Table 142 to give a consumption value of 24 kWh for the peak hour rate. Similarly, a consumption value of 29 kWh is obtained for the off-peak tariff.
  • the server 60 proceeds to form the sound message to be sent to the communicating object, in particular by making the sum of the consumptions for the three tariffs, which corresponds here to 53 kWh. The prepared message is here "Yesterday, you consumed 53 kWh".
  • the application server 60 sends via the network 14 this message to a server 158 managing the communication with the communicating objects 122 and dedicated thereto.
  • This server is usually controlled by the manufacturer of these objects.
  • the sending takes place with the identification data of the object 122 of the customer.
  • This sending takes here the form of a request of type http.
  • a subsequent step 156 and in practice immediately after the server 158 addresses, via the network 14, a response to the server 60 indicating that this shipment has been properly received by the server. If, on the other hand, no acknowledgment is received by the server 60 or if a message indicating an erroneous reception is received, the application server generates an error message for the operators of the system. The message appropriately received by the server 158 is then broadcast by the latter via the network 14 to the installation 4. Arriving at the gateway 12, it is sent to the object 122 to be broadcast in sound form within installation 4 to its occupants.
  • the application server 60 records the sending date of this message.
  • step 160 the server 60 returns to step 136 and executes the latter by going to the next line of table 128.
  • FIG. 7 illustrates the stages of the implementation of the method in the case where the announcement made by the communicating object 122 corresponds to the weekly consumption.
  • the steps are similar and only those that differ from that of the Figure 6 will be stated.
  • the application server 60 retrieves from the database 22 the list 123 of the customers having subscribed to the weekly message service rather than the list 128 of those subscribing to the daily message service.
  • the table 163 therefore comprises, after the first column 164 devoted to the identifier of the communicating object, a second column 166 relating to the time provided for the broadcast of the message and a third column 168 indicating the desired day for the broadcast of the message. message.
  • the application server 60 determines the three dates between which the data will be recovered, namely the first, second and third dates.
  • the third date is the current day at midnight.
  • the second date precedes the third of seven days and the first date precedes the second of seven days.
  • the DATE_1 is set at 1 October 2007 at midnight
  • the Date_2 is 8 October 2007 midnight
  • Time_3 is 15 October 2007 at midnight.
  • the server 60 obtains the maximum indexes for each period separated by two successive ones of these dates and for each hourly rate. If there is no maximum index value, it is set to 0. Thus, Table 174 shows that for the period between the first included date and the second included date, the value is 0 for the base rate maximum index, 22 for the peak hour maximum index and 47 for the maximum peak hour index. For the next period between date_2 (excluded) and date_3 (included), these values are 0, 38 and 59, respectively. In a subsequent step 176, the application server 60 determines the maximum value of the indexes. before the first date for each hourly rate. As shown in Table 178, these values are 0, 14 and 18, respectively.
  • the server 60 calculates the consumption for each hourly rate for each of the two periods of a week by subtracting the period in question from the previous period by the maximum of that period.
  • the full-time rate consumption is obtained by removing 14 of 22, which gives 8.
  • the off-peak rate it is obtained by removing 18 of 47, which gives 29.
  • consumption at the full-time rate is obtained by removing 22 of 38, which gives 16.
  • the off-peak rate it is obtained in taking 47 out of 59, which gives 12.
  • the consumption is zero for the base rate.
  • the server 60 proceeds to form the sound message to be sent to the communicating object by comparing the two values of the consumption sums.
  • This message will for example be of the type "This week, you consumed 9 kWh less than the previous week". This is just an example.
  • the system is configured to send an alert message to the client of the installation 4 when the consumption of a predetermined period exceeds a threshold previously chosen by this customer. This may be for example the consumption of a day.
  • a threshold previously chosen by this customer.
  • the method whose steps are illustrated in FIG. 8 is executed periodically, for example every 20 minutes. In this case, it is to send an alert message by SMS (Short Message Service).
  • SMS Short Message Service
  • the application server 60 connects to the database 22.
  • a step 202 it obtains the list of the customers having subscribed to this alert service as well as the data concerning them. He thus obtains a table 204 presenting in successive columns 206 the identity of the customer, 208 his telephone number, 210 the threshold of consumption which, once it is crossed, must be used to trigger an alarm, and 212 the date sending the last message.
  • step 214 the server identifies the last time stamp recorded for that client.
  • step 216 the two deadlines between which the indexes will have to be obtained, namely the first and second dates.
  • the second date is that of the last recorded time stamp and the first date is the one closest to the midnight hour of the day corresponding to the second date as illustrated in the diagram 217.
  • the server 60 obtains the maximum index values for each hourly rate of the period 219 delimited by the dates 1 and 2. On Table 220 shows that these maxima for base rates, peak hours and off-peak hours are 0, 38 and 47 kWh, respectively.
  • the server 60 determines the maximum values of the indexes for each hourly rate before the first date. These maximum values are here identified respectively at 0, 14 and 18 kWh for the three tariffs.
  • the server calculates the consumption for the period considered for each hourly rate. For this, it subtracts the maximum preceding the first date from the maximum for the period. Thus, for the full-time rate, it subtracts 14 from 38, which gives a consumption of 24 kWh. Similarly, for the off-peak rate, it subtracts 18 from 47 for a consumption of 29 kWh.
  • the consumption at the basic rate is here nil.
  • the server 60 performs the sum of the consumption for the three tariffs which is here 53 kWh, then proceeds to the comparison of this total with the threshold set. In the next step 228, if the threshold is exceeded and if the last sending date is earlier than the first date, then the server 60 prepares the message to be sent. If not, it returns to step 214 and returns table 204 to the next client.
  • the server 60 in step 230, sends the message to a server 232 dedicated to the dispatch of this type of message, with the customer's telephone number.
  • a server 232 dedicated to the management and sending of SMS type messages is known in itself and connected to the network 14. It is through the latter that the server 60 sends the message to him to send .
  • the server 232 sends to the application server 60, via the network 14, an acknowledgment of receipt of the message to the server. If this acknowledgment of good reception is not received by the server 60, it reports an error to the operators of the system.
  • the server 232 also proceeds to send the message to the digital handheld device 120 of the client 14. This message is sent by means of an antenna
  • the device 120 is a handheld device that can be consulted by its owner in any location, and in particular at a distance from the installation 4.
  • step 236 the sending server 60 stores in database table 204 the date the message was sent in order to update the corresponding line of the client.
  • This sequence of steps is performed for example every 20 minutes by the server 60 but this period could be chosen at any value between one minute and two hours for example. In the present example, if the threshold is exceeded more than once in the day, the message is not sent each time the steps of FIG. 8 are executed.
  • the method (s) just presented are implemented by the servers and / or devices and devices that have been discussed. These, including servers, include for this purpose means for this implementation such as CPU, clock, memory, sending and receiving data on the network 14, etc.
  • the execution of or processes is controlled by the instructions of a program stored in these servers, devices and / or devices according to the steps implemented.
  • These programs may also be recorded on a conventional recording medium such as a DVD. It is also expected to make available these programs on the internet for download, for example the download of an update version, this download may be restricted access to be reserved for authorized persons.
  • the consumption data after having been collected and processed, can be communicated to the natural person corresponding to the installation 4 in various forms, whether they are widgets appearing on the computer.
  • the method makes it possible to get close enough to a true synchronism situation between the reality that is measured (namely the indexes on the counter) and the information actually available in the database 22 then sent to the client associated with installation 4. Naturally, this synchronism is only approached and is not reached to the extent that we must take into account:
  • At least some of the data communicated and / or displayed could include amounts of resource amount invoiced, for example in euros, rather than indications of quantity consumed in units, for example in kWh.
  • provision may be made to control the display of the consumption data of a resource so that it generates at least one graphic zone consisting of parts associated with respective different conditions of supply of the resource, by example of tariff conditions.

Landscapes

  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Telephonic Communication Services (AREA)

Abstract

Dans le procédé, on commande une diffusion de données relatives à une consommation d'une ressource consommée directement à partir d'un réseau de distribution (5) par une installation (4), de sorte que la diffusion a lieu sur un objet (122) sans écran apte, sans l'intermédiaire d'un ordinateur, à recevoir des informations par Internet et à les diffuser sous forme sonore.

Description

Procédé de diffusion de données relatives à une consommation d'une ressource au moyen d'un objet communicant.
L'invention concerne la consommation d'une ressource telle qu'une ressource énergétique et en particulier la diffusion des informations concernant cette consommation.
L'occupant d'une installation, par exemple d'une habitation, est informé régulièrement de la quantité de courant électrique qu'il a consommée. Cette information lui est communiquée dans les factures qu'il reçoit, par exemple tous les mois ou tous les deux mois. Or de nombreux occupants souhaitent mieux maîtriser la quantité de courant qu'ils consomment. Mais la réception de la facture avec une telle périodicité ne leur permet pas d'effectuer un contrôle étroit à ce sujet. En particulier, si la facture révèle qu'une quantité de courant très élevée a été consommée sur la période correspondante, il s'avère souvent difficile d'en retrouver les causes exactes. Face à ce problème, l'envoi des factures avec une plus grande fréquence n'est pas une bonne solution. En effet, la génération de factures plus nombreuses est coûteuse en elle-même et entraîne un plus grand nombre d'opérations comptables, aussi bien pour le fournisseur d'électricité que pour l'occupant. En outre, il ne paraît pas envisageable de prévoir une fréquence de facturation suffisamment élevée pour permettre à l'occupant de contrôler très étroitement sa consommation. Un but de l'invention est de permettre à l'occupant d'une installation de mieux contrôler sa consommation de la ressource.
A cet effet, on prévoit selon l'invention un procédé dans lequel on commande une diffusion de données relatives à une consommation d'une ressource consommée directement à partir d'un réseau de distribution par une installation, de sorte que la diffusion a lieu au moyen d'un objet sans écran apte, sans l'intermédiaire d'un ordinateur, à recevoir des informations par Internet et à les diffuser sous forme sonore.
Ainsi, le fournisseur de la ressource peut informer l'occupant de sa consommation avec un retard particulièrement réduit. Dès lors, si l'occupant constate une élévation de sa consommation, il peut sans difficulté identifier quelles en sont les causes, voire agir sur ces causes si elles persistent afin de réduire cette consommation. L'occupant peut donc mieux maîtriser sa consommation de la ressource.
Le procédé selon l'invention pourra présenter en outre au moins l'une quelconque des caractéristiques suivantes :
- la ressource est de nature énergétique, par exemple du courant électrique ; - l'installation est une habitation ;
- la commande a lieu à distance de l'installation ; - on commande une obtention des données, les données concernant par exemple la consommation entre deux dates prédéterminées ;
- les données sont relatives à des intervalles de temps différents et on commande un regroupement des données relatives à un même intervalle de temps ; - pour au moins un intervalle de temps, on commande une détermination d'une valeur maximale des données relatives à l'intervalle ;
- pour au moins un intervalle de temps, on commande une détermination d'au moins une valeur de quantité consommée de la ressource pendant l'intervalle ; et
- on diffuse les données sous forme sonore. De préférence, au préalable:
- un premier serveur commande un enregistrement des données sous forme linéarisée; et
- un deuxième serveur commande une obtention des données à partir du premier serveur et leur délinéarisation. Ainsi, le deuxième serveur peut aller chercher aussi fréquemment qu'on le souhaite les données les plus récentes sur le premier serveur pour les délinéariser lui-même. Il est donc peu dépendant du premier. Les données délinéarisées par le deuxième serveur peuvent alors être exploitées sans délai pour fournir des informations récentes au client. Le prestataire associé à ce serveur peut donc informer l'occupant de sa consommation avec un retard particulièrement réduit.
On prévoit également selon l'invention un procédé dans lequel on commande un agencement de données, relatives à une consommation d'une ressource consommée directement à partir d'un réseau de distribution par une installation, sous une forme permettant leur diffusion au moyen d'un objet d'un type prédéterminé, sans écran et apte, sans l'intermédiaire d'un ordinateur, à recevoir des informations par Internet et à les diffuser sous forme sonore.
On prévoit également selon l'invention un serveur qui comprend des moyens pour commander un agencement de données relatives à une consommation d'une ressource consommée directement à partir d'un réseau de distribution par une installation, sous une forme permettant leur diffusion au moyen d'un objet d'un type prédéterminé, sans écran et apte, sans l'intermédiaire d'un ordinateur, à recevoir des informations par Internet et à les diffuser sous forme sonore.
On prévoit en outre selon l'invention un ensemble comprenant au moins un serveur selon l'invention et une base de données. On prévoit également selon l'invention un procédé dans lequel on reçoit des données, relatives à une consommation d'une ressource consommée directement à partir d'un réseau de distribution par une installation, sous une forme permettant leur diffusion au moyen d'un objet d'un type prédéterminé, sans écran et apte, sans l'intermédiaire d'un ordinateur, à recevoir des informations par Internet et à les diffuser sous forme sonore.
On prévoit enfin selon l'invention un programme d'ordinateur comprenant des instructions aptes à commander la mise en œuvre d'un procédé selon l'invention, un support d'enregistrement comprenant un tel programme et une mise à disposition d'un tel programme en vue de son téléchargement.
D'autres caractéristiques et avantages de l'invention apparaîtront encore dans la description suivante d'un mode préféré de réalisation donné à titre d'exemple non limitatif en référence aux dessins annexés sur lesquels :
- la figure 1 est un schéma d'ensemble d'un système selon l'invention ;
- la figure 2 est un organigramme illustrant différentes étapes de collecte de données de consommation dans le procédé mis en œuvre par le système de la figure 1 ; - la figure 3 est un organigramme illustrant différentes étapes de traitement des données, mises en œuvre par le procédé selon l'invention dans le système de la figure 1 ;
- la figure 4 illustre un écran sur lequel les données traitées sont présentées ; et
- les figures 5 à 8 sont des vues analogues à la figure 3 illustrant d'autres séries d'étapes pour le traitement des données dans le procédé selon l'invention.
On a illustré à la figure 1 un mode de réalisation du système selon l'invention. Ce système permet le traitement de données relatives à la consommation d'une ressource au sein d'une installation 4. Cette ressource est ici consommée par l'installation 4 directement à partir d'un réseau de distribution 5. Ce réseau est typiquement un réseau régional ou national alimentant plusieurs milliers d'installations telles que l'installation 4, voire bien davantage.
La ressource est en l'espèce une ressource énergétique. Mais il pourrait s'agir d'une ressource d'une autre nature telle qu'un fluide comme de l'eau. Le réseau serait ainsi un réseau d'alimentation en eau courante. Il pourrait aussi s'agir d'un réseau de télécommunication, la ressource étant par exemple un temps de connexion ou de communication ou encore une quantité de données transitant sur le réseau en provenance de l'installation 4 ou à destination de celle-ci.
Cette installation est en l'espèce une habitation. Mais il pourrait s'agir alternativement de locaux professionnels tels que des bureaux ou une usine. A l'installation 4 est associé un identifiant d'abonné ou de client du réseau 5. -A-
Dans le présent exemple, le courant électrique constituant la ressource est consommé par l'installation 4 directement à partir du réseau 5. Cette ressource est consommée par les différents appareillages présents au sein de l'installation 4, par exemple des appareils électroménagers (lave-linge, lave-vaisselle, télévision, ordinateur, appareils de chauffage, réfrigérateur, etc.).
Comme on va le voir, ce système permet à l'occupant de l'installation 4 de connaître le détail de sa consommation électrique peu de temps après que cette consommation a eu lieu.
Collecte des données
Le système comprend un capteur électrique 6 qui constitue un premier module du système. Ce capteur se trouve dans l'installation 4 et est raccordé sur un port de téléinformation du compteur d'électricité électronique 8 du client. Ce premier module 6, connu en lui-même, est apte à relever périodiquement la valeur d'un index de consommation sur le compteur 8. Cet index est directement dépendant de la quantité de courant électrique consommée.
Le système comprend un deuxième module formé par un transmetteur 10. Ce transmetteur est apte à communiquer par une liaison sans fil avec le premier module 6 pour obtenir les valeurs d'index relevées par ce dernier. Le transmetteur 10 est raccordé, par exemple au moyen d'une liaison filaire, à une passerelle résidentielle 12 de l'installation 4. Cette passerelle est en communication avec un réseau de télécommunication qui est en l'espèce le réseau Internet 14. Cette passerelle est ici une passerelle ADSL. En l'absence d'une liaison à haut débit vers Internet, le procédé selon l'invention peut être mis en œuvre au moyen d'une ligne téléphonique classique. Le deuxième module 10 peut ainsi transmettre au réseau 14 les valeurs d'index obtenues par le premier module 6 sur le compteur 8.
Le système comprend également un troisième module 16 constitué par un afficheur. Cet afficheur est formé par un boîtier muni d'un écran et apte lui aussi à communiquer avec le transmetteur 10, par exemple au moyen d'une liaison sans fil. L'afficheur 16 peut être manipulé et porté dans l'installation 4 par un occupant de celle-ci. Il permet à ce dernier de prendre connaissance de données relatives à la consommation de l'installation sur le réseau électrique.
Les premier, deuxième et troisième modules sont tous trois présents au sein de l'installation 4. Ils comprennent chacun des moyens électroniques classiques leur permettant d'avoir le fonctionnement indiqué ici et notamment une unité centrale, des moyens de communication avec les autres éléments du système, le cas échéant des moyens d'affichage, etc.
Nous allons maintenant présenter avec leurs fonctions les composants du système qui se trouvent hors de l'installation 4 et typiquement à grande distance de celle-ci. Si leur communication avec l'installation 4 est rendue nécessaire, cette communication se fait dans le présent exemple par l'intermédiaire du réseau de télécommunication 14.
Dans le présent exemple, le premier module 6 lit une valeur instantanée de l'index sur le compteur électronique et l'envoie au deuxième module 10 toutes les dix minutes.
Cette période pourrait plus généralement être comprise entre une minute et deux heures. Le deuxième module 10 stocke les index ainsi collectés et les regroupe dans un fichier plat. Les index y sont ainsi sous forme linéarisée et donc inorganisée. Le module
10 envoie périodiquement le fichier ainsi constitué à un dispositif 18 qui est en l'espèce un ordinateur tel qu'un serveur. Nous désignerons ce serveur par le terme « serveur frontal » dans la présente description. Ce serveur est apte à communiquer avec l'installation 4 au moyen du réseau 14. Le rôle de ce serveur est en l'espèce de collecter les index qu'il reçoit du deuxième module 10. Dans le présent exemple, la transmission par le module
10 au serveur frontal 18 se fait toutes les trois heures mais on pourrait prévoir qu'elle se fait avec une période inférieure à une heure, et par exemple de l'ordre de quelques minutes, ou bien avec une période plus longue, par exemple de dix ou quinze heures. Il est toutefois avantageux que cette période soit aussi courte que possible. Le serveur frontal reçoit de la sorte les fichiers de nombreuses installations 4, par exemple de plusieurs milliers de ces installations.
Le serveur frontal 18 enregistre ces données nouvellement obtenues avec celles dont il dispose déjà en raison des réceptions précédentes dans un fichier 38 illustré à la figure 2. Il ne conserve en l'espèce que les données relatives aux 15 derniers jours glissants mais on pourrait choisir une durée différente (par exemple entre un jour et un mois).
Le système comprend en outre un dispositif de traitement qui est en l'espèce un ordinateur tel qu'un serveur 20 lui aussi relié aux autres éléments du système via le réseau 14. Ce serveur a pour fonction d'obtenir du serveur frontal 18 les index collectés par ce dernier et de les traiter.
Le système comprend également une base de données 22 qui enregistre les index préalablement traités par le serveur 20 puis envoyés ainsi traités par ce dernier à la base via le réseau 14. Nous allons maintenant à ce stade, en référence à la figure 2, illustrer en détail le déroulement de ces différentes étapes. Les étapes qui vont être présentées sont mises en œuvre par le serveur de traitement 20.
Dans une première étape 24, le serveur 20 se connecte à la base de données 22. Si la connexion s'avère impossible à établir, le serveur abandonne l'exécution de cette étape et émet une alarme selon des procédures prédéterminées relatives à une situation d'erreur dans le système.
Si la connexion a pu avoir lieu, il passe à l'étape 26. Au cours de celle-ci, le serveur 20 obtient de la base de données 22 une liste 28 des clients 4 ayant souscrit à l'un des services associés au procédé. Cette liste a été illustrée en partie à la figure 2 et comprend différentes lignes associées aux clients respectifs, une par client. Dans une première colonne 30, la liste comprend une adresse URL d'un fichier de stockage 38 à récupérer, l'adresse débutant par les termes « http://... ». Dans une deuxième colonne 32, la liste comprend le dernier timbre horaire d'index stocké. On rappelle qu'un timbre horaire ou "timestamp" est un marqueur de temps informatique correspondant au nombre de secondes écoulées depuis le 1er janvier 1970, s'agissant en l'espèce d'un timestamp Unix. Par exemple, la valeur 1 197116587 correspond à la date du 08/12/2007 à 12 heures 23 minutes 07 secondes. Dans une troisième colonne 34 intitulée "idb", la liste comprend l'identifiant des éléments domestiques du système, c'est-à-dire en l'espèce des modules 6, 10 et 16 de l'installation 4. Cet identifiant est constitué par une suite de caractères alphanumériques.
Les étapes suivantes qui vont être présentées en référence à la figure 2 concernent à chaque fois un client particulier. Ces étapes sont exécutées pour ce client, puis le procédé recommence pour le client suivant de la liste 28. Au cours d'une étape 36, le serveur de traitement 20 consulte sur le serveur frontal
18 le fichier 38 de stockage des index du client associé à l'installation 4. Ce fichier est stocké en mode lecture seule sur le serveur frontal 18 au format http. Le serveur de traitement 20 atteint ce fichier grâce à l'adresse figurant dans la colonne 30. Si la connexion au serveur frontal s'avère impossible ou si le fichier est introuvable, le serveur 20 abandonne l'exécution de cette étape pour ce client et émet une alarme conformément aux procédures d'erreur.
Dans une étape suivante 40, le serveur de traitement 20 procède à l'extraction complète du contenu 42 de ce fichier. Si le fichier s'avère illisible, le serveur de traitement abandonne l'exécution de cette étape et émet une alarme. Au cours de l'étape suivante 44, le serveur 20 procède à la délinéarisation des données formant ce contenu. Il exécute à cette fin une fonction "unserialize" sur ce contenu. Il s'agit d'une fonction standard en langage PHP. Ainsi, tandis que le fichier plat 38 avait un contenu inorganisé, l'étape 44 permet au serveur de traitement 20 de procéder a une organisation des données qu'il contient. Ces données sont ainsi devenues accessibles et lisibles par le serveur de traitement. Ces données couvrent les 15 derniers jours glissants. Le serveur sélectionne donc les données dont il ne disposait pas encore pour mettre à jour et compléter un tableau 46 relatif aux index. Le tableau 46 est lui aussi tout entier associé au client en question. Chaque ligne correspond à une valeur d'index. Dans une première colonne 48, est indiqué le timbre horaire et dans une deuxième colonne 50 est indiquée la valeur de l'index correspondant à ce timbre horaire. La plupart des données du tableau y étaient déjà présentes en raison des itération précédentes du procédé. L'itération dont il est question ici permet de compléter le tableau avec les données des trois dernières heures voire avec d'autres données qui viendraient à manquer. Si l'opération d'organisation échoue, le serveur abandonne l'exécution de cette étape pour ce client et émet une alarme. Dans une étape suivante 52, le serveur de traitement 20 se connecte à la base de données 22 et accède à la table des index associée au client en question. Le serveur 20 procède à l'insertion dans cette table des couples timbre horaire et index qui viennent d'être organisés et pour lesquels le timbre horaire est supérieur à celui indiqué dans la colonne 32 en référence à l'étape 26. Ainsi, il n'insère par les couples qui sont déjà présents dans la base 22. Si cette étape d'insertion échoue, elle est abandonnée et le serveur de traitement signale une erreur.
Dans une étape suivante 54, le serveur de traitement 20 passe au client suivant de la liste 28 et reprend à partir de l'étape 36 la même succession d'étapes pour ce client suivant. La base de données 22 peut être une base de données d'un type quelconque et peut être gérée au moyen d'un programme quelconque. En l'espèce, la base est gérée au moyen du programme connu sous le nom "MySQL".
En ce qui concerne les étapes 24 à 54 illustrées à la figure 2, elles sont exécutées pour l'ensemble des clients de la liste 28 toutes les trente minutes dans le présent exemple. Ici encore, cette période pourrait varier entre quelques minutes et plusieurs heures, par exemple une à cinq heures. Mais il est à nouveau avantageux que cette période soit aussi courte que possible. On rappelle que, dans cet exemple, les index sont relevés toutes les 10 minutes par le module 6 puis une fois regroupés transmis toutes les 3 heures par le module 10 au serveur frontal 20. Le serveur de traitement 20 consulte les fichiers 38 toutes les trente minutes et exécute avec la même période les étapes de la figure 2. Les données sont donc mises à jour dans la base 22 avec un retard de seulement trois heures trente environ. Nous allons exposer dans la suite comment ces données sont transmises et présentées au client. La suite du traitement étant très rapide, il s'ensuit que les données sont présentées au client avec un retard de trois heures quarante au maximum. En d'autres termes, le client a connaissance de ses données de consommation trois heures quarante seulement après la consommation concernée.
Nous allons maintenant exposer comment les données sont traitées et transmises au client pour son information. Dans le présent exemple, plusieurs modes de traitement et de présentation sont prévus et se cumulent afin de permettre au client de prendre connaissance de différentes façons de ses données de consommation.
Affichage sur un widget
Nous allons tout d'abord exposer comment les données sont traitées puis présentées en vue d'apparaître dans un widget. On sait qu'un widget est un outil informatique et graphique qui permet d'obtenir des informations. Comme illustré à la figure
4, c'est un objet interactif 1 10 comprenant un composant graphique apparaissant sur un écran 112 d'un ordinateur ou d'un autre appareil numérique, par exemple sous la forme d'une page web de petit format par rapport à l'écran et ne remplissant donc pas l'intégralité de ce dernier. De nombreux environnements et systèmes d'exploitation permettent le développement et la présentation de widgets. C'est le cas par exemple de celui connu sous l'appellation Netvibes. Le procédé selon l'invention permet au client de visualiser dans un widget sous la forme graphique, par exemple sous forme de diagrammes ou de courbes, certaines de ses données de consommation ou des résultats d'un traitement de ces données. En l'espèce, trois courbes sont présentées :
- la courbe des dernières 24 heures réalisée à partir des dernières données d'index collectées ;
- la courbe des sept derniers jours jusqu'à la veille de la date de consultation à minuit et enfin - la courbe des trente derniers jours également jusqu'à la veille de la consultation à minuit. Ces courbes sont présentées sous la forme de diagrammes à barres dans le présent exemple. Le client de l'installation 4 accède à ce service par exemple au moyen d'un ordinateur 64 qui peut être connecté au réseau 14. Cela peut avoir lieu depuis l'installation 4 via la passerelle 12. On présente à la figure 3 les différentes étapes permettant l'affichage de la courbe correspondant à la consommation de courant électrique sur le réseau de distribution pour rinstallation 4. Ces étapes sont mises en œuvre par un dispositif 60 qui est en l'espèce un ordinateur tel qu'un serveur. Lui aussi est connecté au réseau 14. Nous désignerons ici ce serveur par le terme serveur d'application.
Dans une première étape 62, l'ordinateur 64 sur ordre du client se connecte via le réseau 14 au serveur d'application 60, lequel se connecte à la base de données 22 via le réseau 14. Un couple identifiant-mot de passe est envoyé par l'ordinateur au serveur d'application 60, puis à la base de données 22 via le réseau 14. Cet envoi se fait ici de façon transparente pour le client, une inscription préalable à ce service ayant permis de mettre en place cette procédure. Lors d'une étape suivante 64, le serveur 60 vérifie la validité de ce couple identifiant
- mot de passe en les comparant à un identifiant et un mot de passe enregistrés au préalable. Si ce couple ne correspond pas à un couple valide ou si la connexion du serveur 60 à la base de données s'avère impossible, le serveur 60 émet, à destination de l'ordinateur 64, un message d'erreur à la place de l'image prévue correspondant au widget.
A l'étape suivante 66, le serveur d'application 60 obtient auprès de la base de données 22 le dernier timbre horaire enregistré pour le client 4.
Lors d'une étape suivante 68, il désigne par « deuxième date » ou "date_2" la date indiquée par ce dernier timbre horaire, et par « première date » ou "date_1" cette date diminuée de 24 heures. En d'autres termes, le serveur 60 fixe deux dates : la plus récente, la deuxième, correspondant au timbre horaire et la plus ancienne, la première, précédant la deuxième de 24 heures. Ainsi, la première date est par exemple le 09/10/07 à 12 h 15 et la deuxième date est le 10/10/07 à 12 h 15.
Dans une étape ultérieure 70, le serveur d'application 60 obtient auprès de la base de données 22 toutes les valeurs d'index de la période comprise entre ces deux dates. Ces valeurs sont communiquées sous la forme d'un tableau 72 illustré à la figure 3. Chaque colonne correspond à une date, la colonne la plus à gauche étant la date_1 et la colonne la plus à droite la date_2. Les colonnes entre ces deux dates correspondent aux dates intermédiaires. Dans le présent exemple, sachant que le premier module 6 obtient la valeur d'index sur le compteur 8 toutes les dix minutes, les dates successives sont espacées les unes des autres de dix minutes.
En l'espèce, on prend en compte les circonstances de la fourniture du courant. Ici, il s'agit de la notion d'horosaisonnalité de l'index, c'est-à-dire en fonction du contrat souscrit par le client 4, l'heure à laquelle a eu lieu la consommation de la ressource. En effet, dans le présent exemple, le courant électrique n'est pas facturé au même tarif horaire suivant l'heure de sa consommation. On distingue en l'espèce trois types de tarifs en fonction de trois types d'horaires : un tarif de base qui correspond à la première ligne du tableau 72, un tarif heures pleines qui correspond à la deuxième ligne et un tarif heures creuses qui correspond à la troisième ligne. Chaque index appartient à un et un seul de ces trois tarifs. Sur le tableau 72, on voit ainsi que l'index de la première date a une valeur de 10 et correspond à des heures pleines. En l'espèce, le client a eu le choix de souscrire un contrat dans lequel la facturation se fait ou bien de façon uniforme avec le tarif de base, ou bien d'une façon qui tient compte des heures creuses et pleines. C'est ce dernier cas qui est retenu dans la suite de sorte que les valeurs d'index pour le tarif de base sont toujours à 0. Dans une étape ultérieure 74, le serveur d'application 60 obtient auprès de la base de données 22 une valeur maximale de chaque index avant la première date. En l'espèce, il obtient une valeur maximale pour chacune des horosaisonnalités, c'est-à-dire chacun des tarifs possibles (ici au nombre de trois). Il opère une sélection de ces valeurs maximales 80 dans un tableau 76 de la base 22. Si aucune valeur maximale ne peut être déterminée, par exemple si tous les index sont à 0, la valeur maximale est alors mise à 0.
Au cours d'une étape ultérieure 82, le serveur 60 procède au découpage en plusieurs tranches horaires successives de la période définie par les deux dates. En l'espèce, ces tranches correspondent chacune à une heure. Il regroupe ainsi les index qui se trouvent au sein d'une même tranche horaire. Ce traitement conduit à la réalisation du tableau 89. On distingue ainsi dans une première colonne 84 le numéro des tranches ainsi découpées, dans une deuxième colonne 86 les timbres horaires correspondant à la tranche, puis dans les colonnes suivantes les tarifs respectifs avec les valeurs d'index pour chaque timbre horaire. On observe que chaque tranche de la colonne 84 recouvre plusieurs timbres horaires, c'est-à-dire plusieurs lignes des autres colonnes. En l'espèce, ces lignes sont logiquement au nombre de six pour chaque tranche, les index étant relevés toutes les dix minutes. La première tranche concerne ainsi les relevés d'index ayant eu lieu le 9 octobre 2007 de 12 h 15 à 13 h 05 inclus.
Au cours d'une étape ultérieure 88, le serveur d'application 60 détermine la valeur maximale de l'index dans chaque tranche pour chaque tarif. Sur le tableau 89, ces valeurs ont été entourées. On observe ainsi que, pour la première tranche, la valeur maximale de l'index en heures pleines est de 13 et la valeur maximale de l'index en heures creuses est de 30. Pour le tarif de base, tous les index étant à 0, la valeur maximale est à 0. En effet, si tous les index sont à 0 pour un certain tarif dans une tranche, la valeur maximale correspondante est prise à 0. Lors d'une étape ultérieure 90, le serveur 60 procède à la concaténation du tableau
89 afin de ne retenir pour chaque tranche que les valeurs maximales d'index. Il ajoute au tableau ainsi concaténé les valeurs maximales d'index obtenues précédemment pour la période antérieure à la première date. On obtient ainsi un tableau 92 dans lequel la première ligne correspond aux valeurs maximales des index avant la première date et les lignes suivantes correspondent aux tranches successives. Pour chaque ligne, une valeur d'index est indiquée pour le tarif de base, une valeur pour le tarif heures pleines et une valeur pour le tarif heures creuses.
Dans une étape ultérieure 94, le serveur 60 remplace chaque valeur d'index nulle, s'il en existe, par la valeur de la tranche précédente. Ainsi, sur le tableau 92, l'index était à 0 pour la tranche 3 en heures creuses alors qu'il était à une valeur de 33 pour la tranche 2 au même tarif horaire. Il s'ensuit qu'aucune consommation de courant électrique n'a eu lieu pendant la tranche 3 pour ce tarif. L'index reste en fait inchangé et est donc mis à la valeur 33.
A l'étape suivante 96, le serveur 60 procède au calcul des valeurs de consommation pour chaque tranche et pour chaque tarif horaire. En l'espèce, la consommation pour chaque tranche n est égale à la valeur de l'index pour cette tranche diminuée de la valeur de l'index pour la tranche précédente n-1. On obtient ainsi un tableau 97 listant les valeurs des consommations de courant en kWh pour les différents tarifs horaires indiqués en colonne et pour chaque tranche indiquée en ligne.
A l'étape ultérieure 98, le serveur 60 effectue le calcul de la consommation maximale entre les deux dates définissant la période considérée et ce pour chaque tarif horaire. Le calcul de cette valeur maximale de consommation va permettre d'adapter l'échelle de l'axe des ordonnées de la représentation graphique afin de rendre celle-ci la plus claire possible pour sa consultation par le client. Par exemple, on choisira cette échelle pour interrompre l'axe des ordonnées à cette valeur maximale ou bien juste au- dessus.
Enfin, dans une étape 100, le serveur 60 procède à la génération de l'image en représentant dans un diagramme 102 chaque tranche par une barre verticale. En outre, pour prendre en compte les différents tarifs horaires, chaque barre est au besoin subdivisée en différentes fractions empilées correspondant aux consommations pour les différents tarifs horaires. Sur le diagramme 102, 24 barres ont donc été affichées successivement, l'axe des abscisses présentant le temps divisé en 24 heures et l'axe des ordonnées présentant la valeur de la consommation en courant électrique. La plupart des barres telles que la barre 104 sont représentées avec une seule couleur ou d'une seule façon car elles renvoient à un seul tarif horaire tandis que d'autres barres telles que les barres 106 correspondent à des tranches au cours desquelles le tarif horaire a changé de sorte que leur consommation est fragmentée en deux parties visualisées de façon différente. Le client pourra ainsi visualiser la quantité de courant consommée pour chaque tarif au cours de cette heure. Ce diagramme est affiché dans le widget 110, lui même affiché sur l'écran 1 12 de l'ordinateur 64.
On a illustré à la figure 5 les étapes mises en œuvre par le système pour la génération dans le widget d'une courbe correspondant cette fois à la consommation hebdomadaire, c'est-à-dire sur les sept derniers jours jusqu'à la veille minuit par rapport au jour de la consultation. Les étapes mises en œuvre sont identiques ou similaires à celles de la figure 3. On ne présentera dans la suite que les étapes qui varient. Ainsi, cette fois à l'étape 68, la date_1 est choisie pour être antérieure d'une semaine à la deuxième date, date_2, égale à minuit de la veille. Le tableau 76 est inchangé par rapport à celui de la figure 3.
Au cours de l'étape 82, le découpage de la période se fait cette fois par tranches journalières et non plus par tranches horaires. Il aboutit ainsi au tableau 1 10 analogue au tableau 89. La première tranche couvre l'intervalle de temps compris entre la date du 3/10/07 à 12 h 15 et le 4/10/07 à 12 h 05. La deuxième tranche couvre l'intervalle de temps compris entre le 4/10/07 à 12 h 15 et le 5/10/07 à 12 h 05.
Le tableau 92 est similaire à celui de la figure 3. Il en est de même pour le tableau suivant. A l'étape 96, pour le calcul des consommations par tranches, on aboutit à un tableau 98 similaire à celui de la figure 3, chaque tranche étant toutefois ici une tranche journalière.
Le diagramme 112 qui est obtenu se présente de la même façon que le diagramme 102. Toutefois, chaque barre représente ici la consommation d'une journée de la semaine considérée. Chaque barre peut se trouver subdivisée en différentes parties successives empilées l'une au-dessus de l'autre, ces différentes parties renvoyant à des consommations obéissant à différents tarifs horaires.
On peut prévoir que les courbes de consommation, plutôt qu'être envoyées sur un ordinateur 64, sont envoyées sur un appareil numérique portable de poche tel qu'un téléphone mobile 120 ou un assistant personnel de type PDA. Cet envoi peut se faire via un réseau de téléphonie mobile au moyen d'au moins une antenne 22, ce réseau communiquant avec le réseau 14. L'appareil 120 étant un appareil de poche, le client associé à l'installation 4 peut être informé de sa consommation de courant électrique même s'il se trouve en un lieu éloigné de cette installation. Cette information peut se faire sur requête du client envoyée à partir de ce téléphone ou bien à dates régulières, le serveur 60 transmettant au client sur son appareil 120 de façon spontanée les courbes précitées. Cet envoi pourra se faire par exemple au moyen de la technologie de téléphonie mobile de troisième génération appelée UMTS (Universal Mobile Télécommunications System).
On pourra prévoir une communication des données au moyen d'une page web autre qu'un widget.
Diffusion par un objet communicant
Un autre aspect du procédé selon l'invention va être présenté en référence à la figure 6. Cette fois, les informations de consommation sont communiquées au client 4 par l'intermédiaire d'un objet 122. Il s'agit d'un objet communicant d'un type connu en soi. Cet objet a par exemple l'allure d'un personnage ou d'un animal. Il est sans écran. Il comprend des moyens le rendant apte, sans l'intermédiaire d'un ordinateur, à recevoir des informations par Internet et donc en l'espèce à partir du réseau 14 et par l'intermédiaire de la passerelle 12. Il peut en particulier se connecter directement à cette passerelle au moyen d'une liaison sans fil. Ayant reçu ces informations sous la forme d'un message, il est apte à les diffuser sous forme sonore au moyen d'un haut-parleur. Il peut également adresser à son environnement immédiat des signaux lumineux. Il peut en outre disposer de parties mobiles permettant de simuler des gestes. Un tel objet est par exemple connu sous la désignation de "Nabaztag" en ayant la forme d'un lapin stylisé capable d'agiter les oreilles. Naturellement, le procédé peut être mis en œuvre au moyen d'objets communicants autres que celui de ce dernier exemple.
En variante, l'objet 122 pourra comporter un écran et/ou un ordinateur. Dans cet aspect de l'invention, le système prépare un jeu de messages vocaux et l'adresse à l'objet communicant 122. Pour cela le fabricant de ce type d'objet met à disposition une ou plusieurs interfaces de programmation permettant d'en exploiter les fonctionnalités. Ces interfaces sont connues en elles-mêmes et ne seront pas décrites plus en détail. On peut prévoir par exemple deux types de messages. Il peut s'agir d'un message journalier constitué par une annonce vocale par l'objet du récapitulatif de la consommation électrique de la veille, par exemple de minuit à minuit. Il peut également s'agir d'un message hebdomadaire constitué par l'annonce verbale par l'objet 122 du comparatif de consommation électrique de la semaine passée (par exemple les sept jours précédents) avec la consommation électrique de la semaine précédente (de sept à quatorze jours précédents).
Pour l'envoi du message journalier, les étapes mises en œuvre sont illustrées à la figure 6. A l'étape 124, le serveur d'application 60 se connecte à la base de données 22. Si cette connexion est impossible, le serveur émet un message d'erreur à destination des opérateurs du système.
Lors de l'étape ultérieure 126, le serveur 60 récupère depuis la base la liste 128 des clients ayant souscrit au service de messagerie journalier par ce type d'objet ainsi que les données les concernant. Ces données sont regroupées dans les différentes colonnes du tableau 128. On trouve ainsi dans la première colonne 130 l'identifiant de l'objet 122, dans la deuxième colonne 132 l'heure souhaitée pour l'annonce vocale, et dans la colonne 134 les jours souhaités pour cette annonce vocale. L'heure et les jours auront été choisis précédemment par le client 4 concerné. On observe ainsi que le client associé à l'objet de la première ligne souhaite une annonce vocale à 10 h tous les jours du lundi au dimanche. Le client associé à l'objet de la deuxième ligne souhaite une annonce vocale à 21 h le samedi et le dimanche seulement. Le client associé à la troisième ligne souhaite une annonce vocale à 7 h du lundi au vendredi seulement. Sachant qu'un même client 4 peut détenir plusieurs objets 122, plusieurs lignes du tableau 128 pourront concerner un même client 4.
Lors d'une étape ultérieure 136, le serveur 60 vérifie une ligne du tableau 128 si le jour et l'heure actuels correspondent au jour et à l'heure configurés pour l'annonce. Dans la négative, ce qui sera le cas le plus fréquent, le serveur 60 passe à la ligne suivante et procède à la même vérification. Une fois que le tableau 128 a été ainsi parcouru intégralement, le serveur repasse à la première ligne du tableau. L'étape ultérieure 138 ne concerne donc que le cas où il a été constaté que la date et l'heure actuelles correspondent à celles configurées pour l'annonce.
Au cours de cette étape suivante 138, le serveur 60 détermine les deux dates limites entre lesquelles les index seront récupérés. Il associe ainsi à la date_2 la date du jour courant à minuit et à la première date la date_2 moins 24 heures. La première date précède donc de 24 heures la deuxième. Dans le présent exemple, la date_1 correspond donc au 9 octobre 2007 à minuit et la date_2 au 10 octobre 2007 à minuit.
Au cours de l'étape ultérieure 140, le serveur 60 obtient de la base 22 les valeurs d'index maximales de chaque tarif horaire pour l'intervalle de temps entre ces deux dates. Ainsi, on voit sur le tableau 142 que la valeur d'index maximale est à 0 pour le tarif de base, à 38 pour le tarif heures pleines et à 47 pour le tarif heures creuses. Cette obtention des valeurs maximales se fait de la même façon que lors de l'étape 74 de la figure 3.
A l'étape ultérieure 144, le serveur 60 obtient de la base de données 22 la valeur maximale des index pour chaque tarif horaire avant la première date. Ici, dans la table 146 consultée à cette fin, le maximum pour le tarif heures pleines est à 14 et le maximum pour le tarif heures creuses à 18, le maximum étant à 0 pour le tarif de base.
Au cours de l'étape ultérieure 148, le serveur 60 procède au calcul d'une valeur de consommation pour chaque tarif. Pour cela, pour chaque tarif, il soustrait à la valeur maximale d'index de la période la valeur maximale d'index avant la période. Ainsi, sur le tableau 150, l'index reste à 0 pour le tarif de base. Le maximum 14 du tableau 146 est ôté du maximum 38 du tableau 142 pour donner une valeur de consommation à 24 kWh pour le tarif heures pleines. De même, on obtient une valeur de consommation à 29 kWh pour le tarif heures creuses. Au cours de l'étape ultérieure 152, le serveur 60 procède à la formation du message sonore à envoyer à l'objet communicant en effectuant notamment la somme des consommations pour les trois tarifs, ce qui correspond ici à 53 kWh. Le message préparé est ici "Hier, vous avez consommé 53 kWh".
Au cours d'une étape ultérieure 154, le serveur d'application 60 envoie via le réseau 14 ce message à un serveur 158 gérant la communication avec les objets communicant 122 et dédié à ceux-ci. Ce serveur est en général commandé par le fabricant de ces objets. L'envoi a lieu avec les données d'identification de l'objet 122 du client. Cet envoi prend ici la forme d'une requête de type http.
Au cours d'une étape ultérieure 156, et en pratique immédiatement après le serveur 158 adresse, via le réseau 14, une réponse au serveur 60 lui indiquant que cet envoi a été convenablement reçu par le serveur. Si, au contraire, aucun accusé réception n'est reçu par le serveur 60 ou si un message indiquant une réception erronée est reçu, le serveur d'application génère un message d'erreur à destination des opérateurs du système. Le message convenablement reçu par le serveur 158 est ensuite diffusé par ce dernier via le réseau 14 jusqu'à l'installation 4. Arrivant à la passerelle 12, il est envoyé jusqu'à l'objet 122 pour être diffusé sous forme sonore au sein de l'installation 4 à destination de ses occupants.
Au cours d'une étape ultérieure 158, le serveur d'application 60 enregistre la date d'envoi de ce message.
Enfin, au cours de l'étape 160, le serveur 60 retourne à l'étape 136 et exécute cette dernière en passant à la ligne suivante du tableau 128.
On a illustré à la figure 7 les étapes de la mise en œuvre du procédé dans le cas où l'annonce effectuée par l'objet communicant 122 correspond à la consommation hebdomadaire. Les étapes sont analogues et seules celles qui diffèrent de celle de la figure 6 seront énoncées. Ainsi, cette fois, au cours de l'étape 162 qui fait suite à l'étape 124, le serveur d'application 60 récupère dans la base de données 22 la liste 123 des clients ayant souscrit au service de message hebdomadaire plutôt que la liste 128 de ceux ayant souscrit au service de message journalier. La table 163 comprend donc, après la première colonne 164 consacrée à l'identifiant de l'objet communicant, une deuxième colonne 166 relative à l'heure prévue pour la diffusion du message et une troisième colonne 168 indiquant le jour souhaité pour la diffusion du message. Ainsi, en ce qui concerne la première ligne, il est prévu que le message soit envoyé à l'objet 122 de l'installation 4 chaque lundi à 10 h. L'étape 136 est inchangée par rapport à celle de la figure 6. Au cours de l'étape 170 qui lui fait suite, le serveur d'application 60 détermine les trois dates entre lesquelles les données seront récupérées, à savoir les première, deuxième et troisième dates. La troisième date est celle du jour courant à minuit. La deuxième date précède la troisième de sept jours et la première date précède la deuxième de sept jours. Ainsi, dans le présent exemple, la date_1 est fixée au 1er octobre 2007 à minuit, la date_2 est fixée au 8 octobre 2007 à minuit et la date_3 est fixée au 15 octobre 2007 à minuit.
Au cours d'une étape ultérieure 172, le serveur 60 obtient les index maximum pour chaque période séparée par deux successives de ces dates et pour chaque tarif horaire. S'il n'y a pas de valeur maximale d'index, celle-ci est mise à 0. Ainsi, on observe, sur le tableau 174, que pour la période comprise entre la première date incluse et la deuxième date incluse, la valeur est à 0 pour l'index maximal du tarif de base, à 22 pour l'index maximal du tarif heures pleines et à 47 pour l'index maximal du tarif heures creuses. Pour la période suivante comprise entre la date_2 (exclue) et la date_3 (incluse), ces valeurs sont respectivement à 0, 38 et 59. Au cours d'une étape ultérieure 176, le serveur d'application 60 détermine la valeur maximale des index avant la première date pour chaque tarif horaire. Comme indiqué sur le tableau 178, ces valeurs sont respectivement à 0, 14 et 18.
Au cours d'une étape ultérieure 180, le serveur 60 calcule la consommation pour chaque tarif horaire pour chacune des deux périodes d'une semaine en soustrayant au maximum de la période en question celui de la période précédente. Ainsi, pour la consommation lors de la première période définie par les première et deuxième dates, la consommation au tarif heures pleines s'obtient en ôtant 14 de 22, ce qui donne 8. Au tarif heures creuses, elle s'obtient en ôtant 18 de 47, ce qui donne 29. De même, pour la deuxième période (entre les dates 2 et 3), la consommation au tarif heures pleines s'obtient en ôtant 22 de 38, ce qui donne 16. Au tarif heures creuses, elle s'obtient en ôtant 47 de 59, ce qui donne 12. Pour les deux périodes, la consommation est nulle pour le tarif de base.
Au cours d'une étape ultérieure 182, le serveur 60 procède à la formation du message sonore à envoyer à l'objet communicant en comparant les deux valeurs des sommes des consommations. Ce message sera par exemple du type "Cette semaine, vous avez consommé 9 kWh de moins que la semaine précédente" . Il ne s'agit que d'un exemple. On pourrait naturellement prévoir un message plus complet ou plus étoffé donnant le détail de chaque consommation pour chaque période.
Les quatre étapes suivantes 154, 156, 158 et 160 sont les mêmes que celles de la figure 6.
Envoi d'un message d'alerte
On peut également prévoir que le système est configuré pour l'envoi d'un message d'alerte au client de l'installation 4 lorsque la consommation d'une période prédéterminée dépasse un seuil préalablement choisi par ce client. Il peut s'agir par exemple de la consommation d'une journée. A cette fin, le procédé dont les étapes sont illustrées à la figure 8 est exécuté de façon périodique, par exemple toutes les 20 minutes. En l'espèce, il s'agit d'envoyer un message d'alerte par SMS (Short Message Service). Au cours d'une étape 200, le serveur d'application 60 se connecte à la base de données 22.
Au cours d'une étape 202, il obtient la liste des clients ayant souscrit à ce service d'alerte ainsi que les données les concernant. Il obtient ainsi un tableau 204 présentant dans des colonnes successives 206 l'identité du client, 208 son numéro de téléphone, 210 le seuil de consommation qui, une fois qu'il est franchi, doit servir à déclencher une alerte, et 212 la date d'envoi du dernier message.
Les étapes suivantes sont mises en œuvre par le serveur 60 pour chaque ligne du tableau 204. On va donc supposer dans la suite qu'on traite la première ligne.
Au cours de l'étape 214, le serveur identifie le dernier timbre horaire enregistré pour ce client.
Il détermine ensuite à l'étape 216 les deux dates limites entre lesquelles les index devront être obtenus, à savoir les première et deuxième dates. La deuxième date est celle du dernier timbre horaire enregistré et la première date est celle la plus proche de l'heure de minuit du jour correspondant à la deuxième date comme illustré sur le diagramme 217. Au cours d'une étape ultérieure 218, le serveur 60 obtient les valeurs d'index maximales pour chaque tarif horaire de la période 219 délimitée par les dates 1 et 2. Sur Ie tableau 220, on voit que ces maxima pour les tarifs de base, heures pleines et heures creuses sont respectivement de 0, 38 et 47 kWh.
Lors de l'étape suivante 222, le serveur 60 détermine les valeurs maximales des index pour chaque tarif horaire avant la première date. Ces valeurs maximales sont ici identifiées respectivement à 0, 14 et 18 kWh pour les trois tarifs.
A l'étape suivante 224, le serveur effectue le calcul de la consommation pour la période considérée pour chaque tarif horaire. Pour cela, il soustrait le maximum précédant la première date du maximum concernant la période. Ainsi, pour le tarif heures pleines, il soustrait 14 de 38, ce qui donne une consommation de 24 kWh. De même, pour le tarif heures creuses, il soustrait 18 de 47 pour obtenir une consommation de 29 kWh. La consommation au tarif de base est ici nulle.
A l'étape suivante 226, le serveur 60 effectue la somme de la consommation pour les trois tarifs qui est ici de 53 kWh, puis procède à la comparaison de ce total avec le seuil fixé. A l'étape suivante 228, si le seuil est dépassé et si la date du dernier envoi est antérieure à la première date, alors le serveur 60 prépare le message à envoyer. Dans le cas contraire, il revient à l'étape 214 et reprend le tableau 204 au client suivant.
Si un message a été préparé, le serveur 60, à l'étape 230, envoie le message à un serveur 232 dédié à l'expédition de ce type de message, avec le numéro de téléphone du client. Un tel serveur 232 dédié à la gestion et à l'envoi des messages de type SMS est connu en lui-même et relié au réseau 14. C'est par l'intermédiaire de ce dernier que le serveur 60 lui adresse le message à expédier.
Lors d'une étape ultérieure 234, le serveur 232 expédie au serveur d'application 60, via le réseau 14, un accusé de bonne réception du message au serveur. Si cet accusé de bonne réception n'est pas reçu par le serveur 60, ce dernier signale une erreur aux opérateurs du système.
Le serveur 232 procède par ailleurs à l'envoi du message à destination de l'appareil numérique de poche 120 du client 14. Ce message est envoyé au moyen d'une antenne
122 d'un réseau de téléphonie mobile relié au réseau Internet. Comme précédemment, l'appareil 120 est un appareil de poche pouvant être consulté par son possesseur dans un endroit quelconque, et notamment à distance de l'installation 4.
A l'étape 236, le serveur d'envoi 60 enregistre dans le tableau 204 de la base de données 22 la date d'envoi du message afin de mettre à jour la ligne correspondante du client. Durant l'étape 238, le serveur 60 retourne à l'étape 214 et aborde la ligne suivante du tableau 204. Cet enchaînement d'étapes est effectué par exemple toutes les 20 minutes par le serveur 60 mais cette période pourrait être choisie à une valeur quelconque entre une minute et deux heures par exemple. Dans le présent exemple, si le seuil est dépassé plus d'une fois dans la journée, le message n'est pas envoyé à chaque exécution des étapes de la figure 8.
Le ou les procédés qui viennent d'être présentés sont mis en œuvre par les serveurs et/ou les appareils et dispositifs dont il a été question. Ceux-ci, notamment les serveurs, comprennent à cette fin des moyens pour cette mise en œuvre tels que unité centrale, horloge, mémoire, organes d'envoi et de réception de données sur le réseau 14, etc.. L'exécution du ou des procédés est commandée par les instructions d'un programme enregistré dans ces serveurs, appareils et/ou dispositifs selon les étapes mises en œuvre.
Ces programmes pourront être aussi enregistrés sur un support d'enregistrement classique tel qu'un DVD. On prévoit en outre la mise à disposition de ces programmes sur internet en vue de leur téléchargement, par exemple le téléchargement d'une version de mise à jour, ce téléchargement pouvant être en accès restreint pour être réservé à des personnes autorisées.
Ainsi, comme on le voit, les données de consommation, après avoir été collectées et traitées, peuvent être communiquées à la personne physique correspondant à l'installation 4 sous diverses formes, qu'il s'agisse de widgets apparaissant sur l'ordinateur
64 ou sur l'appareil 120, de messages sonores diffusés par l'objet 122 ou de messages d'alerte envoyés à l'appareil 120.
Le procédé permet de s'approcher d'assez près d'une véritable situation de synchronisme entre la réalité qui est mesurée (à savoir les index sur le compteur) et les informations effectivement disponibles dans la base de données 22 puis envoyées au client associé à l'installation 4. Naturellement, ce synchronisme n'est qu'approché et n'est pas atteint dans la mesure où on doit tenir compte de :
- la fréquence du relevé des index au niveau du compteur électronique 8 du client ;
- la fréquence de collecte de ces données par le deuxième module 10 pour leur envoi au serveur frontal 18 ;
- la fréquence de récupération des données par le serveur de traitement 20 ; et enfin
- la fréquence d'exécution des étapes des figures 3 et 5 à 8 selon les cas. Toutefois, en cumulant ces différentes fréquences, qui sont dans le présent exemple fixées respectivement à 10 minutes (relevé d'index), 3 heures (fréquence de collecte), 30 minutes (récupération à partir du serveur frontal), on obtient selon le mode de communication au client un retard situé entre 3 heures 40 minutes et 4 heures. La personne responsable de l'installation 4 est donc par exemple informée avec un retard raisonnable et relativement bref que le seuil de consommation a été franchi.
Bien entendu, on pourra apporter à l'invention de nombreuses modifications sans sortir du cadre de celle-ci. Certaines au moins des données communiquées et/ou affichées pourraient comprendre des montants de quantité de ressource facturée, par exemple en euros, plutôt que des indications de quantité consommées en unités, par exemple en kWh.
Indépendamment des autres caractéristiques du procédé, on pourra prévoir de commander l'affichage des données de consommation d'une ressource de sorte qu'il génère au moins une zone graphique constituée de parties associées à des conditions respectives différentes de fourniture de la ressource, par exemple des conditions tarifaires.

Claims

REVENDICATIONS
1. Procédé caractérisé en ce qu'on commande une diffusion de données relatives à une consommation d'une ressource consommée directement à partir d'un réseau de distribution (5) par une installation (4), de sorte que la diffusion a lieu au moyen d'un objet (122) sans écran apte, sans l'intermédiaire d'un ordinateur, à recevoir des informations par Internet et à les diffuser sous forme sonore.
2. Procédé selon la revendication précédente dans lequel la ressource est de nature énergétique, par exemple du courant électrique.
3. Procédé selon l'une quelconque des revendications précédentes dans lequel l'installation (4) est une habitation.
4. Procédé selon l'une quelconque des revendications précédentes dans lequel la commande a lieu à distance de l'installation (4).
5. Procédé selon l'une quelconque des revendications précédentes dans lequel on commande une obtention des données, les données concernant par exemple la consommation entre deux dates prédéterminées.
6. Procédé selon l'une quelconque des revendications précédentes dans lequel les données sont relatives à des intervalles de temps différents et on commande un regroupement des données relatives à un même intervalle de temps.
7. Procédé selon l'une quelconque des revendications précédentes dans lequel, pour au moins un intervalle de temps, on commande une détermination d'une valeur maximale des données relatives à l'intervalle.
8. Procédé selon l'une quelconque des revendications précédentes dans lequel, pour au moins un intervalle de temps, on commande une détermination d'au moins une valeur de quantité consommée de la ressource pendant l'intervalle.
9. Procédé selon l'une quelconque des revendications précédentes dans lequel on diffuse les données sous forme sonore.
10. Procédé selon l'une quelconque des revendications précédentes dans lequel au préalable: - un premier serveur (18) commande un enregistrement des données sous forme linéarisée; et
- un deuxième serveur (20) commande une obtention des données à partir du premier serveur et leur délinéarisation.
1 1. Procédé caractérisé en ce qu'on commande un agencement de données, relatives à une consommation d'une ressource consommée directement à partir d'un réseau de distribution (5) par une installation (4), sous une forme permettant leur diffusion au moyen d'un objet (122) d'un type prédéterminé, sans écran et apte, sans l'intermédiaire d'un ordinateur, à recevoir des informations par Internet et à les diffuser sous forme sonore.
12. Serveur (60) caractérisé en ce qu'il comprend des moyens pour commander un agencement de données relatives à une consommation d'une ressource consommée directement à partir d'un réseau de distribution (5) par une installation (4), sous une forme permettant leur diffusion au moyen d'un objet (122) d'un type prédéterminé, sans écran et apte, sans l'intermédiaire d'un ordinateur, à recevoir des informations par Internet et à les diffuser sous forme sonore.
13. Ensemble comprenant au moins un serveur (60) selon la revendication précédente et une base de données (22).
14. Procédé caractérisé en ce qu'on reçoit des données, relatives à une consommation d'une ressource consommée directement à partir d'un réseau de distribution (5) par une installation (4), sous une forme permettant leur diffusion au moyen d'un objet (122) d'un type prédéterminé, sans écran et apte, sans l'intermédiaire d'un ordinateur, à recevoir des informations par Internet et à les diffuser sous forme sonore.
15. Programme d'ordinateur comprenant des instructions aptes à commander la mise en œuvre d'un procédé selon l'une quelconque des revendications 1 à 11 et 14.
16. Support d'enregistrement comprenant un programme selon la revendication précédente.
17. Mise à disposition d'un programme selon la revendication 15 en vue de son téléchargement.
PCT/FR2009/050183 2008-02-05 2009-02-05 Procede de diffusion de donnees relatives a une consommation d'une ressource au moyen d'un objet communicant WO2009101336A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0850728 2008-02-05
FR0850728A FR2927189A1 (fr) 2008-02-05 2008-02-05 Procede de diffusion de donnees relatives a une consommation d'une ressource au moyen d'un objet communicant

Publications (1)

Publication Number Publication Date
WO2009101336A1 true WO2009101336A1 (fr) 2009-08-20

Family

ID=39884525

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2009/050183 WO2009101336A1 (fr) 2008-02-05 2009-02-05 Procede de diffusion de donnees relatives a une consommation d'une ressource au moyen d'un objet communicant

Country Status (2)

Country Link
FR (1) FR2927189A1 (fr)
WO (1) WO2009101336A1 (fr)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2016056961A1 (fr) * 2014-10-07 2016-04-14 Telefonaktiebolaget L M Ericsson (Publ) Procédé et système destinés à produire des données sonores pour générer une notification audible liée à la consommation d'énergie

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2001006432A1 (fr) * 1999-07-15 2001-01-25 Ebidenergy.Com Interface utilisateur permettant de faciliter, d'analyser et de gerer la consommation de ressources
WO2001074045A1 (fr) * 2000-03-24 2001-10-04 Abb Metering Ltd. Transmission d'informations de commande
EP1178616A1 (fr) * 2000-08-02 2002-02-06 Xeline Co., Ltd. Compteur d'électricité et système pour la transmission de signaux par les lignes d'alimentation
WO2006096854A2 (fr) * 2005-03-08 2006-09-14 E-Radio Usa, Inc. Systemes et procedes destines a modifier l'utilisation de l'energie
US20070008171A1 (en) * 2005-07-06 2007-01-11 Bowman Eric L Wireless meter-reading system and methods thereof

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2001006432A1 (fr) * 1999-07-15 2001-01-25 Ebidenergy.Com Interface utilisateur permettant de faciliter, d'analyser et de gerer la consommation de ressources
WO2001074045A1 (fr) * 2000-03-24 2001-10-04 Abb Metering Ltd. Transmission d'informations de commande
EP1178616A1 (fr) * 2000-08-02 2002-02-06 Xeline Co., Ltd. Compteur d'électricité et système pour la transmission de signaux par les lignes d'alimentation
WO2006096854A2 (fr) * 2005-03-08 2006-09-14 E-Radio Usa, Inc. Systemes et procedes destines a modifier l'utilisation de l'energie
US20070008171A1 (en) * 2005-07-06 2007-01-11 Bowman Eric L Wireless meter-reading system and methods thereof

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
TWEEDY S B: "Remote meter displays", METERING APPARATUS AND TARIFFS FOR ELECTRICITY SUPPLY, 1992., SEVENTH INTERNATIONAL CONFERENCE ON GLASGOW, UK, LONDON, UK,IEE, UK, 1 January 1992 (1992-01-01), pages 202 - 206, XP006514665, ISBN: 978-0-85296-555-9 *

Also Published As

Publication number Publication date
FR2927189A1 (fr) 2009-08-07

Similar Documents

Publication Publication Date Title
CN104903927A (zh) 服务器装置及服务器程序
EP1916623A1 (fr) Procédé de fourniture de données de transactions, terminal, procédé de transaction, procédé d'enrichissement de relevés bancaires, serveur, signaux et produits programme d'ordinateur correspondants.
US20080298567A1 (en) Web based telephone management system
WO2001030093A1 (fr) Systeme et procede de transmission de messages, et utilisation du systeme de transmission pour l'investigation de services fournis
FR2837953A1 (fr) Systeme d'echange de donnees
US8447227B2 (en) Jukebox system
EP1260107B1 (fr) Procede pour echanger des informations entre plusieurs utilisateurs de telephones mobiles
WO2009101335A1 (fr) Procede d'affichage d'une consommation d'une ressource
EP1433322B1 (fr) Procede de transmission d'emissions audiovisuelles proposees par des utilisateurs, terminal et serveur pour la mise en oeuvre du procede
WO2009101336A1 (fr) Procede de diffusion de donnees relatives a une consommation d'une ressource au moyen d'un objet communicant
FR2819606A1 (fr) Procede de traitement d'annonces sur un terminal de reseau informatique et terminal pour mettre en oeuvre le procede
FR3033638A1 (fr) Procede et systeme de releve d'un compteur de consommation
WO2009101337A1 (fr) Procede de transmission de donnees relatives a la consommation d'une ressource sur un appareil de poche
WO2009101334A2 (fr) Procede de traitement de donnees de consommation d'une ressource telle que du courant electrique
CA2397888A1 (fr) Systeme et procede de stockage et de traitement de donnees a l'aide d'un telephone mobile
EP2553906B1 (fr) Procédé d'acquisition par un terminal mobile d'informations complémentaires liées à au moins une affiche présente sur un panneau d'affichage
FR2916070A1 (fr) Procede de delivrance de billets.
FR2910764A1 (fr) Procede de transmission d'accuse reception d'un message destine a plusieurs appareils, appareil et serveur mettant en oeuvre le procede
WO2010007330A2 (fr) Procede et dispositif lumineux d'information de la consommation d'une installation
FR2832532A1 (fr) Procede de programmation a distance et de telecommande d'equipements situes dans differentes zones d'un batiment
WO2023169922A1 (fr) Procede de partage de documents electroniques energetiquement sobre et systeme associe
WO2005034541A1 (fr) Procede, systeme et equipement pour la diffusion vers des terminaux d’informations relatives a des evenements futurs
CN111241219A (zh) 数据传输展示方法、装置、存储介质及处理器
FR2845852A1 (fr) Procede et systeme de messagerie automatique a transmission declenchee par une action du destinataire, et application
EP0612429A1 (fr) Procede et installation de diffusion de messages sur un reseau d'ecrans video

Legal Events

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

Ref document number: 09710760

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 09710760

Country of ref document: EP

Kind code of ref document: A1