Field of the Invention

The present invention relates to a method and system for managing device power, and especially managing the use of battery power and device lifetime.

Background of the Invention

Battery operated devices will always exhaust their battery at some point and cease to function. For everyday items such as mobile phones, a rechargeable battery can be used and regularly recharged. Other devices may not be suitable for use with

rechargeable batteries. In such cases, then the battery itself may be replaced. However, there is a further class of devices that are manufactured together with a battery (e.g.

integrated) or where a battery is installed at the start of the active lifetime of the device, where the battery is intended to last the entire life of the device. These devices may be located where it is difficult or impossible to replace the batter or provide external power, for example. Such devices may include smart meters, remote sensors, or components of an Internet-of-Things (loT).

Such devices will need to be replaced when the battery is exhausted and so care may be taken to minimise the power requirements or the reduce functionality of the device to prolong battery life. Whilst the environment and usage of a particular device may alter the time in which the battery is exhausted, some safety margin may be used so that the device is replaced before this occurs. Therefore, there can be an undesirable trade-off between device functionality and lifespan.

Therefore, there is required a method and system that overcomes these problems. Summary of the Invention

A method is provided that combines parameters describing the state or history of a device with parameters that define requirements or values external to a device within an algorithm to generate control variables to be applied to alter the operation of the device. The device parameters may include information describing historic operations of battery usage of the device, predicted operations or battery usage and/or other data describing the device. Preferably, the altered operation allows the device to operate so as to consume its remaining battery energy more efficiently or to meet a particular required device lifetime (i.e. battery lifetime). The determination of the control variables may occur outside of the device (e.g. within a server) or within the device. The external values may come from outside of the device. Example implementations include devices used within smartmeters, pipeline monitoring (e.g. oil and gas), and remote weather stations. There may be formed a system including a plurality of devices controlled and managed in this way by one or more servers.

In accordance with a first aspect there is provided a method for managing the battery life of a device, the device having a battery with a total and remaining capacity, the method comprising the steps of:

obtaining one or more device parameters including at least an indication of the remaining battery capacity (e.g. full/part used/depleted, percentage, or remaining charge in mAh) and an indication of an amount of energy used for the device to perform one or more tasks;

retrieving one or more external parameters;

deriving from the device parameters and the external parameters one or more device control values; and

applying the one or more device control values to the device. Therefore, the device and device battery usage may be managed more effectively. The task may be usage of the device within a particular event (e.g. operating for a period of time or sending or receiving a particular volume of data). The device may have a transceiver or other interface. The device may communicate over a network such as a cellular network (e.g. 2G, 3G, 4G or 5G). Optionally, the device may have a low power mode and a high power mode, and further wherein the one or more device control values may include a time for the device to remain in the low power mode and/or a time for the device to remain in high power mode. The low power mode may be a mode in which the device uses less power (e.g. from the battery) to operate (than the high power state) but remain in a state that allows it to carry out at least one or more functions (e.g. turn to a different or higher power state after a period of time or when one or more conditions are met, e.g. when a temperature is reached). Therefore, the device may be managed to alter the time between being in the low power state and the high power state (when more functions may carried out but more battery power is consumed). The control values may change these particular times or conditions.

Preferably, the time for the device to remain in a low power and/or the time for the device to remain in a high power mode may be selected to correspond with the remaining battery capacity to provide a required device life. In other words, the total remaining battery capacity may be exhausted over a required lifetime (at least providing that lifetime) by changing the amount of time that the device is in the low and high power states. There may be more than two power states (e.g. a medium power state with reduced functionality that is between the low and high power values). Therefore, the device may be in the high power state (i.e. providing required functionality) for a greater or maximised proportion of time whilst maintaining device (i.e. battery) lifetime.

Optionally, the device parameters include an indication of the energy used by the device over a time period. This may be in in percentage, energy mAh, mWh or other units or terms.

Preferably, the time period is a period for the device to be in the low power mode.

Optionally, the external parameters may include any one or more of: device lifetime, scheduled end of life, temperature forecast at the device's location, historic data usage of the device, time required to apply a firmware update to the device, an indication of energy used to send and/or receive an amount of data, expected volume of data to be sent and/or received by the device, and previous battery remaining capacity. Other external parameters may be used. External may mean predetermined (e.g. before device deployment), global (i.e. the same for all devices or groups of devices), dependent on factors not affected by device operation (e.g. the weather) or stored or generated outside of the particular device or set of devices.

