Estimating the lifespan of a battery of a device associated with a tyre

Abstract

The invention relates to a method for estimating the lifespan of a battery (27) of a device (20) associated with a tyre (11) of a motor vehicle, comprising steps of: transmitting (S1) a frame (40) to a remote receiver unit (30), containing a value of an incrementation indicator (442) that is incremented at the time of transmission; comparing (S2) said value to a threshold value (Ids) corresponding to a threshold population (Ps) associated with an end of life, by means of a statistical chart (51); determining (S3) an estimate of said lifespan based on said comparison.

Description

DESCRIPTION Estimating the lifespan of a battery in a device associated with a tire TECHNICAL FIELD

[0001] This description relates to the transmission of measurement data between a device associated with a mounted assembly comprising a tire and a wheel, and a remote receiving device. It applies particularly to devices incorporating sensors, such as temperature and pressure sensors, that measure the condition of the tire.

[0002] It is already known that vehicles have sensors on their tires, such as TPMS (Tire Pressure Monitoring System) devices, which monitor tire pressure. These systems use sensors installed inside or outside the tires to measure pressure; these measurements are then transmitted wirelessly to an electronic component of the vehicle to warn the driver in case of a pressure problem.

[0003] More recently, more complex systems have emerged for tire management, the TMS (Tire Mounted System) systems which aim to multiply the sensors and provide advanced functionalities through the measured data.

[0004] However, due in particular to the increasing number of sensors and the growing volume of data to be transmitted, various technical challenges arise. These challenges are primarily related to the energy consumption of these electronic devices (TMS or TPMS), and also to radio transmission issues between them and the remote receiving organ.

[0005] Each transmission of a frame to the remote component generates energy consumption. However, for the most efficient pneumatic system management, it is important for the receiving component to have a significant amount of data, potentially of different types (pressure, temperature, etc.). Increasing the amount of data necessarily leads to an increase in the number of frames to be transmitted and therefore the energy consumption of the electronic device.

[0006] However, the electronic device is integrated with a tire and cannot be wired to the vehicle in industrial mode. It must therefore be electrically powered by a battery. Its operating time thus depends primarily on the battery's capacity and power consumption. Furthermore, the electronic device may be difficult to access, or even completely inaccessible if it is located inside a tire, making battery replacement either impossible or undesirable.

[0007] It is therefore important to estimate the condition of the electronic device's battery and the (remaining) lifespan of that battery. DESCRIPTION OF THE INVENTION

[0008] The proposals described therefore aim to improve the situation compared to the state of the art, and in particular, to allow an accurate estimation of the remaining life of a battery of a device associated with a tire, without this estimation impacting the life.

[0009] To this end, according to a first aspect, a method is proposed for estimating the lifespan of a battery in a device associated with a tire of a motor vehicle, comprising the following steps: transmission of a frame to a remote receiving device containing a value of an increment indicator that is incremented during said transmission; comparison of said value to a threshold value corresponding to a threshold population associated with the end of its lifespan, using a statistical nomogram; and determination of an estimate of said lifespan based on this comparison

[0010] According to preferred embodiments, the process comprises one or more of the following features, which may be used separately, in partial combination, or in total combination: The frame further contains an identifier for the device; the nomogram is formed by accumulating increment indicator values ​​received from different devices and associates a received value of the increment indicator with a number of transmitted frames containing the received value; a detection that the value of the increment indicator is less than or equal to a previous value contained in a frame previously transmitted by the device; the statistical nomogram consists of a centralized platform connected to the remote receiving device and a set of other remote receiving devices. The remote receiving device transmits the estimate to equipment embedded in the motor vehicle and / or to equipment belonging to a fleet management system.

[0011] Another aspect concerns a centralized platform for estimating the lifespan of a battery in a device associated with a tire of a motor vehicle, comprising: an interface for receiving a message from a remote receiving organ, this message containing a value of an increment indicator and an identifier of said device; circuits adapted for comparing said value to a threshold value corresponding to a threshold population associated with an end of life, by means of a statistical nomogram, and for determining an estimate of said lifespan based on this comparison.

[0012] According to one embodiment, said circuits are further adapted to update said statistical nomogram according to said increment indicator and said identifier.

