Fleet Minimization - Revision history

Anw: test

2024-05-17T06:41:41Z

test

← Older revision		Revision as of 08:41, 17 May 2024
Line 41:		Line 41:
	[[Category:C-TMS Modules\|B-180]]		[[Category:C-TMS Modules\|B-180]]
	[[Category:C-TMS User Guide\|BB-180]]		[[Category:C-TMS User Guide\|BB-180]]
			[[Category:TEST\|B-180]]

Anw at 11:26, 11 May 2011

2011-05-11T11:26:52Z

← Older revision		Revision as of 13:26, 11 May 2011
Line 38:		Line 38:

	If Fleet Minimization comes across an invalid/infeasible trip then it will ignore the trip and count it as an error.		If Fleet Minimization comes across an invalid/infeasible trip then it will ignore the trip and count it as an error.
			[[Category:Trip Management\|180]]
			[[Category:C-TMS Modules\|B-180]]
			[[Category:C-TMS User Guide\|BB-180]]

Admin at 13:39, 12 November 2010

2010-11-12T13:39:33Z

← Older revision		Revision as of 15:39, 12 November 2010
Line 1:		Line 1:
	In [[~~MTS~~]], a schedule consists of a number of trips, each of which has a defined start and end time. At any given time instant, there will be a number of concurrent trips under way, and this is approximately the number of tractor units and drivers who are required to be employed at that time.		In [[C-TMS]], a schedule consists of a number of trips, each of which has a defined start and end time. At any given time instant, there will be a number of concurrent trips under way, and this is approximately the number of tractor units and drivers who are required to be employed at that time.

	The reason that it is approximate is that a trip may return to the depot to reload, before going out on the road again, so even though this trip may be current, it does not in fact require a driver nor a tractor for the time it is back at the depot.		The reason that it is approximate is that a trip may return to the depot to reload, before going out on the road again, so even though this trip may be current, it does not in fact require a driver nor a tractor for the time it is back at the depot.
Line 9:		Line 9:
	In general, the starting time of a trip will have a certain amount of flexibility, which is to say that it could start earlier or later, whilst still meeting all of its collection and delivery window commitments. It is therefore possible to reduce the total number of vehicles and drivers required, either by delaying trips which start near the peak, or starting earlier some of the trips which end around the peak.		In general, the starting time of a trip will have a certain amount of flexibility, which is to say that it could start earlier or later, whilst still meeting all of its collection and delivery window commitments. It is therefore possible to reduce the total number of vehicles and drivers required, either by delaying trips which start near the peak, or starting earlier some of the trips which end around the peak.

	However, because of the way in which external systems perform scheduling, trips will generally endeavour to occur as early as possible, so as to hit the start of the collection and delivery windows. This is not always true where continuous moves is deployed, in which the optimal start time may not be the earliest possible start time. However, in this situation it would not be desirable to start the trip earlier in any case. This is also true of the [[~~MTS~~]] Recalculate Distance and Time function.		However, because of the way in which external systems perform scheduling, trips will generally endeavour to occur as early as possible, so as to hit the start of the collection and delivery windows. This is not always true where continuous moves is deployed, in which the optimal start time may not be the earliest possible start time. However, in this situation it would not be desirable to start the trip earlier in any case. This is also true of the [[C-TMS]] Recalculate Distance and Time function.

	This fact simplifies the requirement, reducing it to the need to delay the trips which start around the peaks such that they no longer contribute to the peak, but without delaying them such that they arrive at stops too late. This, in essence, is the purpose of the Minimize Fleet function.		This fact simplifies the requirement, reducing it to the need to delay the trips which start around the peaks such that they no longer contribute to the peak, but without delaying them such that they arrive at stops too late. This, in essence, is the purpose of the Minimize Fleet function.

Crisfordm: Highlighted MTS

2008-12-31T10:03:22Z

Highlighted MTS

← Older revision		Revision as of 12:03, 31 December 2008
Line 1:		Line 1:
	In MTS, a schedule consists of a number of trips, each of which has a defined start and end time. At any given time instant, there will be a number of concurrent trips under way, and this is approximately the number of tractor units and drivers who are required to be employed at that time.		In [[MTS]], a schedule consists of a number of trips, each of which has a defined start and end time. At any given time instant, there will be a number of concurrent trips under way, and this is approximately the number of tractor units and drivers who are required to be employed at that time.

	The reason that it is approximate is that a trip may return to the depot to reload, before going out on the road again, so even though this trip may be current, it does not in fact require a driver nor a tractor for the time it is back at the depot.		The reason that it is approximate is that a trip may return to the depot to reload, before going out on the road again, so even though this trip may be current, it does not in fact require a driver nor a tractor for the time it is back at the depot.