Optionally, the device parameters may include any one or more of: total battery capacity, battery model, device location, energy used by the device over a time period, and temperature. Other device parameters may be used. Optionally, the external parameters may be retrieved from a server separate from the device. The server may be in direct or indirect communication with the device over a network, for example.

Optionally, the deriving step may be carried out within the device.

Preferably, the steps may be repeated at intervals. This may be regular or ad hoc or defined in the control parameter, for example.

Preferably, the method may further comprise the step of operating the device according to the one or more device control values.

Optionally, the one or more tasks may include any one or more of: sending and/or receiving a volume of data, operating in a low power mode for a period of time, operating in a high power mode for a period of time, rebooting the device, and updating firmware of the device.

Advantageously, the step of deriving from the device parameters and the external parameters one or more device control values may further comprise determining a temperature at the location of the device and determining the energy required to perform the one or more tasks at that temperature. This may be obtained from a weather forecast, for example.

Optionally, the one or more device control values may include a time to carry out the one or more tasks selected based on the time that a temperature will be reached at the location requiring less energy to carry out the one or more tasks than at another time and temperature.

According to a second aspect there is provided a management server for managing the battery life of a device, the device having a battery with a total and remaining capacity, the management server comprising:

one or more processors;

a data store configured to store one or more external parameters; an interface configured to obtain from a device one or more device parameters including at least an indication of the remaining battery capacity and an amount of energy used for the device to perform one or more tasks; and

memory storing instructions executable by the one or more processors to:

retrieve the one or more external parameters using the interface;

derive from the device parameters and the stored external parameters one or more device control values; and

apply the one or more device control values to the device using the interface.

According to a third aspect there is provided a system comprising the management server and one or more devices, according any or all of those previously described.

According to a fourth aspect there is provided device comprising:

a battery;

an interface;

one or more processors; and

memory storing instructions executable by the one or more processors to:

receive from a management server using the interface one or more external parameters;

derive from device parameters and the received external parameters one or more device control values;

apply the one or more device control values; and

operate according to the one or more device control values.

Preferably, the one or more external parameters may include at least a device lifetime and/or required battery lifetime.

The methods described above may be implemented as a computer program comprising program instructions to operate a computer. The computer program may be stored on a computer-readable medium.

The computer system may include a processor such as a central processing unit (CPU). The processor may execute logic in the form of a software program. The computer system may include a memory including volatile and non-volatile storage medium. A computer-readable medium may be included to store the logic or program instructions. The different parts of the system may be connected using a network (e.g. wireless networks and wired networks). The computer system may include one or more interfaces. The computer system may contain a suitable operating system such as UNIX, Windows (RTM) or Linux, for example.

It should be noted that any feature described above may be used with any particular aspect or embodiment of the invention. Brief description of the Figures

The present invention may be put into practice in a number of ways and

embodiments will now be described by way of example only and with reference to the accompanying drawings, in which:

FIG. 1 shows a schematic diagram of a system for managing the battery life of one or more devices;

FIG. 2 shows a sequence diagram of a method operated by the system of figure 1 ; FIG. 3 shows a flowchart of an algorithm used within the method of figure 2; and FIG. 4 shows a flowchart of the method for managing the battery life of a device. It should be noted that the figures are illustrated for simplicity and are not necessarily drawn to scale. Like features are provided with the same reference numerals.

Detailed description of the preferred embodiments Figure 1 shows a schematic diagram of a system 10 for managing the battery life of one or more devices. This example diagram shows three devices but any number may be used.

A management server 20 has a database 30 storing external parameters relating to one or more devices 40. Each device 40 communicates with the management server 20 using a wireless protocol, which uses an antenna 45. The devices communicate through a network 60 such as a mobile or other wireless network. The management server 20 also communicates either directly or indirectly with the network 60 either using a wired or wireless interface 25. This interface is used to receive data from and send data and/or commands to the devices 40. Each device includes a battery 50, which in this example is non-rechargeable, although different types of batteries may be used. Each device 40 includes a memory 70 and at least one processor 80. The memory 70 or data store is used to store one or more control values received from the management server 20 and the processor 80 is used to implement or operate the device 40 according to the one or more device control values.

In this example, the management server 20 obtains device parameters from each device 40. These one or more device parameters include at least a value indicating the remaining battery capacity of the device 40 and an amount of energy used by the device 40 to perform one or more tasks. This amount of energy may be in the form of a percentage of battery capacity or other in another format (e.g. mAh or mWh). The management server 20 uses the one or more device parameters and external parameters (e.g. retrieved from database 30) to derive the control values, which are sent to each device 40. Each device may receive specific or customised control values specific to that individual device 40 or generic control values specific to a class or group of devices.

