A distributed power management system and communications device

Abstract

The invention provides a tracking device, comprising a processor and a memory, the device being arranged to: receive data from a central server, the received data representing a matrix subset corresponding to the expected location of the device and detecting physical parameters from a local environment and in dependence on a comparison of the detected local communications parameters and the received subset determining an operation.

Description

[0001] A Distributed Power Management System and Communications Device

[0002] The present invention relates to a power management system and a communications device. In embodiments, the invention relates to a tracking device, a server system and a method of operating a server system for control of a plurality of loT (internet of things) devices, such as tracking devices. In embodiments, the invention relates to a distributed power management system for optimising edge communications and device behaviours in the global supply chain.

[0003] Artificial Intelligence (Al) has now become a key driver for business transformation. Big consulting firms and all listed companies with significant market capital valuations are developing strategies to benefit from recent Al advancements. The long-term future of Al will rely on computational power or resource as a key metric of performance. According to Sam Altman, in the future, if more computational resource can be used for a task, it will be used. The cost of the computing will become the key limiting factor due to economics. This is because, aside from other growth factors in Al use, given the choice, it follows that the maximum intelligence will be used for any task.

[0004] The high cost of computational power or resource is due to the processing of data. Reducing the cost of computational power or resource can be achieved by reducing the amount of data through pre-processing.

[0005] In the supply chain industry, which is the world's biggest industry and a key beneficiary of Al value improvements, the majority of data is collected by sensors in realtime at the edge, i.e. , away or remote from the central data processing resource which will typically be in a cloud environment.

[0006] A key way to handle this task is through pre-processing data in real-time to events to reduce the cost of computational power or resource. As such, edge intelligence deployed optimally at the edge will be a key mechanism for value creation through cost reduction, capacity enlargement, and optimum economic use of Al, enhancing margins inside businesses and in the economy at large. According to a first aspect of the present invention, there is provided an loT device, e.g. a tracking device, comprising a processor and a memory, the device being arranged to: receive data from a central server, the received data representing a matrix subset corresponding to the expected location of the device and detecting physical parameters from a local environment and in dependence on a comparison of the detected local communications parameters and the received subset determining an operation.

[0007] A tracking device is provided which is arranged to receive from a central server a subset of a matrix indicating the location of the loT device and some physical parameters relating to the environment of the loT device. The loT device is preferably arranged to periodically (at appropriate or determined times, described below) to scan its local environment to gather data relating to one or more physical parameters. The gathered data is preferably stored locally at the loT device and then, at an appropriate time communicated to the central server. The data gathered at the central server can be used to train a model for control and of the tracking device or to enable the tracking device to control itself.

[0008] Importantly, the central server, based on received data from the tracking device and an Al / machine learnt model developed from the data, is able to determine what if any data needs to be transferred to the tracking device. The transferred data will typically comprise a subset of the matrix stored at, by or associated with, the central server.

[0009] In use, when the tracking device has received data, i.e. , a subset of the matrix from the central server, it is able to compare the received subset of the matrix and compare the data within the matrix subset with locally scanned data. In dependence on the locally scanned data, it can take various courses of action, as will be explained in detail below. For example, if it finds that the data received is up to date then it might do nothing further. In contrast, if it detects that the values of the physical parameters in its local environment are not consistent with the data in the matrix subset it has received, it can communicate an update to the central server.

[0010] The use of such a tracker device enables a minimising of the communication between the central server and the tracker device. The central sever might typically be arranged in the cloud.

[0011] A system is also provided in which a model is maintained and updated based on data received from one or more edge devices, such as the tracking or loT devices referred to above.

[0012] Communication between the tracking device and the central server or cloud, is preferably only performed when a change is detected by an edge device. Thus, communication between the edge device, which is typically an IOT tracking device, and the central database is minimised, which consequently minimises power consumption by the edge device, whilst at the same time ensuring that the central database is maintained updated in such a way that reliable processing can be performed on the data and determined from it.

[0013] Typically, Al such as Machine learning is used on the database and factors such as expected movement trajectories of the individual IOT device can be determined.

[0014] In an embodiment, the tracking device stores locally the subset matrix and stores a record of physical parameters for cells within the subset matrix.

[0015] In an embodiment, the comparison of the detected local communications parameters and the received subset comprises a comparison of the subset matrix and the recorded physical parameters for the tracking device.

[0016] In an embodiment, the comparison of the detected local physical parameters and the received subset comprises a determination of the time since the subset matrix was received from the central database. In an embodiment, if the time since the subset matrix was received is greater than a defined threshold the tracking device performs a new scan of the local physical parameters.

[0017] In an embodiment, in which the new scan of local parameters is a low power scan.

[0018] In an embodiment, in which, subsequent to performance of a new scan of the local physical parameters, the local parameters are communicated by the tracking device to the central database.

[0019] In an embodiment, the tracking device is arranged to receive from the central database a tracker device cell sequence indicating an expected route of movement.

[0020] In an embodiment, the physical parameters including one or more of communications parameters, temperature parameters and dwell time parameters.

[0021] In an embodiment, the tacking device having a transmitter for issuing communications.

[0022] In an embodiment, the tracking device is arranged to communicate with a second like tracking device using low power Bluetooth.

[0023] In an embodiment, the tracking device is arranged to transfer to the second like tracking device a matrix subset if it is determined that the matrix subset stored by the second like tracking device is older than that of the first tracking device.

[0024] In an embodiment, a unique identifier is associated with each matrix subset and the determination as to age of subset is based on the unique identifier.

[0025] In an embodiment, the tracking device comprises one or more sensors for detecting physical parameters from a local environment. In an embodiment, the one or more sensors are arranged periodically to activate and detect physical parameters from a local environment of the tracker.

[0026] In an embodiment, the periodicity with which the one or more sensors are arranged to activate and detect physical parameters from a local environment of the tracker is higher than a periodicity with which the tracker is arranged to communicate gathered data to a central server.

