With the release of ServiceScheduling 11.1, the system has been updated to now support three different levels of travel time estimates. These levels are:

Travel Matrix
- An initial estimate of travel time between locations is based on an expected travel time lookup from a Travel Matrix file. While not as accurate as the P2P or RTT travel time estimates (see below), the Travel Matrix estimate is very fast to obtain, which allows appointment offers and initial schedule optimization to be performed quickly.
Point to Point (P2P)
- A more accurate estimate of travel time between locations, based on an expected "point to point" travel time lookup. When enabled, P2P estimates are used to refine the schedule layout during optimization, once a specific point to point travel time estimate has been obtained and cached for the relevant FRU.
Real Time Travel (RTT)
- The most accurate estimate of travel time between locations, based on an expected "real time" travel time lookup, which takes into account the specific journey and the specific real time traffic conditions for that journey. When enabled, RTT estimates are used to refine the schedule layout when a job's start travel time comes into a defined look-ahead window of time.

This page describes how these three levels work, and their configuration in ServiceScheduling, in more detail.

On This Page:

Related Pages:

Install ServiceOptimizer Deploying ServiceOptimizer Installing the Travel Matrix

Job Location

In order for travel time estimates to work, the location of jobs needs to be available to ServiceScheduling. This can happen in one of two ways:

When a job is booked with a valid address code (either a Zip Code, Post Code or other ServiceScheduling supported address code), then the ServiceScheduling travel time estimate system will translate the address code into a Latitude/Longitude Pair (LLP), using internal conversion tables which will be set up during the installation of ServiceScheduling by a ServicePower Consultant.
- The travel time estimate system will use an exact address code to LLP translation if possible, otherwise, where an LLP is not known for the exact address, the LLP of the address code region will be used.
Otherwise, if no valid address code can be supplied, then the job must be booked with specific Latitude and Longitude values.

Travel Matrix

Travel Matrix File

The initial estimate of travel time between locations is generated from a Travel Matrix file.

The Travel Matrix file used for this defined by the sp083_system_parameters database table's travel_matrix system parameter, which references the Travel Matrix file supplied with ServiceScheduling, covering your particular geography.

See Install ServiceOptimizer Deploying ServiceOptimizer Installing the Travel Matrix for further details on setting up the Travel Matrix.

Region to Region vs. Same Region Travel Time Estimates

Travel Matrix based initial estimates of travel time are categorized in one of two ways:

Where the two locations are in different regions, this is known as a "region to region" travel time estimate.
Where the two locations are both in the same region, this is known as a "same region" travel time estimate.

This categorization is relevant in terms of modifying or overriding Travel Matrix based estimates, as per the "Modifying Travel Time Estimates" and "Overriding Travel Matrix Time Estimates" sections below.

Modifying Travel Time Estimates

When desired, it is possible to modify initial Travel Matrix estimates of travel time via the use of the following sp083_system_parameters database table parameters.

Parameter	Description
`travel_overhead`	A fixed addition of time (in minutes) for all travel values used in the system.
`travel_multiplier`	A multiplier for all "region to region" travel values.
`internal_travel_multiplier`	A multiplier for all "same region" travel values.

The values of these parameters are used to modify travel time estimates as described below.

Description	Formula
"Region to region" travel time estimates	`(value_from_matrix_file + travel_overhead) * travel_multiplier`
"Same region" travel time estimates	`((sp083_system_parameters.same_postcode_travel * internal_travel_multiplier) + travel_overhead) * travel_multiplier`

Modified travel time estimates using the above formulas are not used when the travel time estimate is obtained from a user-defined override of the Travel Matrix estimate (see "Overriding Travel Matrix Time Estimates" below).

This is because it is assumed that where a specific override value is provided for a travel time estimate, this estimate has been estimated as desired, and so travel overhead and multiplier values should not be applied.

Overriding Travel Matrix Travel Time Estimates

Where found to be necessary, it is possible to override either the estimated travel times or the journey type (profile) for any journey using ServiceManager. Modifications to travel times and profiles do not update the Travel Matrix itself, but update fields in the ServiceScheduling database.

This approach is taken so that:

User specified Travel Matrix travel time estimate overrides are retained whenever the Travel Matrix file itself is re-issued to incorporate updates; and
If a problem arises, it is easier to trace whether there is an error in ServicePower supplied Travel Matrix file or in user supplied travel time estimate overrides.

Overriding "Region to Region" Travel Time Estimates

A Travel Matrix "region to region" travel time estimate can be overridden for any pair of regions by adding a value to the sp014_travel_overrides database table travel_time field, where the columns region_no1 and region_no2 reference the relevant two regions.

Similarly, the travel profile for can be overridden for any pair of regions by adding a value to the sp014_travel_overrides database table travel_profile field, where the columns region_no1 and region_no2 reference the relevant two regions.

Overriding "Same Region" Travel Time Estimates

A Travel Matrix "same region" travel time estimate can be overridden for any region by adding a value to the sp057_regions database table internal_travel_time field for the record corresponding to the relevant region.

Similarly, the travel profile can be overridden for any region by adding a value to the sp057_regions database table sp057_regions.internal_journey_type field for the record corresponding to the relevant region.

Please note that overriding travel time estimate values for the same region are only used when the value is less than the default value.

Same region travel time estimates that are greater than or equal to the default value will not be used.

Point to Point (P2P)

When enabled, the more accurate "point to point" estimate of travel time between locations is generated by Here Maps. A license to use Here Maps will need to be set up by ServicePower Consultants.

The use of RJServer for Point to Point travel time estimates is no longer supported.