[0013] Another aspect relates to a system comprising a remote receiver for estimating the battery life of a device associated with a tire of a motor vehicle, adapted for reception of a frame transmitted by said device, said frame containing a value of an increment indicator; transmission of a message containing said value and an identifier of said device, to a centralized platform; and, this centralized platform as previously defined.

[0014] Another aspect concerns a computer program capable of being implemented on a device, the program comprising code instructions which, when executed by a processor, carries out the steps of the process as previously defined.

[0015] Another aspect concerns a data carrier on which at least one series of program code instructions for the execution of a process as previously defined has been stored. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] Other aspects, objectives, advantages and features of the invention will become more apparent from the following detailed description of preferred embodiments thereof, given by way of non-limiting example, and made with reference to the accompanying drawings in which: Figure 1 represents a context for implementing the method and devices described, Figure 2 schematically represents an architecture of a device according to one embodiment, Figure 3 illustrates an illustrative flowchart of a method according to one embodiment, Figure 4 illustrates an example of a frame transmitted between a device and a remote receiving organ, according to embodiments, Figure 5 illustrates an example of a payload of a frame transmitted between a device and a remote receiving organ, according to embodiments, Figure 6 illustrates an example of a statistical nomogram, according to one embodiment. DETAILED DESCRIPTION OF SPECIFIC METHODS OF IMPLEMENTATION

[0017] Figure 1 shows a mounted assembly, or wheel, 10 comprising a tire 11 and a rim 12. The wheel is intended to be mounted on a motor vehicle.

[0018] A device 20 is associated with the tire 11, that is to say adapted to provide information on the condition of this tire by means of sensors.

[0019] The device 20 can be positioned directly on or within the tire 11. In particular, this device can be positioned and fixed to an inner surface of the tire. The device 20 can also be positioned on the rim 12, or on a valve associated with the tire. Generally, the device 20 is attached to the mounted assembly 10.

[0020] This device is suitable for communicating measurements acquired by the sensors to a remote receiving organ 30.

[0021] This remote receiver 30 can be located within the motor vehicle. For example, it could be one of the circuits that make up the vehicle's dashboard.

[0022] The remote receiving unit 30 can also be located outside the vehicle. For example, it can be located in a station where the motor vehicle may be parked periodically. This could be a regular parking area for the vehicle, or a maintenance area, for example.

[0023] The remote receiving unit 30 can be designed to transmit data 72 to equipment 60 installed on the vehicle. This equipment can be logically linked to an interface on the vehicle's dashboard and adapted to display information related to this data, for example, a gauge indicating the remaining lifespan, or a warning signal if this lifespan falls below a predefined threshold.

[0024] The measurement data can be communicated by transmitting a data frame 40 to this remote receiving device. This frame 40 includes, in particular representative values ​​of these measurements, adapted for processing by the distant receptor organ 30.

[0025] Figure 2 schematically illustrates a possible architecture of such a device 20.

[0026] In this embodiment, sensors 21, 22, and 23 are integrated into the device's structure. Other embodiments may involve sensors located outside the device itself, capable of communicating with it via wired or wireless means, for example, using near-field communication (NFC). This example shows three sensors, but it is obviously possible to use fewer or more.

[0027] The device also includes processing means 24, or electronic circuits, typically comprising a microcontroller, or processor, and a memory 25.

[0028] Device 20 also includes a battery 27.

[0029] The device 20 also includes a radio frequency interface 26 adapted to transmit frames 40 to the remote receiving device 30. This radio interface 26 can conform to various radio communication mechanisms and protocols. In particular, it can conform to short-range radio communication protocols such as Wi-Fi or Wi-Fi Direct, Zigbee, Z-Wave, Bluetooth, or BLE.

[0030] In cases where the transmission itself needs to minimize the energy consumption of the transmitting device, the BLE protocol can be chosen.

[0031] The Bluetooth Low Energy (BLE) protocol is a version of the Bluetooth protocol designed to provide low-power wireless communications. BLE is standardized in the IEEE 802.15.1 standard and is part of the Bluetooth specifications adopted by the Bluetooth Special Interest Group (Bluetooth SIG).

[0032] The BLE protocol uses 2.4 GHz frequency bands and 40 channels distributed between 2402 and 2480 MHz and with a width of 2 MHz.

[0033] According to this protocol, three advertising or announcement channels are planned. These are specific channels used for broadcasting advertising messages or frames. Advertising is used, particularly for establishing a connection: devices listening on these channels can receive advertisements, which allows a device to initiate a connection. They can also be used to announce their presence (discovery mechanism) or for beacon-type signaling. Data is exchanged between participants after a connection is established, in frames transmitted over other channels.

