Methods and Systems of Assigning Trips to Vehicles

Abstract

A method of assigning a trip to a vehicle within a fleet of vehicles that traverse a navigable network in a geographic area is disclosed, where each of the vehicles in the fleet is equipped with one or more electronic devices for logging the activities of one or more drivers associated with the vehicle and for determining the location of the vehicle in the geographic area. For each one of one or more vehicles of the fleet of vehicles, location of interest data and log data is obtained in respect of the vehicle. A time budget for the vehicle is determined using the obtained log data, the time budget representing the amount of time that the vehicle can be legally operated by the one or more drivers associated with the vehicle within a given time period starting from a time of interest. The obtained location of interest and determined time budget for the vehicle are used to determine a boundary enclosing a portion of the geographic area representing an area that is reachable by the vehicle by traversing the navigable network from the location of interest within the determined time budget for the vehicle. Data indicative of at least the determined boundary and the location of interest upon which the boundary is based is provided to a display device of the dispatcher for display thereon.

Claims

1-20. (canceled)

21. A fleet management system for assigning trips to at least one vehicle within a fleet of vehicles that traverse a navigable network in a geographic area, the system comprising: an electronic device provided in each vehicle within the fleet of vehicles, each electronic device configured to transmit energy data indicative of an actual or estimated energy level of the vehicle, and each electronic device further comprising a position sensor configured to determine the location of the vehicle in the geographic area; one or more server devices configured, for each one of one or more vehicles of the fleet of vehicles, to: obtain a location of interest associated with the vehicle via any one or more of a determined location of the vehicle via the position sensor, an input via a dispatcher device functionally linked to the one or more server devices, and receipt of data corresponding to a new job to be assigned to a vehicle; determine a current energy level for the vehicle based on the energy data transmitted from the electronic device; dynamically calculate, using at least the obtained location of interest and the determined current energy level for the vehicle, real-time boundary data indicative of a dynamic boundary enclosing a portion of the geographic area that is currently reachable by the vehicle by traversing the navigable network, from the location of interest, within a calculated real-time energy budget for the vehicle; wherein the dynamic boundary is calculated by exploring segments of an electronic map representative of navigable elements of the navigable network from a position on a segment representative of the location of interest in respect of the vehicle using a search algorithm having an associated cost function.

22. The fleet management system of claim 21, one or more server devices are further configured, for each one of one or more vehicles of the fleet of vehicles, to generate respective information to a device associated with the vehicle, the respective information to be displayed comprising at least navigation instructions corresponding to a trip assigned to the vehicle based at least in part on the calculated dynamic boundary for the vehicle.

23. The fleet management system of claim 21, wherein the dispatcher device further comprises a display, and wherein the one or more servers are configured to generate information to the dispatcher device for displaying, for each one of the one or more vehicles of the fleet of vehicles, at least the respective calculated dynamic boundary and the location of interest upon which the boundary is based on a representation of at least a portion of the navigable network by displaying and updating an electronic map.

24. The fleet management system of claim 21, wherein the one or more servers are configured to receive data from the dispatcher device selecting the trips to be assigned to the at least one of the vehicles and comprising at least a location associated with each trip.

25. The fleet management system of claim 21, wherein the one or more server devices are configured to dynamically calculate the real-time boundary data further accounting for one or more predetermined margins for error as respective proportions of the energy budget to define dynamic boundaries corresponding to each of the one or more margins for error using at least the obtained location of interest and the determined current energy level for the vehicle.

26. The fleet management system of claim 21, wherein the one or more server devices are further configured, for the each one of the one or more vehicles of the fleet of vehicles, to: obtain vehicle profile data indicative of at least one property of the vehicle; and dynamically calculate the real-time boundary data further based on the obtained vehicle profile data.

27. The fleet management system of claim 26, wherein the at least one property is selected from a group consisting of: a vehicle type; at least one dimension of the vehicle; at least one weight of the vehicle; emissions information for the vehicle; and information identifying any hazardous materials carried by the vehicle.

28. The fleet management system of claim 21, wherein the one or more server devices are configured to use the vehicle profile to identify one or more segments of the electronic map representative of navigable elements that should not and/or could not be traversed by the vehicle.

29. The fleet management system of claim 21, wherein the one or more server devices are further configured to: obtain data indicative of live conditions on the navigable network; and dynamically calculate the real-time boundary data further based on the obtained data indicative of the live conditions.

30. The fleet management system of claim 29, wherein the live conditions comprise live traffic conditions and/or live road conditions.

31. The fleet management system of claim 21, wherein the one or more server devices are further configured to: obtain historical data indicative of historical traversal times for various segments of the navigable network; and dynamically calculate the real-time boundary data further based on the obtained historical data.

32. The fleet management system of claim 21, wherein the one or more server devices are further configured to: obtain data indicative of a driving behaviour of the one or more drivers associated with the vehicle; and dynamically calculate the real-time boundary data further based on the obtained data indicative of the driving behaviour.

33. The fleet management system of claim 21, wherein the one or more server devices are further configured to: receive job data indicative of one or more parameters for a new job; and identify a subset of the fleet of vehicles which are available to perform the new job, based at least in part on a respective temporal and/or spatial proximity for each of the subset of the fleet of vehicles relative to a location of the new job.

34. The fleet management system of claim 21, wherein the one or more server devices are further configured to: obtain existing job data indicative of jobs assigned to respective vehicles in the fleet of vehicles; wherein the existing job data comprises, for each vehicle having a job assigned thereto, data indicative of the or each job assigned to the vehicle and comprising at least the location of the job; and use the data in determining the respective location of interest; wherein the assigned job data further comprises a duration of the or each job; and wherein, where multiple jobs are assigned to a vehicle, the assigned job data comprises an ordered list of jobs.

