Method and apparatus for monitoring a motive power battery unit

Abstract

A monitoring method of a swappable motive power battery unit 120 of a vehicle 100 wherein performance data of the battery is collected. The performance data of the battery is tagged to the battery ide

Description

The present disclosure relates to methods of monitoring the performance of a motive power battery unit for a vehicle, and in particular a swappable motive power battery unit. Introduction Modern vehicle fleets, and in particular electric vehicles, may communicate data to the cloud so that the status of the fleet may be monitored. For vehicle manufactures such connected vehicles can provide information to help the manufacturer understand vehicle usage habits and identify faults before they occur. If impending faults can be predicted then vehicle down-time may be minimised. The data from connected vehicles is typically a collection of timeseries datasets, tagged with the source vehicle. The data may be streamed from the vehicle over an external communication network, such as a cellular network while the vehicle is in use. Alternatively, when vehicles of a fleet return to a depot or personal vehicles return to the owner’s home, the data may be streamed over wi-fi. For example, as shown in figure 1 data from a vehicle such as a car 10 may be streamed from the car via the cloud 20 to a database 30. A computer connected to the database or the database itself may also communicate back through the cloud to the vehicle, for example for handshaking when setting up the communication or acknowledging receipt of the data. For electric vehicles the data that is streamed may include data related to the battery module or unit that provides motive power. Summary of the Invention The present invention provides methods of monitoring swappable, motive power battery units of module in a vehicle, charging station or when swapped between vehicles. The methods described herein provide for the collection and organisation of swappable, motive power battery units to allow the status and performance of a battery to be monitored through its life irrespective of the vehicle in which it is located. The collected data can be used for battery centric analytics relating to that batter or across a fleet or batteries. The present invention provides a method of monitoring a swappable, motive power battery unit in a vehicle, comprising: collecting, by a controller, performance data relating to the ongoing or continuing status of the battery; determining the identity of the motive power battery unit by either: (a) sending, by a controller in the vehicle, a request across a communication network of the vehicle to determine an identity of the motive power battery unit, or (b) from fingerprinting of data from the motive power battery unit; tagging, by the controller, the performance data with battery identity; and sending the tagged performance data over an external communication network to a remote database. The controller may be a telemetry control unit of the vehicle. The telemetry control unit may comprises a processor, memory, a connection to a vehicle communication network and a network interface for connecting to the internet, such as by a cellular connection. We describe herein a swappable motive power battery unit, although this term may be interchangeably be used with swappable motive power battery module. The step of determining the identity of the motive battery unit may comprise sending, by the controller in the vehicle, a request across the communication network of the vehicle to obtain the identity of the motive power battery unit, wherein the communication network of the vehicle may be a CAN bus network and / or a vehicle ethernet. The identity of the motive power battery unit may be a serial number, or may be derived from a serial number, of the battery motive power unit. The step of determining the identity of the motive battery unit may comprise fingerprinting of data of the motive power battery unit. The fingerprinting may comprise: collecting battery fingerprint data from the vehicle communication network; sending the battery fingerprint data to a fingerprint module; and receiving from the fingerprint module the identity of the battery based on the fingerprint data. Preferably, the fingerprint module is a software module or algorithm operating in the cloud, but alternatively the fingerprint module may be a software module or algorithm operating in the telemetry control unit. The step of sending the battery fingerprint data to a fingerprint module may comprise sending the battery fingerprint data over the external communication network; and wherein receiving the identity of the battery may comprise receiving the identity of the battery over the external communication network. The collected battery fingerprint data may comprises specification data of the motive power battery unit and / or operating data of the motive battery power unit and / or characteristics of the motive power battery unit. The collected battery fingerprint data may comprise any one or more of the following inputs: firmware version of a battery management system of the motive power battery unit, battery cell configuration in the motive power battery unit; battery capacity; geographical location; open-circuit voltage curve; self-discharge rate; thermal response; isolation resistance; state of health and timing of messages output from the battery motive power unit. The geographical location may be provided from a GPS / GNSS device, such as a receiver / chip, which is part of the telemetry control unit. The battery fingerprint data may be collected from the vehicle communication network by the controller, sorted, by the controller, into a predefined order; and sent to the fingerprint module. The battery fingerprint data received at the fingerprint module may be hashed by a cryptographic hashing function to produce a unique battery identifier. The method may further comprise triggering determining the identity of the motive power battery unit based on the controller identifying an occurrence of an event related to the battery or the vehicle, wherein the event is any of: receipt of a signal indicating an battery swap has occurred; a sudden or large change in battery state of charge; a change in the state of the vehicle such as from drive mode to park mode; a change in the state of the vehicle such as from park mode to charge mode; and the vehicle powering off or on or changing to a sleep mode. The performance data relating to the ongoing or continuing status of the battery unit may comprise one or more of: state of charge; state of health; output voltage of the motive power battery unit; minimum cell voltage of a plurality of cells in the motive power battery unit; maximum cell voltage of a plurality of cells in the motive power battery unit; output current of the motive power battery unit; temperature of the motive power battery unit; isolation resistance of the motive power battery unit; capacity of the motive power battery unit; and fault / error flags relating to the motive power battery unit. The controller may further collect and send over the external communication network any of the following data relating to the environment surrounding the vehicle: relative humidity, pressure, and temperature. The present invention further provides a method of monitoring a swappable, motive power battery status, comprising: receiving, from a first vehicle, data relating to the performance of a battery in the first vehicle, the data tagged with the identity of the battery; receiving from a second vehicle, data relating to the performance of the same battery in the second vehicle, the data tagged with the identity of the battery; recognising the battery data from the first vehicle and the battery data from second vehicle as related to the same battery that has been swapped from the first vehicle to the second vehicle; and associating the battery data from the first vehicle and the battery data from the second vehicle together to form a performance status log of the battery. The method may be performed by a computer or across distributed computers such as in the cloud, connected across the internet. The computer(s) may be coupled to or may include a database for storing the data. The method may further comprise receiving from a motive power battery unit charging station data relating to the performance of the same battery, the data tagged with the identity of the battery. The performance data for the same battery relates to the battery located in a vehicle at the charging station or not in a vehicle at the charging station. The method may further comprise analysing the performance status log of the battery unit and determining that the battery unit is close to failing or determining an estimated likelihood that the battery unit will fail. The method may further send an indication to a user or system that maintenance of the battery unit is required. The battery unit may be a first battery unit, and the method may further comprise analysing the performance status log of the first battery unit to compare the performance of the first battery unit with the performance of one or more other batteries of a fleet. The method may further determine whether the performance of the first battery is within a margin of the average for the fleet of batteries. The margin may be 1%, 5% or 10% of the average, for example. The method may further comprise analysing the performance status log of the battery unit and based on the status log predicting future performance of the battery unit. The method may further comprise analysing the performance status log of the battery unit and based on the status log and current planned use of the battery unit, estimating when the battery unit will require a next charge. The method may further comprising determining the identity of the battery unit according to any of the methods described herein. The performance data relating to the ongoing or continuing status of the battery unit may comprise one or more of: state of charge; state of health; output voltage of the motive power battery unit; minimum cell voltage of a plurality of cells in the motive power battery unit; maximum cell voltage of a plurality of cells in the motive power battery unit; output current of the motive power battery unit; temperature of the motive power battery unit; isolation resistance of the motive power battery unit; capacity of the motive power battery unit; and fault / error flags relating to the motive power battery unit. The controller may further collect and send over the external communication network any of the following data relating to the environment surrounding the vehicle: relative humidity, pressure, and temperature. The present invention provides a method of monitoring a swappable, motive power battery unit, the method comprising: swapping a first motive power battery unit into a first vehicle; monitoring the performance of the first motive power battery unit according to the methods described herein; swapping the first motive power battery unit out of the first vehicle and into a second vehicle or charging station; monitoring the performance of the first battery unit in the second vehicle or charging station according to the methods described herein; and associating the battery data from the first vehicle and the battery data from the second vehicle together to form a performance status log of the battery The present invention further provides a method of monitoring a plurality of a swappable, motive power battery units powering a fleet of vehicles, the method comprising: swapping a first motive power battery unit into a first vehicle; monitoring the performance of the first motive power battery unit according to the methods described herein; swapping the first motive power battery unit out of the first vehicle and replacing it with a second motive power battery unit; monitoring the performance of the second motive power battery unit in the first vehicle according to the methods described herein. The present invention further provides a vehicle comprising a swappable, motive power battery unit and a telemetry controller unit, the telemetry control unit comprising a controller configured to perform the methods set out herein. The present invention further provides a fleet of vehicles, each comprising a swappable, motive power battery unit and a telemetry controller unit, the telemetry control unit comprising a controller configured to perform the methods described herein. The present invention provides a computer readable storage medium storing instructions, which when executed by a processor or one or more processors, causes the processor processors to carry out any of the methods described herein. The present invention further provides a computer program for performing the methods set out herein. The present invention may further provide a method of fingerprinting a swappable, motive power battery unit, for example, performed separately to that of monitoring the status of the battery. Although we have described herein methods performed by a computing device such as a telemetry control unit (TCU) at the vehicle and also by a computing device in the cloud having or coupled to a database, these methods may be combined with each other and may be performed in combination with swapping of batteries. Brief Summary of the Drawings Embodiments of the invention will now be described, by way of example only, with reference to the accompanying drawings of which: Figure 1 is a schematic diagram showing how data from a vehicle such as a car may be streamed or transmitted via the cloud to a database; Figure 2 is a schematic block diagram of a communication network or communication bus in an electric vehicle; Figure 3 is a flow chart indicating steps in a method of collecting an tagging battery performance data, as may be perfumed by a TCU; Figure 4 is a flow chart indicating steps in a method of fingerprinting characteristic battery data to determine the identity of a battery; Figure 5 is a flow chart indicating steps in a method of organising battery data collected at vehicle for generating a battery identifier; Figure 6 is a schematic diagram showing how a battery may be swapped between vehicles and a charging station and collected and tagged data may be used to generate a performance log of a battery; Figure 7 is s flow chart indicating steps on a method of collecting and associating battery data in the cloud at a database to form a performance log for a battery; and Figure 8 is a table of fault / error flags that may be collected as battery performance data for analysing the status of a battery. Detailed Description of Embodiments Figure 2 is a schematic block diagram of a communication network or communication bus in an electric vehicle. The figure shows an arrangement of computing units that may communicate on the network or communication bus. The vehicle may be a car, van, truck, lorry, bicycle, three-wheeled trike, etc. The vehicle is powered by a battery unit or a battery module, that is, the motive power for generating motion of the vehicle is provided by a battery unit 120 or battery module. Vehicle battery units or modules may comprise a number of cells which may be grouped together in various ways. A battery unit for a car or lorry may have more cells than a battery for a bicycle. However, by grouping the cells and connecting the groups in series or parallel arrangements the desired current and voltage characteristics for providing motive power to the vehicle can be achieved. In such cases the battery unit or battery module may comprise a battery management system (BMS) 122 which may monitor and facilitate the safe charging and discharging of the cells in the unit. For example, a battery management system may balance the voltage and / or current when charging and discharging the cells to ensure that the cells stay within safe temperature limits. For battery units or modules that have forced cooling the BMS may also manage the cooling. The battery management system may communicate across the vehicle on a vehicle communication network 130 which may be a CAN bus or may be ethernet. Also connected to the vehicle communication network may be a motor control unit (MCll) 140 which communicates information regarding the drive motor. A vehicle control unit (VCll) 150 may receive communications across the vehicle communication network and may provide control signals to the network for controlling various components connected thereto. The VCll may also interface with driver controls and thus may be considered the main or overriding controller of the vehicle. For connected vehicles according to the present invention, a telemetry control unit (TCU) 130 may collect data from the bus and send it via antenna 132 to the cloud. The data may be data relating to the motive power battery unit. Some electric vehicles have a battery that is built into the vehicle and it is expected that the battery will last the life of the vehicle or the battery may be changed infrequently such as one or two times during the life of the vehicle. For other electric vehicles the swapping process occurs many mores times during the life of the vehicle. This may be because the battery may be easily and quickly removed from the vehicle such as in seconds or minutes. In such as case it is more convenient to swap the battery when the battery is out-of-charge or low on charge because it is quicker than waiting for the battery to charge. In such situations, for example at a depot of a delivery company, there may be a charging station or rack at which fully charged batteries may be taken and swapped for discharged batteries. In other scenarios the battery swapping may be desirable for example if a larger battery with an extended capacity or range is required. Swapping may occur when a vehicle user or owner wishes to upgrade the battery temporarily or permanently. Accordingly, some electric vehicles may have a lifecycle in which battery swapping is common. In battery-swapable vehicles, the dataset that is collected in relation to the battery needs to be associated with the physical battery asset and not the vehicle as is conventionally the case. By associating the battery data with the physical asset the performance of the battery can be monitored and analysed as it used in different vehicles and also while at a charging station or rack and not in a vehicle. When swapping a battery of a vehicle it is the whole battery module that is swapped. This may comprise a single housing containing the battery cells, cooling system and a BMS component (Battery Management System). The battery is connected into the vehicle network, often a CAN bus network, on which the TCll sits. The CAN bus (Controller Area Network) is a robust, standardized communication protocol designed for reliable data exchange between multiple electronic control units (ECUs) or microcontrollers in a system, without requiring a central computer. It is widely used in automotive, industrial, and embedded systems, CAN enables devices to share data in real-time over a single two-wire bus, minimizing wiring complexity and costs. The TCU may communicate with the battery module using standardised CAN messaging. As well as being able to monitor the performance of the battery, it is desirable to build data models or simulate digital-twins that accurately reflect the performance of a battery based on its use through its life. Figures 3 and 7 are flow-charts of methods of monitoring a swappable, motive power battery units according to the present invention. Since the monitoring steps may be partly performed at a vehicle and partly over the internet or in the cloud, the method may be split between those steps that are taken at the vehicle (figure 3) and those steps that are taken over the internet or in the cloud (figure 7). Of course, the method steps may be combined. In figure 3 at step 310 battery performance data is collected in the vehicle. This may be collected periodically or when a particular event occurs. The performance data relates to the battery module or battery unit and may be information that a controller of the battery module, such as the BMS, regularly transits on the vehicle communication network and is monitored and collected by the telemetry control unit (TCU) or may be information that the TCU specifically requests from the BMS. The battery performance data may include any one or more of the following: • State-of-Charge (SoC) of the battery unit; • State of health (SoH) of the battery unit; • Output voltage of the battery unit; • Minimum cell voltage and max cell voltage across all cells in a pack or battery unit; • Output current; • Temperature of the battery unit; • Isolation; • Capacity of the battery unit; and • Any fault / error flags that have been raised relating to the battery unit. Figure 8 provides a table of examples of fault / error flags that may be collected. Additionally, environmental factors relating to the environment that the vehicle is located in may be collected, for example, temperature, relative humidity, and pressure. The battery performance data may be collected regularly such as every 1000ms depending on the vehicle configuration and the application. The performance data may be collected more frequently such as low as every 100ms or less frequently such as every 30,000ms. While collecting the battery performance data the TCU also determines the identity of the battery. To determine the identity of the battery module, the TCU, which is part of the vehicle, may send out a data query on the vehicle communication network. The battery module may respond to the request by identifying itself with an immutable identifier, such as a serial number. If the battery does not respond with an identifier or if the identifier appears to be incorrect, the TCU may collect data relating to the battery module to generate a fingerprint of the battery . The fingerprint may be based on combining a number of characteristics to uniquely identify the battery. We will describe the battery fingerprinting technique in more detail in relation to figures 4 and 5. Returning to figure 3, at step 330 the TCU tags the battery performance data with the battery identity. For example, the collected battery performance data may be combined with battery identity, or identifier, into a message or file. At step 340 the tagged battery performance data is sent to a remote database, that is, the tagged battery performance data is sent over the internet to a database. The tagged performance data may be organised by the database to associate the received battery performance data with any already stored performance data for that battery identity. The tagged performance data may be sent over the internet such as over a cellular network. For example, the tagged performance data may be sent in a compressed message format such as compressed JSON, or may be sent as a messages in which the data is serialized such as Protobuf messages. The messages may be send to the cloud using MQTT protocol. The cellular network may use 4G LTE or 5G or the latest cellar configuration. Vehicle data that is not specific to the battery may also be sent over the cloud, but may or may not be tagged with the battery identity. Figure 4 is a flow chart of a method of fingerprinting a battery unit such as described above where no identifier is provided by the unit. Figure 5 is a further flow chart providing further information regarding how the fingerprint data may be processed. The start or trigger for the fingerprinting process may be that, after sending a query on the vehicle communication bus for a battery identifier, no response or no usable identifier is received. The TCU may then commence a battery fingerprinting process to generate or determine a fingerprint of a battery. For example, if the battery has not previously been allocated an identifier, the fingerprinting may generate and allocate an identifier. Alternatively, if the battery has previously been allocated a fingerprint-generated identifier the fingerprinting process may identify the battery as matching a previously generated fingerprint. To generate a fingerprint the TCU may collect one or more characteristics of the battery module, as shown at step 410. The characteristics may be collected either by polling across the communication network or by receiving information broadcast on the network by the battery. The characteristics may comprise any one or more of: • firmware version that the BMS is running; • configuration of the battery module, such as number, size and arrangement of cells or groups of cells in the battery module; • capacity of the battery module (this may include or take into account whether the cells are arranged in series or parallel); • GPS location where the battery was last seen (e.g. it may have been last online at a depot or swapping station), which could be assisted by data from the cloud;. • State of Health of the battery (SoH); • The relationship between output voltage at various points on the SoC curve; • Timing of various messages that are emitted by the battery module; • Self-discharge rate of the battery (by monitoring how quickly the battery loses charge when idle); • Thermal response (heat generation of the battery under controlled load conditions); and • Isolation resistance (The internal isolation characteristics of the battery). For a number of the characteristics mentioned above, for battery modules of the same or similar type, the characteristic may be very similar on a macro scale, however, when examined carefully different battery modules will have small but identifiable differences. For example, battery module capacities will vary a small amount due to manufacturing tolerances, differences in the open-circuit voltage curve for the state-of-charge can act as a fingerprint, and the internal isolation characteristics may vary due to slight differences in properties of the insulation. Each of these small but identifiable differences may be used as at least part of a fingerprint. Some of the characteristics may be measured by the BMS. For example, isolation resistance may be measured by the BMS by making a number of measurements of voltage on both sides of the battery. The BMS may then calculate the isolation resistance and transmit it as a data signal onto the vehicle communication bus. Some of the above characteristics (such as open-circuit voltage curve of the state-of-charge) are characteristics that are collected over a period of time requiring multiple measurements or data points. The TCU may have a local data storage buffer (such as a flash memory chip) on to which data requiring multiple measurements may be stored, for example for later processing. The storage buffer may also be used to store data if there are other reasons for not being able to send data to the cloud, such as if the cellular network connection has dropped out (e.g. driving through a tunnel) or if there is a clocksynchronisation problem that is causing a difficulty which cryptographic keys. The location characteristic such as GPs location may be used to limit the number of batteries that may possibly be matches. For example, a battery based in Brazil is very unlikely to be found at a vehicle swap in Estonia. Having collected the characteristic or fingerprint data, the data is sent to the cloud for processing by a fingerprint module, as shown at step 420 of figure 4. The fingerprint module may be a software module running on a computing device. The fingerprint module analyses the received data and, if an already known battery matches the fingerprint, returns over the cloud to the TCU the identity of the battery module (step 430). If no battery module can be identified from the characteristic data, the fingerprint module uses a cryptographic hashing function to produce a unique battery identifier. The battery identifier is then sent over the cloud to the TCU (step 430). Whether the identifier is that of a previously identified battery module or generated by a cryptographic hashing function, the TCU begins tagging the battery performance data with the battery identifier. In alternative embodiments the fingerprinting, such as the cryptographic hashing, may be performed at the TCU. When no match to a previous battery module is identified this may be because it is a new battery, or a battery new to the customer, or the identity has become scrambled. Figure 5 is flow chart providing further information on the collection of characteristic data for sending to the fingerprinting module. As shown at step 510 the data collected by the TCU may be normalised into standard encoding. For example, the data is formatted and / or normalised such that the input to the fingerprint function provides a consistent output, this may include padding the data value to a specified string length, etc. As indicated at step 520, the data may also have its precision reduced for characteristics that change slowly over time. For example, if battery capacity is measured to seven significant figures but, other than for variations due to noise, does not vary beyond a third significant figure for much of the battery life then the precision of the battery capacity may be reduced between that collected by the TCU and that sent across the internet. Of course, normalising the data into standard encoding and reducing the precision are optional steps and may depend on the actual battery characteristic being collected. At step 530 in figure 5 the various battery characteristics may be sorted into a predefined order in preparation for sending in a message. By sorting and having a predefined order, the fingerprinting module does not have to identify which data is which. Furthermore, only the data itself needs to be sent rather than also sending labels of the data. At step 540 the battery characteristic data is sent to the fingerprinting function. As mentioned in relation to figure 4 the fingerprinting module first checks to see if a battery matching the fingerprinting data is already logged by the fingerprinting module. If a battery matching the received fingerprinting data the fingerprint module returns the ID for the battery module. If no battery module is identified the fingerprinting module uses a cryptographic hashing function to produce a unique battery identifier, which can then be used as a unique battery identifier by the TCU for tagging of performance data. We have previously discussed that the TCU may periodically collect the performance data relating to the battery and this is collected by the TCU from across the vehicle communication network. The TCU may also periodically send a request for checking the same battery is present in the vehicle. When the TCU identifies that the battery identifier has changed the TCU identifies that a battery swap has taken place. The TCU may then send a battery swap event notification to the cloud. The notification may include the identifiers of both the swapped-out battery and the swapped-in battery. The TCU also stores the new battery identifier to tag future performance data for sending to the cloud. As well as periodic checking, the TCU may monitor the performance data for the occurrence of battery swaps. A battery swap may be identified by a sudden and / or large change in battery state-of-charge (SoC), by a change in the state of the vehicle such as a change in drive mode (for example, a change from drive to park or from park to charge), by a change in power mode (such as changes between on, off and sleep modes), or by any of these events. This information that is used to trigger the TCU in identifying a battery swap is published on the vehicle communication network at high frequency and so can be detected in near real-time. The periodic checking allows any swap events that may not have been detected by the actual event itself to be detected. The periodic checking may occur once per minute, or may occur at other frequencies. The computational process of checking is lightweight so the computational cost of doing the checks does not place significant demands on the TCU. Figure 6 schematically showing how a battery may be swapped from one vehicle to another. A battery module starts, at time T1, in vehicle A and a telemetry control unit (TCU) of the vehicle collects and communicates battery performance data to a database in the cloud. At time T2 after T1 the battery module is moved to a charging rack. A TCU of the charging rack collects battery performance data and sends it to the database in the cloud. At time T3, after time t2, the battery module is in another vehicle. This time it is in a vehicle B. The TCU of vehicle B collects and communicates battery performance data to the database in the cloud. The database or a computing device linked to the database associates the data for the battery together to form a performance log for the battery. For example, the log shown in figure 6 assembles performance data for battery having an ID “30023422”. The log data has been collected at three times corresponding to times T1, T2 and T3. For the first two rows the performance data (temperature, charge, voltage) is very similar to each other and the times are close and may corresponding to the battery status in vehicle A immediately before removal from vehicle A and the battery status immediately after being placed in the charging rack. The third row of data has a timestamp of around a day later and may be immediately after it has been put into vehicle B. It can be seen that the temperature of the battery has reduced and the charge and voltage have increased. Turning now to figure 7 we describe the method performed in the cloud, that is the method performed at a computer or across distributed computers that is / are connected to the internet and receive the tagged battery unit performance data from one or more TCUs. The computer or computers may be connected to a database. At step 710 tagged battery performance data is received at the networked computer from a first vehicle. The tagged battery data may be stored in a performance log that is specific to the battery. The computer may be continually receiving performance data for a plurality of different battery units and allocating or associating the data to a performance log for the specific battery unit based on the tagged ID. At step 720 further battery performance data is received relating to the said battery. However, it is received from a second vehicle because the battery has been swapped to a different vehicle. The computer recognises the tag matches the battery previously found that was in the first vehicle. This is indicated at step 730 in figure 7. At step 740 the battery performance data received from the second vehicle is allocated or associated to the performance log for the identified battery. In this way the performance log for the battery can be built up over time. The computer may also perform analysis on the performance log data for a given battery and also across groups of batteries, such as batteries across a vehicle fleet or across batteries from one vehicle or battery manufacturer. In this way trends across fleets or groups of vehicles may be identified, for example battery units that ate defective or contain defective cells or groups of cells. Batteries that are being mistreated may also be identified, for example, at a particular depot or customer. The data for an individual battery unit may also be analysed by checking if it appears to be failing or is in the early stages of a future impending failure. An alert may be raised to a user or monitoring system to indicate that the battery unit is approaching failure such that maintenance steps may be taken or it may be removed from service before failure occurs. Other analyses that may be performed include checking whether the battery performance is being maintained and estimating the life of the battery unit. As well as being useful for users to avoid sudden failure, this lifetime estimation may also be useful for checking whether the battery will have an agreed or specified performance during or at the end of a warranty period, for example, five, eight or ten years. The battery analytics may also be used for fleet route optimisation. For example, the near real-time analytics and comparison to known performance of similar batteries may allow vehicles in a delivery fleet to continue making deliveries and only return to a depot or charging station when the battery needs charging or swapping. In one example embodiment, battery swap analytics is deployed in last mile delivery vehicles such as food delivery vehicles including three-wheel electric vans. However the approach is valid for any vehicles that support battery swapping, including: e-bikes, motor scooters, lightweight EV delivery vehicles, and passenger vehicles. The approach is not limited by the mechanism used for swapping the battery units or the size of the battery units. For example, the battery swapping may be applied in full-size passenger cars such as compact, sedans, coupes, SUVs etc, for example which may require a dedicated facility to perform the battery swap, to much smaller vehicles such as e-bikes where the battery is smaller an can be swapped by a user. The collection of data along with information on the type or structure of the battery allows a digital-twin of the real-battery to be generated. This allows more sophisticated predictions of lifetime and long-term performance to be made. The present invention has particular application in batteries meeting EU Battery Passport legislation. The legislation sets out a Battery Passport which is a digital record for each motive power battery containing information on its composition, origin, performance, environmental footprint, and lifecycle. This allows stakeholders across the supply chain, including manufacturers, recyclers, and consumers, to access detailed data on each battery's sustainability and compliance. 5 Although specific embodiments of the invention have been described with reference to the drawings, the skilled person will be aware that variations and modifications may be applied to these embodiments without departing from the scope of the invention as defined in the claims.