[0034] The ad frames, transmitted through the ad channels, thus differ from the data frames transmitted through other channels.

[0035] The advertising channels are channels 37 (2402 MHz), 38 (2426 MHz) and 39 (2480 MHz). These three channels are strategically located within the frequency band to minimize interference with other technologies using the same band (such as Wi-Fi, which also operates in the 2.4 GHz band).

[0036] Establishing a connection between two parties in a BLE communication poses an energy consumption problem, particularly due to the synchronizations to be carried out between them and the multiple frequency hops to be made to transmit and listen in the correct channels.

[0037] Also, according to an embodiment based on this BLE protocol, it is chosen not to establish a connection between the device 20 and the remote receiving organ 30. In particular, the frames 40 are transmitted on an advertisement channel.

[0038] Figure 3 illustrates a flowchart of the described process, according to one embodiment. This flowchart shows a breakdown into steps, provided for illustrative purposes. It may be necessary to subdivide certain steps, combine others, or use a different breakdown that achieves the same final functionality.

[0039] According to this embodiment, in a step SI, the device 20 transmits a frame 40 to the remote receiving organ 30.

[0040] This frame can include a sequence of values ​​determined from measurements acquired by sensors 21, 22, 23. Such a frame can therefore be transmitted to several times over time in order to communicate the evolution of measurements taken by sensors 21, 22, 23.

[0041] Figure 4 illustrates a frame 40 in the case of an implementation according to the BLE protocol and transmission in advertising channels of this protocol. In this embodiment, the frame 40 comprises a preamble 41 of one byte, an address field 42 of four bytes, a header 43 of two bytes, and a payload 44 (or PDU for Protocol Data Unit). The frame also includes an error correction code (CRC) 45 of three bytes.

[0042] Preamble 41 is a synchronization field used to indicate the start of the frame.

[0043] For advertisement frames, address field 42 is fixed and has the value 0x8E89BED6. For data frames, this address is unique to the current connection between two devices.

[0044] Header 43 indicates the frame type: for example, a "connectionless communication" type for an advertisement frame. For such a frame, it also indicates the length of the payload 44, which can be between 0 and 37 bytes.

[0045] Also, the transmission of the sequence of values ​​is constrained in this payload to a maximum of 37 bytes.

[0046] As illustrated in the particular embodiment of Figure 5, this payload 44 can be used to transmit various information, for example: an identifier 441 of the device 20, an increment indicator 442, a format indicator 444, a sequence of values ​​443, determined from sensor measurements.

[0047] This device identifier 441 is a unique identifier, meaning that it allows device 20 to be identified in a unique way.

[0048] The 444 format indicator allows you to indicate the frame type and define a format for this sequence of values.

[0049] In particular, this format indicator can specify the type of measurement: pressure, temperature, acceleration, etc.; the unit of encoding of these measurements: pascals, hectopascals, bars..., degrees Celsius, Fahrenheit...; the type of encoding: each measurement on a fixed number of bits, or encoding with reference value and relative deviations; one or more sampling periods, and the corresponding subdivision of the sequence of values ​​according to these sampling periods, etc.

[0050] The order of the fields is illustrative.

[0051] The increment indicator 442 contained in the frame is incremented during frame transmission. Since the device transmits a sequence of frames over time, this increment indicator is incremented with each transmission.

[0052] This increment indicator allows a frame 40 to be uniquely identified among those transmitted by a device 20. In other words, the unique identifier pair 441 and increment indicator 442 uniquely identifies a frame 40 among the set of all frames.

[0053] Field 442 of frame 40 can be configured to allow for an incrementing function that ensures such uniqueness of frame identification. This uniqueness can be guaranteed for a sufficiently long period so as not to disrupt the creation of a statistical nomogram 51 based on these increment indicators, as will be discussed later. In particular, it can be configured so that this increment indicator 442 allows for uniqueness over a period of time at least equal to the (estimated) maximum lifetime of the device 20. For example, the field could contain a number of bits that encode a maximum value for the increment indicator, which statistically corresponds to a lifetime exceeding this maximum lifetime.

[0054] This maximum lifespan is an estimated duration provided by the device manufacturer and is assumed to be greater than the battery life 27 that we are trying to estimate.

