METHOD FOR APPLYING CORRECTIONS TO SMART COUNTER COMMANDS

Description

TECHNICAL FIELD

[0001] The present invention relates to the on-the-fly application of a patch to instructions executed by a smart meter. Applying a patch makes it possible to correct anomalies found in the instructions executed by the smart meter and / or to enhance operations performed by executing instructions by the smart meter. STATE OF PRIOR ART

[0002] Nowadays, water, gas, and electricity meters have become smart meters, meaning they integrate data processing and communication interfaces to exchange information with a centralized server. This centralized server allows, among other things, for readings taken by these smart meters. It also allows for software updates to these smart meters, in order to correct anomalies detected in the instructions executed by the smart meters and / or to enhance the operations performed by executing these instructions.

[0003] A software update ( e.g., FOTA (Firmware Over-The-Air) is a particularly resource-intensive process. Specifically, a completely new instruction set (new software) must be provided to each smart meter to be updated. A large amount of data must be transmitted from the central server to each smart meter, resulting in significant network resource consumption. Furthermore, when the smart meters are water or gas meters, they operate on battery power to ensure independent operation. Such software update operations significantly impact battery life.

[0004] In addition, these software updates require a restart of the smart meter once the new instruction set is downloaded, so that this new instruction set can be executed by a processor of said smart meter, resulting in a service interruption.

[0005] Document EP 2 275 935 A2 describes a method for modifying an instruction sequence, where each instruction is associated with an address and stored in a read-only memory (ROM) of a smart card. The method involves identifying the addresses associated with the instructions to be modified within the instruction sequence and then storing them in a breakpoint unit. Groups of alternative instructions are stored in non-volatile memory to associate each instruction group with its respective address. The current address of a current instruction in the sequence is compared to the identified addresses, with the current address corresponding to one of the identified addresses, to allow an update to execute the current instruction.

[0006] It is therefore desirable to overcome these drawbacks of the state of the art with a solution that allows in particular for a fix to be applied on the fly (without interruption of service). DESCRIPTION OF THE INVENTION

[0007] A method is proposed here for applying a patch to an instruction set executed by a controller of a smart meter, said smart meter being configured to communicate with a centralized server via a communication network, said controller having a processor integrating a debugging module configured to stop the execution of instructions on detection of a breakpoint being reached and to generate an associated hardware interrupt, the method being implemented by said controller and comprising the following steps: receiving a new patch message via said communication network, said message providing the patch to be applied and a breakpoint for applying the patch in the instruction set executed by said controller;to store instructions from the patch provided by said message in non-volatile memory, for a future restart of the smart meter, and also in RAM, for on-the-fly application, i.e., without restarting the smart meter; to configure the debugging module with said patch application breakpoint; and to apply the patch, whose instructions are stored in RAM, on the fly, upon detection of a hardware interrupt associated with said patch application breakpoint. Thus, it is possible to apply a patch on the fly to an instruction set executed by a smart meter controller, and this patch will also be taken into account during any subsequent restart of the smart meter. Moreover, by proceeding in this way, the bulk of the instruction set can remain unchanged, which limits the consumption of network resources to transmit / receive the patch.

[0008] In one particular embodiment, the fix is ​​one of the following: a skip of an instruction or a set of instructions; a change to at least one function argument; a change in the order of execution of instructions; the addition of at least one instruction; or the substitution of at least one instruction. Thus, the method is suitable for a multitude of fixes.

[0009] In one particular embodiment, the new patch message contains information that allows instructions for applying the patch to be derived. As a result, the message is smaller in size.

[0010] In one particular embodiment, the fix to be applied is included in the new fix message as machine language instructions. This allows complex fixes to be applied.

[0011] In one particular embodiment, upon startup of the smart meter, the controller performs the following steps: configures the debugging module with any breakpoints for each patch previously received; waits for the detection of a hardware interrupt corresponding to said breakpoint; and waits for the receipt of any new patch messages. Thus, each patch is applied at startup, and new patches can be received and integrated on the fly.

[0012] Also proposed here is a computer program containing program code instructions that cause an implementation of the process when said instructions are executed by a smart counter processor. Also proposed here is an information storage medium that stores such program code instructions.

[0013] Also proposed here is a smart meter configured to apply a patch to an instruction set executed by a smart meter controller, said smart meter being configured to communicate with a centralized server via a communication network, the controller having a processor integrating a debugging module configured to stop the execution of instructions on detection of a breakpoint being reached and to generate an associated hardware interrupt, the controller being configured to: receive a new patch message via an interface of said smart meter with said communication network, said message providing the patch to be applied and a breakpoint for applying the patch in the instruction set executed by said controller;to record instructions from the fix provided by said message in non-volatile memory, for a future restart of the smart meter, and in RAM, for on-the-fly application, i.e. without restarting the smart meter; to configure the debugging module with said fix application breakpoint; and to apply on the fly the fix whose instructions are recorded in RAM, upon detection of a hardware interrupt associated with said fix application breakpoint. BRIEF DESCRIPTION OF THE DRAWINGS

[0014] The features of the invention mentioned above, as well as others, will become clearer upon reading the following description of at least one exemplary embodiment, said description being made in relation to the accompanying drawings, among which: [ Fig. 1 ] schematically illustrates a communication system in which the present invention can be implemented; [ Fig. 2 ] schematically illustrates an algorithm for applying a fix to a set of instructions executed by a smart counter in the communication system; [ Fig. 3 ] schematically illustrates an algorithm for taking into account, on the fly, a correction to be applied to a set of instructions executed by an intelligent counter of the communication system; and [ Fig. 4 ] schematically illustrates an example of the hardware layout of a smart meter controller in the communication system. DETAILED DESCRIPTION OF IMPLEMENTATION METHODS

[0015] There Fig. 1 schematically illustrates a communication system in which the present invention can be implemented.

[0016] The communication system includes a first device D1 101, and a second device D2 102, connected by a communication network 103.

[0017] The second device D2 102 is a smart meter. For example, the second device D2 102 is an electricity meter. In a preferred embodiment, the second device D2 102 is a water or gas meter.

[0018] The first device D1 101 is adapted and configured to transmit, via the communication network 103, patches to be applied to a set of instructions executed by the second device D2 102.

[0019] The first device D1 101 is typically connected to a multitude of smart meters via the communication network 103, in order to allow software updates to be made to said smart meters.

[0020] For example, when the second device D2 102 is an electricity meter, the communication network 103 is a power line communication (PLC) network, and the first device D1 101 is a data concentrator (DC) or a computer system connected to such a data concentrator. As another example, when the second device D2 102 is a water or gas meter, the communication network 103 is a low-power wide area network (LPWAN), that is, a long-range, low-power wireless network as used in the Internet of Things (IoT), and the first device D1 101 is a gateway or a computer system connected to such a gateway.

[0021] To perform metering operations (water, gas, and electricity consumption), the D2 102 device includes a metrology module M 120. To communicate via the communication network 103, and more specifically with the D1 101 device, the D2 102 device includes a communication interface I 140. To perform data processing, such as compiling consumption readings from the metering operations of the metrology module M 120 and generating consumption statistics, the D2 102 device includes a controller C 110. When the second D2 102 device is a water or gas meter, the D2 102 device includes a battery B 130 to power the second D2 102 device. The battery B is typically calibrated to have a lifespan of approximately fifteen to twenty years.Potential heavy data transfers via the communication interface I may impair this lifespan (although the battery has been calibrated to allow some), which the present invention aims to avoid.

[0022] There Fig. 2 schematically illustrates an algorithm for applying a fix to a set of instructions executed by the D2 102 device.

[0023] In step 201, device D2 102 is powered on and performs a software boot. Controller C 110 then copies instructions stored in non-volatile memory into RAM. Controller C 110 reads the instructions from RAM and executes them.

[0024] The instructions correspond to a main program and possibly to one or more fixes applied to the main program.

[0025] The C110 controller includes a processor (for example, an ARM processor, or Advanced RISC (Reduced Instruction Set Computer) machine) incorporating a debugging module configured to halt instruction execution upon detection of a breakpoint and to generate an associated hardware interrupt. This hardware interrupt is then associated with patch instructions, which correspond to an interrupt handling routine that redirects the C110 controller to apply a patch. The main program is suspended to apply the patch, as detailed below.

[0026] In step 202, device D2 102 configures the debugging module so that each fix previously received by device D2 102 from device D1 101 is taken into account. A breakpoint is then defined for each fix to be applied.

[0027] In step 203, the D2 102 device activates its correction service and puts it on standby for detection of a possible hardware interruption indicating that the execution of the main program instructions has reached a said breakpoint.

[0028] In step 204, the D2 102 device checks whether such a hardware interrupt is detected. If such a hardware interrupt is detected, it typically means that a register (called the program counter (PC)), which points to the RAM address of the next instruction to be executed, has reached that breakpoint. Step 205 is then performed. Otherwise, the correction service remains in step 203, waiting for the detection of such a possible hardware interrupt.

[0029] In step 205, device D2 102 suspends the execution of the main program, and in step 206, device D2 102 executes the instructions of the fix associated with the detected hardware interrupt. The value of the program counter (PC) register can be used to determine which fix is ​​involved.

[0030] It should be noted that, as soon as access to the general purpose registers (R0, ..., Rn) is possible under interruption, many types of fixes can be applied.

[0031] In one embodiment, the fix is ​​a jump of an instruction or a set of instructions (code section). This is the case, in particular, when the instruction or set of instructions in question has been identified as unnecessary or incorrect. For example, this could be due to improper handling of a GPIO (General Purpose Input / Output) port, or the unnecessary activation of a peripheral, which leads to excessive power consumption. One possible fix is ​​to change the value of a register (called the Link Register (LR)), which points to the RAM address of a function return instruction, according to the jump to be made. Another possible fix is ​​to increment the value of the Program Counter (PC) register, according to the jump to be made.

[0032] According to a second embodiment, the fix is ​​a change to at least one function argument. For example, a configuration function for a GPIO-type input / output port uses an incorrect argument ( e.g ., incorrect GPIO input / output port number). A possible fix is ​​to change the value of one or more registers from among general-purpose registers intended to store function arguments (often named R0, ..., Rn (with, for example, n = 12)).

[0033] According to a third embodiment, the fix is ​​a change in the order of instruction execution. For example, reconfiguring the state of a GPIO input / output port must be done after initializing it, not the other way around. A possible fix then consists of listing the instructions in the correct order and changing the value of the link register (LR) to return to the main program (step 207) at the instruction following the incorrectly ordered instructions.

[0034] According to a fourth embodiment, the fix is ​​the addition of at least one instruction. For example, inserting an initialization for a GPIO input / output port that was omitted from the main program. A possible fix then consists of providing initialization instructions for the GPIO input / output port in question, without changing the value of the link register (LR).

[0035] According to a fifth embodiment, the fix is ​​an instruction substitution. For example, it could involve rewriting a complex function or introducing new operations into a function. The fix instructions are then received as a compiled binary function, that is, directly as machine language instructions. The fix also modifies the value of the link register (LR) to return to the main program (step 207) at the instruction following the instructions being substituted.

[0036] Next, the correction service goes back to waiting for the detection of a possible hardware interrupt indicating that the execution of the main program instructions has reached a said breakpoint, in step 203.

[0037] There Fig. 3 schematically illustrates an algorithm for taking into account, on the fly, a correction to be applied to a set of instructions executed by the D2 102 device.

[0038] In step 301, device D2 102 is powered on and performs a software boot. Step 301 is the same as step 201.

[0039] In step 302, the D2 102 device activates its correction service (as in step 203) and puts it on standby for detection of a possible receipt of a new correction message.

[0040] The new patch message is a message that requests a patch to be applied to the main program. The new patch message includes a breakpoint value relevant to the patch to be applied. In a particular embodiment, the message includes information that allows the application of patch instructions to be derived, such as register values. This allows for small patch message sizes (a few bytes), which is particularly advantageous when transmissions from device D1 101 to device D2 102 have low bandwidth (as is the case in LPWAN networks). In a particular embodiment, the message includes machine language instructions corresponding to the patch to be applied. This makes it easy to transmit more complex patches.

[0041] In step 303, the D2 102 device checks if such a new corrective message has been received. If so, step 304 is performed; otherwise, the correction service remains on standby, waiting to detect a possible receipt of such a message in step 302.

[0042] In step 304, the D2 102 device stores instructions corresponding to the new patch in non-volatile memory. Therefore, upon the next reboot of the D2 102 device, the patch is incorporated into the debugging module configuration (step 202). Furthermore, in step 304, the D2 102 device stores instructions corresponding to the new patch in RAM.

[0043] In step 305, device D2 102 configures the debugging module so that the newly received patch from device D1 101 is taken into account. A breakpoint is then set for this new patch to be applied. Storing the corresponding instructions in RAM (step 304) allows the patch to be implemented on the fly, without having to restart device D2 102.

[0044] Next, the correction service goes back to waiting for the detection of a possible receipt of a new correction message, in step 302.

[0045] There Fig. 4 schematically illustrates an example of the layout of the C 110 controller.

[0046] The C 110 controller comprises, connected by a communication bus 410: a processor or CPU (Central Processing Unit) 401; a RAM (Random-Access Memory) 402; a non-volatile memory, for example of the EEPROM (Electrically-Erasable Programmable Read Only Memory) or Flash type 403; a storage unit, such as a storage medium SM 404, for example a hard disk drive HDD, or a storage medium reader, such as an SD card reader (Secure Digital); and an I / F interface manager 405.

[0047] The processor or CPU 401 integrates the debugging module used to generate hardware interrupts on predefined breakpoints.

[0048] The I / F interface manager 405 allows the controller C 110 to interact with other elements of the device D2 102 (smart meter), including the metrology module M 120 and the communication interface I 140 (to receive new patch messages from the device D1 101). The processor or CPU 401 is capable of executing instructions loaded into the RAM 402, including from the non-volatile memory 303 or the storage medium (such as an SD card) 304, or upon receipt of a new patch message (as described in relation to the Fig. 3When the C110 controller is powered on, the 401 processor or CPU is able to read instructions from RAM 302 and execute them. These instructions can be updated on the fly by applying a new patch, as previously described. These instructions form a computer program that causes the 401 processor or CPU to implement the steps and behaviors described here.

Claims

1. Method for applying a correction to a set of instructions executed by a controller (110) of a smart meter (102), said smart meter being configured to communicate with a centralised server (101) via a communication network (103), said controller (110) comprising a processor (401) incorporating a debugging module configured to stop execution of the instructions when it is detected that a stop point is reached and to generate an associated hardware interrupt, the method being implemented by said controller (110) and comprising the following steps: - receiving (303) a new-correction message via said communication network, said message supplying the correction to be applied and a point of stopping application of the correction in the set of instructions executed by said controller (110); - recording (304) instructions of the correction supplied by said message in non-volatile memory with a view to a future restarting of the smart meter, as well as in random access memory with a view to taking into account on the fly, i.e. without restarting the smart meter; - configuring (305) the debugging module with said point of stopping application of the correction; and - applying (206) on the fly the correction the instructions of which are recorded in random access memory, when a hardware interrupt associated with said point of stopping application of the correction is detected.

2. Method according to claim 1, wherein the smart meter (102) is a water or gas meter, and the communication network is of the LPWAN type .

3. Method according to one of claims 1 and 2, wherein the correction is among the following corrections: - an instruction skip or one relating to a set of instructions; - a change of at least one function argument; - a change of order of executing instructions; - an addition of at least one instruction; - a substitution of at least one instruction.

4. Method according to any one of claims 1 to 3, wherein the new-correction message comprises information that makes it possible to derive the correction instructions to be applied.

5. Method according to any one of claims 1 to 3, wherein the correction to be applied is included in the new-correction message in the form of instructions in machine language.

6. Method according to any one of claims 1 to 5, wherein, when the smart meter (102) is started up, the controller (110) performs the following steps: - configuring (202) the debugging module with any stop point for each correction possibly received previously; - awaiting (203) detection of any hardware interrupt corresponding to a said stop point; - awaiting (302) reception of any new-correction message.

7. Computer program product comprising program code instructions causing an implementation of the method according to any one of claims 1 to 6, when said instructions are executed by a processor (401) of a smart meter (102).

8. Information storage medium storing program code instructions causing an implementation of the method according to any one of claims 1 to 6, when said instructions are read and executed by a processor (401) of a smart meter (102).

9. Smart meter (102) configured to apply a correction to a set of instructions executed by a controller (110) of the smart meter (102), said smart meter being configured to communicate with a centralised server via a communication network, the controller (110) comprising a processor (401) incorporating a debugging module configured to stop execution of the instructions when it is detected that a stop point is reached and to generate an associated hardware interrupt, the controller (110) being configured for: - receiving (303) a new-correction message via an interface of said smart meter with said communication network, said message supplying the correction to be applied and a point of stopping application of the correction in the set of instructions executed by said controller (110); - recording (304) instructions of the correction supplied by said message in non-volatile memory with a view to a future restarting of the smart meter, as well as in random access memory with a view to taking into account on the fly, i.e. without restarting the smart meter; - configuring (305) the debugging module with said point of stopping application of the correction; and - applying (206) on the fly the correction the instructions of which are recorded in random access memory, when a hardware interrupt associated with said point of stopping application of the correction is detected.

10. Smart meter (102) according to claim 9, wherein the smart meter (102) is a water or gas meter, and the communication network is of the LPWAN type .