Claims

1. A method of monitoring a swappable, motive power battery unit in a vehicle, comprising:collecting, by a controller, performance data relating to the status of the motive power battery unit;determining the identity of the motive power battery unit by either (a) sending, by a controller in the vehicle, a request across a communication network of the vehicle to determine an identity of the motive power battery unit, or (b) from fingerprinting of data from the motive power battery unit;tagging, by the controller, the performance data with battery identity; and sending the tagged performance data over an external communication network to a remote database.

2. The method of claim 1, wherein determining the identity of the motive power battery unit comprises sending, by the controller of the vehicle, a request across the communication network of the vehicle to obtain the identity of the motive power battery unit, wherein the communication network of the vehicle is a CAN bus network and / or a vehicle ethernet.

3. The method of claim 2, wherein the identity of the motive power battery unit is a serial number, or is derived from a serial number, of the battery motive power unit.

4. The method of claim 1 or claim 2, wherein determining the identity of the motive battery unit comprises fingerprinting of data of the motive power battery unit, wherein the fingerprinting comprises:collecting battery fingerprint data from the vehicle communication network;sending the battery fingerprint data to a fingerprint module; andreceiving from the fingerprint module the identity of the battery based on the fingerprint data.

5. The method of claim 4, wherein sending the battery fingerprint data to a fingerprint module comprises sending the battery fingerprint data over the external communication network; and wherein receiving the identity of the battery comprises receiving the identity of the battery over the external communication network.