[0055] For example, a 16-bit encoding can increment up to the decimal value 65536. This value roughly corresponds to the number of frames transmitted in a single week, assuming one transmission every 10 seconds. In other words, at the end of this period, the increment indicator 442 loops back to 0, and its uniqueness is lost over a period longer than approximately one week.

[0056] A 32-bit encoding can encode an increment indicator up to the value of 4,294,967,296, which statistically corresponds to a period of approximately 71,000 weeks, or 1,365 years for the same emission period. It is therefore possible to determine different encoding sizes for the increment indicator 442, ensuring its uniqueness over a desired time period, for example, the estimated maximum lifespan of device 20.

[0057] A compromise can also avoid encoding on too many bits which would limit the space available in frame 40 for other information, including data sequences determined from sensor measurements.

[0058] The increment indicator can be generated using a simple counter implemented by the circuits 24 of the device 20. During each transmission of a frame 40, this counter is incremented by one unit. It can be incremented before or after transmission, depending on operational choices.

[0059] The remote receiving device 30 can use the increment indicator to position the received frames relative to each other, that is, to order them. This increment number also makes it easy to identify frames that were not received. Thus, the content of a frame that was not received can be reconstructed, at least partially, by the remote receiving device 30, using the contents of the immediately preceding and following frames.

[0060] As mentioned previously, according to one embodiment, the frame also includes an identifier 441 of device 20.

[0061] In order to be able to construct a good statistical abacus 51, it may be provided that this identifier is a unique identifier, guaranteeing that two devices 20 cannot have the same identifier.

[0062] Typically this identifier 441 is a MAC address (for "Media Access Control" in English) uniquely assigned by the manufacturer of device 20. This identifier can then include a first part of 24 bits identifying the manufacturer (OUI for "Organizationally Unique Identifier" in English) and a second part of 24 bits identifying the device 20 among the different products of the manufacturer.

[0063] However, other embodiments are possible for identifying device 20.

[0064] In a step S2, the value of the increment indicator 442 is compared to a statistical nomogram 51.

[0065] According to one embodiment, this comparison can be carried out by the remote receiving organ 30. In this case, it can be provided that the statistical nomogram 51 is previously downloaded to it from, for example, a centralized platform 50. The remote receiving organ can also, in a step S3, determine an estimate of the (remaining) life of the battery 27 based on this comparison, in a way that will be explained later.

[0066] According to another embodiment, this comparison can be carried out by a centralized platform 50 which is in communication with the remote receiving organ 30.

[0067] In other words, according to different embodiments, the comparison steps S2 and the determination S3 of a lifetime estimate can be carried out by different entities of the proposed architecture, in particular by the remote receiving organ 30, or by the centralized platform 50.

[0068] As previously mentioned, the remote receiving unit 30 can be located on the vehicle or outside the vehicle (garage, maintenance area, etc.). The centralized platform It can be located away from this remote receiving organ. In particular, it can be deployed as a cloud computing service (or "cloud computer" in English), on a remote server or on a server farm.

[0069] It can be connected to the remote receiving organ via a WAN (Wide Area Network) type network such as the public Internet.

[0070] In this way, a single centralized platform 50 can be connected to a plurality of remote receiving organs 30 (which may correspond to a plurality of vehicles and devices 20).

[0071] The remote receiving organ 30 can transmit a message 70 containing the value of the increment indicator 442. This message can also contain the identifier 442 of the device 20.

[0072] The centralized (or "service") platform 50 includes an interface 52 for receiving this message 70 from remote receiving organ(s) 30.

[0073] It also includes circuits 53 adapted to perform the comparison (step S2) between the value contained in the received message 70 and a statistical nomogram 51. This statistical nomogram can also be contained in or associated with the centralized platform 50. The circuits 53 are also adapted to determine (step S3) an estimate of the lifespan of the device 20 based on this comparison.

[0074] Circuits 53 can be shared resources of a set of computer servers, including both computational resources (notably microprocessors) and memories.

[0075] The statistical abacus 51 can be a suitable data structure to allow the estimation of the lifespan of a device 20 from a value of its increment indicator 442.

[0076] This abacus can be seen as a function allowing to correspond, in a unique way, a value of an increment indicator 442 to a number of frames 40 containing such a value.