[0027] According to a second aspect of the present invention, there is provided server system for control of a plurality of loT devices, the system comprising a server; memory storing a matrix representing an area to be covered by the system; a processor, arranged, upon receipt of a communication from one of the loT devices, to select a subset of the matrix including the region in which the loT device is located, and sending it to the loT device, wherein at least one or more of the cells of the subset of the matrix contains data relating to physical parameters from a local environment in which the loT device is located.

[0028] In an embodiment, subsequent to performance of a scan of the local physical parameters by the loT device, the local parameters are communicated by the tracking device to the server.

[0029] In an embodiment, the sever system is arranged to receive from the central server a tracker device cell sequence indicating an expected route of movement.

[0030] In an embodiment, the physical parameters including one or more of communications parameters, temperature parameters and dwell time parameters.

[0031] In an embodiment, the server system comprises a model builder arranged to build a predictive model for loT device movement in dependence on location data provided by the loT device to the server.

[0032] A server system is provided in which a model is maintained and updated based on data received from one or more edge devices, such as loT or tracking devices. The communication between the tracking device and the data upon which the model is based is only performed when a change is detected by an edge device. Thus, communication between the edge device, which is typically an loT tracking device, and the central server where the database can be maintained, is minimised. Consequently, this minimises power consumption by the edge (loT) device, whilst at the same time ensuring that the central database is maintained updated in such a way that reliable processing can be performed on the data and determined from it.

[0033] In an embodiment, the model builder uses machine learning to develop the model.

[0034] In an embodiment, in dependence on the developed model the size and position of the matrix subset is selected.

[0035] In an embodiment, machine learning with the use of a transformer model can be used, i.e. , a neural network that learns context and thus meaning by tracking relationships in sequential data like the sequence of cells through which an loT device has travelled. It will be appreciated that known methods of machine learning and Al can be used to determine the outputs from the central server or the loT devices. What is important and enables this to be done is the maintenance of the data set gathered from the loT devices as described throughout herein.

[0036] In an embodiment, a first loT device is arranged to communicate, e.g., to broadcast, locally with other loT devices using a low power communications protocol.

[0037] In an embodiment, the low power communications protocol is low power Bluetooth communication.

[0038] In an embodiment, the server system comprises a server trajectory model, the server trajectory model being arranged to receive as an input the cell sequence for one of the loT devices and to predict based thereon the next cell position for the loT in question.

[0039] In an embodiment, the server trajectory model is an Al generated model trained using device cell sequences provided by individual ones of the plurality of loT devices. In an embodiment, the physical parameters relate to the RF environment of the one or more loT devices.

[0040] In an embodiment, the physical parameters relate to one or more of the temperature of or dwell time in an environment of the one or more loT devices, accelerometer data (detection of movement, orientation) and light.

[0041] In an embodiment, the server is located in the cloud, i.e. , on a cloud computing infrastructure, and the loT devices are provided as tags for association with a product or vehicle. It will be appreciated that a tag is merely a non-limiting example of what is termed more broadly an loT device. The loT devices could alternatively be mobile gateways or other forms of loT device.

[0042] In an embodiment, the, or each, of the loT devices are tracking devices according to the first aspect of the present invention.

[0043] According to a third aspect of the present invention, there is provided a method of operating a server system for control of a plurality of loT devices, the system comprising a server; a memory storing a matrix representing an area to be covered by the system; and a processor, the method comprising: upon receipt of a communication at the server from one of the loT devices, selecting a subset of the matrix including the region in which the loT device is located, and sending it to the loT device, wherein at least one or more of the cells of the subset of the matrix contains data relating to physical parameters from a local environment in which the loT device is located.

[0044] In an embodiment, the method comprises generating a server trajectory model in dependence on data received from the plurality of loT devices.

[0045] In an embodiment, the server trajectory model is Al generated using trained using device cell sequences provided by individual ones of the plurality of loT devices.

[0046] According to a fourth aspect of the present invention, there is provided a distributed power management system for control of a plurality of loT devices, the system comprising a server; memory storing a matrix representing an area to be covered by the system; a processor, arranged, upon receipt of a communication from one of the loT devices, to select a subset of the matrix including the region in which the loT device is located, and sending it to the loT device, wherein at least one or more of the cells of the subset of the matrix contains data relating to physical parameters from a local environment in which the loT device is located.

[0047] A system is provided in which a server is able to communicate with plural loT devices which are preferably distributed in association with, say, individual vehicles, goods consignments, pallets etc. The system functions to manage the power of the loT devices in dependence on data gathered by the loT devices and that can be managed both at the central server and at the loT devices themselves. As will be explained below, machine learning using, say, a transformer model, is used to enable optimisation of power usage of the loT devices. In the global supply chain this provides a significant technical advantage, as described in detail below.

[0048] In an embodiment, the power management system comprises a plurality of loT device each controlled or controllable to communicate with the server and / or with each other in dependence on data received from the server.

[0049] In an embodiment, the server is arranged to communicate context in the form of a matrix subset to one or more of the loT devices.

[0050] In an embodiment, the or each loT device, in dependence on a received matrix subset is arranged to determine whether or not to communicate with the server.

[0051] In an embodiment, the or each loT device has a power supply, such as a rechargeable power supply, and is arranged to minimise usage of the power from the supply by determining if communication with the server is required, and only communicating with the server if such communication is required.

[0052] In an embodiment, the or each loT device determines that communication with the server is required if it does not have a store of a subset matrix which is within a determined Time To Live period. It will be appreciated that the or each of the loT devices present in the fourth aspect of the present invention, can be a tracking device according to the first aspect of the present invention (and as specified in any of the embodiments thereof).

[0053] The invention thus provides in embodiments, to the interoperation of supply chain systems, loT devices and the use of Al. Tracking data, such as data relating to RF environment of an loT device, can be gathered at a central server (from the one or more loT devices) and used to train machine learning model used for control of the loT devices. The use of such a system enables power control for the system as a whole due to the selective operation or control of the loT devices, as explained in greater detail below.

