METHOD FOR APPLYING A CORRECTIVE TO SMART METER INSTRUCTIONS

Abstract

A controller (110) of a smart meter (102) includes a processor incorporating a debugging module configured to halt instruction execution upon detection of a breakpoint and to generate an associated hardware interrupt. To apply a patch to an instruction set, the controller (110): receives a patch update message via a communication network (103), said message providing the patch to be applied and a breakpoint for applying the patch in the instruction set executed by said controller (110); stores patch update instructions in non-volatile memory, for a future restart of the smart meter (102), and in RAM, for on-the-fly implementation; configures the debugging module with said patch update breakpoint; and applies the patch upon detection of a hardware interrupt associated with said patch update breakpoint.Figure to be published with the abbreviation: Fig. 1.

Description

Title of the invention: METHOD FOR APPLYING A CORRECTIVE TO SMART METER INSTRUCTIONS Technical field

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

[0002] Nowadays, water, gas and electricity meters have become smart meters, that is to say they integrate data processing and communication interfaces so as to be able to exchange with a centralized server. This centralized server makes it possible in particular to carry out meter readings carried out by these smart meters. This centralized server also makes it possible in particular to carry out software updates of these smart meters, in order to correct anomalies observed in the instructions executed by the smart meters and / or to enrich operations carried out by execution of the instructions by the smart meters.

[0003] A software update (eg, FOTA (“Firmware Over-The-Air”)) is a particularly cumbersome sequence of operations. In particular, a complete new set of instructions (new software) must be provided to each smart meter to be updated. A large amount of data must be transmitted from the centralized server to each smart meter to be updated, which results in a large consumption of network resources. In addition, when the smart meters are water or gas meters, these smart meters operate on batteries, so as to have an autonomous power supply. However, such software update operations have a significant impact on the battery life.

[0004] Furthermore, these software updates require a reboot 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, which results in an interruption of service.

[0005] It is then desirable to overcome these drawbacks of the state of the art with a solution which in particular makes it possible to apply a correction on the fly (without interruption of service). Statement of the invention

[0006] A method is proposed here for applying a patch to a set of instructions executed by a controller of a smart meter, said controller comprising a processor integrating a debugging module configured to stop the execution of the instructions upon detection of reaching a breakpoint 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 a communication network, said message providing the patch to be applied and a breakpoint for applying the patch in the set of instructions executed by said controller; recording new patch instructions in non-volatile memory, for a future restart of the smart meter, as well as in RAM, for on-the-fly consideration; configuring the debugging module with said breakpoint for applying the patch;and apply the patch upon detection of a hardware interrupt associated with said patch application breakpoint. Thus, it is possible to apply, on the fly, a patch to an instruction set executed by a controller of a smart meter, and this patch will also be taken into account during a possible subsequent restart of the smart meter. Moreover, by doing so, the essential part of the instruction set can remain unchanged, which limits the consumption of network resources to transmit / receive the patch. ;

[0007] According to a particular embodiment, the patch is among the following patches: a jump of an instruction or a set of instructions; a change of at least one function argument; a change of the order of execution of instructions; an addition of at least one instruction; a substitution of at least one instruction. Thus, the method is suitable for a multitude of patches.

[0008] According to a particular embodiment, the new patch message includes information that makes it possible to derive patch instructions to be applied. Thus, the message is of reduced size.

[0009] According to a particular embodiment, the patch to be applied is included in the new patch message in the form of machine language instructions. Thus, complex patches can be applied.

[0010] According to a particular embodiment, when the smart meter starts up, the controller performs the following steps: configure the debugging module with any breakpoint for each patch possibly previously received; wait for detection of a possible hardware interruption corresponding to a said breakpoint; wait for reception of a possible new patch message. Thus, each patch is taken into account at startup, and new patches can be received and integrated on the fly.

[0011] Also provided herein is a computer program comprising program code instructions causing an implementation of the method, when said instructions are executed by a smart meter processor. Also provided herein is an information storage medium storing such program code instructions.

[0012] Also proposed here is a smart meter configured to apply a patch to a set of instructions executed by a controller of the smart meter, the controller comprising a processor integrating a debugging module configured to stop the execution of the instructions upon detection of reaching a breakpoint 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 a communication network, said message providing the patch to be applied and a breakpoint for applying the patch in the set of instructions executed by said controller; record new patch instructions in non-volatile memory, for a future restart of the smart meter, as well as in RAM, for on-the-fly consideration; configure the debugging module with said breakpoint for applying the patch;and apply the patch upon detection of a hardware interrupt associated with said patch application breakpoint.; Brief description of the drawings