35. The fleet management system of claim 21, wherein the one or more server devices are further configured to: use the obtained data indicative of jobs assigned to the vehicles to determine whether the vehicle already has one or more jobs assigned thereto; and when the vehicle does not have a job assigned thereto, to use the current location as the location of interest, and, when the vehicle has one or more jobs assigned thereto, to use the assigned job data for the vehicle to determine the location of interest.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

[0145] Embodiments of the invention will now be described, by way of example only, with reference to the accompanying Figures, in which;

[0146] FIG. 1A is a flow chart illustrating one embodiment of a method for assigning a new job to a vehicle in accordance with the invention;

[0147] FIG. 1B is a flow chart illustrating one embodiment of a method for assigning a rest stop to a vehicle in accordance with the invention;

[0148] FIG. 2 illustrates a set of boundaries and reachable areas determined in respect of a vehicle;

[0149] FIG. 3 illustrates sets of overlapping reachable areas determined in respect of five vehicles;

[0150] FIG. 4 illustrates the change in the boundaries and reachable areas of FIG. 3 when one of the vehicles is no longer available;

[0151] FIG. 5 illustrates a further example of boundaries and reachable areas determined in respect of five vehicles;

[0152] FIG. 6 illustrates the effect on the boundaries and reachable areas determined in FIG. 5 when one vehicle is no longer available;

[0153] and FIG. 7 illustrates one example of a system which may be used to implement e methods described herein.

DETAILED DESCRIPTION OF THE FIGURES

[0154] Embodiments of the present invention are described with reference to road segments. It should be realised that the invention may also be applicable to other navigable segments, such as segments of a path, river, canal, cycle path, tow path, railway line, or the like. For ease of reference these are commonly referred to as a road segment.

[0155] The present invention provides a method which is used in the context of a fleet management system.

[0156] When managing a vehicle fleet, one particularly important factor to take into account when assigning rest stops or new jobs is the remaining driving time for the vehicles. The remaining driving time is the remaining permissible time that a vehicle may legally be operated before a regulated stop is required. A vehicle in a fleet may be operated by a single driver, in which case the remaining driving time for the vehicle will correspond to that for the driver, or by multiple drivers, in which case the remaining driving time for the vehicle will be based upon the remaining driving times for each of the drivers. The remaining driving time for a driver will be dictated by applicable regulations. Vehicles in a fleet are equipped with one or more electronic devices for logging data indicative of the activities of the one or more drivers of the vehicle, and which may be used to determine a remaining driving time for the vehicle from a current time in a predefined period. For example, vehicles operating in Europe are equipped with a digital tachograph to ensure compliance with the drivers' working hours regulation EC 561/2006. Similarly, vehicles operating in the US are equipped with an electronic logging device (ELD) to ensure compliance with the hours of service (HOS) rules.

[0157] Compliance with driving time regulations is of great importance to a fleet dispatcher, and potential fines for violating rules or regulations are high. The Applicant has realised that existing FMS (fleet management systems) fail to enable a dispatcher to readily and reliably take remaining driving time into consideration e.g. when assigning new jobs or rest stops to vehicles. This is a particular problem when planning a response e.g. reassigning jobs in response to unplanned events. Such events may require a fleet dispatcher to make estimates of which vehicles are best suited for a new job considering the remaining driving time available to each vehicle, and other factors, including a distance of the vehicle to the location associated with the new job etc. Planning responses to unplanned events becomes even more complex in the case of considering more than one vehicle of a fleet at a time. The need to take remaining driving time into consideration adds another layer of complexity when responding to dynamic changes when performing fleet operational planning.

[0158] Existing FMS may result in a dispatcher failing to adequately consider remaining driving time, which may result in sub-optimal planning and assignment of jobs to vehicles, inability to provide accurate information to third parties e.g. regarding arrival times of vehicles at jobs, or even failure to comply with driving time regulations.

[0159] A Fleet Management System (FMS) is an industry term used to refer to a broad range of solutions for vehicle-related applications that help companies manage their fleets of vehicles, such as cars, vans, trucks and buses. A fleet management system (FMS) may be provided by a combination of vehicle-based technology (e.g. telematics devices, positioning systems) and Software-as-a-Service (SaaS). An FMS may be intended to help a fleet dispatcher to improve overall fleet efficiency and vehicle performance, e.g. save fuel, improve driver safety, aid risk management, enhance job-dispatching etc. An FMS may help a fleet dispatcher to manage the use of vehicles e.g. the assignment of routes and destinations, and may also help with the management of vehicle drivers, and destinations. This may be of assistance where vehicles in the fleet pick up or deliver goods at a multiple destinations, perform a service operation at several destinations, etc. The FMS dispatcher has a need to manage the cost of operating a fleet.

[0160] Typically, the management of fleet operations e.g. the assignment of duties, is performed by a human dispatcher with assistance from various planning tools, including an FMS. These tools may be used to generate a vehicle travel plan, which may then be provided to the FMS. However, inaccuracies in vehicle plans commonly occur due to dynamic changes caused by unforeseen circumstances, e.g. additional work, accidents, road closures, car breakdowns, sickness, customer cancellations, etc. The fleet dispatcher must update vehicle plans to try to compensate for these unplanned events e.g. by redistributing assignments to the current set of operating vehicles and drivers. Given the complexity of such tasks, although remaining driving time may be available to the dispatcher via some system, it is difficult to take this into account together with other factors, and dispatchers may simply ignore remaining driving time when managing operations, particularly when making changes in response to unplanned events.

[0161] Embodiments of the present invention provide methods for determining a reachable area for a vehicle of a fleet based on a time budget, which takes into account remaining driving time for the vehicle. The invention provides information regarding the reachable area to a dispatcher in a manner which enables the dispatcher to more readily take the information into account when assigning trips e.g. to new jobs or rest stops to vehicles.

[0162] The invention may be implemented by means of a server running FMS software. The server is in communication with a remote device of a fleet dispatcher e.g. tablet, desktop, mobile etc. running a FMS application.