[0054] Embodiments of the present invention will now be described in detail with reference to the accompanying drawings, in which:

[0055] Figure 1 is a schematic view of a 2-dimensional matrix representing the surface of the earth used in device management;

[0056] Figure 2 is a schematic view of a device update process;

[0057] Figure 3 is a schematic of a view of a 2-dimensional matrix update process;

[0058] Figure 4 is a schematic view of the live updated status of the 2-dimensional matrix representing the surface of the earth;

[0059] Figure 5 is a schematic view representing the process of device cell sequence update;

[0060] Figure 6 is a schematic view showing device subset matrix update;

[0061] Figure 7 is a schematic view representing the process of device cell sequence update causing device behaviour change; Figure 8 is a schematic of a view of low-power inter-device communication;

[0062] Figure 9 is a schematic of an overall system architecture including plural edge devices in communication with the central database and two dimensional matrix;

[0063] Figure 10 is a flow diagram showing the steps of setup in a system architecture such as that of Figure 9;

[0064] Figure 11 is a flow diagram showing the steps of data reporting and fetching as executed and operated by devices within a system architecture such as that of Figure 9;

[0065] Figure 12 is a flow diagram showing the steps of device behaviour tracking location within a system architecture such as that of Figure 9; and

[0066] Figure 13 is a flow diagram showing the steps of inter-device communication and data sharing within a system architecture such as that of Figure 9.

[0067] The present system and method rely on use of plural devices that are arranged and configured to track and provide date regarding vehicles or units with which they are associated. For example, a device could be associated with a vehicle such an HGV lorry or with a pallet of goods within a container on a goods tanker conveying goods from, say Europe to Asia.

[0068] The devices are deployed globally, monitoring logistics movements for businesses and organizations. The devices, which may be referred to as edge devices within the present application as they are remote from a central server, are typically battery-powered with either rechargeable or primary (non-rechargeable) cells. Thus, they have a limited operating period before the battery depletes. Techniques are employed to manage battery use, allowing for longevity and small size while collecting and transmitting sufficient sensor data back to the central server typically arranged in the cloud, for respective use cases.

[0069] There is a constant need for optimization between data collection and energy consumption. The optimization allows for data to be collected in a manner optimized for use cases. Importantly, it also allows for a centralized dataset to be optimally maintained for continuous training of an Al model that encapsulates the business logic for the use case. The devices, referred to herein as loT (“internet of things”) devices, are arranged to collect data and transmit the collected data to a central server. The gathered data can then be used to train an Al model which itself can be used to optimise the function and battery life of the loT devices.

[0070] In its broadest sense, the present system provides a way in which supply chain systems, loT devices and Al are used to optimise the management and control of the flow of goods around the world. The three items are brought together in a way which addresses the technical problem that the loT devices have a finite and, in practice, limited power source but nonetheless to retain effectiveness and utility need to last a long time, e.g., weeks and months rather than hours or days.

[0071] The loT devices are arranged in a general sense to gather data which is fed into a large Al data set. The Al data set is then used to optimize management, control and operation of the loT devices as they move around the world. The detailed methods and processes by which this is achieved will be described in detail below.

[0072] As will be explained in detail below, at the “centre” of the system architecture, e.g., in the data cloud, an x-dimensional latitude-longitude (“lat-long”) matrix is maintained representing the physical 2-dimensional surface of the area under management. The matrix is made up of a 2-dimensional array of cells each corresponding to a region on the earth in the area under control or management. Typically, this would be the entire surface of the earth as it represents the surface upon which one of the devices could be moving. It could also be a smaller area if the system were used to optimise a supply chain in. say, just one country, region or continent on earth.

[0073] Each cell of the matrix contains time-stamped sensor data obtained from the loT devices at the “edge”. The sensor data is time stamped and specifically is assigned a time to live (TTL). The TTL is important. It can be adjusted for different matrix cells once the system understands or has learnt the frequency with which the RF environment within the cell changes As mentioned, the devices are defined at being at the edge in contrast to the central server and managed database arranged to receive data transmitted from the loT devices. Typically, the central server 12 and database are provided in the cloud. At the edge, devices periodically receive local knowledge (context) from the centre in the form of a subset of the matrix, allowing them to make decisions based on the immediate sensed environment and the context provided by the centre.

[0074] The edge device decides in real time whether to change behaviour or not based on various factors. An edge device may, for example, scrape (gather data continuously for a period), sample (take a snapshot), or report to act on the use case or gather data to enable the central model to be refreshed. An individual loT device may also signal a second local device to augment that second device’s context.

[0075] In operation of one of the loT devices, the energy consumption of the device is carefully managed and limited in that the primary use of energy is in communicating, not sensor scanning. Sensor scanning is typically significantly less energy intensive. Furthermore, decision making for each of the loT devices is done locally. Individual loT devices make local decisions to interrupt their normal or current behavior based on environmental monitoring at the edge.

[0076] For example, a device set to report once an hour can wake every minute when moving and sample sensors without communicating, i.e. , scan the RF environment without communicating. As will be explained below, if it detects it is in a cell requiring a data refresh, it switches to data gathering mode and transmits the data back to the central server at the next opportunity.

[0077] Thus, the system provides the ability to use RF-Zones to behave in a context- aware manner without permanent communication with the centre, i.e., in the cloud. Infrequent communication is an intended feature of battery-powered loT devices, and 'data gaps' are not problematic but a feature of the use case. The crucial aspect is for the device to wake up at the right time and place to achieve its desired technical goal, to be described in detail below. The system provides an innovative and non-obvious way in which power usage is controlled by the interaction of Al and loT devices within a supply chain environment.

