GB2604613A - Battery Stock Management - Google Patents

Abstract

A method for determining when to replace batteries provided in a plurality of devices, comprises: monitoring battery related events on all devices; monitoring the battery health level of all the devices; and using the monitored information to set a threshold level of battery health to indicate when batteries of devices within the group should be replaced and/or to control stock levels of batteries. The battery events may be: battery discharge rates, low battery events, battery swaps, connectivity problems, frequency of charging or instances of charging. The events may be indicative of a problem device or condition. The method may be performed on a server and the battery data may be transmitted from the devices to the server. The devices may be grouped according to their different uses, functions or components. Future stock levels of batteries may be predicted, including stock levels at different locations.

Description

Battery Stock Management This invention relates to battery stock management.

In particular, it relates to a system and method for predicting when batteries within a stock should be replaced to avoid battery-related productivity losses.

Batteries in mobile devices deteriorate over time, which reduces the effective full-charge capacity of the batteries. A practical effect of this is that a full or partial battery charge will last a shorter time, meaning that a battery must be charged more frequently, which can be inefficient and be severely detrimental to productivity of the user of the mobile device. If the health of a battery provided in the device for a mobile worker drops below an acceptable standard, then that worker will lose productivity by having to repeatedly swap batteries or devices or place the device onto a charger more frequently, or before the end of the worker's shift. When this occurs, it is generally desirable to replace the battery with a new one to retain productivity.

On the other hand, replacing batteries in the stock on a fixed rotation irrespective of their state may lead to extra expense over the lifetime of the device and has a negative environmental impact. It is generally not desirable to replace a battery when that battery continues to perform acceptably in the application for which it is currently being used.

Some "smart batteries" are available which provide users with a measure of battery health or a capacity factor (i.e. the percentage of its rated capacity the battery can still hold at full charge), but a measure of battery health which is acceptable in one environment or situation may not be acceptable in another environment or situation. An acceptable health level depends strongly on the specific use the batteries are put to and in some situations replacing a battery too early is a waste of resources.

Other indicators of poor battery performance, such as high battery discharge rates, low battery warnings, devices running out of battery during use, or having to put devices back on to charge before the end of the working day, give a more direct picture of how the battery performs in practice.

However, these performance metrics are highly noisy and can be affected by factors other than the battery health itself; for example problems with wireless connectivity, that cannot be fixed by replacing the battery in the device. Thus, in many instances batteries are replaced too early, leading to increased downtime and cost.

The present invention arose in attempt to provide an improved method of analysing the health of batteries and determine the optimum time for battery replacement.

According to the present invention in the first aspect there is provided a method for determining battery replacement or stock level of batteries provided in a plurality of devices comprising providing said plurality of devices; monitoring battery related events on the devices; monitoring the battery health level of all the devices, and using the monitored information to set a threshold level of battery health to indicate when batteries of devices should be replaced and/or to control stock levels of batteries.

Thus by using a plurality of devices and monitoring performance, a much 25 less noisy and more reliable estimate can be made of when a battery needs replacement or restocking.

The battery related events may be one or more of; battery discharge rates; battery low events, frequency or instances of battery swaps; connectivity issues, 30 frequency of charging devices, and instances of charging events.

For one or more of the monitored events a level may be set that is considered to be indicative of a problematic device or condition. The level that is set may comprise one or more of a particular battery discharge rate; a particularly low battery level; a particular frequency by which batteries are swapped, and; a particular frequency or time-of-day of charging a device.

The devices may be monitored over time, and the method comprise setting an initial default threshold level and moving this threshold level as the devices are monitored over time.

A group of the batteries that perform the best is preferably compared with a group of batteries that performed the worse in order to determine the threshold level. In one embodiment the best performing batteries are considered to be the top performing 50% of the batteries and the worse batteries to be the bottom performing 10% of the batteries.

Embodiments of the invention will now be described, by way of example only, with reference to the accompanying drawings, in which; Figure 1 shows a method for battery stock management; Figure 2 shows a method for battery stock management; Figure 3 shows a scenario; Figure 4 shows a further scenario; Figure 5 shows a step of learning which devices are used in similar ways to protect the number of batteries that need replacing in the future; Figure 6 shows a prediction step; Figure 7 shows a number of batteries provided at physically different locations, and, Figure 8 shows a plurality of mobile devices connected to a server.