[0163] The server obtains data over a wireless communication network from each vehicle in a fleet of vehicles from devices associated with the vehicle e.g. telematics devices. Alternatively, it is envisaged that the devices associated with the vehicles may send data to the device of the fleet dispatcher running the FMS application, which may then communicate with the server to provide the data thereto as required.

[0164] The fleet dispatcher uses the FMS to update vehicle plans e.g. the assignment of jobs or rest stops, etc. The FMS system sends the updated vehicle plan(s) to the relevant vehicle devices. The fleet dispatcher may make updates via their own device, which may then cause the updates to be sent out to the devices (typically via the server).

[0165] An embodiment of the method of the invention will be described by reference to the flow chart of FIG. 1A. In the embodiment described this method is implemented by a server, although this need not necessarily the case. For example, the method may be implemented by a device associated with a fleet dispatcher, or some steps may be performed by a server, and some by the dispatcher's device, or the method may be performed using more than one server, or any other suitable arrangement may be used as discussed further below.

[0166] FIG. 1A illustrates an embodiment of the present invention used to assign a new job to a vehicle from a fleet of vehicles traversing a navigable network in a geographic area. Each vehicle is equipped with one or more electronic devices for logging the activities of one or more drivers associated with the vehicle and for determining the location of the vehicle In the geographic area. For example, the vehicle may include a positioning device such as a GNSS or GSM positioning device for providing location data. The log data and location data may be provided to the server via a telematics control unit associated with the vehicle. The one or more electronic devices for logging the activities of the one or more drivers may comprise a tachograph or electronic logging device, or similar. The log data provided by the one or more electronic devices may be used to determine a remaining driving time for the vehicle from a current time in a predefined period (based on the remaining driving time for the or each driver of the vehicle). One example of a telematics control unit which may be used to provide location and vehicle log data to the server from the one or more electronic devices associated with the vehicle is a TomTom® LINK device. The location data may, in some embodiments, be obtained from an electronic device of a positioning system of the telematics control unit. However, it will be appreciated that it is not necessary to use a telematics control unit, and data may be provided directly to the server from the one or more electronic devices. Whether or not a telematics control unit is used, it will be appreciated that the log data and location data may be provided by the same or different electronic devices, and any one of the electronic devices may or may not be integrated with the vehicle.

[0167] FIG. 7 illustrates one exemplary system which may be used to implement the methods described herein.

[0168] In step 1 a server receives log data and location data from each vehicle e.g. over an appropriate cellular communication channel. Each vehicle in the fleet is associated with a vehicle ID.

[0169] The server also has access to job data indicative of existing jobs assigned to each vehicle in the fleet of vehicles. Each job is associated with a location i.e. a job location. For each vehicle, the server has access to details of each job assigned thereto (if any). Where multiple jobs have been assigned to a vehicle, the job data will include an ordered list of the jobs. Each job may also be associated with a predicted job duration.

[0170] In step 2 a new job to be assigned to a vehicle in the fleet of vehicles is received by the server. The job is associated with a location. The job may also be associated with a desired start time, which may be immediately.

[0171] In step 3 the server may perform art initial filtering step to identify a subset of the vehicles that are potentially most suitable to perform the job. This step is optional. The way in which the filtering is performed may depend upon the particular context of the method. For example, the filtering step may identify those vehicles available to perform the new job, and/or that are within a certain distance or travel time of the location associated with the job. The travel time or distance may be set by reference to a desired start time of a job. A closest vehicle in terms of distance/time might already be performing a job, or travelling to an existing job. Thus, availability may be considered in combination with spatial and/or temporal proximity. In one exemplary arrangement, in which the method is used to assign jobs to emergency or first response vehicles, those vehicles which are available and/or can reach the location of the new job by the desired start time, or within a certain time period thereafter may be identified. It will be appreciated that identifying, vehicles within a certain spatial and/or temporal proximity to the location of the new job may be performed using appropriate routing calculations. The server may perform calls on an appropriate routing service when performing this step.

[0172] In other embodiments, the dispatcher may indicate the subset of vehicles to be considered.

[0173] The server then performs a method of generating information for the dispatcher to facilitate the assignment of the new job to a vehicle from the fleet of vehicles. This method is performed in relation to at least some i.e. one or more of the vehicles. The vehicles may be a subset as identified in step 3 or e.g. as indicated by the dispatcher.

[0174] The following steps are performed in relation to the or each vehicle considered. in step 4, a location of interest is determined in respect of the vehicle. The location of interest is a location relevant to determining a reachable area for the vehicle taking into account remaining driving time. The location of interest may he a current location or a future location. Thus the location of interest may correspond to, or be obtained using the location data for the vehicle and/or the location of any jobs assigned to the vehicle as provided by the job data.

[0175] The relevant location will depend upon the context in which the method is performed, and potentially the job status of the vehicle. For example, where a vehicle is available, the current location may be used. Where a vehicle is currently performing a job, and no subsequent job has been assigned, the current location may similarly be used. Where a vehicle is heading to a job, and that job is the only job allocated to the vehicle, the location of that job may be used. If the vehicle has multiple jobs assigned (within an applicable time window), the location of interest may be the location of the final job allocated to the vehicle. In general, the location of interest will be the location from which the vehicle may set out in order to reach the new job.

[0176] In step 5, log data indicative of the activities of the one or more drivers associated with the vehicle is obtained by the server e.g. via a telematics control unit of the vehicle. This log data includes data which may be used to determine a remaining driving time for the vehicle from a current time in a predefined period. The remaining driving time from a current time in a predetermined period is the remaining time that the vehicle may continue to be operated by the driver or drivers associated therewith from a current time in the predefined period. The remaining driving time data may he determined in any suitable manner based on log data received from the vehicle. Where a vehicle is a multi-driver vehicle, determining of the remaining driving time for the vehicle may involve an intermediate step of determining remaining driving time data for the individual drivers, or a suitable function may be used which may directly determine the remaining driving time for the vehicle based on the log data for the individual drivers.