In general, the system 10 carries out a method to manage and extend battery life for constrained connected (e.g. communicate over a network) devices. This is achieved by:

(a) providing a power model that may be visible at a management server,

(b) the application of a power management algorithm by the management server, and

(c) introduction of an activity control feedback loop for the device.

The following provides an example implementation. Figure 2 shows a sequence diagram illustrating the step carried out by the method in this example. The device 40 (e.g. an loT device) runs an application, which wakes up or initiates at step 1 10. As part of this wake-up step 1 10 a timer (application stay-awake timer) J starts running.

At step 1 10 the application wakes once the previous timer T ₂ expires. The application starts its 'wait for application instructions' timer T At step 120, device parameters (e.g. extended power parameters) 125 are sent to the management server 20. These device parameters may include at least an indication of the remaining battery charge and a value that indicates how much battery charge is used to carry out one or more tasks (e.g. operating within a particular mode or modes for a period of time). The task may be the operation of the device 40 during a particular event (e.g. sleep, wake, transmit or receive data, etc.) At step 130, the management server 20 runs a management algorithm to derive control values or activity control parameters 145, which are sent to the device 40 at step 140. The application returns the device 40 back to a sleep or low power mode at step 150 for a new duration T ₂ . The method may repeat with a new set of control values (e.g. T _r ) being sent at step 1 10'.

If necessary, the device 40 is brought out of low power mode and the device 40 connects to the management server 20, sending it an extended set of battery & power parameters (device parameters). These may include but are not limited to any one or more of:

(A1 ) Estimated percentage battery remaining (existing parameter)

(A2) Full capacity of battery, e.g. in milli-Amp hours (new parameter)

(A3) Estimated energy charge used during last Wake event (step 1 10 to step 5 previously), e.g. in milli-Amp hours (new parameter)

(A4) Estimated energy charge used during last Sleep event or other task (step 5 to step 1 previously) (new parameter)

(A5) Location of the device

In one example, the device 40 may include battery model parameters in the same message that it may send the device parameters 125 or service data (e.g. sensor measurements).

In one example, the device 40 may be configured not to include all the battery model parameters in every message (i.e. communication over the network 60). For example, the device may apply a 'Future power parameters' filter to determine which power parameters to send in subsequent messages.

In one example, the device 40 may not include the location parameter (A6) but this might be calculated by the management server 20 using a network based location method, for example. Figure 3 shows a schematic representation of the various data inputs and outputs. At step 130 power management algorithm 210 is executed within the management server 20 (although this could be run within the device 40). This algorithm combines the device parameters or power parameters 220 (e.g. A1 -A5) provided by the device 40 with external parameters 230 (e.g. B1 -B5) stored or derived at the management server 20 to derive a set of output control values 240 or status and control parameters (e.g. C1 -C8 listed below).

The following algorithm external or control parameters may be used and are provided as examples only:

(B1 ) Scheduled end of device lifetime For example, date in UTC format. This date can be agreed with the device customer.

(B2) Temperature forecast at device This may be retrieved by the algorithm or location management server 20 e.g. from a

meteorological web service. It represents the predicted temperature, for example provided on hourly basis over the following five days.

(B3) Forecast profile of data usage of device This is derived by the algorithm based on a known application running on the device 40 and the control values or parameters applicable to that device 40. For example:

- how often the device will wake,

- the anticipated amount of future data transmission at future wake events,

- scheduled firmware update,

- any scheduled device commands.

As a further improvement the algorithm may use previously seen data usage patterns to more accurately predict future data usage patterns.

(B4) Profile of historic data usage This may be determined by the algorithm using a periodic query to a connectivity management platform associated with the device 40. (B5) Stored previous values of 'Estimated Stored values of control values 240 provided remaining energy charge of device' together with timestamp.

Table 1

The following are example control values 240 generated by the algorithm.

Table 2

Some examples of the operation of the algorithm may include any one or more of the following.

Example operations to determine (C1 ):

The algorithm may determine the 'estimated remaining energy charge of device' (C1 ) by combining the 'Estimated remaining energy charge' (A1 ) with the 'full capacity of battery' (A2). For example, if the algorithm has knowledge of the total capacity of the battery (A2) to be l OOOmAh and an estimated 50% is remaining (A2) then the remaining energy charge (C1 ) may be estimated to be 500 mAh. Example operations to determine (C2):