[0013] The characteristics of the invention mentioned above, as well as others, will appear more clearly on reading the following description of at least one exemplary embodiment, said description being made in relation to the attached drawings, among which:

[0014] [Fig-1] schematically illustrates a communication system in which the present invention can be implemented;

[0015] [Fig.2] schematically illustrates an algorithm for applying a patch to an instruction set executed by a smart meter of the communication system;

[0016] [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 a smart meter of the communication system; and

[0017] [Fig.4] schematically illustrates an example hardware arrangement of a smart meter controller of the communication system.

[0018] DETAILED DESCRIPTION OF EMBODIMENTS

[0019] [Fig.l] schematically illustrates a communication system in which the present invention can be implemented.

[0020] The communication system comprises a first device DI 101, as well as a second device D2 102, connected by a communication network 103.

[0021] 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.

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

[0023] The first device DI 101 is typically connected to a multitude of smart meters via the communication network 103, in order to allow software updates to be carried out on said smart meters.

[0024] For example, when the second device D2 102 is an electricity meter, the communication network 103 is a power line communications (PLC) network and the first device DI 101 is a data concentrator (DC) or a computer system connected to such a data concentrator. According to 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), i.e. a long range, low power wireless network as used in the Internet of Things (IoT) and the first device DI 101 is a gateway or a computer system connected to such a gateway.

[0025] To carry out metering operations (consumption of water, gas, electricity), the device D2 102 comprises a metrology module M 120. To communicate via the communication network 103 and more particularly with the device DI 101, the device D2 102 comprises a communication interface I 140. To carry out data processing, such as for example to create consumption readings from the metering operations of the metrology module M 120 and to create consumption statistics, the device D2 102 comprises a controller C 110. When the second device D2 102 is a water or gas meter, the device D2 102 comprises a battery B 130 for supplying electrical power to the second device D2 102. The battery B is typically calibrated to have a lifespan of around fifteen or twenty years.Possible heavy data transfers via the communication interface I can harm this lifetime (although the battery has been calibrated to allow some), which the present invention aims to avoid.

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

[0027] In a step 201, the device D2 102 is powered up and the device D2 102 performs a soft boot. The C 110 controller then copies instructions stored in non-volatile memory into RAM. The C 110 controller reads the instructions from RAM and executes them.

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

[0029] The controller C 110 includes a processor (for example of the ARM type (“Advanced RISC (Reduced Instruction Set Computer) Machine” in English)) integrating a debugging module configured to stop the execution of the instructions upon detection of reaching a breakpoint, and to generate an associated hardware interrupt. The hardware interrupt is then associated with patch instructions, which correspond to a routine for managing the interrupt in question which diverts the controller C 110 to a patch to be applied. The main program is suspended to apply the patch, as detailed below.

[0030] In a step 202, the device D2 102 configures the debugging module, so that each patch previously received by the device D2 102 from the device DI 101 is taken into account. Thus, a breakpoint is defined for each patch to be applied.

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

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

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

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

[0035] According to a first embodiment, the fix is ​​a skip 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 useless or incorrect. For example: incorrect handling of an input-output port GPIO (General Purpose Input / Output) type, or unnecessary activation of a peripheral, which leads to excess power consumption. A possible fix is ​​to change the value of a register (called a Link Register (LR), which points to the RAM address of a function return instruction, in accordance with the jump to be performed. Another possible fix is ​​to increment the value of the Program Counter (PC) register, in accordance with the jump to be performed.

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

[0037] According to a third embodiment, the fix is ​​a change in the order of execution of instructions. For example, reconfiguring the state of a GPIO type input-output port must be done after initializing it and 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) to the instruction that follows the instructions that were incorrectly ordered.

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

[0039] According to a fifth embodiment, the patch is a substitution of instructions. For example: a rewrite of a complex function, or an introduction of new operations in a function. The instructions of the patch are then received in the form of a compiled binary function, that is to say directly as instructions in machine language. The patch further modifies the value of the link register (LR) to return to the main program (step 207) at the instruction which follows the instructions which are the subject of the substitution.

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