[0177] Determination of the remaining driving time for a vehicle based on the log data may be performed by the or a server based on the log data. For example, this may be performed by a suitable module of a FMS system. The log data may be indicative of changes in work state of the driver(s) of the vehicle e.g. between resting, driving, on standby, and performing other work states. Each driver will he legally required to conform to a specific set of rules defining their resting and working periods. These rules will depend upon factors such as country of operation, type of vehicle driven, type of work undertaken, specific labour agreements etc. Each vehicle and driver in the system may be treated as separate entity by the FMS system. The specific set of rules that a driver must operate under may be configured as an attribute to the driver entity. For example, an FMS operator may be able to assign rule sets from a drop down list. The FMS system may then continually update a remaining driving tune for a driver based upon real-time vehicle log data. For any driver in the system, a remaining driving time from a current time in any predefined period may thus be determined. Where a vehicle is operated by more than one driver, a remaining driving time for the vehicle entity from a current time in a predefined period may be determined directly or indirectly based on the log data, the rules governing the operation of each driver, and the rules governing multi-driver operation. This remaining driving time for the vehicle may be determined based on the individual remaining driving times for the drivers from the current time in the predefined period, or may be determined directly from the log data without necessarily determining such intermediate data. Thus, a remaining driving time for the vehicle from the current time in a predefined period may also be known at any time. A remaining driving time may be determined in respect of any suitable period from the current time. The FMS system may be arranged to provide a remaining driving time for a vehicle and/or driver of the system in respect of a predefined period which is preset e.g. a period until the next break is required, or which may be customised e.g. by dispatcher specifying the period. The applicable remaining driving time for determining the time budget may therefore be provided by specifying a predefined period corresponding to the given time period upon which the time budget is based, and requesting the remaining driving time for the vehicle from the FMS system.

[0178] In step 7 a time budget for the vehicle is obtained using the log data. The time budget represents the amount of time that the vehicle can be legally operated by the one or more drivers associated with the vehicle within a given time period starting from a time of interest.

[0179] The time of interest may be a current time or a future time, and is the relevant time upon which a reachable area for the vehicle is to be based. As with the location of interest, the relevant time of interest for a vehicle may depend upon various factors, including the context of the method, and jobs already assigned to a vehicle. For example, where a vehicle is available for a new job, the current time may be used. Where a vehicle is currently performing a job, then the predicted time at which the job is due to be completed may be used as the time of interest (which may be obtained based upon the expected duration of the job). Where a vehicle is heading to a job, the time of interest may similarly be the predicted time at which the job is due to be completed (which may be obtained based upon the expected travel time to the job and the expected duration of the job). If a vehicle has multiple jobs assigned to it, then the time of interest may be based upon the predicted time at which the final job is due to be completed (e.g. based on the expected durations of each job and the expected travel time between jobs). Generally the time of interest will be the time at which the vehicle is available to leave the location of interest to set out for the new job.

[0180] The time budget is determined using a remaining driving time for the vehicle from a current time in a predefined period corresponding to the given period to which the time budget relates, and which may be obtained in the manner described above. Some adjustment of this remaining driving time may be required where the time of interest is not a current time. The time budget is in relation to a given period starting from the time of interest. The period might be e.g. a 24 hr or 2 hour period, or even a weekly or two weekly period. The period may be specified e.g. by a dispatcher or set by the system, depending upon the relevant period for a particular application or context. The given time period effectively sets a time window of interest, and may be e.g. in the context of assigning jobs to emergency vehicles, a desired response time.

[0181] Where a single driver is associated with the vehicle, the time budget for the vehicle will be based on the remaining driving time from the current time for the driver in the given period, while, where multiple drivers are associated with the vehicle, the time budget will be based on the remaining driving times for each driver from the current time in the given period (which may be a simple sum thereof, or, depending upon relevant regulations, may be less than the sum of the remaining driving times for each driver e.g. where non-driving working time acts to reduce the remaining driving time of a driver). The remaining driving time from the current time in the given period will take into account legal requirements in relation to breaks etc. Depending upon the period selected, the remaining driving time may be made up of one or more continuous period of driving (e.g. where the given period is sufficiently long that it includes one or more mandatory rest periods).

[0182] The remaining driving time for a driver (or vehicle) may be obtained directly or indirectly using the log data. The remaining driving time or the time budget for a vehicle may be provided by a different server to that which performs the other steps of the method e.g. by the server performing the method requesting a remaining driving time or time budget for a vehicle, from the server, which may then perform any necessary processing of remaining driving time log data received from the vehicle. For example, the server may provide a vehicle ID, given time period to be considered and, where applicable, the start time of interest for the time budget to be determined to another server, e.g. a remaining driving time service providing server, which may then provide the required time budget for the vehicle.

[0183] Determining the time budget also takes into account the job data. By way of example, where a vehicle is available, or is performing an existing job, the time budget for a single driver vehicle may be correspond to the current remaining driving time for the driver (or, for a multiple driver vehicle, will be based upon the remaining driving time for each driver). Where a vehicle is travelling to an existing job, the time budget may be based upon the current remaining driving time for the driver or drivers minus the expected time to travel to the existing job. Thus, some calculation may be required to determine a time budget using the remaining driving time for a vehicle starting from a time of interest where this is not the current time, since the remaining driving time is typically based on a current time.