When a job is scheduled, the FRU's P2P cache file is checked for a point-to-point travel time estimate between the two location LLP values.
1. If a P2P travel time estimate for the two specific location LLP values exists in the cache file, then this P2P travel time estimate value is used.
2. If a P2P travel time estimate for the two specific location LLP values does not exist in the cache file, then:
  1. The standard "region to region" travel time estimate from the Travel Matrix is used (see above); and
  2. A request is made to the configured P2P travel time server to get the P2P travel time estimate. When a reply is received, the FRU's P2P cache file is updated. Consequently, on the next re-layout of the schedule, the P2P travel time estimate will be used.

The FRU's P2P cache file is a continually growing file, as more and more "point to point" travel time estimates stored. One file is created per FRU, and the times for each specific journey are never re-evaluated - currently the only way to force that is to delete the file.

Configuring Point to Point Travel Time Estimates

To enable the P2P travel time system, the following system parameters need to be set up by ServicePower Consultants for the customer. They can either be set globally in the sp083_system_parameters database table, or for specific FRUs in the sp213_scheduler_parameters database table, where indicated as being FRU level configurable.

Parameter	Description	FRU Level Configurable?
`postcode_tm_lookup`	Enable/disable the P2P travel time estimate system. Valid values: `0`: Disabled `1`: Enabled	Yes
`postcode_matrix_directory`	The directory/folder where FRU P2P cache files will be created. The directory/folder must exist. P2P cache files will be created as `<FRU name>.tm2`. Must be set if the P2P travel time estimate system has been configured (at any level).	No
`postcode_tm_server`	The name of a Here Maps server that will be queried for P2P time travel estimates, corresponding to a configured server name in the `sp245_id_configuration` table. Must be set either globally or for all FRUs where the P2P time travel estimate system has been enabled.	Yes
`postcode_tm_scan_interval`	The number of seconds between the start of each run of the P2P updater thread to check for required P2P travel time estimates. Has an initial value of 20 seconds. Must be set either globally or for all FRUs where the P2P time travel estimate system has been enabled.	Yes
`postcode_tm_server_trigger_level`	The number of P2P travel time estimate requests which are required to trigger a scan by the P2P updater thread. Has an initial value of 0, and a maximum permitted value of 2000. Must be set either globally or for all FRUs where the P2P time travel estimate system has been enabled.	Yes
`postcode_retry_count`	The number of times a query to the P2P server will be retried on failure. Must be set either globally or for all FRUs where the P2P time travel estimate system has been enabled. The same value is also used for RTT query retries, when the RTT time travel estimate system has been enabled.	Yes

For users upgrading from versions prior to ServiceScheduling 11.1, please note that the rjs_retry_count parameter has replaced by the postcode_retry_count parameter. The rjs_retry_count parameter is no longer required.

Real Time Travel (RTT)

When enabled, the most accurate "real time travel" estimate of travel time between locations is generated by Here Maps. A license to use Here Maps will need to be set up by ServicePower Consultants.

When the start travel time of an Earmarked or Contacted job comes within the RTT update lead time from the current time, it is selected for RTT time retrieval - unless it has already had its RTT Travel Time set, or is a No Travel job.
A request is made to the RTT travel time server for the current travel time estimate between the two location LLP values.
If the request is successful, the RTT Travel Time for the job is set.

If the RTT Travel Time is set on a job, it will be used as the travel time.

Additionally, the RTT Travel Home will be set up for the last job of a technician's day when the job is set to Logged Off or Cleared.

Configuring Real Time Travel Time Estimates

To enable the RTT travel time system, the following system parameters need to be set up by ServicePower Consultants for the customer. They can either be set globally in the sp083_system_parameters database vale, or for specific FRUs in the sp213_optimizer database table, where indicated as being FRU level configurable.

Parameter	Description	FRU Level Configurable?
`postcode_rtt_lookup`	Enable/disable the RTT travel time estimate system. Valid values: `0`: Disabled `1`: Enabled	Yes
`postcode_rtt_server`	The name of a Here Maps server that will be queried for RTT time travel estimates, corresponding to a configured server name in the `sp245_id_configuration` table. Must be set either globally or for all FRUs where the RTT time travel estimate system has been enabled.	Yes
`postcode_rtt_scan_interval`	The number of seconds between the start of each run of the RTT updater thread to check for required RTT travel time estimates. Has an initial value of 20 seconds. Must be set either globally or for all FRUs where the RTT time travel estimate system has been enabled.	Yes
`postcode_rtt_update_lead`	A job will be eligible for selection for RTT set up when its start time (start of travel) gets within the range of `now` to `(now + postcode_rtt_update_lead)`. This has an initial value of 900 seconds (15 minutes). Must be set either globally or for all FRUs where the RTT time travel estimate system has been enabled.	Yes
`postcode_retry_count`	The number of times a query to the RTT server will be retried on failure. Must be set either globally or for all FRUs where the RTT time travel estimate system has been enabled. The same value is also used for P2P query retries, when the P2P time travel estimate system has been enabled.	Yes

Unsetting RTT Travel Time Values

Jobs that have an RTT Travel Time set will have this value unset under the following conditions:

When a job is moved - either for the same technician or between technicians - such that it has a different start time.
When a job changes in any way that results in it becoming un-earmarked.
When a job is manually un-earmarked.
When a job is deallocated
When the job's start location changes e.g. another job is inserted before the job.

Actual Travel Time

In all cases, when a job actually starts and moves to the Logged On status, the travel time for the job will be set to the actual travel time taken, regardless of the source of the time travel estimate that was in place at the time for the job.

Browser not supported