6. The method of claim 4 or claim 5, wherein the collected battery fingerprint data comprises specification data of the motive power battery unit and / or operating data of the motive battery power unit and / or characteristics of the motive power battery unit.

7. The method of claim 6, wherein the collected battery fingerprint data comprises any one or more of the following inputs: firmware version of a battery management system of the motive power battery unit, battery cell configuration in the motive power battery unit; battery capacity; geographical location; open-circuit voltage curve; self-discharge rate; thermal response; isolation resistance; state of health and timing of messages output from the battery motive power unit.

8. The method of claims 4 to 7, wherein the battery fingerprint data is collected from the vehicle communication network by the controller, sorted, by the controller, into a predefined order; and sent to the fingerprint module.

9. The method of any of claims 4 to 8, wherein the battery fingerprint data received at the fingerprint module is hashed by a cryptographic hashing function to produce a unique battery identifier.

10. The method of any preceding claim, further comprising triggering determining the identity of the motive power battery unit based on the controller identifying an occurrence of an event related to the battery or the vehicle, wherein the event is any one or more of: receipt of a signal indicating a battery swap has occurred;a sudden or large change in battery state of charge;a change in the state of the vehicle from drive mode to park mode;a change in the state of the vehicle from park mode to charge mode; and the vehicle powering off, powering on or changing to sleep mode.