[0184] In step 8, the determined time budget is used together with the location of interest to determine boundary data indicative of a boundary enclosing a portion of the geographic area representing an area that is reachable by the vehicle by traversing the navigable network from the location of interest within the determined time budget for the vehicle. In other words, a boundary defining a reachable area for the vehicle is determined. This is performed by exploring segments of an electronic map representative of navigable elements of the navigable network from a position on a segment representative of the location of interest using a search algorithm having an associated cost function. The cost function may be selected or determined based upon information provided e.g. by the dispatcher as to the type of route required e.g. “fastest” or “eco” i.e. most fuel or energy efficient. Various techniques which may be used in determining a reachability area for a vehicle based upon one or more constraints are described in WO 2014/001565A1, in the name of TomTom Development Germany GMBH, the entire content of which is incorporated herein by reference.

[0185] It will he appreciated that, in addition to the time budget, other factors limiting the reachable area for a vehicle may be taken into account when determining the boundary e.g. energy, such as fuel or electricity budgets where these may further limit the reachable range. These may be based on a current energy level e.g. fuel or charge level, which could be an actual measured or estimated level. Such data may be obtained from any suitable source.

[0186] The determination of the boundary may also take into account vehicle profile data. Such data may be available to the server. Vehicle profile data may include data identifying a vehicle type, together with other attributes such as vehicle length, width, height, axle weight and overall weight, hazardous material loads etc. Such data may be taken into account by influencing the costs associated with segments of the electronic map, such that segments which the vehicle is unable to, or should not traverse, are associated with higher cost. Vehicle profiles and their use by a routing engine are described in WO 2017/032816A1 of TomTom Navigation B.V an TomTom Telematics B.V, the entire content of which is incorporated herein by reference.

[0187] The boundary may be determined based upon the entire time budget, or a proportion thereof i.e. to define a reachable area corresponding to the portion of the geographic area reachable using the entire time budget or a proportion thereof e.g. 95%. Determining the boundary based upon less than the entire time budget may provide some margin for error. In some embodiments, the dispatcher may indicate the proportion of the time budget to be used.

[0188] In step 9 data indicative: of the determined boundary and the location of interest upon which it is based is provided to a display device of the fleet dispatcher, and displayed thereon, superposed on a representation of at least a portion of the navigable network.

[0189] The dispatcher is thus provided with an indication, for each vehicle being considered, of the area which it is expected to be able to reach from the location of interest without contravening a time budget for the vehicle representing the amount of time that the vehicle may be legally operated by the driver(s) thereof. The dispatcher is provided with a clear indication, for each vehicle, of the area which may be reached by the vehicle within the time period being considered without contravening regulations. The dispatcher may compare the reachable areas for each vehicle and use these to determine to which vehicle to assign the new job.

[0190] In step 10 the server receives an indication from the dispatcher as to which vehicle the new job is to be assigned. The indication includes at least the location associated with the new job. The system may then take any desired steps to assign the job to the vehicle e.g. by providing routing information to the vehicle for travel to the location associated with the job.

[0191] In accordance with a second embodiment, described by reference to the flow chart of FIG. 1B, the method is used to assign a rest stop to a vehicle. This method is similar to that previously described by reference to FIG. 1A, and only the difference will be described in detail.

[0192] In step 20 a server receives log data and location data from each vehicle e.g. over an appropriate cellular communication channel.

[0193] As in the previous embodiment the server also has access to job data indicative of jobs assigned to each vehicle in the fleet of vehicles.

[0194] The server then performs a method of generating information for the dispatcher to facilitate the assignment of a rest stop to a vehicle from the fleet of vehicles. This method is performed in relation to at least some i.e. one or more of the vehicles. The method of this embodiment may typically be performed in relation to a single vehicle, but could also be performed in relation to a subset of vehicles from the fleet in proximity to a particular location. Such a subset may be identified using an appropriate filtering step based on vehicle location. The location considered might be e.g. a location of a possible rest stop.

[0195] The following steps are performed in relation to the or each vehicle considered.

[0196] In step 22, a location of interest is determined in respect of the vehicle. The location of interest is a location relevant to determining a reachable area for the vehicle taking into account remaining driving time. The location of interest may be a current location or a future location. Thus the location of interest may correspond to, or be obtained using the location data for the vehicle and/or the location of any jobs assigned to the vehicle as provided by the job data. Where the vehicle is available, the location may be a current location, while, where a vehicle, is currently performing a job, the location may be the location of the job. Where multiple jobs are assigned to the vehicle, the location may be the location of the final job.

[0197] In step 24, log data for the vehicle is obtained by the server e.g. via a telematics control unit of the vehicle. This log data includes data which may be used to determine a remaining driving time for the vehicle. The remaining driving time is the remaining time that the vehicle may continue to be operated by the driver or drivers associated with from a current time.

[0198] In step 26 a time budget for the vehicle is obtained using the log data. The time budget represents the amount of time that the vehicle can be legally operated by the one or more drivers associated with the vehicle until a rest stop is required starting from a time of interest.

[0199] The time of interest may be a current time or a future time, and is the relevant time upon which a reachable area for the vehicle is to be based. Generally the time of interest will be the time at which the vehicle is available to leave the location of interest to travel to a rest stop. Thus, the time of interest may be a time at which a (final) job assigned to the vehicle is expected to be completed, or, it no job is assigned thereto, the current time.

[0200] The time budget is determined as described in relation to the previous embodiment, but this time is in respect of a given period from the start time of interest corresponding to the remaining driving time for the vehicle until a rest stop is required. Such remaining driving time may be obtained based upon the log data from the vehicle as previously described. Of course, it is envisaged that, as described in relation to the earlier embodiment, the determination of remaining driving time data for a vehicle and/or the time budget, may be performed by another server, upon request by the server performing the other steps of the method, in the same manner described in relation to FIG. 1A.

[0201] In step 23, the determined time budget is used together with the location of interest to determine boundary data indicative of a boundary enclosing a portion of the geographic area representing an area that is reachable by the vehicle by traversing the navigable network from the location of interest within the determined time budget for the vehicle. This may be performed in the same manner as described in relation to the earlier embodiment, and may take into account other constraints e.g. energy budget. The boundary may be based upon using the entire time budget, or a proportion thereof, as described in relation to the earlier embodiment.