[0078] Figure 1 is a schematic view of a two-dimensional matrix representing the surface of the earth used in device management. The matrix 2 is made up of a number of individual cells 4 each representing a two-dimensional area on the surface of the earth. As can be seen from the schematic representation of the globe 6 the two- dimensional matrix may be thought of as a latitude-longitude two-dimensional array. Each of the cells 4 of the matrix 2 thus represents a two-dimensional area on the surface of the earth. “2D” refers to the earth’s surface although it will be appreciated that this could also include 3D data such as details of the local terrain or buildings. So, it could actually be a 3D representation of the earth’s surface including hills / mountains, buildings.

[0079] Within each of the cells, which might be anything from a few square metres to a few square kilometres, there is a defined radio frequency (RF) environment. It should be noted that the description herein will be predominantly with respect to a detected RF environment. However, other environmental parameters could be used as well as or instead of the RF environment. Typically, the parameters can be use-case specific factors including amongst others, say, light, temperature, vibration, humidity, etc.

[0080] Within any one of the cells 2 the RF environment is determined by RF transmission devices that might be in the locality or within range of the cell. That means that within any cell, there will be a detectable RF environment which could comprise any one or more of WiFi, Bluetooth, mobile telephone and / or GPS signal. The RF environment within each of the cells has a TTL (time to live) given that the RF signals will vary over time. For example, it might be that a GPS satellite is passing within the vicinity of one of the cells at one point in time whereas at some later point in time the satellite will not be present. A skilled person will understand that multiple factors affect cell signals, e.g., cell-breathing (signal power management based on cell-tower usage), movement of physical infrastructure, even the weather. The same is true with other signals, e.g., people move their WiFi access points and the movement of vehicles, and humans all affect signals.

[0081] Accordingly, the RF environment of the cell, as it would be detected by a detecting device, will vary over time.

[0082] In some of the cells, such as the cell numbered 5, there is a temperature that has been measured. In common with the RF environment, the temperature is another parameter that can apply to a particular cell and will also be associated with a TTL. A central server connected to or storing a central database is provided (not shown in Figure 1) which stores the two-dimensional lat-long matrix together with the defined RF defined environments and the TTLs for each of the cells at any point in time. As will be explained below, this represents a large data set which can be used to control and determine behaviour of individual loT devices.

[0083] As explained above, in practice, an individual loT device will be associated with a particular vehicle or pallet, mode of transport, batch of goods, or type of conveyance which might be travelling on the earth’s surface. This means that at any point in time the loT device will be arranged within one of the cells 4 of the lat-long matrix.

[0084] Referring to Figure 2, an exemplary process by which an loT operates within the present system and can be updated will be described.

[0085] Referring to Figure 2, an loT device 8 can be seen which is typically provided in the form of a device which includes a PCB having various desired components fixed thereon. In this example, the tag 8 includes some processing capacity, e.g., a microprocessor together with memory and a power supply such as a rechargeable battery. As explained above, a goal of the present system is to optimise the usage and lifetime of the power source within the loT device 8.

[0086] The loT device 8 is arranged to scan the RF environment 9 in whichever cell it is positioned at the point in time when the scan is taking place. Sensor data is collected which relate to the values of the detected parameters. For example, it could include the identification and strength of a WiFi signal or the strength of a local Bluetooth signal. At an appropriate time, to be discussed in greater detail below, the scanned RF environment is communicated 10 to a central server 12 which is typically in the cloud and associated with the lat-long matrix 2. The server 12 upon receipt of the scanned RF environment from the loT device 8 is arranged to update the matrix content in the appropriate corresponding cell 14. The RF environment might typically be represented by a number of parameters relating to the identity and strength of various communication signals detected as part of the scan. In the example shown, a WiFi signal 16 has been detected, as has a tower signal 18 for a mobile telephone, together with a Bluetooth signal 20 and a GPS signal 22.

[0087] As well as updating the matrix content for the particular cell 14, the server 12 functions to update a device cell sequence which is a record of the physical position of the loT device, i.e. , a record showing the sequence of cells within the matrix 2 that the loT device has been in and is in at the time the scan in questions was taken. The location of the loT device is part of the data that is provided to the server 12 via the communication link 10 when the server 12 is updated. As will be explained below, the loT device cell sequence 15 can be used to predict the subsequent cells that the loT device is expected to travel through.

[0088] The device cell sequence is a record of the sequence of cells through which the IOT device has passed. The central server 12 thus stores not only the central matrix that has values of RF parameters for individual cells but is also able to develop an ML / AI-generated model showing the movement patterns and trajectories of loT devices based on data the transmitted to and received by the server 12.

[0089] Figure 3 is a schematic view of a two-dimensional matrix process which shows in greater detail the snapshot of an RF environment and as specified for a particular cell 14. In this example, the snapshot 24 includes data relating to the WiFi signal and cell phone data associated with that cell. As indicated, at TTL of one week is shown for this cell within the matrix 2.

[0090] Figure 4 shows a view of a matrix 2, in which the individual cells are colour coded (can we re-do this figure with different hashing or shading as the colour won’t be accepted in formal drawings in the application). The coding of the cells indicates for each of the individual cells within the matrix 2 their status and whether or not they contain valid data, i.e., data that is still within the TTL of the cell in question. Cells marked red do not have valid data. Cells marked green do have valid data. Thus, a number of the cells 26 are shown as green given that they have an active RF fingerprint which is within its TTL.

[0091] Quite a number of the cells 28 are shown as red given that they are outside their TTL and therefore they are not considered to have up to date information within them relating to the RF environment of the cell in question. However, this is not a problem at any point in time given that as long as there are no IOT devices within those individual cells there is no need for the RF environment to be up to date and within its TTL.

[0092] As will be explained below with reference to the present method, if an loT device 8 were to enter one of the cells 28 currently shown red, it would realise that there is no live RF environment for the cell. This would cause it to activate itself to take a scan of the RF environment and communicate the scanned data 10 back to the server 12 so that the central matrix 2 can be updated. The cell would then turn green and have its TTL reset.

