TKS # 11 – How to model truck and trailer?
When you have a scenario with trucks and trailers (or tractor and trailers), you will have to answer the question how to model this in TM. This blog should show different options and evaluate advantages and disadvantages from my point of view.
Modeling “Virtual Big Trucks”
If your trucks are usually are driving with the same coupled trailer without uncoupling it or if trailers aren’t a limited resource in your scenarios and you are usually couple “any” of your trailers to a tractor (which is quite common scenario in north America from my experience), you might be fine to model the reality incorrect in TM with just assuming that a truck and trailer combination is reflected by a big truck covering the capacity of both the truck and the trailer.
For sure this is a massive simplification of the reality and therefore it has some disadvantages:
- Trailer-Swap Scenarios: This modelling does not support scenarios in which you exchange a fully loaded trailer at a certain parking lot or depot which will get picked up unchanged from another truck.
- No Tracking on Trailer Level: As you aren’t model the trailer resources you will not be able to track where certain trailer is located.
- Load Planning: As you are modeling the load plan of a truck and trailer as one big box you will not be able to use the load planning functionality in a sense full way
While this modeling was the only possible simplification of truck and trailer scenarios till 9.6 I would not recommend this approach anymore as you can use combination resources instead.
Trailer Units and Trailer Resource
The most obvious solution might be to use trailer resources and trailer units for modeling the trailer, but experience showed that you should only use this modeling if you really need it.
Basically, in this modeling approach you are modeling trailers as trailer resources and assign freight to them – which will create trailer units. For those trailer units you will need to search truck resources to create freight orders.
The biggest disadvantage of this modeling is that it increases the scenario complexity: Users need to learn the semantics of a trailer unit document („a tour of a trailer“), you increase the number of documents to handle (which also impacts system performance) and increase the complexity for the VSR optimization (which result in worst results given the same time).
For VSR optimization you will need to additionally maintain Means of Transport Combinations (which is an own story for another blog).
Anyways for sure there are reasons and scenarios in which you will need exactly this modeling. If you have a lot of trailers swapped in your scenario I guess you will need to go this way.
The newest possibility to model a truck and trailer scenario is the so called combination resource. The basic idea behind the combination resource is that often there are fix combinations of certain tractor with certain trailer (or at least trailer type) which are only uncoupled in exceptional cases but for TM it will be handled as undividable unit.
With that it’s kind of an improved modeling of the virtual big trucks but other than that it’s able to handle real physics in load planning.
In the modeling you define the trucks and trailers as usual and afterwards creating the combination resource referencing the different trucks, tractors and trailers in a combination. The combination resources will be dealt as truck resources as the combination itself should contain at least one vehicle which can carry the others. Creating a freight order for such resource will result in a freight order creating items for the main truck/tractor as well as the trailers.
Sadly the VSR considers the combination like one huge truck, meaning that after VSR all items will be stuck under the main item and need to get distributed manually or via load planning.
As the trailers aren’t modeled as own objects it’s once again it’s not possible to swap those on the ride.
From my perspective you should try to use the combination resource wherever possible. It’s the smart “between both worlds” solution which can fit a lot of scenarios but doesn’t increase complexity. Sure there are limitations and for some scenarios you will end up needing the use of trailer units but think twice whether you can separate them (regional, by process, …).
Don’t let the edge case scenarios increase the complexity of all. As for all process modeling decisions, remember to divide and conquer.