11. The method of any preceding claim, wherein the performance data relating to the status of the battery unit comprises one or more of:state of charge;state of health;output voltage of the motive power battery unit;minimum cell voltage of a plurality of cells in the motive power battery unit;maximum cell voltage of a plurality of cells in the motive power battery unit;output current of the motive power battery unit;temperature of the motive power battery unit;isolation resistance of the motive power battery unit;capacity of the motive power battery unit; and fault / error flags relating to the motive power battery unit.

12. The method of claim 11, wherein the controller further collects and sends over the external communication network any of the following data relating to the environment surrounding the vehicle: relative humidity, pressure, and temperature.

13. A method of monitoring a swappable, motive power battery status, comprising: receiving, from a first vehicle, data relating to the performance of a battery in the first vehicle, the data tagged with the identity of the battery;receiving from a second vehicle, data relating to the performance of the same battery in the second vehicle, the data tagged with the identity of the battery;recognising the battery data from the first vehicle and the battery data from second vehicle as related to the same battery that has been swapped from the first vehicle to the second vehicle; andassociating the battery data from the first vehicle and the battery data from the second vehicle together to form a performance status log of the battery.

14. The method of claim 13, further comprising receiving from a motive power battery unit charging station data relating to the performance of the same battery, the data tagged with the identity of the battery.

