GB2539422A

GB2539422A - System and method

Info

Publication number: GB2539422A
Application number: GB1510480.5A
Authority: GB
Inventors: Ott Justin
Original assignee: CAB4ONE Ltd
Current assignee: CAB4ONE Ltd
Priority date: 2015-06-16
Filing date: 2015-06-16
Publication date: 2016-12-21
Anticipated expiration: 2035-06-16
Also published as: GB201510480D0; GB2539422B

Abstract

The present invention provides a scheduling system for taxi providers that use battery electric vehicles. The system enables a taxi provider to select an electric vehicle which has sufficient battery charge remaining to perform a requested journey. The present invention provides a scheduling system which is able to obtain battery charge data and/or vehicle range data from electric vehicles automatically and in real-time, and use the vehicle range data to select a vehicle for a particular journey. Also, an in vehicle computing device is provided which is activated when the vehicle is running and automatically retrieves and provides battery charge data at predefined intervals.

Description

System and Method

FIELD OF THE INVENTION

The invention relates to a system and method for vehicle scheduling and management, and in particular to scheduling electric vehicles based on the remaining battery charge of the vehicles.

BACKGROUND TO THE INVENTION

Taxi services have traditionally operated using internal combustion engine based vehicles. The abundance of petrol / gasoline stations in most countries, and particularly in populous cities, means that taxi drivers are never too far away from a petrol station and can re-fill their vehicles relatively easily when required. This also means that vehicle scheduling systems for petrol-based vehicles simply need to determine which vehicle is closest to a passenger who requests a vehicle, and do not necessarily need to factor in how much fuel a vehicle has, since the vehicle is likely to be in the vicinity of a petrol station.

However, more and more vehicle-providing services and courier/delivery companies use either petrol-based and battery electric-based vehicle fleets, or entirely battery electric-based vehicle fleets. Battery electric vehicles are those vehicles which use chemical energy stored in rechargeable battery packs for propulsion. A problem with using battery electric-based vehicles is that there are currently far fewer electric vehicle re-charging points in most countries, and even within populous cities such as London (UK). This means that providing a vehicle scheduling service for, or a courier service which uses, battery electric vehicles is more difficult, since the service providers do not know how much charge a vehicle has, whether they will have enough charge to complete a journey, and travel on to a re-charging point (so that the driver is not stranded). While electric vehicles generally provide an estimated range for the remaining battery charge on the dashboard of the vehicle, there is currently no efficient way to provide this data to a scheduling system.

The present applicant has therefore recognised the need for an improved vehicle scheduling system for battery electric vehicles.

SUMMARY OF THE INVENTION

According to a first aspect of the present invention, there is provided an electric vehicle scheduling system comprising: a plurality of electric vehicles; at least one first computing device, wherein the first computing device is associated with the plurality of electric vehicles and is configured to retrieve first data from the electric vehicles, wherein the first data comprises battery state of charge data; and a control system comprising: a monitoring system comprising at least one data store, and at least one processor configured to: receive the retrieved first data from the first computing device associated with the plurality of electric vehicles; store the received first data in the at least one data store; and determine, using a range prediction algorithm, a vehicle range for each vehicle from the first data; a journey scheduling system comprising at least one processor configured to: receive a journey request for a vehicle from a customer; receive the determined vehicle range for each vehicle from the monitoring system; and select one of the plurality of electric vehicles to perform the requested journey using the determined vehicle range for each vehicle.

According to a second aspect of the present invention, there is provided an electric vehicle scheduling method for a vehicle service provider having a plurality of electric vehicles, the method comprising: receiving a journey request for a vehicle from a customer; receiving first data from each electric vehicle, wherein the first data comprises battery state of charge data and data identifying the vehicle; determining, using a range prediction algorithm, a vehicle range from the first data for each vehicle; and selecting one of the plurality of electric vehicles to perform the requested journey using the determined vehicle range for each vehicle.

The following features apply to both aspects of the invention.

Broadly speaking, the present invention provides an electric vehicle scheduling system and method for taxis, cabs, private car hire, and courier service businesses which use battery electric or hybrid vehicles. The system enables a vehicle provider or courier company to determine where its battery electric vehicles are at any given time and which vehicle is best placed to respond to a customer's request for a vehicle or to perform deliveries. As explained in more detail below, the optimum vehicles to perform a journey / complete a delivery may be those which have sufficient battery charge remaining to travel to a passenger collection address (travel to a depot or delivery item collection address), make the requested passenger journey (deliver the item(s)), and then travel to another destination via a battery charge point (so that the vehicle and driver are not stranded after completing the journey). While electric vehicles generally provide an estimated range (in miles or kilometres) possible on the remaining battery charge on the dashboard of the vehicle, there is currently no efficient way to provide this data to a scheduling system.

Embodiments of the present invention solve this problem by providing a scheduling system which is able to obtain battery state of charge data from electric vehicles automatically and in real-time (or near real-time), use the data to calculate a vehicle range, and then select the optimum vehicle for a particular journey (or to make a particular delivery). The battery charge state, also known as the battery state of charge (SoC), is the equivalent of a fuel gauge for a battery in a battery electric vehicle or hybrid vehicle. The units of SoC are percentage points (0% = empty; 100% = full).

The SoC for a battery can be converted into a distance/range that the vehicle may be able to travel on the remaining charge. For example, for a particular type of vehicle, a battery SoC of 60% may mean that the vehicle range is 30 miles.

Determining the optimum vehicle for a particular journey may not depend on the battery charge of the vehicle alone, and thus, the vehicle range data obtained from the electric vehicles may not be an accurate range. For example, if the battery in the electric vehicle is old, the driver has a history of accelerating and breaking hard, the tyres are worn, and/or the outside temperature is below 0°C, then a battery SoC of 60% may actually mean that the vehicle range is reduced to 15 miles. Accordingly, a more accurate vehicle range may depend on additional factors such as the vehicle and battery condition, traffic conditions, the weather, driving style, etc. Thus, embodiments of the present invention also provide a more accurate predicted range for an electric vehicle by combining the range obtained from the vehicle itself with additional information. Acceleration information may be obtained from each vehicle via the first computing device, and a driver may be considered to accelerate hard if the acceleration is above a predetermined threshold.

The first data may also comprise one or more of the following: driver identification information, GID-meter data, vehicle identification information, current GPS location of each vehicle, and vehicle reported range.

In embodiments, the at least one data store stores second data comprising vehicle data associated with the electric vehicles, and wherein the at least one processor of the monitoring system is further configured to: retrieve the second data for each vehicle from the at least one data store; combine the first data and the second data for each vehicle; and determine, using the range prediction algorithm, a vehicle range for each vehicle from the combined first data and second data.

In embodiments, the electric vehicle scheduling method further comprises: retrieving, from a data store, second data for each vehicle, wherein the second data comprises vehicle data for each electric vehicle; combining the first data and the second data for each vehicle; and determining, using the range prediction algorithm, a vehicle range for each vehicle from the combined first data and second data.

The second data for each vehicle may comprise vehicle-specific data, such as one or more of: the last service date of the vehicle, age of the battery, vehicle tyres make/model, vehicle manufacturer, vehicle model, vehicle age, vehicle weight when empty, vehicle tyre pressure, vehicle condition, vehicle devices (e.g. air-conditioning, climate control systems, heating systems, radios, CD/DVD players, etc), last charge date/time of the battery, last charge type (e.g. trickle-charged over several hours, or fast-charged in minutes), and ambient temperature.

The second data may further comprise driver-specific data, such as one or more of: driver driving style (e.g. whether the driver repeatedly accelerates quickly and brakes hard, which is less fuel-efficient, or if the driver has a smoother, gentler driving style, which is more fuel-efficient), driver gender and/or height (to estimate driver weight), driver weight (estimated/approximate/actual).

The second data may further comprise additional information that is input either via the driver or is extracted from the journey request received from the customer. For example, the second data may comprise one or more of: total number of adult passengers, total number of children passengers, and total number of luggage items. The range prediction algorithm is In embodiments, the monitoring system further comprises a communication module, and wherein the at least one processor of the monitoring system is further configured to: retrieve third data from third party data providers via the communication module; combine the first data and the second data for each vehicle with the third data; and determine, using the range prediction algorithm, a vehicle range for each vehicle from the combined first data, second data and third data.