Line 9:		Line 9:
	In general, the starting time of a trip will have a certain amount of flexibility, which is to say that it could start earlier or later, whilst still meeting all of its collection and delivery window commitments. It is therefore possible to reduce the total number of vehicles and drivers required, either by delaying trips which start near the peak, or starting earlier some of the trips which end around the peak.		In general, the starting time of a trip will have a certain amount of flexibility, which is to say that it could start earlier or later, whilst still meeting all of its collection and delivery window commitments. It is therefore possible to reduce the total number of vehicles and drivers required, either by delaying trips which start near the peak, or starting earlier some of the trips which end around the peak.

	However, because of the way in which ~~MTM performs the~~ scheduling, trips will generally endeavour to occur as early as possible, so as to hit the start of the collection and delivery windows. This is not always true where continuous moves is deployed, in which the optimal start time may not be the earliest possible start time. However, in this situation it would not be desirable to start the trip earlier in any case. This is also true of the MTS Recalculate Distance and Time function.		However, because of the way in which external systems perform scheduling, trips will generally endeavour to occur as early as possible, so as to hit the start of the collection and delivery windows. This is not always true where continuous moves is deployed, in which the optimal start time may not be the earliest possible start time. However, in this situation it would not be desirable to start the trip earlier in any case. This is also true of the [[MTS]] Recalculate Distance and Time function.

	This fact simplifies the requirement, reducing it to the need to delay the trips which start around the peaks such that they no longer contribute to the peak, but without delaying them such that they arrive at stops too late. This, in essence, is the purpose of the Minimize Fleet function.		This fact simplifies the requirement, reducing it to the need to delay the trips which start around the peaks such that they no longer contribute to the peak, but without delaying them such that they arrive at stops too late. This, in essence, is the purpose of the Minimize Fleet function.

Crisfordm: New page: In MTS, a schedule consists of a number of trips, each of which has a defined start and end time. At any given time instant, there will be a number of concurrent trips under way, and this ...

2008-12-30T10:28:43Z

New page: In MTS, a schedule consists of a number of trips, each of which has a defined start and end time. At any given time instant, there will be a number of concurrent trips under way, and this ...

New page

In MTS, a schedule consists of a number of trips, each of which has a defined start and end time. At any given time instant, there will be a number of concurrent trips under way, and this is approximately the number of tractor units and drivers who are required to be employed at that time.

The reason that it is approximate is that a trip may return to the depot to reload, before going out on the road again, so even though this trip may be current, it does not in fact require a driver nor a tractor for the time it is back at the depot.

From the graph of resource utilisation, an example of which is shown below, it can be seen that there will be a peak, at the point where the most vehicles are out on the road, in the example shown, 66 vehicles and drivers at around midday. This peak is referred to as the “Fleet Defining Point”.

<center>[[Image:flt_min_1.jpg]]</center>

In general, the starting time of a trip will have a certain amount of flexibility, which is to say that it could start earlier or later, whilst still meeting all of its collection and delivery window commitments. It is therefore possible to reduce the total number of vehicles and drivers required, either by delaying trips which start near the peak, or starting earlier some of the trips which end around the peak.

However, because of the way in which MTM performs the scheduling, trips will generally endeavour to occur as early as possible, so as to hit the start of the collection and delivery windows. This is not always true where continuous moves is deployed, in which the optimal start time may not be the earliest possible start time. However, in this situation it would not be desirable to start the trip earlier in any case. This is also true of the MTS Recalculate Distance and Time function.

This fact simplifies the requirement, reducing it to the need to delay the trips which start around the peaks such that they no longer contribute to the peak, but without delaying them such that they arrive at stops too late. This, in essence, is the purpose of the Minimize Fleet function.

== Resource Utilisation ==

The resource utilisation graph shown below shows the same schedule as that above, but after having had the Minimize Fleet function applied. From this it can be seen that the total number of vehicles on the road has been reduced from 66 to 55, representing a saving of 11 tractors, or 17%.

<center>[[Image:flt_min_2.jpg]]</center>

Each time a trip is delayed, it is being moved such that its start time occurs immediately after the end time of a preceding trip, thereby making these two trips non-concurrent.

== Trip Merging ==

There is another optional step that the fleet minimization process can perform, which is the merging together of trips, to create a driver’s day. This is controlled by the use of a system parameter that flags whether this function is turned on or off.

With merging switched on, the program will examine these two trips to see if they can be merged without violating any of the rules governing legal trips (eg maximum driving and shift hours), and if so, then they are merged into a single (multi-petal) trip.

Note that when a trip is merged, recalculate distance and time is called automatically, which may have to insert driver breaks as required. In certain circumstances this could temper the reduction in units.

== Fleet Optimisation ==

The minimize fleet function operates on a single schedule, and will generally operate on all of the trips within that schedule. It can, however, be restricted to consider only those trips with a specified carrier, and/or only those trips that start at a specified depot.

The Fleet Minimization process will normally be run after trips have been obtained from a scheduling package. Once the user has obtained those trips using the Get Trips functionality they can then run Minimize Fleet. Once the program has completed it will display a summary of the results to the user.

The user would then need to examine the audit log to obtain more information about the work that the Fleet Minimisation program has completed. The audit log will detail the start date and time of the minimization process, each trip that has been delayed, and the number of minutes inserted, each pair of trips that have been merged any errors that have occurred and the end date/time of the process, along with the results.

If Fleet Minimization comes across an invalid/infeasible trip then it will ignore the trip and count it as an error.

← Older revision		Revision as of 08:41, 17 May 2024
Line 41:		Line 41:
	[[Category:C-TMS Modules\|B-180]]		[[Category:C-TMS Modules\|B-180]]
	[[Category:C-TMS User Guide\|BB-180]]		[[Category:C-TMS User Guide\|BB-180]]
			[[Category:TEST\|B-180]]