[0077] Knowing the total population of devices 20 that have transmitted at least one value of the increment indicator 442 (i.e., a frame 40), we can deduce a percentage of this population that has reached this value.

[0078] It is assumed that if a device has not transmitted a given increment indicator value, it means that it has ceased to function and, therefore, that the battery is depleted. Statistically, then, an estimate of the remaining battery life can indeed be based on these population percentages forming the statistical nomogram 51.

[0079] The lower the percentage, the lower the estimated lifespan. For example, if 2% of devices reach a certain value, it can be inferred that this value corresponds to a proximity to the end of their lifespan.

[0080] Using this abacus, we can compare the value of the increment indicator 442 contained in a frame received from device 20 with a value corresponding to a threshold population associated with an end of life.

[0081] This threshold population can be predetermined by the manufacturer or the device manager. A high threshold population can minimize risks by providing early warning of the statistical decrease in remaining lifespan. For example, a threshold population could be set at 90%.

[0082] Based on this threshold population, the statistical nomogram allows us to know a corresponding threshold value for the increment indicator.

[0083] Figure 6 illustrates an example of such a statistical nomogram.

[0084] The increment indicator Id is shown on the x-axis, and the population P is shown on the y-axis, that is, the number of frames received from a single device containing this value of the increment indicator.

[0085] A threshold population P is fixed beforehand s The nomogram allows us to determine (here graphically) a corresponding value (called the threshold value) ld sof the increment indicator.

[0086] When a frame is received, its increment indicator ld a can be compared to this threshold value ld s . In figure 6, this comparison is illustrated by the distance d.

[0087] This comparison can be expressed as an increment (or distance) number separating the two values. Thus, d = ld s - ld a This comparison therefore makes it possible to determine the number of frames that can be transmitted before reaching the threshold population P. s which corresponds to the end of the battery's life.

[0088] Knowing the rate, or period, at which frames 40 are emitted by device 20, we can immediately deduce an estimate of the battery life (in time) of this device 20. In other words, this estimate of the battery life is valid for a given rate, or period.

[0089] It should be noted that the transmission period of frames 40 can be modified (for example, by a command message sent to device 20 specifying new data for frame transmission, including measurement and transmission periods). Each modification can then update the battery life estimate of device 20.

[0090] According to one embodiment, this nomogram can be supplied by the manufacturer of the devices 20, or by a third party in charge of its constitution.

[0091] According to another embodiment, it can be constituted by the centralized platform 50.

[0092] It can notably be constituted by accumulation of increment indicator values ​​received from different devices, connected to this centralized platform 50.

[0093] As illustrated in the following table, the abacus 51 can associate a received value, that is to say emitted by a device, (only the values ​​1, 2, 10 6 10 7 10 8 are represented here) to a number of received frames 40 containing this value. In other words, each possible value can be associated with a counter: each time a value is transmitted to the centralized platform 50, the latter increments the counter associated with the value received. Thus, statistical chart 51 can be updated for each increment indicator received.

[0094] [Table 1]

[0095] In this table, the first row represents increment indicator values, and the second row represents the population of devices 20 that have already transmitted this value as an increment indicator. The total number of devices 20 is assumed to be 10,000.

[0096] Just like the curve in Figure 6 discussed earlier, the table illustrates a constant decrease in the population as a function of this value, which represents the age of the device. 10 6 represents approximately ten days of life, 10 7 approximately 10 months and 10 8 approximately 9-10 years. Intermediate values ​​are also present in statistical abacus 51 (but not shown in the table for obvious reasons).

[0097] According to one embodiment, the constitution and updating of the statistical abacus 51 takes into account the identifier 441 of the device 20.

[0098] In particular, situations where the same device 20 has already transmitted an increment indicator value equal to or greater than the one just received are excluded from the creation and updating of statistical nomogram 51. This situation corresponds to a malfunction of device 20 or to a feedback loop of this indicator. This situation can be considered an aberrant case that we do not wish to include in the statistical nomogram.

[0099] In other words, according to one embodiment, an update can be performed upon receipt of a new value of the increment indicator by incrementing a counter associated with the value of this indicator if and only if this counter, or a counter of a higher value, has not already been incremented for this device.

[0100] This situation corresponds to a device that is no longer reliable, and it is no longer possible to estimate its lifespan. Therefore, it should no longer be taken into account when updating the nomogram.

[0101] The process can therefore detect, in a step S4, that the value of the increment indicator is less than or equal to a previous value contained in a frame previously emitted by the same device 20.