[0202] In step 30 data indicative of the (or each) determined boundary and the location of interest upon which it is based is provided to a display device of the fleet dispatcher, and displayed thereon.

[0203] In step 32, the locations of possible rest stops are also displayed to the dispatcher on the display device.

[0204] The dispatcher is thus provided with an indication, for each vehicle being considered which it may be able to reach from the location of interest without contravening a time budget for the vehicle representing the amount of time that the vehicle may be legally operated by the driver(s) thereof before a rest stop is required. The dispatcher is provided with a clear indication, for each vehicle, of the area which may be reached by the vehicle before a rest stop is required. The dispatcher may compare the reachable areas for each vehicle to the locations of the possible rest stops and use these to assign a rest stop to the vehicle(s).

[0205] In step 34 the server receives an indication from the dispatcher assigning a rest stop to the vehicle. The indication includes at least the location of the rest stop. The system may then take any desired steps to direct the vehicle to the rest stop e.g. by providing routing information to the vehicle for travel to the location associated with the rest stop.

[0206] In any of the embodiments of the invention, the electronic map data comprises segments connected by nodes, and the segments are indicative of the road elements of the road network.

[0207] The reachable area is determined in a manner which takes into account the road network. Thus, it is recognised that the distance a vehicle may travel in different directions from the location of interest subject to the time budget may differ, depending upon the properties of the elements of the navigable network, current conditions etc.

[0208] The methods of the invention may take into account live conditions on the road network. This may be achieved, in embodiments, by adjusting traversal times for segments, or other costs associated with segments used in determining the boundary of the reachable area, to reflect current conditions. The conditions may include traffic and/or road conditions as exemplified below. Furthermore, the cost values used in exploring segments of the electronic map in obtaining the boundary may be time dependent e.g. based on typical traffic conditions at different times of day. Thus, applicable cost values may be used to obtain an accurate reachable area applicable to the relevant time. Historical data indicative of applicable costs e.g. traversal times to traverse for segments at different times may be obtained and used.

[0209] The list below shows examples of the data that may be available to the system e.g. server or servers performing the method, and used in determining a boundary representing a reachable area (or other aspects of the methods, e.g. determining a time or location of interest and/or time budget) in any of the embodiments of the invention. The data may be determined by the server e.g. based on vehicle log data or other data obtained from one or more electronic devices e.g. via a TCU associated with a vehicle, and/or may be obtained from other sources e.g. from another server, which may also receive data from the electronic device(s) associated with vehicles and perform processing thereon to provide suitable data e.g. remaining driving time data: [0210] Current location—this may be obtained from e.g. a GNSS device associated with a vehicle over a cellular communications channel, e.g. via a telematics control unit (TCU) of the vehicle. [0211] Energy budget. Each vehicle in the fleet has a current remaining amount of energy for powering the vehicle. The determination of the boundary may take into account a current remaining energy level of the vehicle, which may act as a further constraint to the reachable area in addition to the time budget. An energy budget may be determined. Energy level data may be obtained from electronic device(s) e.g. a telematics control unit associated with a vehicle. This may be actual measured energy level data or predicted energy level data, depending upon the level of integration of a telematics control unit or other device(s) with the vehicle. Alternatively or additionally, historic data on the energy needed for a vehicle to traverse road segments e.g. under various traffic and road conditions may be used in determining the boundary. This may be used e.g. in determining a cost for traversing a segment relating to energy budget and used in exploring segments of the electronic map to determine the boundary where the search algorithm is based on a cost function taking into account energy consumption, e.g. where an “eco” route has been selected. [0212] Driving time. Each driver has a remaining driving time in a given period starting from a current time in which they may legally drive a vehicle. Real-time remaining driving time data for the driver(s) of a vehicle from a current time may be provided based on data obtained from an interface to a tachograph, and is used in determining the time budget. Remaining driving time for a vehicle in a given period may be determined based on the remaining driving time for the driver(s) of a vehicle. Such data may be determined by a server, which may or may not be the server performing the methods of assigning a trip to a vehicle described herein. The remaining driving time data may be obtained e.g. from a suitable remaining driving time service provided by another server e.g. based on inputting a vehicle or driver ID, and time period of interest. [0213] Driver efficiency. Some drivers have a more economical driving profile and can travel a longer distance for a given vehicle and time budget. Historical data may be obtained by the FMS software in any suitable manner, and used to improve the accuracy of the boundary determinations taking into account differences between individual drivers. This may be done e.g. by adjusting cost values determined for segments, or in any other suitable manner. [0214] Traffic conditions. The FMS software may comprise an interface to one or more navigation systems that collect real time traffic information to estimate congestion. Congestion and road parameters determine the time necessary to travel a road segment. [0215] Road conditions. The FMS software may comprise an interface to a component that provides real time road network information e.g. road closures, partial road closures, accidents, weather impact on roads. The road condition information impacts available routes and travel times. [0216] Traffic regulations. A country may have specific regulations restricting driving without special permit e.g. on Sunday or during holidays for specific vehicle types. [0217] Vehicle profile data—data indicative of a vehicle type, together with attributes such as vehicle length, width, height, axle weight and overall weight, hazardous material loads etc. may be available, and can be used in determining the boundary e.g. in exploring segments of the electronic map. [0218] Job data—for each vehicle, an ordered list of each job already assigned to the vehicle, including, for each job, a job location, and predicted job duration.

[0219] In general, at least the remaining driving time and current location for vehicles is known, and the other data may enhance the accuracy of boundary determination.

[0220] It will be appreciated that the methods described herein may be implemented in various manners, using one or more servers and/or devices associated with a dispatcher.