In embodiments, the electric vehicle scheduling method further comprises: retrieving third data from third party data providers; combining the first data and the second data for each vehicle with the third data; and determining, using the range prediction algorithm, a vehicle range for each vehicle from the combined first data, second data and third data.

The third data may relate to external/additional information that is not necessarily specific to each vehicle or driver. The third data may comprise one or more of: environmental conditions (e.g. the current weather conditions at each vehicle's current location, which may affect how much fuel is used by the vehicle), the terrain type at and near to the vehicle's current location, and current traffic conditions in the vicinity of each vehicle.

In embodiments, the first computing device associated with the electric vehicles comprises: a communication module to enable communication with the monitoring system; and a processor configured to: automatically receive the first data at a predefined interval while the electric vehicles are running; and automatically transmit the retrieved first data to the monitoring system via the communication module at the predefined interval.

In embodiments, the at least one first computing device is a remote server located remote to the plurality of electric vehicles, and the first computing device is configured to receive first data from all or a subset of the plurality of electric vehicles. For example, the first computing device may be one or more remote servers located remote to (external to) the plurality of electric vehicles, and the or each remote server is configured to receive battery state of charge data from all or a subset of the plurality of electric vehicles. For example, the remote server may be a particular vehicle manufacturer's server, which holds data on vehicle owners and collects vehicle data remotely from a vehicle's engine control unit. In this case, the required battery state of charge data is obtainable from the remote server directly, rather than from each vehicle itself. Nevertheless, an in-vehicle computing device may be provided in each vehicle as a back-up, in case the remote server is temporarily out of action, so that real-time battery state of charge data is always obtainable.

Additionally or alternatively, a first computing device is provided on-board each electric vehicle. The first computing device comprises a connection to couple the device to a digital communications port of the electric vehicle to receive first data from the electric vehicle. The first computing device may be integrated into an electric vehicle, or be part of the vehicle's engine control unit. Alternatively, the first computing device may comprise a connection to couple the device to a digital communications port of the electric vehicle to receive battery state of charge data from the electric vehicle. Preferably, the in-vehicle first computing device may comprise a connection for an onboard diagnostics (OBD) port and/or a European on-board diagnostics (EOBD) port within the vehicle. OBD/EOBD ports are standardised digital communications ports used to provide real-time data on a vehicle's performance, as well as a standardised set of diagnostic trouble codes (DTCs) which enable a mechanic to identify and remedy malfunctions within the vehicle.

The battery state of charge data and the GID-meter data may both be extracted from a vehicle via the OBD/EOBD port. The GID-meter data typically triggers 'low battery' and very low battery' warnings in a vehicle -this data may be used by the system to calculate the remaining battery of a vehicle and/or predict the range of the vehicle.

In embodiments, the first computing device processor is further configured to: activate the first computing device when the electric vehicle motor is determined to be running; and automatically retrieve the first data from the electric vehicle via the digital communications port at a predefined interval while the electric vehicle is running. Advantageously, this means that the scheduling system only obtains data from vehicles which are currently in service/operation, which is more efficient than obtaining and analysing data from all vehicles.

The in-vehicle first computing device may comprise communication means to communicate the data obtained from the OBD/EOBD port straight to the monitoring system, e.g. via the internet or via a mobile network. However, as the majority of vehicle drivers possess mobile phones/smartphones, the first computing device may simply transmit data to the driver's smartphone, which comprises the communication means required to transmit the data to the monitoring system. Thus, in preferred embodiments, where the first computing device is provided on board each vehicle, the system further comprises at least one second computing device associated with each electric vehicle, wherein the second computing device comprises: a communication module to enable communication with the first computing device (e.g. via Bluetooth (RTM), Wi-Fi or other short-range communication) and with the monitoring system (e.g. via the internet, a mobile network, or other long-range communication); and a processor configured to: receive the first data from the electric vehicle via the communication module; combine the received first data with data identifying the second computing device; and transmit the combined data to the monitoring system via the communication module.

The second computing device (driver's computing device) is configured to communicate with the backend control system via the internet and/or a mobile network.

Thus, the second computing device may be any device suitable for this purpose, such as a mobile phone, a smartphone, a laptop, a tablet PCT, or other portable computing device.

In embodiments, the second computing device processor is further configured to request first data from the first computing device at a predefined interval.

In embodiments, the second computing device processor is further configured to determine if the electric vehicle motor is running, and request first data from the first computing device at a predefined interval while the motor is running.

In embodiments, the predefined interval is any one of: 30 seconds, one minute, two minutes, five minutes, ten minutes, or any other integer number of seconds or minutes.

In embodiments, the journey scheduling system further comprises: at least one data store for storing received journey requests; a journey request receiving module configured to: receive the journey request for a vehicle from a customer; and store the received journey request in the at least one data store; and a journey scheduling module configured to: receive a received journey request from the journey request receiving module; request a determined vehicle range for each vehicle from the monitoring system; select one of the plurality of electric vehicles to perform the requested journey using the determined vehicle range for each vehicle; send a message to the selected electric vehicle to perform the requested journey; and send a confirmation message to the customer (to for example, confirm that a vehicle is on its way).

In embodiments, the electric vehicle scheduling method further comprises: sending a message to the selected electric vehicle to perform the requested journey; and sending a confirmation message to the customer.

Preferably, the vehicle range prediction algorithm will evolve over time, to provide a more accurate algorithm. The vehicle range prediction algorithm may comprise a set of algorithms (or a set of sub-algorithms), where the set of algorithms may comprise a specific algorithm for a/each electric car manufacturer, a/each electric vehicle type, or a/each electric vehicle model. Thus, preferably, the vehicle range prediction algorithm which performs a range calculation for a specific vehicle or vehicle type is selected from the set of algorithms to ensure the correct algorithm is used for the vehicle (based on, for example, vehicle identification information such as a VIN).

The algorithm for each vehicle type may be set to a default algorithm when the system/method is first used. Thus, the algorithm may need to be updated to provide a more accurate algorithm, based on for example, historical vehicle data stored in the data store of the control system. This historical data may be used to extract the actual vehicle ranges achieved per battery state of charge for particular vehicles, such that an 'actual' function for the vehicles between battery state of charge and vehicle range can be calculated. The function may depend on other variables, such as the weight of the vehicle, the vehicle's performance in different weather conditions or at different temperatures, the vehicle/battery age, etc, and these variables may be included in the 'actual' function.

Thus, in embodiments of the electric vehicle scheduling system, the monitoring system is further configured to update the range prediction algorithm for a subset of the plurality of vehicles, by: obtaining a function to convert the first data to the vehicle range from the range prediction algorithm; obtaining historical data for the subset of vehicles; extracting, from the historical data, true vehicle ranges achieved by the subset of vehicles as a function of battery state of charge; determining a new function to convert the first data to the vehicle range, using the extracted true vehicle ranges; and updating the range prediction algorithm to use the determined new function.

Similarly, in embodiments of the electric vehicle scheduling method, the method further comprises updating the range prediction algorithm for a subset of the plurality of vehicles, by: obtaining a function to convert the first data to the vehicle range from the range prediction algorithm; obtaining historical data for the subset of vehicles; extracting, from the historical data, true vehicle ranges achieved by the subset of vehicles as a function of battery state of charge; determining a new function to convert the first data to the vehicle range, using the extracted true vehicle ranges; and updating the range prediction algorithm to use the determined new function.

Here "true vehicle range" refers to a range (or range estimate) based on measured data defining an actual range. This may be, for example, a measured change in range (which may be associated with a measured change in battery charge).

The invention further provides processor control code to implement the above-described systems and methods, for example on a general purpose computer system or on a digital signal processor (DSP). The code may be provided on a carrier such as a disk, a microprocessor, CD-or DVD-ROM, programmed memory such as non-volatile memory (e.g. Flash) or read-only memory (Firmware). Code (and/or data) to implement embodiments of the invention may comprise source, object or executable code in a conventional programming language (interpreted or compiled) such as C, or assembly code. As the skilled person will appreciate such code and/or data may be distributed between a plurality of coupled components in communication with one another.

According to a related aspect of the invention, there is provided a non-transitory data carrier carrying processor control code which when running on a processor, causes the processor to implement the above-described method.

The invention also provides a carrier carrying processor control code to, when running, implement any of the above methods, in particular on a non-transitory data carrier such as a disk, microprocessor, CD-or DVD-ROM, programmed memory such as read-only memory (Firmware), or on a data carrier such as an optical or electrical signal carrier. Code (and/or data) to implement embodiments of the invention may comprise source, object or executable code in a conventional programming language (interpreted or compiled) such as C, or assembly code, code for setting up or controlling an ASIC (Application Specific Integrated Circuit) or FPGA (Field Programmable Gate Array), or code for a hardware description language such as VerilogTM or VHDL (Very high speed integrated circuit Hardware Description Language). As the skilled person will appreciate such code and/or data may be distributed between a plurality of coupled components in communication with one another. The invention may comprise a controller which includes a microprocessor, working memory and program memory coupled to one or more of the components of the system.

According to a further aspect of the invention, there is provided an in-vehicle computing device for an electric vehicle scheduling system, the in-vehicle computing device comprising: a connection to couple the in-vehicle computing device to a digital communications port in the electric vehicle; and a processor configured to: activate the first computing device when the electric vehicle is determined to be running; automatically retrieve battery state of charge data from the electric vehicle via the digital communications port at a predefined interval while the electric vehicle motor is running; and automatically provide the retrieved first data to the electric vehicle scheduling system at the predefined interval.

The in-vehicle computing device is configured to obtain real-time battery state of charge data from the vehicle and provided the data to an electric vehicle scheduling system, so that the data can be used to schedule vehicles as described above.

In preferred embodiments, the in-vehicle computing device connection is for an onboard diagnostics (OBD) port and/or a European on-board diagnostics (EOBD) port within the vehicle.

In embodiments, the in-vehicle computing device comprises communication means to communicate the data obtained from the OBD/EOBD port to the electric vehicle scheduling system, e.g. via the internet or via a mobile network. Alternatively, the in-vehicle computing device comprises communication means to communicate the data (e.g. via Bluetooth (RTM), Wi-Fi or other short-range communication) obtained from the OBD/EOBD port to a portable computing device (such as a smartphone) located within the vehicle, such that the portable computing device transmits the data to the electric vehicle scheduling system (e.g. via the internet, a mobile network, or other long-range communication).

The or each processor mentioned above may be implemented in any known suitable hardware such as a microprocessor, a Digital Signal Processing (DSP) chip, an Application Specific Integrated Circuit (ASIC), Field Programmable Gate Arrays (FPGAs), etc. The or each processor may include one or more processing cores with each core configured to perform independently. The or each processor may have connectivity to a bus to execute instructions and process information stored in, for

example, a memory.

BRIEF DESCRIPTION OF THE DRAWINGS

The invention is diagrammatically illustrated, by way of example, in the accompanying drawings, in which: Fig. 1 illustrates a schematic of an electric taxi service scheduling system according to embodiments of the present invention; Fig. 2 is a block diagram of an electric taxi service scheduling system; Fig. 3 is a block diagram illustrating the inputs and output of a range prediction algorithm used to schedule vehicle journeys; Fig. 4 is a flow chart of the steps taken to process a vehicle request using the system of Fig. 2; Fig. 5 is a flow chart of the steps taken by the monitoring system of the system to calculate predicted vehicle ranges; Fig. 6 is a flow chart of the steps taken to obtain vehicle data used to obtain vehicle data from a vehicle; and Fig. 7 is an example flow chart showing how the vehicle range prediction algorithm can be updated using historical vehicle data.

DETAILED DESCRIPTION OF THE DRAWINGS

Broadly speaking, the present invention provides a scheduling system for taxis, cabs and private car hire businesses which use battery electric or hybrid vehicles. The system enables a taxi provider to determine where its battery electric vehicles are at any given time and which vehicle is best placed to respond to a customer's request for a taxi. In particular, the vehicles which are best placed to respond may not be the vehicles which are closest to the customer collection address but are those which have sufficient battery charge remaining to reach the collection address, complete the requested journey, and then travel to a battery charge point (so that the vehicle and driver are not stranded after completing the journey). While electric vehicles generally provide an estimated range (in miles or kilometres) possible on the remaining battery charge on the dashboard of the vehicle, there is currently no efficient way to provide this data to a taxi scheduling system. Thus, the present invention solves this problem by providing a scheduling system which is able to obtain battery charge data and/or vehicle range data from electric vehicles automatically and in real-time (or near real-time). The scheduling system is then able to use the vehicle range data obtained from the electric vehicles to select a vehicle for a particular journey.

Determining the optimum vehicle for a particular journey may not depend on the battery charge of the vehicle alone, and thus, the vehicle range data obtained from the electric vehicles may not be an accurate range. A more accurate vehicle range may depend on additional factors such as the vehicle and battery condition, traffic conditions, the weather, driving style, etc. Thus, the present invention also provides a more accurate predicted range for an electric vehicle by combining the range obtained from the vehicle itself with additional information.

Fig. 1 illustrates a schematic of an electric taxi service scheduling system 10 according to embodiments of the present invention. The scheduling system 10 comprises a plurality of vehicles 12 which are used to collect and drop-off passengers as per their requested journeys. A vehicle 12 in the system is any one of the following types of vehicle: internal combustion engine based vehicles, electric motor based vehicles, plug-in electric vehicles, battery electric vehicles (i.e. which use chemical energy stored in rechargeable battery packs for propulsion), hybrid engine based vehicles (i.e. which combine an internal combustion engine and one or more electric motors), flexible-fuel based vehicles, natural gas based vehicles, and/or hydrogen fuel based vehicles. Preferably, the vehicles 12 are electric or hybrid vehicles.

Each vehicle 12 is driven by a driver who owns or is provided with a driver computing device 14. Each driver computing device 14 is a computing device configured to communicate with a backend control system, which comprises a monitoring system 18 and a journey scheduling system 24. (The backend control system is described in more detail below with reference to Fig. 2). The driver computing device 14 communicates with the backend control system via the internet and/or a mobile network 16, 30. Thus, the driver computing device is any device suitable for this purpose, such as a mobile phone, a smartphone, a laptop, a tablet PCT, or other portable computing device.

A customer 28 who wishes to use a taxi service either calls the taxi service provider or uses a custom mobile 'app' running on his smartphone to place a request for a taxi. The request is sent from the customer's phone via a mobile phone network or the internet 26 to the journey scheduling system 24. The journey scheduling system 24 receives the request and extracts the required collection and drop-off locations from the request. The journey scheduling system 24 requests vehicle range data from the monitoring system 18 in order to determine which vehicle 12 should be used to make the requested journey.

The monitoring system 18 performs at least two functions: obtaining a vehicle range based on the battery charge state of each vehicle; and calculating a more accurate predicted vehicle range based on the battery charge state and one or more additional variables. The battery charge state, also known as the battery state of charge (SoC), is the equivalent of a fuel gauge for a battery in a battery electric vehicle or hybrid vehicle.

The units of SoC are percentage points (0% = empty; 100% = full). An alternate form of the same measure is the depth of discharge (DoD), the inverse of SoC (100% = empty; 0% = full). SoC is normally used when discussing the current state of a battery in use. The SoC for a battery can be converted into a distance/range that the vehicle may be able to travel on the remaining charge. For example, for a particular type of vehicle, a battery SoC of 60% may mean that the vehicle range is 30 miles. However, if for example, the battery is old, the driver has a history of accelerating and breaking hard, the tyres are worn, and/or the temperature is below 0°C, then a battery SoC of 60% may mean that the vehicle range is reduced to 15 miles.

Firstly, to obtain a vehicle range based on the battery charge state of each vehicle, the monitoring system 18 obtains battery charge data and/or vehicle range data from the driver computing device 14 in each vehicle 12. In embodiments, the monitoring system 18 requests data from the driver computing devices 14 within each vehicle 12 either when required to provide up-to-date information to the journey scheduling system, or on a regular basis (e.g. every minute or every few minutes). Additionally or alternatively, instead of requesting the data, the monitoring system 18 may automatically receive battery charge data and/or vehicle range data from the driver computing devices 14 at frequent and regular intervals. For example, each driver computing device 14 may be configured to transmit data to the monitoring system 18 every minute or every few minutes. In each case, data is obtained from each vehicle 12 and transmitted via the driver computing device 14 in each vehicle to the monitoring system 18 (via the mobile network/internet 16). (This process is described in more detail with respect to Figs. 5 and 6 below).

Once obtained by the monitoring system 18, the vehicle range data may be forwarded directly to the journey scheduling system 24 so that a vehicle 12 can be selected to perform a journey. If the monitoring system 18 obtains battery charge data from the driver computing devices 14, the monitoring system calculates the vehicle range from the battery charge data for each vehicle, and then forwards the calculated vehicle range to the journey scheduling system 24.

Secondly, to calculate a more accurate predicted vehicle range, the monitoring system 18 runs a vehicle range prediction algorithm to calculate predicted ranges for each vehicle 12 in the fleet. The algorithm takes as an input battery charge data and/or vehicle range data from the driver computing device 14, and additional data such as current weather conditions, current traffic conditions, terrain type along the requested journey, etc. Such information may be obtained from the system data stores or from external data sources 20 via the internet 22. The data is input into the algorithm and used to calculate a predicted range for each vehicle 12. The predicted vehicle ranges are provided by the monitoring system 18 to the journey scheduling system 24.

The journey scheduling system uses either the 'simple' vehicle range obtained from the vehicles 12, or the predicted vehicle ranges calculated by the monitoring system 18, to determine which vehicle 12 is the most suitable to make the requested journey. The journey scheduling system selects a vehicle 12 for a journey, and then sends the journey information to the driver computing device 14 located in the selected vehicle 12 via the mobile phone network/internet 30. The journey scheduling system may also be configured to send confirmation data to the user 28 confirming that a taxi is on its way (and possibly also identifying the taxi itself).

Thus, the electric taxi service scheduling system 10 is configured to schedule and manage taxis based on at least the remaining vehicle battery charge, and determine which vehicle is the optimum one to make a requested journey, thereby providing a more efficient and reliable scheduling system for taxi services.

In embodiments, the electric taxi service scheduling system comprises at least one computing device which is associated with the plurality of electric vehicles and is configured to retrieve battery state of charge data from the vehicles. In embodiments, the at least one computing device is a remote server located remote to the plurality of electric vehicles, and the computing device is configured to receive battery state of charge data from all or a subset of the plurality of electric vehicles. For example, the remote server may be a particular vehicle manufacturer's server, which holds data on vehicle owners and collects vehicle data remotely from a vehicle's engine control unit.

In this case, the required battery state of charge data is obtainable from the remote server directly. Nevertheless, an in-vehicle computing device may be provided in each vehicle as a back-up, in case the remote server is temporarily out of action, so that battery data is still collectable.

In embodiments, the electric taxi service scheduling system comprises at least one computing device on-board each of the plurality of electric vehicles. In embodiments, the computing device is integrated into an electric vehicle, or is part of the vehicle's engine control unit. In additional or alternative embodiments, the computing device comprises a connection to couple to a digital communications port of the electric vehicle to receive battery state of charge data from the electric vehicle.

In embodiments, the on-board computing device comprises a communication module to enable the computing device to transmit the battery state of charge data to the monitoring system directly (e.g. over the internet or via a mobile network).

Alternatively, the on-board computing device itself does not comprise the capability to communicate with the monitoring system directly. Instead, the on-board computing device comprises a communication module which enables the computing device to communicate with the driver computing device 14 (e.g. a mobile phone) in each vehicle 12. The driver computing device 14 is configured to transmit the battery state of charge data to the monitoring system. This embodiment is described in more detail with respect to Fig. 2.

Turning now to Fig. 2, this shows a block diagram of the electric taxi service scheduling system. Each (electric) vehicle 12 of the electric taxi service scheduling system used to collect and drop-off passengers is equipped with an in-vehicle device 40 (also termed a "Spark Monitoring Device"). The in-vehicle device 40 is configured to extract real-time data from the vehicle on the vehicle's remaining battery charge, so that it can be provided to the monitoring system of the electric taxi service scheduling system (and used as an input to the vehicle range prediction algorithm). The in-vehicle device 40 comprises a connection for an on-board diagnostics (OBD) port and/or a European on-board diagnostics (EOBD) port within the vehicle. OBD/EOBD ports are standardised digital communications ports used to provide real-time data on a vehicle's performance, as well as a standardised set of diagnostic trouble codes (DTCs) which enable a mechanic to identify and remedy malfunctions within the vehicle. The OBD/E0BD ports are commonly used by mechanics to connect diagnostic equipment to the vehicle. In embodiments, the in-vehicle device 40 is an off-the-shelf device. Additionally or alternatively, the in-vehicle device 40 is a custom-made device for the electric taxi service scheduling system.

The in-vehicle device 40 comprises a processor 40a coupled to program memory 40b storing computer program code to enable data to be extracted from the vehicle via the OBD/EOBD port, to working memory 40d and to interfaces 40c such as a screen, keyboard, mouse, touchscreen, and network interface to enable communication between the in-vehicle device and driver computing device 46.

The processor 40a may be an ARM (RTM) device or a similar processor produced by another manufacturer such as Intel. The program memory 40b, in embodiments, stores processor control code to implement functions, including an operating system, various types of wireless and wired interface, storage and import and export from the in-vehicle device 40.

The in-vehicle device 40 comprises a wireless communication interface 44, for example a Bluetooth (RTM), Wi-Fi or other short-range communication interface, for interfacing with other devices and in particular for communicating data to the driver computing device 46.

The in-vehicle device 40 comprises an OBD/EOBD port connection 42, to enable the device to couple to the on-board diagnostics port of the vehicle. The in-vehicle device may be permanently coupled to the OBD port, or preferably, releasably coupled to the OBD port.

Battery state of charge data, and optionally GID-meter data, are extractable from a vehicle via the OBD/EOBD port. The GID-meter data typically triggers 'low battery' and very low battery' warnings in a vehicle -this data may be used by the system to calculate the remaining battery of a vehicle and/or predict the range of the vehicle.

Data obtained by the in-vehicle device 40 from the on-board diagnostics port of the vehicle is transmitted to the driver computing device 46. A driver of a vehicle in the system either owns or is provided with a driver computing device 46. As mentioned above, each driver computing device 46 is configured to communicate with a backend control system 58. In particular, the driver computing device 46 is configured to transmit data obtained from the in-vehicle device 40 to the backend control system 58 and to receive journey data back from the backend control system 58. The data obtained from the in-vehicle device 40 enables the backend control system 58 to calculate a predicted range for the vehicle. The journey data received by the driver computing device 46 informs the driver of the journey he is required to make and includes at least the passenger collection address and the passenger drop-off address. The driver computing device 46 communicates with the backend control system 58 via the internet and/or a mobile network 54. Thus, the driver computing device 46 is any device suitable for this purpose, such as a mobile phone, a smartphone, a laptop, a tablet PCT, or other portable computing device.

The driver computing device 46 comprises a processor 46a coupled to program memory 46b storing computer program code to enable data to be obtained from the in-vehicle device, transmitted to the backend control system 58 and to receive data back from the backend control system 58. The processor 46a is also coupled to working memory 46d and to interfaces 46c such as a screen, keyboard, mouse, touchscreen, and network interface to enable communication between the in-vehicle device 40 and driver computing device 46 (short-range communication), and between the driver computing device and the backend control system 58 (long-range communication, e.g. via a mobile network).

The processor 46a may be an ARM (RTM) device or a similar processor produced by another manufacturer such as Intel. The program memory 46b, in embodiments, stores processor control code to implement functions, including an operating system, various types of wireless and wired interface, storage and import and export from the driver computing device 46.

The driver computing device 46 comprises a wireless communication interface 52, for example a Bluetooth (RTM), Wi-Fi or other short-range communication interface, for interfacing with other devices and in particular for receiving data from the in-vehicle device 40.

The driver computing device 46 comprises a monitoring 'app' 48 which is configured to enable the device to receive data from the in-vehicle device 40, to convert the data into a useable form (optional) and to transmit the data to the backend control system 58. The monitoring app 48 may be configured to turn-on/activate as soon as the device 46 is determined to be in the vehicle (e.g. when it is in communication range from the in-vehicle device 40).

The driver computing device 46 further comprises a scheduling 'app' 50 which is configured to receive journey data from the backend control system 58. The scheduling app 50 may be configured to turn-on/activate as soon as the device 46 is determined to be in the vehicle, or may need to be turned-on by the driver. In embodiments, the monitoring app 48 and the scheduling app 50 may be provided as a single app on the device 46.

As mentioned above, the driver computing device 46 transmits vehicle data (e.g. battery range data) to the backend control system 58 via a mobile network or the internet 54. The driver computing device 46 may append the vehicle data received from the in-vehicle device 40 with additional information, such as the current location of the vehicle (using a GPS function of the driver computing device or otherwise), and the driver ID and/or other identification data to enable the backend control system 58 to determine which vehicle/driver the data it receives has originated from. The driver ID may be a specific, unique ID associated with the driver (which the driver may have to enter into the driver computing device 46), or may be an ID associated with the driver computing device 46, or may simply be a mobile phone number associated with the driver computing device 46.

The backend control system 58 comprises a monitoring system 60 and a journey scheduling system 68. The monitoring system 60 and journey scheduling system 68 are shown as two separate entities which are connected to each other, preferably via a secure connection. This merely indicates that each entity has a different function or role in the scheduling process. The monitoring system 60 and journey scheduling system 58 may be physically separate. However, it will be appreciated that the separate functions of the monitoring system 60 and journey scheduling system 68 may also be provided by a single entity, e.g. a single monitoring and scheduling system.

A customer who wishes to use a taxi service either calls the taxi service provider or uses a custom mobile 'app' running on his smartphone to place a request for a taxi.

The request is sent from the customer's phone via a mobile phone network or the internet to the journey scheduling system 68. A journey request receiving module 72 is configured to receive the request and to extract the required passenger collection and drop-off locations from the request.

The journey scheduling system 68 comprises at least one processor 68a coupled to program memory 68b storing computer program code to, for example: * receive journey request data from customers, * extract journey details (e.g collection and drop-off locations) from the journey data, * receive predicted vehicle ranges from the monitoring system 60, * determine which vehicle should be used to perform the requested journey, * transmit journey confirmation to a customer, and * transmit journey details to a driver computing device 46 in the selected vehicle for the requested journey.

The at least one processor 68a is also coupled to working memory 68d and to interfaces 68c such as a screen, keyboard, mouse, touchscreen, and network interface to enable communication between customers, the monitoring system 60 and the driver computing devices 46. The processor 68a may be an ARM (RTM) device or a similar processor produced by another manufacturer such as Intel. The program memory 68b, in embodiments, stores processor control code to implement functions (e.g. the above-listed functions), including an operating system, various types of wireless and wired interface, storage and import and export from the journey scheduling system 68.

The journey scheduling system 68 further comprises a data store 70, which is configured to store incoming journey requests from customers, and store predicted vehicle range data received from the monitoring system 60 in order to schedule journeys.

Upon receiving a request for a journey from a customer, the journey request receiving module 72 is configured to communicate the received request to the journey scheduling module 74. The journey scheduling system 68 requests predicted vehicle range data from the monitoring system 60 in order to determine which vehicle should be used to make the requested journey. In embodiments, the journey scheduling module 74 is configured to request the predicted vehicle range data from the monitoring system 60.

As mentioned above, the monitoring system 60 (also known as the "Spark monitoring platform") performs at least two functions: obtaining a vehicle range based on the battery charge state of each vehicle (also referred to herein as the 'simple vehicle range'); and calculating a more accurate predicted vehicle range based on the battery charge state and one or more additional variables. In the latter case, the monitoring system 60 runs a vehicle range prediction algorithm to calculate predicted ranges for each vehicle in the vehicle fleet.

To obtain the 'simple vehicle range' based on the battery charge state of each vehicle alone, the monitoring system 60 obtains battery charge data and/or vehicle range data from the driver computing device 46 in each vehicle. In embodiments, the monitoring system 60 requests data from the driver computing devices 46 within each vehicle either when requested to provide up-to-date information to the journey scheduling system 68, or automatically on a regular basis (e.g. every minute or every few minutes). Additionally or alternatively, the monitoring system 60 may automatically receive battery charge data and/or vehicle range data from the driver computing devices 46 at frequent and regular intervals. For example, each driver computing device 46 may be configured to transmit data to the monitoring system 60 every minute or every few minutes. In each case, data is obtained from each in-vehicle device 40 and transmitted via the driver computing device 46 to the monitoring system 60 (via the mobile network/internet 54).

If the monitoring system 60 receives vehicle range data from each driver computing device 46, it forwards the vehicle range data directly to the journey scheduling module 74. If the monitoring system 60 obtains battery charge data from the driver computing devices 46, the monitoring system calculates the vehicle range from the battery charge data for each vehicle, and then forwards the calculated vehicle range to the journey scheduling module 74.

To calculate a more accurate predicted vehicle range, the monitoring system 60 runs a vehicle range prediction algorithm to calculate predicted ranges for each vehicle in the fleet. The algorithm takes as an input the battery charge data and/or vehicle range data from the driver computing device 46, and additional data such as current weather conditions, current traffic conditions, terrain type along the requested journey, etc. Such information may be obtained from the system data stores or from external data sources 56 via the internet 54. The data is input into the algorithm and used to calculate a predicted range for each vehicle. The predicted vehicle ranges are provided by the monitoring system 60 to the journey scheduling module 74.

The monitoring system 60 comprises at least one processor 60a coupled to program memory 60b storing computer program code to, for example: * receive a request for up-to-date predicted vehicle ranges from the journey scheduling system 68/journey scheduling module 74, * request current vehicle data (including at least the remaining battery charge, and optionally GID data) from the driver computing devices 46, * receive raw vehicle data from the driver computing devices 46 via a mobile network or the internet 54, * extract first data from the raw vehicle data received from the driver computing devices 46, where the first data includes at least the driver ID, the remaining battery charge for each vehicle and the current location of each vehicle, * obtain second data on the vehicle history from database 62, where the second data may include data on the last service date of the vehicle, age of the battery and wear and make of the vehicle tyres, which enable a more accurate predicted vehicle range to be calculated, * (optionally) obtain third data from external data sources 56, where the third data may include current weather conditions at each vehicle's current location and current traffic conditions in the vicinity of each vehicle, * calculate a predicted vehicle range for each vehicle using the first and second data (and optionally the third data), and * transmit predicted vehicle ranges to the journey scheduling system 68/journey scheduling module 74.

The at least one processor 60a is also coupled to working memory 60d and to interfaces 60c such as a screen, keyboard, mouse, touchscreen, and network interface to enable communication between the journey scheduling system 68, the external data sources 56 and the driver computing devices 46. The processor 60a may be an ARM (RTM) device or a similar processor produced by another manufacturer such as Intel. The program memory 60b, in embodiments, stores processor control code to implement functions (e.g. the above-listed functions), including an operating system, various types of wireless and wired interface, storage and import and export from the monitoring system 60.

The monitoring system 60 further comprises at least one database (or data store) 62, which is configured to store the raw vehicle data received from the driver computing devices 46, the first data extracted from the raw vehicle data, the second data on vehicle and driver history, the third data obtained from the external data sources 56, and the calculated predicted vehicle ranges.

The monitoring system 60 comprises application program interfaces (APIs) 64 which enables the monitoring system 60 to interface with, for example, the driver computing devices 46.

The monitoring system 60 is configured to implement a range prediction algorithm/program 66. The range prediction program 66 calculates the predicted range for each vehicle, based on at least the first data (e.g. current remaining battery charge for each vehicle) and second data (e.g. vehicle/driver history), and optionally third data (e.g. current weather conditions, current vehicle location, current traffic conditions, terrain type along the requested journey, etc.). The predicted range for each vehicle is output by the range prediction program 66, and is stored in database 62 and transmitted to the journey scheduling module 74 of the journey scheduling system 68.

The predicted vehicle ranges are provided by the monitoring system 60 to the journey scheduling module 74. The journey scheduling module 74 uses the predicted vehicle ranges to determine which vehicle is the most suitable to make each requested journey. The journey scheduling module 74 may comprise, or may be configured to communicate with, a GPS router or GPS routing system 75. The GPS router is configured to determine which routes are available between a start position A and a destination position B (e.g. motorways, A-roads, B-roads, etc), and which route is most suitable for the particular time of day or the required journey time (e.g. motorways for urgent/fast journeys, A-roads when it is not rush-hour, B-roads for slower, return journeys, etc). Once a vehicle has been selected for a particular requested journey, the journey scheduling module 74 sends the journey information (and the suggested route determined by the GPS router 75) to the driver computing device 14 located in the selected vehicle via the mobile phone network/internet 54. The journey scheduling module 74 (or the journey request receiving module 72) may also be configured to send confirmation data to the customer to confirm that a taxi is on its way.

Fig. 3 is a diagram illustrating the inputs and output of a range prediction algorithm 304 used to schedule vehicle journeys, in an embodiment of the invention. One input is a request 300 for up-to-date vehicle range information. The range prediction algorithm/program implemented by the monitoring system is initiated when the journey scheduling system requests up-to-date vehicle range data from the monitoring system. Once running, the range prediction algorithm requires vehicle data and external data 302 as inputs used to calculate the predicted range for each vehicle. The input data 302 comprises first data 302a extracted from the raw vehicle data received from each driver computing device, second data 302b on the vehicle history extracted from the database, and optionally, third data 302c obtained from external data sources.

The first data 302a comprises at least the driver ID, the remaining battery charge for each vehicle and the current location of each vehicle. It may also comprise information on the ambient temperature (obtained from the vehicle temperature sensor), battery temperature, information on the last time the vehicle battery was charged, and how the vehicle battery was charged (e.g. trickle-charged over several hours, or fast-charged).

The driver ID or other identification information is used to identify the data within the backend control system, to extract vehicle/driver history data from a data store for each vehicle, and to enable the journey scheduling system to contact the correct vehicle/driver computing device when a vehicle is selected to perform a journey.

The second data 302b is vehicle/driver history data, and may include one or more of the following types of data: battery age/degradation, battery charge history, vehicle tyre type, vehicle tyre pressure, vehicle tyre make/model, driver driving style (e.g. whether the driver repeatedly accelerates quickly and brakes hard, which is less fuel-efficient, or if the driver has a smoother, gentler driving style, which is more fuel-efficient), and vehicle condition (e.g. time since the last vehicle safety test, repair status, vehicle age, etc.).

The algorithm may use the first data 302a and second data 302b to calculate the predicted vehicle range for each vehicle. Optionally, the algorithm may use third data obtained from external data sources to improve the accuracy of the calculation. The third data 302c may include one or more of the following types of data: environmental conditions (e.g. the current weather conditions at each vehicle's current location, which may affect how much fuel is used by the vehicle), the terrain type at and near to the vehicle's current location, and current traffic conditions in the vicinity of each vehicle.

The weather data may be obtained from weather service providers, such as the Met Office website, via the internet. The current traffic conditions may be obtained from a traffic monitoring service provider. In embodiments, the traffic data may be obtained from bus stops that display real-time bus information or from bus operators with real-time bus information, as the movement of buses in a particular area/along particular routes can be used to determine if a route is congested or not.

The range prediction algorithm 304 receives inputs 302a, 302b and optionally 302c for each vehicle, and calculates the predicted range for each vehicle in the fleet. The variable which most directly influences the predicted range for each vehicle is the remaining battery charge of each vehicle, and is accordingly given more weight in the algorithm.

The output 306 of the range prediction algorithm is the predicted ranges which are sent to the journey scheduling system to determine which vehicle is most suitable for performing the requested journey.

Fig. 4 is a flow chart of the steps taken to process a vehicle request using the system of Fig. 2. The process begins when a customer sends a request for a vehicle to a taxi service via a phone call or mobile booking 'app' (step S400). The request is received by the journey scheduling system of the electric taxi service scheduling system (step S402), and in order to determine which vehicle should be sent to the customer, the journey scheduling system requests up-to-date vehicle range information (step S404). As mentioned above, in embodiments the journey request receiving module of the journey scheduling system is configured to receive the customer request and requests the up-to-date information from the journey scheduling module.

The journey scheduling system (or the journey scheduling module) transmits a request for vehicle range data to the monitoring system (S404). The monitoring system requires at least battery charge data/vehicle range data from the vehicles themselves in order to provide the required up-to-date (real-time) range information.

As mentioned above, the monitoring system performs at least two functions: obtaining a vehicle range based on the battery charge state of each vehicle (also referred to herein as the 'simple vehicle range'); and calculating a more accurate predicted vehicle range based on the battery charge state and one or more additional variables. In the latter case, the monitoring system runs a vehicle range prediction algorithm to calculate predicted ranges for each vehicle in the vehicle fleet.

To obtain the 'simple vehicle range' based on the battery charge state of each vehicle alone, the monitoring system obtains battery charge data and/or vehicle range data from the driver computing device 46 in each vehicle. In embodiments, the monitoring system 60 requests data from the driver computing devices 46 within each vehicle (step S406) either when requested to provide up-to-date information to the journey scheduling system 68, or automatically on a regular basis (e.g. every minute or every few minutes). A driver computing device receives the request from the monitoring system and polls the in-vehicle device (step S408) to obtain the requested data. The in-vehicle device collates data on the battery charge/vehicle range via the OBD port of the vehicle (step S410) and transmits this to the driver computing device via short range communication (e.g. Bluetooth (RTM)). The driver computing device obtains data from the in-vehicle device and transmits it to the monitoring system (step 5412) over the internet or via a mobile network.

Additionally or alternatively, the monitoring system may automatically receive battery charge data and/or vehicle range data from the driver computing devices at frequent and regular intervals. For example, each driver computing device may be configured to transmit data to the monitoring system every minute or every few minutes. The monitoring system stores the data received from each driver computing device in a data store, and when required to provide the journey scheduling system with up-to-date vehicle range information, the monitoring system can retrieve the data from the data store. In this embodiment, the monitoring system does not need to request data and steps S406 to S412 may be omitted.

If the monitoring system receives vehicle range data from each driver computing device, it forwards the vehicle range data directly to the journey scheduling system (step S418). If the monitoring system obtains battery charge data from the driver computing devices, the monitoring system calculates the vehicle range from the battery charge data for each vehicle, and then forwards the calculated vehicle range to the journey scheduling system (step S418).

If the monitoring system is configured to calculate a more accurate predicted vehicle range, the monitoring system runs a vehicle range prediction algorithm to calculate predicted ranges for each vehicle in the fleet. The algorithm takes as an input the battery charge data and/or vehicle range data from the driver computing device, and additional data such as current weather conditions, current traffic conditions, terrain type along the requested journey, etc. (step S414). The data is input into the algorithm and used to calculate a predicted range for each vehicle (step S416). The predicted vehicle ranges are provided by the monitoring system to the journey scheduling system (step S418).

The journey scheduling system receives either the 'simple vehicle range' or the more accurate predicted vehicle range and uses this to select a vehicle for the requested user journey (step S420). The journey scheduling system then transmits journey data to the selected vehicle (step S422), containing for example, the customer's collection address and destination. The driver computing device in the selected vehicle is configured to receive the journey data (step S424).

The journey scheduling system is also configured to transmit confirmation data to the customer (step S426) which includes a confirmation of the taxi request, and may include details identifying the selected vehicle and the expected arrival time of the vehicle. The customer receives the confirmation data (step S428) via the mobile booking app on their phone, via SMS, or otherwise.

Fig. 5 is a flow chart of the steps taken by the monitoring system to calculate predicted vehicle ranges. The monitoring system receives raw vehicle data from a plurality of vehicles (step S500). The monitoring system extracts first data on the vehicle from the received raw data (step S502). The first data comprises the battery charge state and/or vehicle range, and may include one or more of driver ID, vehicle ID, and vehicle location (GPS location). The extracted first data is saved in a data store (step S504).

The monitoring system obtains second data from a system server or data store (step S506). The second data is vehicle/driver history data, and may include one or more of the following types of data: battery age/degradation, battery charge history, vehicle tyre type, vehicle tyre pressure, vehicle tyre make/model, driver driving style (e.g. whether the driver repeatedly accelerates quickly and brakes hard, which is less fuel-efficient, or if the driver has a smoother, gentler driving style, which is more fuel-efficient), and vehicle condition (e.g. time since the last vehicle safety test, repair status, vehicle age, etc.).

Optionally, the monitoring system obtains third data on external conditions (step S508) and may include one or more of the following types of data: environmental conditions (e.g. the current weather conditions at each vehicle's current location, which may affect how much fuel is used by the vehicle), the terrain type at and near to the vehicle's current location, and current traffic conditions in the vicinity of each vehicle. The weather data may be obtained from weather service providers, such as the Met Office website, via the internet. The current traffic conditions may be obtained from a traffic monitoring service provider. In embodiments, the traffic data may be obtained from bus stops that display real-time bus information or from bus operators with real-time bus information, as the movement of buses in a particular area/along particular routes can be used to determine if a route is congested or not. The obtained third data is saved in a data store (step S510).

Some types of third data may not need to be obtained from an external source each time the vehicle range prediction algorithm is implemented. For example, if the monitoring system identifies from the first data that a vehicle is in the same location as a vehicle was earlier in the day, then it may not be necessary to determine the terrain type again for that location. Similarly, if two or more journeys need to be scheduled in the same area and are requested within a short time of each other, then the weather conditions are likely to be the same for each journey. It may be sufficient to obtain the weather data from an external source for one of the journeys and from the data store for the other journey, which may improve the efficiency of the algorithm and of the overall electric taxi service scheduling system.

The monitoring system calculates the predicted vehicle ranges based on the first and second data, and optionally on the third data, using the range prediction algorithm (step S512). The predicted vehicle ranges are transmitted to the journey scheduling system (step S514).

Optionally, the monitoring system may monitor the vehicle selected to perform a journey to determine how much charge it has left after completing the journey and/or before it is next re-charged (step S516). If the predicted vehicle range substantially matches the actual distance covered by the vehicle before it was re-charged (or is within, e.g. +/-5%, +/-10% of the actual distance), then the algorithm is not changed. However, if the predicted vehicle range is significantly different to the actual distance covered by the vehicle, then the algorithm may need to be updated (step S518). For example, a particular data type may need to be accorded a higher or lower weighting factor to improve the accuracy of the algorithm.

Fig. 6 is a flow chart of the steps taken to obtain vehicle data from a vehicle. When a taxi driver gets into his electric vehicle and starts the engine, the monitoring app on his driver computing device (e.g. mobile phone) is initiated (step S600). The monitoring app is configured to enable the device to receive data from the in-vehicle device installed in his vehicle, to convert the data into a useable form (optional) and to transmit the data to the backend control system. The monitoring app may be configured to turn-on/activate as soon as the driver computing device is determined to be in the vehicle (e.g. when it is in communication range from the in-vehicle device). Additionally or alternatively, the driver may need to turn-on the monitoring app when he begins his shift. The monitoring app on the driver computing device transmits identification information and the current time to the backend control system (step S602) so that it is aware that the vehicle is part of the existing, available fleet of taxi vehicles. The monitoring app on the driver computing device is configured to receive raw vehicle data from the in-vehicle device (step S604), either automatically or on request. The in-vehicle device extracts data from an engine control unit in the vehicle (via the OBD port) and transmits the raw data to the driver computing device (step S606) via Bluetooth (RTM) or wireless, short range communication. The driver computing device combines the received raw vehicle data with device data (e.g. the phone number or other identifying data) (step S608) and then transmits the combined raw data to the backend control system (step 610).

In embodiments where the driver computing device automatically sends up-to-date raw vehicle data to the backend control system at regular intervals, the driver computing device checks whether the engine is still on (step S612). If the engine is still on, the driver computing device is configured to obtain and transmit the vehicle data again. If the engine is off, the driver computing device is configured to stop transmitting data (step S614).

Fig. 7 is an example flow chart showing how the vehicle range prediction algorithm can be updated using, for example, historical vehicle data. The vehicle range prediction algorithm will preferably evolve over time, to provide a more accurate algorithm. The vehicle range prediction algorithm may comprise multiple algorithms (or sub-algorithms) such that, for example, there is a specific algorithm for each electric car manufacturer (e.g. Nissan, Tesla), or each electric vehicle type (e.g. Nissan Leaf, Tesla Model S, Renault Zoe, BMW i3, etc), or each electric vehicle model (e.g. Nissan 2013 Leaf, Nissan 2014 Leaf, etc). Thus, the vehicle range prediction algorithm which performs a range calculation for a specific vehicle is selected by the monitoring system to ensure the correct algorithm is used for the vehicle (based on, for example, vehicle identification information).

Thus, in order to update the vehicle range prediction algorithm, the first step (S700) involves obtaining the stored algorithm for vehicle type X (or vehicle model or manufacturer). The function to convert the battery state of charge to a vehicle range for the vehicle type X is extracted from the stored algorithm (step S702). When the system is first used, this function may be a default function set for all vehicle types/models/manufacturers, and may not therefore, be accurate. However, over time, and by using historical data, the function for each specific vehicle type can be improved.

For vehicle type X, the historical data for the vehicle type is obtained from a data store (step S704). Preferably, the vehicle scheduling system above stores historical vehicle data for each vehicle. The historical vehicle data may comprise, for each journey performed by the vehicle, one or more of: * the battery state of charge at the start of each journey performed by the vehicle, * optionally the battery state of charge at the end of each journey, * the predicted range for the vehicle based on the range battery state of charge (as calculated by the range prediction algorithm), * the actual range covered by the vehicle for each journey (using, for example, data obtained from the vehicle odometer, or from a GPS router, or otherwise), * the range covered by the vehicle between having a 100% charged battery and a 0% charged battery, or between any other charge states, * the range covered by the vehicle between having a 100% charged battery and a 0% charged battery, or between any other charge states, with known additional weight on-board the vehicle (e.g. passengers, luggage, courier packages, delivery items, etc).

This historical data can be used to extract the actual vehicle ranges achieved per battery state of charge for vehicles of type X (step S706). This can be used to determine the 'actual' function for vehicle type X between battery state of charge and vehicle range (step S708). The function may depend on other variables, such as the weight of the vehicle, the vehicle's performance in different weather conditions or at different temperatures, the vehicle/battery age, etc, and these variables may be included in the 'actual' function.

Before the algorithm is updated, it is desirable to check if the 'actual' function matches the current function for vehicle type X (step 3710). If the functions already match, the algorithm for vehicle type X is accurate, and the process ends. If the functions do not match, the algorithm for vehicle type X is modified to replace the current function with the newly determined 'actual' function (step 3712), and the updated algorithm is stored and used to perform all future vehicle range calculations.

The algorithm updating process may be 'local', i.e. performed for individual vehicles, or it may be 'global', i.e. performed for all vehicles of a particular type / model / manufacturer / etc. The algorithm may be updated at regular intervals, e.g. every month, every few months, every six months, etc, or after a particular number of journeys have been completed, e.g. every 100 journeys, every 500 journeys, every 1000 journeys, etc. The first data (and second data) collected from the vehicles may be used for other purposes instead of, or in addition to, scheduling vehicles for a taxi service/courier service. For example, the collected data may be used to determine the performance of each vehicle and to schedule maintenance reminders. Modern vehicles comprise sensors located at multiple points on the exterior and interior of the vehicle, and the system may be configured to obtain sensor data from each sensor in addition to battery state of charge data. Thus, the system can determine from the sensor data whether there is a fault, or a fault is imminent, and can schedule maintenance for the vehicle accordingly. Similarly, the sensor data may be used to provide accurate, time-stamped information regarding a fault which arises as a result of an accident (e.g. vehicle collision).

The system may also be configured to store journey data for journeys travelled by each vehicle in the vehicle fleet. The journey data may include the routes travelled by each vehicle, the time of day each route was travelled, the time taken to complete the route, the average speed of the vehicle along the route, etc. This journey data may be used to determine the 'characteristics' of particular popular routes, e.g. between London Stansted Airport and Cambridge, or between Cambridge train station and the city centre. The characteristics may note for example, whether a particular route is congested at certain times of day, such that the journey scheduling module can determine how long a requested journey will actually take so that the most appropriate vehicle is chosen for the journey (i.e. one with sufficient battery charge to complete the journey at that time of day).

No doubt many other effective alternatives will occur to the skilled person. It will be understood that the invention is not limited to the described embodiments and encompasses modifications apparent to those skilled in the art lying within the spirit and scope of the claims appended hereto.

Claims

CLAIMS: 1. An electric vehicle scheduling system comprising: a plurality of electric vehicles; at least one first computing device, wherein the first computing device is associated with the plurality of electric vehicles and is configured to retrieve first data from the electric vehicles, wherein the first data comprises battery state of charge data; and a control system comprising: a monitoring system comprising at least one data store, and at least one processor configured to: receive the retrieved first data from the first computing device associated with the plurality of electric vehicles; store the received first data in the at least one data store; and determine, using a range prediction algorithm, a vehicle range for each vehicle from the first data; a journey scheduling system comprising at least one processor configured to: receive a journey request for a vehicle from a customer; receive the determined vehicle range for each vehicle from the monitoring system; and select one of the plurality of electric vehicles to perform the requested journey using the determined vehicle range for each vehicle.
2. The electric vehicle scheduling system as claimed in claim 1 wherein the at least one data store stores second data comprising vehicle data associated with the electric vehicles, and wherein the at least one processor of the monitoring system is further configured to: retrieve the second data for each vehicle from the at least one data store; combine the first data and the second data for each vehicle; and determine, using the range prediction algorithm, a vehicle range for each vehicle from the combined first data and second data.
3. The electric vehicle scheduling system as claimed in claim 2 wherein the monitoring system further comprises a communication module, and wherein the at least one processor of the monitoring system is further configured to: retrieve third data from third party data providers via the communication module; combine the first data and the second data for each vehicle with the third data; and determine, using the range prediction algorithm, a vehicle range for each vehicle from the combined first data, second data and third data.
4. The electric vehicle scheduling system as claimed in any preceding claim wherein the first computing device associated with the electric vehicles comprises: a communication module to enable communication with the monitoring system; and a processor configured to: automatically receive the first data at a predefined interval while the electric vehicles are running; and automatically transmit the retrieved first data to the monitoring system via the communication module at the predefined interval.
5. The electric vehicle scheduling system as claimed in any one of claims 1 to 4 wherein the at least one first computing device is a remote server located remote to the plurality of electric vehicles, and the first computing device is configured to receive first data from all or a subset of the plurality of electric vehicles.
6. The electric vehicle scheduling system as claimed in any one of claims 1 to 4 wherein each of the at least one first computing device is on-board each of the plurality of electric vehicles, and wherein the first computing device comprises a connection to couple the device to a digital communications port of the electric vehicle to receive first data from the electric vehicle.
7. The electric vehicle scheduling system as claimed in claim 6 the first computing device processor is further configured to: activate the first computing device when the electric vehicle motor is determined to be running; and automatically retrieve the first data from the electric vehicle via the digital communications port at a predefined interval while the electric vehicle is running.
8. The electric vehicle scheduling system as claimed in claim 6 or 7 further comprising at least one second computing device associated with each electric vehicle, wherein the second computing device comprises: a communication module to enable communication with the first computing device and the monitoring system; and a processor configured to: receive the first data from the electric vehicle via the communication module; combine the received first data with data identifying the second computing device; and transmit the combined data to the monitoring system via the communication module.
9. The electric vehicle scheduling system as claimed in claim 8 wherein the second computing device processor is further configured to request first data from the first computing device at a predefined interval.
10. The electric vehicle scheduling system as claimed in claim 8 or 9 wherein the second computing device processor is further configured to determine if the electric vehicle motor is running, and request first data from the first computing device at a predefined interval while the motor is running.
11. The electric vehicle scheduling system as claimed in any one of claims 4, 9, or 10 wherein the predefined interval is any one of: one minute, two minutes, five minutes, or ten minutes.
12. The electric vehicle scheduling system as claimed in any preceding claim wherein the journey scheduling system further comprises: at least one data store for storing received journey requests; a journey request receiving module configured to: receive the journey request for a vehicle from a customer; and store the received journey request in the at least one data store; and a journey scheduling module configured to: receive a received journey request from the journey request receiving module; request a determined vehicle range for each vehicle from the monitoring system; select one of the plurality of electric vehicles to perform the requested journey using the determined vehicle range for each vehicle; send a message to the selected electric vehicle to perform the requested journey; and send a confirmation message to the customer.
13. The electric vehicle scheduling system as claimed in any preceding claim wherein the monitoring system is further configured to update the range prediction algorithm for a subset of the plurality of vehicles, by: obtaining a function to convert the first data to the vehicle range from the range prediction algorithm; obtaining historical data for the subset of vehicles; extracting, from the historical data, true vehicle ranges achieved by the subset of vehicles as a function of battery state of charge; determining a new function to convert the first data to the vehicle range, using the extracted true vehicle ranges; and updating the range prediction algorithm to use the determined new function.
14. An electric vehicle scheduling method for a vehicle service provider having a plurality of electric vehicles, the method comprising: receiving a journey request for a vehicle from a customer; receiving first data from each electric vehicle, wherein the first data comprises battery state of charge data and data identifying the vehicle; determining, using a range prediction algorithm, a vehicle range from the first data for each vehicle; and selecting one of the plurality of electric vehicles to perform the requested journey using the determined vehicle range for each vehicle.
15. The electric vehicle scheduling method as claimed in claim 14 further comprising: retrieving, from a data store, second data for each vehicle, wherein the second data comprises vehicle data for each electric vehicle; combining the first data and the second data for each vehicle; and determining, using the range prediction algorithm, a vehicle range for each vehicle from the combined first data and second data.
16. The electric vehicle scheduling method as claimed in claim 15 further comprising: retrieving third data from third party data providers; combining the first data and the second data for each vehicle with the third data; and determining, using the range prediction algorithm, a vehicle range for each vehicle from the combined first data, second data and third data.
17. The electric vehicle scheduling method as claimed in any one of claims 14 to 16 wherein the method further comprises: sending a message to the selected electric vehicle to perform the requested journey; and sending a confirmation message to the customer.
18. The electric vehicle scheduling method as claimed in any one of claims 14 to 17 wherein the method further comprises: comparing the determined vehicle range for each vehicle to an actual vehicle range obtained by each vehicle; and updating the range prediction algorithm if the determined vehicle range is substantially different to the actual vehicle range for each vehicle.
19. The electric vehicle scheduling method as claimed in any one of claims 14 to 18 wherein the method further comprises updating the range prediction algorithm for a subset of the plurality of vehicles, by: obtaining a function to convert the first data to the vehicle range from the range prediction algorithm; obtaining historical data for the subset of vehicles; extracting, from the historical data, true vehicle ranges achieved by the subset of vehicles as a function of battery state of charge; determining a new function to convert the first data to the vehicle range, using the extracted true vehicle ranges; and updating the range prediction algorithm to use the determined new function.
20. A non-transitory data carrier carrying processor control code which when running on a processor, causes the processor to implement the method of any one of claims 14 to 19.
21. An in-vehicle computing device for an electric vehicle scheduling system, the in-vehicle computing device comprising: a connection to couple the in-vehicle computing device to a digital communications port in the electric vehicle; and a processor configured to: activate the first computing device when the electric vehicle is determined to be running; automatically retrieve battery state of charge data from the electric vehicle via the digital communications port at a predefined interval while the electric vehicle motor is running; and automatically provide the retrieved first data to the electric vehicle scheduling system at the predefined interval.
22. An electric vehicle scheduling system substantially as hereinbefore described with reference to Fig. 1 or 2.
23. An electric vehicle scheduling method substantially as hereinbefore described with reference to Fig. 3, 4, 5, or 6.