[0093] A number of the cells 30 are shown as yellow / amber, indicating that they are close to expiry and to transitioning back to red cells within the matrix. In other words, they will be approaching the end of the time period defined by the TTL. Overall, a traffic light type system is used to indicate the status of individual cells within the matrix 2.

[0094] With reference to Figure 1, a brief description was provided of the device cell sequence 15. This is an important feature, to be described in greater detail below, as it represents the expected sequence of cells through which an loT device will move. This is based on many factors relating the loT device including its previous positions and trajectories. The device cell sequence is determined using Al and machine learning based on the data within the matrix 2. In other words, it can be thought of as representing the learnt likely sequence of cells within the matrix that a device in question is expected to follow. Referring to Figure 5, a more detailed description is given of this. A device cell sequence 15 represents the sequence of cells that a device has been in. A server trajectory model 32 is provided which determines the likely next cell within the matrix for the loT device in question based on the device cell sequence 15 provided as an input. In other words, the server trajectory model 32 is a model used at the server 12 to determine the next likely cell for the loT device. The server trajectory model 32 is a machine learning generated model that is arranged to work out the next cell a device will be in. It is a large, generated model for use and maintenance by or at the server 12. The significance of this will be explained below.

[0095] The server trajectory model may be a machine learnt model and is arranged to receive as an input the device cell sequence 15 and to determine based upon it, a next cell 34, which it is expected the device will next travel into. Once the next cell 34 has been determined, a subset of the matrix 36 representing the likely cells 38 that the IOT device 8 is expected to travel into, is communicated to the loT device 8. Thus, it will preferably have with it an up-to-date RF environment determined from the central matrix at the server 2.

[0096] Presuming the server trajectory model has correctly identified the next cell 34 and provided an appropriate matrix subset 36 to the loT device, means that the loT device does not for some following period need to communicate again with the central sever 12. Alternatively, it can determine a required next step with the security of the knowledge of its local environment and without necessarily having to communicate with the central server 12. The use of power within the loT device can thus be minimised.

[0097] The matrix subset 36 provided to the loT device can be as small or as large as desired by application. In a situation in which the system is being used to control movement of goods around the UK, tit could for example represent a region such as, say the east Midlands, or if it is being used to control movement of goods across an ocean it could represent a 30 square mile zone of, say, the South China Sea. It will be appreciated that the size and coverage of the subset matrices is entirely application specific. Figure 6 is a schematic view showing communication of the subset matrix 36 to the loT device 8. Accordingly, at the server 12, once it has been determined what the next cell is for the loT device 8, the subset matrix 36 that covers that next cell is sent to the loT device 8. The loT device is then in receipt of the subset 36 of the central or main matrix 2 which includes the cell that it is currently in and the cells it is expected to move to next. The device also has a device trajectory model 32 which is a machine learning generated model that functions to work out the next cell a device will be in. It is a smaller and device specific model than server trajectory model described above.

[0098] As can be seen one of the cells of the subset matrix is red, indicating it does not contain up-to-date information regarding the cell in question. For example, the data may have timed out. If it thinks it is in a green cell it takes a scan (using low power systems) and can confirm that the RF signature corresponds to that of the cell in the subset matrix. It knows where it is, and no further action is needed by the loT device. The decisions as to how a cell operates are made using low power.

[0099] Otherwise, the loT device will determine that it is in a certain cell which is part of its local matrix subset, it takes a local scan, confirms that it is in the cell in question and needs to take no further action.

[0100] If the loT device does not get a next cell indication, i.e., it is out of the subset it has received or has stored locally, it reverts to fallback behaviour and does a full RF scan. loT devices can also communicate with each other independently of any communication with the central server 12. This is beneficial since the communication can be performed using low power Bluetooth and so can be enable cells to communicate the subset matrix, they have stored at any time with a local cell which will also be somewhere within the are covered by the subset matrix in question. In practice, each of the loT devices is arranged to continually scan the local RF environment. The or each loT device includes a subset of the main matrix 2 which has been communicated to it from the central server 12. However, the loT devices are able to communicate with other loT devices within their Bluetooth range. This is useful as it means that for a cell whose subset matrix has all gone out of TTL, it can receive a refreshed valid subset matrix without needing to perform any high- power operations involving communicating with the central server 12.

[0101] In normal operation the frequency of reporting into the central server 12 from an loT device is configurable by users. This configuration is done in such a way as to manage the battery power of the IOT device whilst ensuring functionality of the system as a whole.

[0102] Typical examples would have the loT device reporting into the central matrix every 4 hours. However, this frequency or time period could be set to whatever other value is desired by a user.

[0103] In a particular physical example, individual pallets on a lorry being used to move goods will be provided with a corresponding IOT device. Some devices may be embedded in the pallets themselves whereas others will be associated with the vehicle carrying the palette or provided as a discreet device physically attached to the palette. In this example, where plural palettes are arranged on a common vehicle to the IOT device associated with each of the individual palettes will be moving together consistent with movement of the vehicle. In this situation, it follows that one of the devices on the vehicle will have the subset matrix that all of the other devices will also need, or that will be relevant to each of the other devices on the vehicle. In practice, when the vehicle reaches a distribution centre, the pallets will most likely be separated and sent to different locations.

[0104] For example, if the pallets were delivering food to a supermarket distribution centre, upon arrival at the centre, each of the pallets may be put on a different vehicle to go to a different one of the retail outlets for that particular supermarket. At this point in the journey of the devices, the shared local environment will cease to be relevant since each of the devices will have its own local environment on its independent journey to its respective retail outlet. In this case, the ability to save power due to the common journey of the loT devices will be lost. Thus, the available power savings will vary over the life cycle and product cycle for each of the loT devices, depending on its use. However, the basic idea that loT devices are able to communicate with each other using low power Bluetooth communication is a powerful and useful idea which enables the minimisation of the use of power of the loT devices.