[0221] In the exemplary embodiments described, the methods described herein may be implemented using a FMS. A fleet dispatcher may use a web browser in their device (e.g. PC or mobile device) to interact with a server running the FMS software. However, other arrangements may be used. For example, the boundary data may be determined using an application run by a device of the dispatcher e.g. PC or mobile device. in either case, some of the above information (e.g. map data, traffic data, road closure information) may need to be obtained from other sources. For example, a map service provider may provide map and traffic data.

[0222] Wherever the boundary data and location of interest for a vehicle are determined, they may be displayed on a device of the dispatcher, e.g. a PC or mobile device. The device may then receive the Er information regarding boundary and location of interest the server. For example, a server may make its data available to an application running on the device, or instead may enable a user to interact therewith using a web browser.

[0223] Some exemplary embodiments of boundaries and reachable areas which may be determined in accordance with the invention in its various embodiments, and displayed to a dispatcher, will now be described.

[0224] it will be appreciated that one or more boundary may be determined in respect of a given vehicle. This may be used in embodiments for assigning a new job or a rest stop to a vehicle. Obtaining boundaries based upon using a given amount of the time budget e.g. the entire budget or substantially the entire time budget, and one or more lesser amounts of the time budget may help to increase the margin for error, and enable a dispatcher to assign a new job or rest stop with a desired level of security. Rather than using multiple boundaries, of course, a safety margin may be obtained instead by providing a single boundary based upon an appropriate proportion of the time budget e.g. 90 or 95% as desired.

[0225] FIG. 2 illustrates a method in which multiple boundaries and hence reachable areas are obtained for a vehicle having a current location 12, based on using different amounts of the time budget for the vehicle. FIG. 2 illustrates a representation of the reachable areas with respect to an electronic map which may be displayed to the dispatcher to assist them in assigning a rest stop or new job to a vehicle in accordance with the methods described herein. Of course, rather than a current location, the location may be a location of a (final) existing assigned job for the vehicle.

[0226] In FIG. 2, two reachable areas 20, 30 are shown inside the reachable area 8. The outermost reachable area 8 having a boundary (perimeter) 10 is obtained based on using the entire time budget. A second reachable area 20, having a boundary (perimeter) 22 is then determined based on using 75% of the time budget. A third reachable area 30 having a boundary (perimeter) 32 is determined based on using 50% of the time budget.

[0227] The areas defined between the boundaries of each reachable area may each be shaded a different colour as shown in FIG. 2. In this example, the area (inner darkest grey area) defined within the innermost boundary 32 represents the reachable area with up to 50% of the time budget, the area (middle area shaded mid-grey) between the boundary 32 of this reachable area and the boundary 22 of the next outer reachable area 20 represents the reachable area with from 50-75% of the time budget. The outermost area (shaded lightest grey) defined between the boundary 22 of the reachable area 20 and the boundary 10 of the outermost reachable area 8 corresponds to the area reachable using 75-100% of the time budget.

[0228] FIG. 2 illustrates the way in which multiple reachable areas may be displayed in respect of a single vehicle. Of course, rather than displaying multiple reachable areas based on using different amounts of the time budget, a single reachable area might instead be displayed, preferably incorporating a suitable margin for error. This type of embodiment using a single vehicle might be particularly applicable to assigning a rest stop to the vehicle. The locations of rest stops may be displayed on the map, and the dispatcher may specify in any suitable manner e.g. through interaction with the display which rest stop should be assigned to the vehicle. Of course, where a plurality of vehicles e.g. a subset of vehicles are to be considered, one or more reachable area may be displayed in a similar manner as shown in FIG. 2 for each vehicle, based on the location of interest e.g. current location or location of a final existing job in respect of the vehicle. Where the method is being used to assign a new job to a vehicle, reachable area(s) may be displayed for a subset of vehicles corresponding to those which are available for a new job and/or which are within a given distance or travel time of a location of a new job. Regardless of the application of the method e.g. for assigning a new job or a rest stop, the location of interest may be a current location for each vehicle, or a future location e of a final existing job. Where the location is a future location, the time of interest upon which the time budget is based will typically be a future time e.g. a time at which the vehicle may be available to leave the location.

[0229] FIG. 3 illustrates a situation in which there are five emergency vehicles having current locations within the area covered by the map, vehicles 42, 43, 44, 45 and 46. In this context, the reachable areas for each vehicle are based on a current location and the time budget is based on a current time. Each vehicle shown is available for a new assignment. The vehicles may be a subset of a fleet of vehicles which are expected to be able to reach the location associated with a new job by a desired start time of the job, or within a predetermined period thereafter.

[0230] For each vehicle, a set of boundaries is determined, each indicative of a reachable area, based on first, second and third amounts of the time budget for the vehicle. These boundaries may be based upon different amounts of the time budget as illustrated in FIG. 2 above e.g. 50%, 75%, and 100% of the time budget. The inner, middle and outer reachable areas defined by the boundaries obtained for each vehicle are shaded darkest grey, mid-grey and lightest grey, as in the FIG. 2 example.

[0231] As shown in FIG. 3, some of the reachable areas defined by the boundaries in respect of corresponding amounts of the time budget overlap for the different vehicles, i.e. the inner, middle or outer reachable areas associated with different ones of the vehicles may overlap. In this situation, a boundary defining a single, combined reachable area is obtained. The boundary encompasses the combined area defined by the corresponding overlapping reachable areas. In the example of FIG. 3, the innermost reachable areas for vehicles 44-46 overlap in this way, and a boundary 52 defining a single, combined inner reachable area 50 is defined. It will be seen that boundaries indicative of combined “inner”, “middle” and “outer” areas are obtained for the set of vehicles, with the combined inner, middle and outer areas having the usual darkest, mid and light grey shading. The resulting display enables the dispatcher to readily assign a new job to one of the emergency vehicles based on the location of the job, and a consideration of which vehicle may reach the location most easily within the time budget thereof.

