Print-friendly page

How does the logixcentral vehicle scheduling optimiser work?
What maps are available?
Can the software use postcodes?
How are unloading times calculated?
How does it handle 'rush hour' speeds?
Can logixcentral be used for logistics strategy?
Can logixcentral deal with multi-depot vehicle scheduling?
Can logixcentral handle trunking and backloading?
In what format does logixcentral import data?
What happens when I sign up for logixcentral?
What happens if the auto scheduler doesn't work?

How does the logixcentral vehicle scheduling optimiser work?

The logixcentral vehicle scheduling optimiser is a very sophisticated program and we can not give a complete account of all the interactions that can occur during any given run. However, we will attempt to outline the principles behind its operation and to define some key terms. In order to provide some structure to this section we will first explain what is going on at each stage of the program's execution before going on to consider why such a process is needed and how it is actually performed.

logixcentral actually consists of two programs: an initialisation program which 'sets up data files' and the algorithm itself. When you go into Auto LogiX you are in the initialisation program, and it is only when you 'press the Go button' that you load the algorithm.

Having restructured the data, the software checks for a vehicle scheduling matrix. logixcentral uses its own vehicle scheduling matrix file ALMAPQ.DAT. It will only have to create this file if it is the first time the particular data has been run with logixcentral. This process will be very quick if the existing matrix is still valid, but can take some time if the matrix has to be regenerated.

The program then begins to construct the vehicle schedule. There is often an appreciable delay before the display begins to show orders being allocated. During this time several important functions are performed.

The collections for onward delivery (tramped pairs) are formed (logixcentral itself knows nothing of the connection between these orders hence it must be constructed each time).

Calls within groups are joined together in chains

Orders are formed into clusters

The vehicle scheduling sequence is formed, taking account of clusters

Orders are provisionally allocated to depots, taking throughput limits and vehicle availability into account

Orders now begin to be allocated to routes. The screen is updated frequently but not necessarily after every single calculation. Each order is taken in turn and tried in each possible position on each route. If it cannot be allocated to any existing route, a new route will be started (if possible). This order is now processed and the routine moves on to the next. As each order is attempted the progress bar(s) increase.

There are five progress bars that move across the logixcentral screen during vehicle scheduling. The different colours represent different entities:-

Blue Bar (Attempted): This indicates the % of the orders available which the algorithm has so far attempted to allocate to routes.

Red Bar (Allocated): This indicates the % of the orders which the algorithm has allocated to routes. It will always be the same as, or less than the blue progress bar as the algorithm may have attempted to plan an order, then rejected the original choice as a better choice becomes available. For this reason, it is not uncommon for this progress bar to decrease as well as increase during vehicle scheduling.

Green Bar (Optimised): Once all possible orders have been allocated, this bar indicates a second phase of the vehicle scheduling process that attempts to further optimise the routes. The number indicates the % optimised at this stage.

Yellow & Magenta Bars (Vehicle Utilisation): These %s indicate average vehicle fill for both primary and secondary units of load.

Having completed the vehicle scheduling process the program eliminates existing data files, updates the logixcentral master files to convey the new route structure to logixcentral and writes various files as an audit of the vehicle scheduling operation.

What maps are available?

Street level maps of all of Continental Europe, and many other parts of the world, are available by incorporating data from suppliers such as Navteq.

There is very wide coverage in mapping terms. Currently the mapping databases available are:

Can the software use postcodes?

Yes! Data can be entered into the system in any mix of postcode (European), towns and eight figure or 100km box grid references or even latitude-longitude if you have it!

The import engine is intelligent and will search through an address until it finds a valid reference i.e. Oxford Street, Reading would not be located in Oxford.

DPS have a very comprehensive postcode table with almost 230,000 entries just for Europe as the table below shows:

How are unloading times calculated?

Unloading times at customer are any permutation from 100% fixed through to 100% variable.

Variable times can be imposed per order and are either passed as an amount of work time or time based on the amount of product (and type of product) to be off-loaded. The same is also true for depot loading and unloading times.

The available combinations are as follows:

fixed delivery time
fixed delivery time plus variable product and product volume delivery time
variable only per order
any mix of the above

How does it handle 'rush hour' speeds?

In order to cater for 'rush hour' speeds within logixcentral, the day is split into four parts:

night time
morning peak
day time
evening peak

The user can control the specific time periods each of the above cover and the speed variation for each time period based on the operating conditions prevailing.

Within certain countries we also have 'links' to live traffic systems to enable 'real time' variation of vehicle speeds.

Can logixcentral be used for logistics strategy?

logixcentral is particularly adept in a strategic situation. Once data is available in the system it can be used for a number of strategic scenarios without the need to undertake any data manipulation.

Typical activities may be:

Optimal depot locations
Optimal number of depots
Fleet sizing and composition
Multi-depot and multi-country vehicle scheduling
Pan-European operations with backloading opportunities
Sensitivity analyses and relative costings
Resource use by time of day, day of week, depot and vehicle type
Marginal costing of additional activities
Optimal supply locations
Multi-compartment operations with product incompatibilities

Can logixcentral deal with multi-depot vehicle scheduling?

Yes. It is possible to fix, partially fix, or allow logixcentral free reign on selecting which depot would be best to serve each order.

Using the 'depot zones' setting you can force certain depots to serve certain orders within specific zones. This could be the case for all of your orders or just specific orders.

If logixcentral is allowed the choice of service depot, its standard allocation routine will choose the depot closest to each order by road travel time. However, logixcentral is clever enough to appreciate that if a vehicle is leaving Depot 1 to complete orders right on the edge of its travel time boundary, it would be more efficient to allow that vehicle to complete orders in the same geographical area that are actually closer to Depot 2.

Similarly, if Depot 2 has insufficient resources to handle all of its geographical orders, then logixcentral will make the most of any spare resources from Depot 1 in order to complete as many unallocated orders as it can that fall into Depot 2's area.

Further, using the Preferred Depot functionality, specific orders can be allocated to specific depots because of stock availability.

In summary, logixcentral is very flexible when it come to multi-depot vehicle scheduling. You can let logixcentral decide which depot is optimal or you can force specific orders to be carried by resources from specific depots; or any combination!

Can logixcentral handle trunking and backloading?

The software is fully featured to allow different distribution channels to be modelled accurately. Trunking-only resource can be dedicated purely to trunking, and backloading can be included by use of two features.

The simplest way is to end all routes at the last call on a route without an automatic return to depot. This details where and when the resource is available and then backloading can be incorporated by a manual addition to a route. Alternatively, the software can be run in tramping mode, which allows a collection and delivery pair to be specified.

For example, a route would leave the depot in Tamworth, deliver through Northamptonshire and finish in Huntingdon. The vehicle then travels to Cambridge and collects a full load for delivery to Coleshill. Having completed this it returns to Tamworth.

In what format does logixcentral import data?

Data can be imported in a number of standard formats, although the following are the most widely used:

Fixed ASCII
Dbase
CSV (Comma Separated Values) with column descriptors (the columns can be in any order - no pre-formatting is needed)
Excel
Microsoft Access or SQL

The generally preferred method is using CSV, as these have the flexibility for viewing and/or editing using spreadsheet packages such as Excel or Lotus.

What happens when I sign up for logixcentral?

After you have accepted the terms of our license, we will contact you to set up your payment process. Payment will need to be by Direct Debit which we will arrange with you. As soon as that is in place, we will email you a username and password and off you go! The system is very intuitive, but there is a built-in help facility and tutorials, as well as a support desk available to you should you need it.

What happens if the auto scheduler doesn't work?

Don’t panic! You probably have conflicting parameters. The worst thing that can happen is that orders are not scheduled.

The following are typical conflicts:-

Order is too big for a vehicle, forcing it to return to the depot to reload
Closed days or book times or may not fit within days allowed
Sequence numbers may be set
Order units are incorrect making orders impossibly large to deliver
You may need multiple depots to deliver all the orders within the time constraints specified but have only set your parameters for a single depot