Referring to the figures, a battery stock system will now be described, for predicting when batteries should be replaced for maximum efficiency and cost effectiveness.

As described above, batteries in mobile devices tend to deteriorate over time and an organisation which has many battery-using devices will need to replace those batteries regularly. However, it is unproductive and not cost effective to replace batteries unless the battery state at that time necessitates this.

In embodiments of the invention a relatively large number of devices are monitored. In typical environments, this may be at least 50 batteries, although the number may be lower or higher than this. The greater the number of batteries that are monitored the better, but the invention can work with any number of batteries.

Referring to Figure 1, an organisation uses a plurality of battery-powered mobile devices 1. This may be mobile phones (cell phones), mobile devices used for logging, stock control or delivery, or indeed devices such as tablets, laptops or computers, amongst other types of devices. They may be used in a single environment such as an office or a warehouse or may be portable and used in many different locations.

Each of the devices 1 is used by an operator to conduct their work.

In embodiments, as shown in Figure 8, each device 1 connects to a server 30 or control unit 2. The connection will typically be a wireless one, for example using WiFi, a mobile telephoning system, Bluetooth or other wireless connectivity. They may also be connected by wired or other physical connections if necessary.

In the general scheme shown in Figure 1 each of the devices is used normally by its user, and also communicates (as shown in Figure 8) to the central server. Note that the server 2 shown in Figure 8 may be one that is dedicated to monitoring battery heath and stock levels, although it may alternatively be part of a server which is used to more generally communicate with the devices in order to transmit, receive and/or store data relevant to their normal day to day use. Thus, each device may communicate with several servers; normal day to day ones used to conduct their work, and a separate battery-monitoring server, if desired.

The devices continually, or perhaps at specific time intervals, transmit data indicative of the health of their batteries to the server. The server is then provided with algorithms which learn from what battery health level users start to see an increase in battery problems, such as low battery events, high battery discharge rates, frequent battery swaps, erratic battery level, or high frequency of having to put a device back to charge. Many other symptoms of battery problems may be apparent, such as connectivity issues. Any one of more of these or other events or symptoms or conditions are supplied to the server 2.

This may be informed, for example, when a user has to put their device onto 20 charge, and the battery itself (eg a 'Smart Battery') may indicate its battery level or health to the server.

The server may also be provided with data indicative of the type of use of the device at any time, so that it can correlate this with the battery health level.

For example, the device may transmit to the server that it is being used to scan or process goods, or monitor the completion or flow of a service or process, or that it is being used for a telephone or video conversation, or to transmit data using messaging services, or for email and web browsing, for photography, for audio and/or video playback, or many other uses. Other parts of a system may also transmit this or other data to the server, instead of or in addition to the device itself.

The batteries and devices may indicate, to the server, high battery discharge rates, low battery warnings, warnings of devices running out of battery during use, or of having to put devices back onto charge before the end of the working day, so that a picture can be built up of how the battery performs in practice. This can then be related to and/or correlated with, the type of operations and functioning the device is being used for.

By using a relatively large number of devices (for example over 50, although the number may be less than this) a threshold can be learnt of a particular battery health level at which users of a device start to see an increase in battery problems such as low battery events. Note that battery health per se is of course a different parameter to battery level.

Noisy information on battery related problems can thus be rendered less noisy by aggregating the results from a plurality of devices, relating them to the uses the devices are put, and thus learning a threshold of a more stable battery health level in which battery should be replaced. The server can then learn and predict when a battery should be replaced in any particular device, based upon battery health threshold levels learnt from a plurality of devices, for maximum efficiency and productivity and to avoid battery-related productivity losses.

This is shown in Figure 1 which shows a plot 3 is made of the likelihood battery problems P against a measure of battery degradation H (battery health). A threshold level 5 is learned relating to a battery health level (battery degrading) at which time problems will start to occur at an unacceptable rate and therefore this threshold represents a battery level of any particular device (within the cluster or group of devices that are being monitored) at which the battery in that device should be replaced. The system then informs the user of the device (via the device itself), or a central operator, to replace the battery or issues an alert or signal to a central controller that the battery in that particular device needs replacing so that the device can be recalled and the battery replaced.