[0105] It will be appreciated that each of the loT devices has two functions. The first of these functions is to do with the individual configuration and management of the loT device itself and the vehicle or goods with which it is associated. A secondary function is the collection of data and communication with that data to a central server and data store or database associated with it, which is then able to apply machine learning and Al methodologies to assist in the control of the distributed loT devices as they move around the world. The system relies on a balance between the requirements to accumulate a large data set and use this to guide and drive movement control of the individual devices, whilst managing the constraints of the finite and limited battery power of the individual loT devices.

[0106] Absent any such power constraints, the easiest way to achieve this technical goal would be to continually communicate between the central server 12 and database and the loT devices. With the presence and use of a large number of the loT devices, a full and comprehensive data set would be acquired which could be maintained current at all times and then used to make Al inferences. The problem with this is that in the supply chain, the loT devices used do not have large or unlimited amounts of power and therefore there exists the need to optimise the power usage of the loT devices whilst not adversely affecting the data collection and harvesting used to produce the large Al data set.

[0107] The present system achieves this with the use of the provision of subset matrices to the loT devices which can be used to control and direct the devices and also to determine when an individual device is actually required to take a local scan and communicate that back to the central server 12.

[0108] Thus, the technical goals are achieved of harvesting and accumulating large amounts of data whilst managing the difficult and limited power constraints to which each of the individual loT devices are subject. The communication of subset matrices to each of the loT devices provides a powerful and effective way for ensuring that the control and navigation of the devices can be achieved within strict power constraints. The determination of what the subset matrix 36 should be is achieved through the use of the ML / AI-generated server trajectory model 32 which can determine based on received device cell sequences 15 the required subset matrix 36 for communication to the loT device in question.

[0109] Each time an loT device moves into a new cell, it can perform a local RF scan. This is a low power process. It is able to look up the cell in its own subset matrix received from the from the central server 12 and determine if there is correlation between the expected RF environment and the detected RF environment. If there is (all of which processes are low power processes), nothing further is needed. Only if there is not the expected correlation, it can or may determine that it needs to contact the central server 12. Accordingly, only if the loT device determines that communication is necessary to update its local subset matrix, will it perform the higher power steps needed to communicate with the central server 12.

[0110] Referring to Figure 8, two loT devices 50 and 52 can be seen. Each will have its own subset matrix 54. The subset matrices 54, are to be maintained up to date. Communication of a subset matrix from the central server to the loT devices is the high- power stage of any system communication and accordingly it is preferable that such communication is minimised. The loT devices 50 and 52 are arranged to communicate via low power Bluetooth and to broadcast the sequence number for their individual subset matrices. Given that they are in the same physical location, if one has a more up to date subset matrix then more up to date subset matrix will be shared, again using low power Bluetooth, between the loT devices.

[0111] This is a way of ensuring that the loT devices maintain an up-to-date subset matrix whilst again minimising the (higher power) communication with the central server.