15. The method of claim 14, wherein the performance data for the same battery relates to the battery located in a vehicle at the charging station or not in a vehicle at the charging station.

16. The method of any of claims 13 to 15, further comprising analysing the performance status log of the battery unit and determining that the battery unit is close to failing or determining an estimated likelihood that the battery unit will fail, and sending an indication to a user or system that maintenance of the battery unit is required.

17. The method of any of claims 13 to 16, wherein the battery unit is a first battery unit, and further comprising analysing the performance status log of the first battery unit to compare the performance of the first battery unit with the performance of one or more other batteries of a fleet, and determining whether the performance of the first battery is within a margin of the average for the fleet of batteries.

18. The method of any of claims 13 to 17, further comprising analysing the performance status log of the battery unit and based on the status log predicting future performance of the battery unit.

19. The method of any of claims 13 to 18, further comprising analysing the performance status log of the battery unit and based on the status log and current planned use of the battery unit, estimating when the battery unit will require a next charge.

20. The method of any of claims 13 to 19, further comprising determining the identity of the battery unit according to the method of any of claims 1 to 12.

21. The method of any of claims 13 to 20, wherein the received data relating to the performance of the battery is received across the internet.

22. The method of any of claims 13 to 21, wherein the performance data relating to the status of the battery unit comprises one or more of:state of charge;state of health;output voltage of the motive power battery unit;minimum cell voltage of a plurality of cells in the motive power battery unit; maximum cell voltage of a plurality of cells in the motive power battery unit; output current of the motive power battery unit;temperature of the motive power battery unit;isolation resistance of the motive power battery unit;capacity of the motive power battery unit; and fault / error flags relating to the motive power battery unit.