The threshold level can then be adjusted as the devices are used over time. Thus, initially, a threshold level will be estimated and this threshold level will then be adjusted up or down as more information and data is obtained from the devices to give a better estimate of the threshold level.

Figure 2 shows how after an initial default threshold level is first set, the threshold level may be updated by "moving" it. This means that the health level of a particular battery at which replacement is considered necessary may be adjusted as the system learns from experience of use over time of the group of devices containing batteries.

As shown in Figure 2, a method according to the invention first sets a default threshold level 5a. This will be related to the capacity (ie health) of a battery at any time. It may be, for example, when the battery health has reached 20% of its 15 maximum (ie new) capacity.

Each particular device la, lb, 1c.......1 n is monitored and the measurement made of its lower battery health score (Y-axis) against battery capacity (X-axis). As described, battery health can considered lower if the device must be put on-charge zo more, and so on. A level higher on the y axis has a worse (lower) battery health than a level lower on the axis, ie the higher the device is in the Y direction then the worse it is performing. Thus, as shown, in practice different devices perform better or worse than other battery devices at the same battery capacity level. So one device 1 n is shown as having fewer problems or a better battery health, than a second device in-i.

This default threshold can then be moved left and right along the axis, depending upon the measured levels, as described below.

Figures 3 and 4 are examples of different scenarios by which the threshold may be changed. In the scenario of Figure 3 batteries 1 e, if and lg are closer to the threshold than batteries la, lb and 1 c, for example. That is, they have a lower battery capacity than batteries la to lc. However, these batteries are not actually performing significantly worse than batteries I a, lb and lc in terms of battery discharge rate, frequent battery swaps and so on. They are generally at around the same height on the y-axis. In such a scenario, it is seen that batteries close to the initial threshold level 5a do not appear to perform worse than 'better' batteries (ie batteries of higher battery capacity). In this case, the threshold level 5a has therefore been set too high and the threshold level may be moved to a new lower level 5b.

In a typical embodiments, in order to determine this, a percentage of the batteries with the best health/highest capacity factor t is compared to a percentage of batteries with the worst health. In one implementation, these two sets of batteries, set A and set B (shown by the rings in the figure) are then compared using a statistical test to determine if the batteries with the lower health/capacity factor perform worse than the batteries with the better health/capacity factor. If a statistical significant difference in performance is detected we additionally use a threshold for effect size to determine if the difference is of a meaningful magnitude.

One measure of battery performance to conduct this test might be based on the number of battery low events within the last month, week, day, or other time period. This relates to how often the battery level drops below a certain threshold which may be 20%. However, other factors may be used for this statistical test such as battery discharge rate, the number of times batteries are swapped in the device, frequency by which the battery has to be put onto charge and so on.

Depending upon the average capacity factor of the worst batteries, and on whether they perform worse than the better batteries, then the battery replacement threshold may be moved up and down.

Figure 4 shows a scenario in which the threshold is moved up from 5b to a new threshold Sc because batteries close to the threshold seem to perform worse than better batteries.

Thus, in embodiments, a group of the batteries that have the best health is compared with the group of batteries that have the lowest health in order to determine the threshold level on a dynamic basis.

In modifications, devices may be grouped into different sub-populations so that different battery thresholds may be obtained for different subgroups of devices.

Unsupervised clustering techniques may be used for this, as will be apparent to those skilled in the art. This is shown in Figure 5.

113 Figure 5 shows three groups of devices, 10, 11 and 12 each of which have different uses. Thus, group 10 may be used for communications, group 11 for stock control and so on, although in practise the uses may be much more nuanced in their differences than this. For example, some devices, say group 10, may be used in a warehouse/storing centre and the devices in group 11 may be used in delivery vans, such that they are used to monitor delivery of goods to third parties.

The devices in different groups may have different applications installed or the same or similar applications installed but different applications used between different groups so that, for example, all the devices used in a warehouse may have one set of applications installed or used to a greater extent whereas all the deliveries devices may have another set of applications installed or used. Mobile devices may also be grouped by whether they are using mobile SIMs and/or mobile data on one hand, or which solely use WiFi or similar, or by how much they are physically moved in operation. For example, the degree by which they move may be based on GPS or other tracking data. The grouping may include the use of different components of the mobile device or external apparatus, eg use of a camera, scanner, speaker and/or microphone.