[0112] Referring again to Figure 7, the device cell sequence 38 represents the cell sequence for an individual loT device. An exemplary use case would be if a loT device is arranged on a container on a ship. The device would be aware that from the WiFi environment that it is on a ship in the middle of the ocean and therefore unlikely to be exposed to a mobile telephone signal, e.g., a cellular network. Accordingly, the device will not attempt to communicate using cellular communication. Of course, it is possible that would not be available either. Accordingly, in one example, an accelerometer algorithm would be used to determine the device was at sea. A similar algorithm can be used to detect flight (and temporarily disable cellular communications.

[0113] Within the loT device itself the device trajectory model 40 can be used to produce a prediction of a next cell 42 in which the loT device is expected to move.

[0114] The device trajectory model can itself be used to minimise power based on recognition of its likely position and the location of the next cell 42. For example, if the device is said in a port in Thailand and is associated with a shipment of computers from a manufacturing site, the device trajectory model 40 can be trained to expect the next cell 42 to be a container port such as at Los Angeles.

[0115] Accordingly, the device is able to avoid making any communication with the central server 12 for an extended period of time. The loT device can turn off until it sees an RF signal that corresponds to the expected container port. The likely ports that the device is suspected to see can be understood from its device trajectory model 40 and so the device will in effect look out for a signal that corresponds to this expected port of arrival. The device would therefore not make any attempt to communicate with the central server 12 until it sees the expected container port (e.g., a known WiFi signal corresponding with that port) of Los Angeles.

[0116] The system effectively operates in a number of a parallel data collection channels. The communication between the central server 12 and loT devices themselves are minimised so as to minimise power usage.

[0117] It will be appreciated that, in effect what is happening is that large volumes of data regarding RF signatures and movement trajectories are transferred to the central server 12 and this data is used to train models which can then be used to controllably communicate with the loT devices and enable management of the devices. In other words, the cell sequence data is stored and used as training data for an Al model which can then be used to make predictions for other loT devices in future. Figure 9 shows a schematic view of the overall system architecture.

[0118] Plural loT devices 56 can be seen. These are arranged to communicate 58 with the application server 60 (identified as central server 12 in Figure 2 above) and also with each other 62 using low power Bluetooth communication, as explained above. An RF environment 64 exists, as a matter of physical reality, and this is scanned when needed by the IOT devices 56. The application server is arranged to form various functions including generation of sequence database 66 which contains device cell sequences 49 communicated from individual loT devices.

[0119] In addition, the architecture includes an Al model builder 68 which is arranged to receive the device cell sequences from the sequence database 66 together with the context from the Matrix to Context DB 67. The model builder 68 is arranged to use machine learning and Al to generate the models, such as the server trajectory model 32 (Figure 5) and the next cell indication 34 for a device in question, which is in turn communicated 58 via the application server to the loT devices 56.

[0120] In dependence on the model created by the model builder 68 and indeed on the next predicted cell 34 for a particular device the size and position of the matrix subset 38 (see figure 5) can be selected. In other words, if the generated model predicts that a particular loT cell will move in a certain direction, say North, based on its previous device cell sequence, then the selected subset of the matrix 38 which is provided to the loT device is chosen in dependence on the output of the model to ensure that it covers the region or cell to which the loT device has moved.

[0121] Figure 10 is a flow diagram showing the set-up steps for use in a system architecture such as that of Figure 9.

[0122] Initially, the method 70 starts up 72 and generates a blank matrix 74, the blank matrix 74 is generated to represent the area of land that is of interest for the application. For a worldwide distribution management and control system the matrix will be an entire lat-long matrix for the earth’s surface as shown in Figure 1. Initially, as there is no live data in the matrix all cells are in the matrix are marked as having their TTL expired. As the system starts up and communicates with loT devices, the matrix is backfilled using data it receives from loT devices. Where data is received and is within the TTL, the cells will be marked as ready. Finally, 80, the central matrix is ready for use.

[0123] The step of reporting and fetching from individual IOT devices will now be described with reference to Figure 11.

[0124] It is assumed at step 82 that an loT device somewhere in the world is in the process of reporting to the central server 12 in the cloud. The loT device will have scanned its local RF environment and at step 84 report that to the central server 12 which will then update the main matrix, by updating the appropriate cell or cells within the matrix with the provided RF environment data.

[0125] Based on the movement of the loT device, the device sequence is updated at 86. At step 87, the received device cell sequences are processed, preferably in batches, and used to train the Al prediction model used to generate an indication of likely next cell.

[0126] Next, the predicted next cell for the loT device in question is obtained based on a server trajectory machine learning model 88. In other words, the data received at step 86 and processed at step 87 enables determination of the next cell indication for the loT device in question. If the device trajectory machine learning model is determined as being up to date, no operation is performed.

[0127] Referring back to step 84 at which the matrix is updated with an RF environment, the step of predicting the next cell in the matrix based on a server trajectory machine learning model, it is determined at step 90, whether a new sub-matrix for a particular device is required. If it is not, then no operation 92 is performed. However, if it is determined based on the server trajectory machine learning model that a new sub-matrix for a device is required, a new sub-matrix is extracted from the matrix, and this is performed based on the predicted location 94. The central server 12 then downloads the appropriate sub-matrices from the main central matrix 2 to the device in question.

[0128] At step 98, it is determined if the device trajectory machine learning model is up to date. The device trajectory model (described above with reference to Figure 7) is the locally stored trajectory model that a device itself can use to determine a likely next cell, without contact being needed with the server 12 to determine a likely next cell. If the device trajectory ML model is up to date, then no operation is performed 100 whereas if it is not, a new device trajectory machine learning model is obtained at 102. This can then also be updated to the loT devices 96 from the server 12.

[0129] The device behaviour based on tracking its location will now be described with reference to Figure 12. Initially, a device wakes up at step 104. Waking of one of the loT devices can be in response to a detected change of environment, triggered by a sensor or a timed process according to some predetermined or selected configuration.

[0130] A scan of the local RF environment is made by the loT device. The sensors or other integrated or connected hardware forming part of the device are activated to perform the required scans at step 106. The scanned RF environment is then appended to the previous scan sequence at step 108 for the device in question. The sequence is applied to the device trajectory machine learning model 110.

[0131] A decision is made at 112 based on the output of the applied model at step 110 as to whether or not the device is in a new cell location. If it is not, then no operation 114 is performed. If it is, a determination is made as to whether or not the TTL for that cell has expired.

[0132] If the TTL has not expired, then the device behaviour associated with the cell is applied and the device can return to low power mode 120.

[0133] If, however, it is determined that the TTL has expired for the cell in which the device now finds itself, a scan of the RF environment 122 of the new cell is performed and sent to the server 12 for processing as described above. In this case, a reporting and fetching process is started as described in step 82 of Figure 11. Referring to Figure 13, the process of local sharing performed by loT devices will now be described. This process applies in the case of data sharing between local edge loT devices when it can be determined that no communication with the central server 12 is required.

[0134] At step 124, a device wakes up. As above with reference to Figure 12 (step 104), this can be in response to a detected change of environment, triggered by a sensor or a timed process according to some predetermined or selected configuration.

[0135] The loT device advertises the sequence numbers of both its device trajectory model 126 and its sub-matrix 128. Other devices which are in the location, or within low power Bluetooth range will receive the advertised sequence numbers 130. If the sequence number received by one of the other loT devices within range is higher than that of the local device, then no operation is performed 132 and 134.

[0136] If, however, the sequence number is determined to be lower than that of the local device then the sub matrix and model is downloaded at the local device from the originating device 136. Thus, the loT devices are able to maintain as up to date their device trajectory models and sub-matrices without communicating with the central server 12 via inter device communication using low power Bluetooth. This inter-device communication is an important factor that enables minimising of power usage of any individual device.

[0137] Clearly, it will only be of use if more than one device is within Bluetooth range of another device. However, in practice given that millions of such tracking devices are already used and even more expected to be used, the ability to transfer active (i.e. , having at least some cells within TTL) sub-matrices and models between devices using low power Bluetooth is significant technical feature.

[0138] Embodiments of the present invention have been described with particular reference to the examples illustrated. However, it will be appreciated that variations and modifications may be made to the examples described within the scope of the present invention.

Claims

Claims1. A tracking device, comprising a processor and a memory, the device being arranged to: receive data from a central server, the received data representing a matrix subset corresponding to the expected location of the device and detecting physical parameters from a local environment and in dependence on a comparison of the detected local communications parameters and the received subset determining an operation.

2. A tracking device according to claim 1, in which the tracking device stores locally the subset matrix and stores a record of physical parameters for cells within the subset matrix.

3. A tracking device according to claim 2, in which the comparison of the detected local communications parameters and the received subset comprises a comparison of the subset matrix and the recorded physical parameters for the tracking device.

4. A tracking device according to claim 3, in which the comparison of the detected local physical parameters and the received subset comprises a determination of the time since the subset matrix was received from the central database.

5. A tracking device according to claim 4, in which if the time since the subset matrix was received is greater than a defined threshold the tracking performs a new scan of the local physical parameters.

6. A tracking device according to claim 5, in which the new scan of local parameters is a low power scan.

7. A tracking device according to claim 6, in which, subsequent to performance of a new scan of the local physical parameters, the local parameters are communicated by the tracking device to the central database.

8. A tracking device according to claim 7, arranged to receive from the central database a tracker device cell sequence indicating an expected route of movement.

9. A tracking device according to any of claims 1 to 8, in which the physical parameters including one or more of communications parameters, temperature parameters and dwell time parameters.

10. A tracking device according to any of claims 1 to 9, the tracking device having a transmitter for issuing communications.

11. A tracking device according to claim 10, arranged to communicate with a second like tracking device using low power Bluetooth.

12. A tracking device according to claim 11 , arranged to transfer to the second like tracking device a matrix subset if it is determined that the matrix subset stored by the second like tracking device is older than that of the first tracking device.

13. A tracking device according to claim 12, in which a unique identifier is associated with each matrix subset and the determination as to age of subset is based on the unique identifier.

14. A tracking device according to any of claims 1 to 13, comprising one or more sensors for detecting physical parameters from a local environment.

15. A tracking device according to claim 14, in which the one or more sensors are arranged periodically to activate and detect physical parameters from a local environment of the tracker.

16. A tracking device according to claim 15, in which the periodicity with which the one or more sensors are arranged to activate and detect physical parameters from a local environment of the tracker is higher than a periodicity with which the tracker is arranged to communicate gathered data to a central server.

17. A server system for control of a plurality of loT devices, the system comprising a server; memory storing a matrix representing an area to be covered by the system; a processor, arranged, upon receipt of a communication from one of the loT devices, to select a subset of the matrix including the region in which the loT device is located, and sending it to the loT device, wherein at least one or more of the cells of the subset of the matrix contains data relating to physical parameters from a local environment in which the loT device is located.18 A server system according to claim 17, in which subsequent to performance of a scan of the local physical parameters by the loT device, the local parameters are communicated by the tracking device to the server.

19. A sever system according to claim 17 or 18, arranged to receive from the central server a tracker device cell sequence indicating an expected route of movement.

20. A sever system according to any of claims 17 to 19, in which the physical parameters including one or more of communications parameters, temperature parameters and dwell time parameters.

21. A server system according to any of claims 17 to 20, comprising a model builder arranged to build a predictive model for loT device movement in dependence on location data provided by the loT device to the server.

22. A server system according to claim 21, in which the model builder uses machine learning to develop the model.

23. A server system according to claim 22, in which in dependence on the developed model the size and position of the matrix subset is selected.

24. A server system according to claim 17 to 21, in which the machine learning uses transformer models.

25. A server system according to any of claims 17 to 24, in which a first loT device is arranged to communicate locally with a second loT device using low power communications protocol.

26. A server system according to claim 25, in which low power communications protocol is low power Bluetooth communication.

27. A server system according to any of claims 17 to 26, comprising a server trajectory model, the server trajectory model being arranged to receive as an input the cell sequence for one of the loT devices and to predict based thereon the next cell position for the loT in question.28 A server system according to claim 27, in which the server trajectory model is an Al generated model trained using device cell sequences provided by individual ones of the plurality of loT devices.

29. A server system according to any of claims 17 to 28, in which the physical parameters relate to the RF environment of the one or more loT devices.

30. A server system according to any of claims 17 to 29, in which the physical parameters relate to the temperature of or dwell time in an environment of the one or more loT devices.

31. A server system according to any of claims 17 to 30, in which the server is located in the cloud and the loT devices are provided as tags for association with a product of vehicle.

32. A server system according to any of claims 17 to 31, in which the, or each, of the loT devices are tracking devices according to any of claims 1 to 16.

33. A method of operating a server system for control of a plurality of loT devices, the system comprising a server; a memory storing a matrix representing an area to be covered by the system; and a processor, the method comprising:upon receipt of a communication at the server from one of the loT devices, selecting a subset of the matrix including the region in which the loT device is located, and sending it to the loT device, wherein at least one or more of the cells of the subset of the matrix contains data relating to physical parameters from a local environment in which the loT device is located.

34. A method according to claim 33, comprising generating a server trajectory model in dependence on data received from the plurality of loT devices.

35. A method according to claim 34, in which the server trajectory model is Al generated using trained using device cell sequences provided by individual ones of the plurality of loT devices.

36. A power management system for control of a plurality of loT devices, the system comprising a server; memory storing a matrix representing an area to be covered by the system; a processor, arranged, upon receipt of a communication from one of the loT devices, to select a subset of the matrix including the region in which the loT device is located, and sending it to the loT device, wherein at least one or more of the cells of the subset of the matrix contains data relating to physical parameters from a local environment in which the loT device is located.

37. A power management system according to claim 36, comprising a plurality of loT device each controlled or controllable to communicate with the server and / or with each other in dependence on data received from the server.

38. A power management system according to claim 36 or 37 in which the server is arranged to communicate context in the form of a matrix subset to one or more of the loT devices.

39. A power management system according to claim 38 in which an loT device, in dependence on a received matrix subset is arranged to determine whether or not to communicate with the server.

40. A power management system according to any of claims 36 to 39, in which the or each loT device has a power supply, such as a rechargeable power supply, and is arranged to minimise usage of the power from the supply by determining if communication with the server is required, and only communicating with the server if such communication is required.

41. A power management system according to claim 40, in which the or each loT device determines that communication with the server is required if it does not have a store of a subset matrix which is within a determined Time To Live period.

Images