23. The method of claim 22, wherein the controller further collects and sends over the external communication network any of the following data relating to the environment surrounding the vehicle: relative humidity, pressure, and temperature.

24. A method of monitoring a swappable, motive power battery unit, the method comprising:swapping a first motive power battery unit into a first vehicle;monitoring the performance of the first motive power battery unit according to the method of any of claims 1 to 12;swapping the first motive power battery unit out of the first vehicle and into a second vehicle or charging station;monitoring the performance of the first battery unit in the second vehicle or charging station according to the method of any of claims 1 to 12; andassociating the battery data from the first vehicle and the battery data from the second vehicle together to form a performance status log of the battery.

25. A method of monitoring a plurality of a swappable, motive power battery units powering a fleet of vehicles, the method comprising:swapping a first motive power battery unit into a first vehicle;monitoring the performance of the first motive power battery unit according to the method of any of claims 1 to 12;swapping the first motive power battery unit out of the first vehicle and replacing it with a second motive power battery unit;monitoring the performance of the second motive power battery unit in the first vehicle according to the method of any of claims 1 to 12.

26. A vehicle comprising a swappable, motive power battery unit and a telemetry controller unit, the telemetry control unit comprising a controller configured to perform the method of any of claims 1 to 12.27 A fleet of vehicles, each comprising a swappable, motive power battery unit and a telemetry controller unit, the telemetry control unit comprising a controller configured to perform the method of any of claims 1 to 12.

28. A computer readable storage medium storing instructions, which when executed by a processor or one or more processors, causes the processor processors to carry out a method according to any of 1 to 23.s