In embodiments, the devices in different groups may be monitored separately so that if one type of application or use tends to degrade batteries and the health of batteries quicker than another type or use or application, then different thresholds may be set for the devices in the different groups. Thus the batteries in one group of devices may be changed at a different threshold level 5a to that of another, differently used or configured, group.

Figure 6 shows an embodiment in which not only is the threshold for battery 5 change calculated but in which the system is used to predict when battery replacement will be required at some date in the future. This can be done by monitoring devices over time so that the rate by which batteries deteriorate and go from fresh new batteries to needing replacement batteries is monitored and therefore the requirements for future replacement and therefore future replenishment of stock levels of batteries may be determined or predicted.

Figure 6 therefore shows a plot at which the plot of the requirement for replacement batteries over time, which therefore of course increases as shown in plot 13. This enables for better stock control and for bulk ordering so that batteries 15 are only ordered in when required but in good time for when they are required.

In further embodiments, as shown in Figure 7, in which devices are generally used in different locations 14, 15 and 16 then the system can be used to determine the number of new batteries needed in a specific location from a number of devices using each location and their uses and applications used. Again, location 14 may be warehouse, location 15 may be logistic centre, location 16 another warehouse in a physically remote location and so on. This is because devices used in different locations will often have different use patterns, intensity of use, and so on.

Claims (16)

1. Claims 1. A method for determining battery replacement or stock level of batteries provided in a plurality of devices, comprising said plurality of devices; monitoring battery related events on the devices; monitoring the battery health level of all the devices, and using the monitored information to set a threshold level of battery health to indicate when batteries of devices should be replaced and/or to control stock levels of batteries.
2. 2. A method as claimed in claim 1, comprising a server for receiving health and event data from each of the devices and for setting the threshold level based on these.
3. 3. A method as claimed in claim 1 or 2 wherein the data is transmitted from 15 each device to a server.
4. 4. A method as claimed in any preceding claim wherein the battery event data comprises one or more of; battery discharge rates; battery low events, frequency or instances of battery swaps, connectivity issues, frequency of charging devices, 20 and; instances of charging events
5. 5. A method as claimed in claim 4 wherein for one or more of the monitored events a level is set that is considered to be indicative of a problematic device or condition.
6. 6. A method as claimed in claim 5 wherein the level that is set comprises one or more of a particular battery discharge rate; a particularly low battery level; a particular frequency by which batteries are swapped, and; a particular frequency of charging a device or a particular time-of-day at which a device is charged.
7. 7. A method as claimed in any preceding claim wherein a group of the batteries that have the best health/highest capacity factor is compared with group of batteries that has the worst health/lowest capacity factor in order to determine the threshold level.
8. 8. A method as claimed in claim 6 wherein the best batteries are considered to 5 be the top 50% of the batteries with the best health and the worse batteries to be the bottom 10% of the batteries with the worst health.
9. 9. A method as claimed in any preceding claim wherein the devices are monitored over time, and comprising setting an initial default threshold level and 10 moving this threshold level as the devices are monitored over time.
10. 10. A method as claimed in any preceding claim comprising grouping the devices into sub-groups dependent upon different uses the devices are put to, and/or different applications, functionalities, or components used and/or installed, 15 and setting separate thresholds for different groups.
11. 11. A method as claimed in any preceding claim including predicting, from the data, future stock levels of batteries.
12. 12. A method as claimed in any preceding claim comprising monitoring the location at which devices are used and using this information to determine levels of stock of batteries at different locations.
13. 13. A method as claimed in any preceding claim comprising monitoring the use 25 made of each device and collating this with battery events.
14. 14. A method as claimed in any preceding claims comprising using at least 50 devices.
15. 15. A system for controlling stock levels of batteries in an environment, comprising a server; a plurality of battery-powered devices; the devices being arranged to transmit battery performance data and health data to the server and the server using the battery performance data and health data to determine a health threshold below which batteries should be replaced.
16. 16. A system as claimed in claim 15, adapted to perform a method as claimed in any of claims 1 to 12.