The algorithm may derive remaining lifetime by combining the current forecast of data usage (B3) with the estimated energy charge used per byte sent (C4) and received (C5) and the estimated remaining energy charge of the Device (C1 ). For example, if the algorithm estimates the remaining energy charge to be 500 mAh (C1 ) and it has

information describing the forecast profile (B3), for example, that it is expected that 400 bytes will be sent each day and 100 bytes received a day, and there is an estimated energy charge requirement of 0.1 mAh per 100 bytes sent or received (C4), (C5), then it may be estimated that the energy charge expended will be 0.5 mAh per day. From this it may be estimated that there is enough battery capacity left for a further 1000 similar days (or usage), representing a value of 'Estimated remaining lifetime for device' (C2) as 1000 days.

Example operations to determine (C6), (C7):

The algorithm may use a scheduled or required date for the end of lifetime of this device (B1 ), which is stored or recorded in the management server 20 as an external parameter. This may provide a basis to assess whether the estimated remaining lifetime of the device (C2) is more or less than scheduled or required. This can be used to modify subsequent control values or parameters, (C6) and (C7). If the estimated remaining lifetime is less than the scheduled end of lifetime then the algorithm may increase the value of (C6) to better reflect the required lifetime.

If the algorithm knows from the future forecast of data usage that no commands are expected (e.g. within a predetermined period), then it can decrease the value of the application stay-awake timer (C7).

A further enhancement is to combine a temperature forecast at the device location (B2) with the forecast profile of data usage of the device (B3) to select the next time for the application to wake to ensure that the temperature is at a relatively high (e.g. higher or highest) point in a forecast temperate cycle. This can be used to increase the battery efficiency or utilisation during the next wake event (step 1 10 to step 150), taking advantage of improved battery efficiency for a particular range of temperatures. To achieve this effect the algorithm may set the value of the application sleep timer (C6) to enable the application to wake at a required time (e.g. warmest time or to avoid excessive or damaging heat on the battery 50 or device 40).

In one example, the algorithm may store previous values of 'estimated energy charge during last wake event' (A3) to provide further information assisting planning of device usage and replacement.

In one example, the management server 20 may notify a customer owner or supplier of the device with information indicating the estimated lifetime in a suitable format (e.g. hours) and proposed changes to control values 240 to, e.g. parameters (C6), (C7) to manage the lifetime. These may be accepted or refused by the customer or supplier before they are sent to the device or take effect.

In one example, a simplified power management algorithm may be used and implemented within in the device 40 rather than in the management server 20. An example operation of the power management algorithm implemented in the device 40 may be that the management server 20 informs the device 40 of the required 'scheduled end of device lifetime' (B1 ). The power management algorithm operating with the device 40 may derives future values of application sleep timer (C6) or other control values 240 to attempt to manage its battery's energy remaining charge to meet that date or desired lifetime.

At step 140, the control values are sent (or otherwise implemented within the device 40). In the example implementation illustrated by figure 2, the management server 20 sends activity control parameters (C6), (C7), (C8) derived by the power management algorithm to the device 40.

At step 150, the previously set 'application stay-awake' timer J expires and the application goes into low power mode. If other applications on the device 40 do not require communication or other functions then the device 40 can also go into low power mode.

The application starts the 'application sleep' timer with new value set by the power management algorithm, e.g. T _2b .

The introduction of: (a) an extended battery model with the management server 20, (b) the application of a power management algorithm at the management server 20, and (c) the introduction of an activity control feedback loop to the device 40 allows for the future connection, communication or other energy-requiring activity schedule of the device 40 to be optimised or at least improved. This may take into consideration factors such as environmental conditions and anticipated data volumes, and so extend the lifetime of the device and/or maintain functionality so long as the required lifetime is met. This device management method may be applied throughout the lifetime of the device or at critical, specific or predetermined times.

Figure 4 shows a flowchart of a further example method 300. At step 310, device parameters are obtained. At step 320, external parameters (e.g. B1 -B5) are obtained or read. At step 330 the control values are derived and these are applied to the device at step 340. The method 300 may iterate and so generated different control values, if necessary.

As will be appreciated by the skilled person, details of the above embodiment may be varied without departing from the scope of the present invention, as defined by the appended claims.

For example, other control values may be set other than wake and sleep times. These may include data rate changes or changing the operation of sensors (e.g. using fewer sensors at any one time).

Many combinations, modifications, or alterations to the features of the above embodiments will be readily apparent to the skilled person and are intended to form part of the invention. Any of the features described specifically relating to one embodiment or example may be used in any other embodiment by making the appropriate changes.