[0102] As described previously, the centralized platform 50 can then transmit the estimate of the (remaining) battery life to the remote receiving organ 30, or other equipment 60 of the motor vehicle, via a message 71.

[0103] The remote receiving unit 30 can transmit this estimate to this other equipment 60 via a message 72. This message 72 can use an internal communication network of the motor vehicle in the case where the remote receiving unit 30 is on board the vehicle.

[0104] This equipment 60 can be part of or work in conjunction with the vehicle's dashboard. In particular, it can be logically linked to a vehicle dashboard interface and adapted to display related data, for example, a gauge indicating the remaining lifespan, or a warning signal if this lifespan falls below a predefined threshold.

[0105] The battery life estimate can also be transmitted to a fleet management system. This allows the system to monitor the condition of its vehicle fleet and take timely action to replace a device.

[0106] Thus, the proposed method does not require any additional action on device 20 and therefore does not affect its power consumption. Without reducing the remaining lifespan of battery 27, the method allows for a statistically accurate estimate of its remaining lifespan.

[0107] Accuracy is all the more important given that the statistical nomogram contains data produced by numerous devices. This statistical nomogram is therefore preferentially fed by a centralized platform capable of collecting data. of a large number of vehicles. In particular, it can be supplied by fleet managers, by structures that interact with many vehicles, etc.

[0108] Many embodiment variants are possible, particularly regarding the distribution of the implementation of the different stages of the process between the remote receiving unit 30 and the centralized platform 50, in particular between the equipment present on the motor vehicle and that located outside of this vehicle.

[0109] More generally, these proposals are not limited to the examples and embodiments described and illustrated. They are particularly susceptible to numerous variations accessible to those skilled in the art, some of which have been described previously or simply mentioned.

Claims

DEMANDS 1. A method for estimating the lifespan of a battery (27) of a device (20) associated with a tire (11) of a motor vehicle, comprising the steps of: transmitting (S1) a frame (40) to a remote receiving device (30) containing a value of an increment indicator (442) incremented during said transmission; comparing (S2) said value to a threshold value (ld1). s ) corresponding to a threshold population (P s ) associated with an end of life, by means of a statistical abacus (51); determination (S3) of an estimate of said lifespan based on this comparison.

2. Method according to the preceding claim, wherein said frame further contains an identifier (441) of said device.

3. Method according to the preceding claim, wherein said nomogram is constituted by accumulation of increment indicator values ​​received from different devices and associates a received value of said increment indicator with a number of transmitted frames containing said received value.

4. A method according to any one of claims 2 or 3, further comprising a detection (S4) that said value of said increment indicator is less than or equal to a previous value contained in a frame previously emitted by said device.

5. Method according to claim 3, wherein said statistical nomogram (51) is constituted by a centralized platform (50) connected to said remote receiving organ (30) and to a set of other remote receiving organs.

6. A method according to any one of the preceding claims, wherein said remote receiving organ (30) transmits (72) said estimate to equipment (60) on board said motor vehicle, and / or to equipment of a motor vehicle fleet manager.

7. A centralized platform (50) for estimating the lifespan of a battery (27) of a device (20) associated with a tire (11) of a motor vehicle, comprising: an interface (52) for receiving a message (70) from a remote receiving device (30) containing a value of an increment indicator (442) and an identifier (441) of said device (20); circuits (53) adapted for a comparison (S2) of said value to a threshold value (Ids) corresponding to a threshold population (P s ) associated with an end of life, by means of a statistical abacus (51), and for a determination (S3) of an estimate of said lifespan based on this comparison.

8. Centralized platform (50) according to the preceding claim, wherein said circuits (53) are further adapted to update said statistical nomogram (51) according to said increment indicator and said identifier.

9. System comprising a remote receiving element (30) for estimating the life of a battery (27) of a device (20) associated with a tire (11) of a motor vehicle, adapted for receiving a frame (40) transmitted by said device (20), said frame containing a value of an increment indicator (442); a transmission of a message (70) containing said value and an identifier (441) of said device (20), to a centralized platform (50); and, said centralized platform according to any one of claims 7 to 8.

0. Computer program capable of being implemented on a device (20) or on a centralized platform (50), the program comprising code instructions which, when executed by a processor, carries out the steps of the process defined in claims 1 to 6.

Images