Per km was based on power multiplied by some made up efficiency multiplier multiplied by some made up fuel number for the period. To simulate vehicle servicing and replacement an additional factor based on initial purchase cost was also added representing the useful life of the vehicle so that after some very large distance it eventually pays for a new one. It was intended to bring down the per km cost of some of the high speed vehicles which were balanced around traditional Simutrans speed bonus payments so become impossibly expensive to run late game.
I am well aware physics does not work like this. However this model was required to prevent moving stuff slowly with very fast powerful (express) locomotives from being overpowered as they have a lower per km running cost than the similar powered locomotives intended to operate at the appropriate speed. In real life this was not the case as the very fast powerful locomotives are usually less efficient as they waste more energy/fuel moving themselves around at the slower speeds than an appropriately sized locomotive would.
The issue is that due to the black box nature of the physics as well as some vehicles being made from multiple units it does not factor in vehicles like busses which do not use all their power to hit their operating speed. As time progresses such vehicles have more powerful modern engines resulting in worse per km fuel efficiency and which only gets fully used while the vehicles accelerate.
To some extent the balance implemented did achieve what it set out to do. In the situation of a heavy goods train that has its top speed limited by power of the locomotive the use of a more powerful but still limited engine correctly results in more cost per km reflecting the use of more fuel that is needed to provide that more power. Where it mostly failed was every single vehicle combination that is speed limited and not power limited.
Finally the monthly costs were some fraction of the purchase cost added to some guessed wage amount. Values chosen were purposely kept small to make gameplay easy for testers on the server games. Since I was literally looking at internal data names, I incorrectly guessed the size of some ships, resulting in the stupid situation of tiny boats having monthly costs similar to paying for 100-200 crew.
The two parts used to calculate per km cost are eventually meant to be separated into separate systems which more accurately simulate real life behaviour. The maintenance part would be simulated by wear and servicing similar to how rails currently are. The power part of the per km cost is then derived from the actual work done as being discussed in another thread, possibly with dynamic efficiency factors and the ability to set speed limits.