[0232] As a further example, FIG. 4 shows the same map area with five vehicles, of which one vehicle, vehicle 44 is now not available for another job. Boundary and reachable area data is not determined for this vehicle i.e. it is not included in the subset of vehicles considered. Boundary and reachable area data based on using 50%, 75% and 100% of the time budget for the vehicle is determined for the other four vehicles, and, where there is overlap between corresponding reachable areas for different vehicles, a boundary defining a single combined area is determined as in the FIG. 3 case. The overall pattern of reachable areas provided for the vehicles is different to that in the FIG. 3 case.

[0233] FIGS. 5 and 6 are similar to FIGS. 3 and 4, but this time based on a larger time budget based on a longer given period from the current time, set by a longer target response time. The outermost boundary for each vehicle is based on using 100% of this time budget, and the middle and inner boundaries for each vehicle being set at 75% and 50% thereof. FIG. 5 illustrates the case where all five vehicles 60, 61, 62, 63, 64 are available, and FIG. 6 the case where only 4 are available (60, 61, 62, 63).

[0234] In both cases, boundaries defining combined reachable areas based on the boundaries of the corresponding reachable areas for each vehicle have been determined. As the time budget is larger (20 minutes in FIGS. 5 and 6), each corresponding reachable area is larger too. In the Figures, which illustrate the view which may be displayed to a dispatcher, the dark grey, mid grey and light grey shaded areas correspond to using a fraction of the time budget (0-50%, 50-75% and 75-100% respectively).

[0235] Based on the representations shown in FIGS. 3 and 4 or 5 and 6, which may be displayed to the dispatcher on their display device, the fleet dispatcher can make a more informed decision to assign a new job to a vehicle taking into account remaining driving time of the vehicle. In an example, the dispatcher may assign an emergency vehicle to a reported incident requiring assistance.

[0236] The invention may, in embodiments at least, increase overall accuracy of the information used by a fleet dispatcher and reduce manual planning effort to enable the amount of time that a vehicle can be legally operated by the driver(s) associated with the vehicle to be taken into account.

[0237] Determination and display of boundaries and reachable area(s) for vehicles may be triggered in response to a command from a dispatcher, or, for example, by the receipt of a new job to be assigned to a vehicle.

[0238] The invention may, in embodiments, enable a dispatcher to make better decisions for handling unplanned events without contravening time budgets for vehicles based on remaining driving time. Usage of accurate reachable area information leads more informed ad-hoc planning decisions and impacts the cost of operating a vehicle fleet in a positive way.

[0239] A system which may be used to implement embodiments of the invention is exemplified by FIG. 7. The vehicle can include: a tachograph; a telematics control unit (TCU); and a navigation device (which is an optional component). The TCU can he arranged to communicate with a server, which in turn is arranged to communicate with the navigation device in the vehicle and a computer of a dispatcher e.g. at a fleet management location. While the system the system shows three distinct devices in the vehicle: the tachograph, the TCU and the navigation device, it will be appreciated that the vehicular components of the system can be shared between a greater number or a fewer number of devices as desired. Similarly, while FIG. 7 shows data being transmitted to the server only from the TCU, in other embodiments data can be sent to the server from any of the vehicular devices as desired.

[0240] The functionality of each of the components shown in FIG. 7 will now be described in more detail.

[0241] Tachograph: The digital tachograph (or other electronic logging device) records driver activity as log data. The log data is data which may be used to determine a remaining driving time for the vehicle in a predefined period from a current time. The tachograph delivers the log data to the TCU.

[0242] TCU: The TCU comprises a position determining device, such as a global navigation satellite system (GNSS) receiver, e.g. GPS or GLONASS. It will be appreciated, however, that other means may be used, such as using the mobile telecommunications network, surface beacons or the like. The positioning determining device generates tracking data, such as time-stamped positions, indicative of the change in position of the device over time. The tracking device further comprises one or more communication devices that are arranged to communicate with the tachograph, the navigation device and the server, either using a wired or wireless connection. The one or more communication devices can comprise a short range wireless transceiver, such as a Bluetooth transceiver, e.g. for communicating with the tachograph and the navigation device, and can comprise a mobile telecommunications transceiver, such as a GPRS or GSM transceiver, e.g. for communicating with the server. One example of a suitable TCU is a TomTom® LINK device as described herein.

[0243] Navigation device: The navigation device comprises at least one processor and a display device. The navigation device may be capable of one or more of: calculating a route to be travelled to a desired destination and providing navigation instructions to guide the driver along a calculated route to reach a desired destination.

[0244] Server: The server comprises at least one processor and a communications device for communicating with one of more of the vehicular devices, preferably the TCU, and is arranged to perform the methods described herein to generate data indicative of a boundary and location of interest based on log data and position data received from the TCU and/or tachograph.

[0245] Computer: The computer is in communication with the server, and is used by a dispatcher to perform fleet management operations, including the assignment of trips to vehicles as described herein. The boundary and location of interest data is displayed on the computer device to the dispatcher.

[0246] All of the features disclosed in this specification (including any accompanying claims, abstract and drawings), and/or all of the steps of any method or process so disclosed, may be combined in any combination, except combinations where at least some of such features and/or steps are mutually exclusive.

[0247] Each feature disclosed in this specification (including any accompanying claims, abstract and drawings), may be replaced by alternative features serving the same, equivalent or similar purpose, unless expressly stated otherwise. Thus, unless expressly stated otherwise, each feature disclosed is one example only of a generic series of equivalent or similar features.

[0248] The invention is not restricted to the details of any foregoing embodiments. The invention extends to any novel one, or any novel combination, of the features disclosed in this specification (including any accompanying claims, abstract and drawings), or to any novel one, or any novel combination, of the steps of any method or process so disclosed. The claims should not be construed to cover merely the foregoing embodiments, but also any embodiments which fall within the scope of the claims.