[0041] [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 device D2 102.

[0042] In a step 301, the device D2 102 is powered up and the device D2 102 performs a soft boot. Step 301 is the same as step 201.

[0043] In a step 302, the device D2 102 activates its correction service (as in step 203) and puts it on standby to detect a possible reception of a new correction message.

[0044] The new patch message is a message that requires applying a patch to the main program. The new patch message includes a breakpoint value affected by the patch to be applied. In a particular embodiment, the message includes information that makes it possible to derive patch instructions to be applied, such as register values. This makes it possible to have reduced sizes (a few bytes) of new patch messages, which is particularly advantageous when the transmissions from the DI device 101 to the D2 device 102 have a low bandwidth (as is the case in LPWAN type 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.

[0045] In a step 303, the device D2 102 checks whether such a new corrective message is received. If this is the case, a step 304 is performed; otherwise, the correction service remains waiting to detect a possible reception of such a message, in step 302.

[0046] In step 304, the device D2 102 stores in non-volatile memory instructions corresponding to the new patch. Thus, during a next restart of the device D2 102, the patch is taken into account in the configuration of the debugging module (step 202). Furthermore, in step 304, the device D2 102 stores in RAM instructions corresponding to the new patch.

[0047] In a step 305, the device D2 102 configures the debugging module, so that the patch newly received by the device D2 102 from the device DI 101 is taken into account. Thus, a breakpoint is defined for this new patch to be applied. The recording in RAM (step 304) of the corresponding instructions allows on-the-fly implementation of the patch, i.e. without having to restart the device D2 102.

[0048] Then, the correction service goes back to waiting to detect a possible reception of a new correction message, in step 302.

[0049] [Fig.4] schematically illustrates an example of arrangement of the controller C 110.

[0050] The controller C 110 comprises, connected by a communication bus 410: a processor or CPU (“Central Processing Unit” in English) 401; a RAM (“Random-Access Memory” in English) 402; a non-volatile memory, for example of the EEPROM type (“Electrically-Erasable Programmable Read Only Memory” in English) or of the 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 (“Secure Digital” in English) card reader; and an I / f interface manager 405.

[0051] The processor or CPU 401 integrates the debugging module used to generate hardware interrupts on previously defined breakpoints.

[0052] The I / f interface manager 405 allows the controller C 110 to interact with other elements of the device D2 102 (smart meter), in particular the metrology module M 120 and the communication interface I 140 (to receive messages of new corrections from the device DI 101)

[0053] The processor or CPU 401 is capable of executing instructions loaded into the RAM 402, in particular 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 [Fig. 3]). When the controller C 110 is powered on, the processor or CPU 401 is thus capable of reading instructions from the RAM 302 and executing them. These instructions can be updated on the fly by applying a new patch, as already described. These instructions form a computer program causing in particular the implementation, by the processor or CPU 401, of the steps and behaviors described here.

Claims

Claims

1. Method for applying a patch to a set of instructions executed by a controller (110) of a smart meter (102), said controller (110) comprising a processor (401) integrating a debugging module configured to stop the execution of the instructions upon detection of reaching a breakpoint and to generate an associated hardware interrupt, the method being implemented by said controller (110) and comprising the following steps: - receiving (303) a new patch message via a communication network, said message providing the patch to be applied and a breakpoint for applying the patch in the set of instructions executed by said controller (110); - recording (304) new patch instructions in non-volatile memory, for a future restart of the smart meter, as well as in random access memory, for on-the-fly consideration;- configuring (305) the debugging module with said patch application breakpoint; and - applying (206) the patch upon detection of a hardware interrupt associated with said patch application breakpoint.;

2. The method of 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, in which the patch is among the following patches: - a jump of an instruction or a set of instructions; - a change of at least one function argument; - a change of order of execution of instructions; - an addition of at least one instruction; - a substitution of at least one instruction.

4. A method according to any one of claims 1 to 3, wherein the new patch message comprises information which enables patch instructions to be applied to be derived.

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

6. A method according to any one of claims 1 to 5, wherein upon startup of the smart meter (102), the controller (110) performs the following steps: - configure (202) the debugging module with any breakpoint for each patch possibly previously received; - wait (203) for detection of a possible hardware interruption corresponding to a said breakpoint; - wait (302) for reception of a possible new patch message.

7. A 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. An 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 patch to a set of instructions executed by a controller (110) of the smart meter (102), the controller (110) comprising a processor (401) integrating a debugging module configured to stop the execution of the instructions upon detection of reaching a breakpoint and to generate an associated hardware interrupt, the controller (110) being configured to: - receive (303) a new patch message via an interface of said smart meter with a communication network, said message providing the patch to be applied and a breakpoint for applying the patch in the set of instructions executed by said controller (110); - record (304) new patch instructions in non-volatile memory, for a future restart of the smart meter, as well as in random access memory, for on-the-fly consideration;- configuring (305) the debugging module with said patch application breakpoint; and - applying (206) the patch upon detection of a hardware interrupt associated with said patch application breakpoint.;

10. A 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.

Images