Bi-modal, or multi-modal vehicles

[Vladki]

Recently I was thinking a lot about multi-modal vehicles. I have a proposal, how it could be handled in .dat files. Please take this as "design part" with some brainstorming, open for discussion, which could later lead to implementation (coding).  From start we should really think no only about bi-modal (as in diesel or electric), but multi-modal (diesel, DC-electric, AC-electric), or even multi-system (electric but able to run on different voltages). Multi-system electric engines and EMUs have different characteristics when running on different voltages. The system as I see it, would allow to have multi-system engines with exact specification, which electrification systems it can use (unlike now when multi-system engines can run on any voltage). Also it could allow electric engines to be pulled by diesel engines on non electrified lines.
So the proposal is like this:

1. new option "multi-mode = 1" that will enable all these new fuctions. 0 would mean legacy behavior.
2. vehicle characteristics (power, tractive_effort, ...) for running in independent mode (diesel, hydrogen, battery, ...) would be defined as usual. Purely electric vehicles would have power=0 here.
3. there would be an extra set of characteristics for each way_constraint_permissive that this vehicle can use. The index would be the constraint number (e.g. in pak128.Britain-ex: 0 = DC third-rail, 2 = AC overhead)
Example:

Code Select Expand


obj=vehicle
name=BR-800MiddlePower
engine_type=diesel
multi_mode=1
# diesel mode
speed=200
power=700
tractive_effort=122
gear=50
runningcost=210
# electric mode (AC)
speed[2]=225
power[2]=904
tractive_effort[2]=77
gear[2]=80
runningcost[2]=226
# hypothetic third-rail DC mode (lower power and speed limit)
speed[0]=160
power[0]=850
tractive_effort[0]=77
gear[0]=80
runningcost[0]=226

(Hmm, I thought the electric mode would have lower running cost... But thats what I found in br-800.dat and br-801.dat...)
The list of options that can vary with the mode of operation is up to discussion. Most importantly range should be added to the above list. (Battery powered vehicles have quite limited range.)
If any option in this set would be omitted, it will default to the same value as is specified for independent (diesel) mode. Also values for all unspecified indexes will default to independent mode. (e.g. for the above vehicle, power[1] for DC overhead catenary, would have the same values as independent mode.). As you see the way_constraint_permissive[2]=2 and way_constraint_permissive[0]=0 is omitted. This will allow the vehicle to run anywhere.

The implementation of vehicle movements would have to do the following:
- check the multi-modal flag
- if multi-modal, check what permissive constraints are on the current tile where the vehicle is.
- if no constraints are present, continue as usual, use the normal values
- if there are multiple constraints, choose the constraint with the highest power
- use the indexed values of the chosen constraint

Issues I'm aware of now:
- purely electric vehicles would have power=0 by default, and only some power[n]=non-zero. They wouldn't be able to depart from non-electrified depot, but what if they encounter a stretch of unelectrified track on their journey? Would they refuse to leave the last electrified station, saying "no route"? Or would they enter the section, coast for a while, and eventually get stuck? Would they move at least 1 km/h to get out of there?
- using both diesel and electric engine on a train, would give power of both on electrified track. On non-electrified track, the electric engine would be just dead weight. (Not an issue though).
- electric engine with optional battery car. Engine would have power=0 and power[2]=880; battery car would have power=100 and power[2]=0. If the current way has the constraint no. 2, power[2]=0 should take precedence and switch the battery car off. (So it would not "boost" the engine while running on AC catenary). But it would boost anyway if the track has both AC catenary and 3-rd rail, because power[0] would default to power=100...

- implementation issue - as described above, the memory consumption of the vehicles would explode as it would have 9 sets of power related options (1 for independent mode and 8 for all possible permissive constraints). This could be reduced to store only those that are defined, but the algorithm for choosing the values would be more complicated.

- exceeding the range - well that could happen even now - what if there are multiple engines with different ranges in the same train, and the next destination is within the range of some engines, but out of range for others? With multimodal it becomes more funny. There might be an unelectrified stretch of track, but too long for the given vehicle's batteries. But both stops would be electrified, so the departure check for range would assume infinite range...

That's all for now. Any opinions, suggestions, etc?

[jamespetts]

We do need bi-modal support at some point, as bi-modal trains have, in the last 10 years, become mainstream in a way that they had not been before. This is not the highest priority at this time, but certainly worth implementing.

The design detail will need to be considered in more detail closer to the implementation time.

[Rollmaterial]

Is there any existing or potential permissive way constraint that isn't an electrification system? If so, I would suggest creating a separate way constraint type.

[Vladki]

Is there any existing or potential permissive way constraint that isn't an electrification system? If so, I would suggest creating a separate way constraint type.

I'm planning to use permissive way constraint for rack railways - there exist rack railway engines that have only the cogwheel powered. So this would work exactly as with electrification (i.e. lack of constraint = lack of power).
The only other permissive way constraint I know of is "waterway" for inland waters (lakes, rivers, canals). If there is any permissive way_constraint that would be really physically required by a multi-modal vehicle, then it would have to be specified in the usual way. OTOH it would not need to set power & comp. values defined for this constraint, but only for those constraints providing power. So unless we run out of constraints (max is 8 for each waytype IIRC), there is no need to split them to "power only" and "physical".  However I have considered such a split before, as one of the possible ways to exactly define multi-system electric locos (AC/DC).

Also such split (or distinction) would be useful for prohibitive constraints regarding rack railways, but that's for another topic (I'll post soon anyway).

[freddyhayward]

I'm not sure whether this is relevant, but there are also cable railways that could be implemented the same way as electrification.

[jamespetts]

There is no need for a special way constraint type for electrification, since the original Standard electrification flag is retained. Thus, non-electrification way constraints can be encoded into way types or way objects that do not have the electrification flag set. Thus, multi-system electric vehicles can simply be created by coding them as electric without any way constraints. This is done frequently in Pak128.Britain-Ex.

[Vladki]

Thus, multi-system electric vehicles can simply be created by coding them as electric without any way constraints. This is done frequently in Pak128.Britain-Ex.

Yes, but causes funny result, that such multi-system electric vehicles can use ANY electrification. E.g. Sheffield tram-train that in reality can run on AC/DC overhead catenary, can (in simutrans) run also on 3-rd rail power. In pak.CS I plan to have more fine distinction for electrification: DC: 600-700 V (tram), 1500 V (early train), 3000 V (modern train), 750 V (metro 3rd-rail bottom contact); AC 25 kV/50 Hz (standard), 15 kV/16 Hz (german).   But in current situation, it does not make much sense to distinguish more than DC/AC overhead and DC 3rd-rail.

The proposed design will allow to specify exactly which electrification types are supported, and to limit power on DC electrification, or speed on 3rd rail.

[Sirius]

E.g. Sheffield tram-train that in reality can run on AC/DC overhead catenary, can (in simutrans) run also on 3-rd rail power

Oops, you mean the Sheffield tram-train 4-th rail running on Stephenson was a little hacky?

Anyways, I totally agree here. The way how multi-system vehicles are defined is far from optimal. It's rather a hack than anything else.

p192c-ex ran into the same issue when we discussed electrification constraints.

[Vladki]

I'm not sure whether this is relevant, but there are also cable railways that could be implemented the same way as electrification.

This is similar to rack railways. Depends on the rules and capabilities of vehicles:
- use way_constraint_permissive if the cable car cannot be detached from the cable
- use way_constraint_prohibitive if all cars must be attached to the cable
(you may use both at the same time). This will work fine even in the current system.
The newly proposed system will allow for cable cars to be detached from the cable and pulled by locomotive on cable-less track.

[Sirius]

Imho, the suggested system seems fine, but I am not sure if it's a good idea to strictly limit it to engines and the arraying seems odd.
What about more general vehicle modules?
Besides this problem, we have an issue to offer all the features that modern highly configurable train platforms offer.

A module can come with the same parameters as vehicles, but with an additional option to either override or add that value to the attribute of the basic vehicle.

A vehicle can attach those modules by name with a new

Code Select Expand

vehicle_module[i]=module_name,optional parameter.
If the "optional" is given, that module can be installed or uninstalled in the depot as some kind of a more flexible implementation of upgrades. Otherwise it's always installed.

A module will be activated when all the constraints defined in the module match the available constraints of the way.
There needs to be a module_group or something like that, where only one module of the same group can be active at the same time, to prevent multi engine vehicles to stack up the installed power, but also to offer multiple different seating options whilst preventing multiple seating options from being active at the same time.

[Vladki]

Freahk, can you give some examples what you mean? I'm not sure what do you mean by vehicle modules? And what is odd on the arraying?

I was also thinking about how to display the multi-modality to players.
- the power, tractive effort, etc, that is shown now (at any place in the game), would be the values defined by the currently available (used) way constraint.
- in convoy dialog/details, perhaps a new tab could be added - showing multimodal specs in tabular form (rows - constraints, columns - power, tractive effort, gear, speed, range, running costs, ...)
- in depot it is much more complicated - there is already a lot of information. Perhaps the multimodality could be shown next to way constraints, and listing only those constraints whose values are different from independent mode - this is to show, which constraints can have some advantage for given vehicle. Then in the convoy totals, each value that has multiple values would have an icon to draw attention, and show all relevant values in tooltip. This would mean that the current tooltips would have to be converted to normally visible lines (and that should be IMHO done anyway). Unfortunately I have no idea how to show these values for individual vehicles in depot, as their specs are shown on mouseover, so any tooltips, or click on some button to show more are not possible.

[Sirius]

I'll just pick your example

Code Select Expand


obj=vehicle
name=BR-800MiddlePower
tractive_effort=77
vheicle_module[0]=BR-800-AC-engine
vheicle_module[1]=BR-800-DC-engine
vheicle_module[2]=BR-800-diesel-engine,optional
... further vehicle attributes as usual

# diesel mode
obj=vehicle_module
name=BR-800-diesel-engine
module_group=engine #any name
speed=200
power=700
gear=50
runningcost=210

# electric mode (AC)
obj=vehicle_module
name=BR-800-AC-engine
module_group=engine
way_constraint_permissive[0]=0
speed=225
power=904
gear=80
runningcost=226

# hypothetic third-rail DC mode (lower power and speed limit)
obj=vehicle_module
name=BR-800-DC-engine
module_group=engine
way_constraint_permissive[2]=2
speed=160
power=850
gear=80
runningcost=226


The first module matching the available constraints will be anabled.
I.e. If DC catenary is available, it will be activated. Otherwise if 3rd-rail is available, it will be activated. Otherwise diesel will be activated.
As the diesel engine is optional, it can be dismounted in the depot, thus removing the ability to run on diesel but also removing the weight, cost and so on.
Most numerical vehicle attributes should behave additive, whilst some might need an overriding behavior.
Explicit control of this behavior might be useful, but I am not sure about this. I guess always using add on "real" numeric attributes and override everywhere else, including booleans should be fine.

Code Select Expand


engine_type=electric,override
is_tilting=1,override
runningcost=226,add


[Vladki]

Thanks for example. Seems to make thing even more complicated, but made me rethink the original proposal.

To avoid having an array of features for all possible constraints, it would be done like this:

- new option: way_constraint_optional[prio]=X, where X is the number of permissive constraint
- other options (specs) would be specified as power[prio]=123...
- prio is priority, 0 = max. 
- way constraints would be chcecked in order of priority, and the first matching will be used.

This solves the following issues
- reduced memory consumption
- more precise control of which set of specs will be used (pakset designer will choose) = battery car solved
- maybe the multi-mode flag would not be needed, replaced by way_constraint_optional

Issues still left
- range
- user interface
- behavior of pure electric trains on non-electrified track

[Sirius]

- behavior of pure electric trains on non-electrified track

I don't understand that point? They simply cannot provide any power on such tracks. A convoy that cannot provide any power on a specific section cannot use that section.

The point in the above suggestion is not only bi-mode, but also to consequently follow the "allow what is possible, not what was actually ordered" guideline.
Especially modern train platforms offer many many options. Too many to offer all of these in the current system.

Implementing those options as vehicle modules is practically close to the "deck system" we use for ships, but comes without the drawback of being a vehicle on its own.
I considered using that deck system on trains as well, but that's impractical.

Indeed it's more complicated than a system which is restricted to engines.

[Flemmbrav]

Shouldn't it be best to calculate the route the same way the vehicles does usually, but in plus you do multiple routes for all the possible tractions?
Choose the best route the same way it does by now too.
Just add some extra options.

[Sirius]

The mode can switch on-route, so you need to consider all available options on a single route search, instead of running multiple route searches.

[Flemmbrav]

Does it really matter?
Well, technically they could, yes.
An ET 450 switches modes between stops.

An ET 474 does not.
Neither does a combination of BR 101 and BR 218 in front of an IC train.
In fact, most multi-mode vehicles do not.
They might stop on the open line to swap modes, but that could be covered with waypoints.

[Vladki]

They simply cannot provide any power on such tracks. A convoy that cannot provide any power on a specific section cannot use that section.

The point is, that now, if you build a train with no power, it won't leave the depot (and show an error message). Also the current system will not allow you to build electric vehicles in non-electrified depot. However if electrified, you can build an electric train and send it out on a schedule that is partially electrified. The train will stop in the last electrified station, and say "no route". Same as if you destroy the electrification in front of running train. But that check is done due to "engine=electric" and "own_waytype=electrified_track" (and way_constraints (and axle_load, etc, etc)).  This means that now, electric vehicles are not allowed to enter non-electrified track, even if a diesel engine is somewhere on the train.

But the proposed system should allow that. So the hard check on engine=electric and own_waytype=electrified_track should be removed. Instead the pathfinder will have to check, if the convoy will have at least some power on each tile of the route (just as it does not exceed axle_load, etc).

@Flemmbrav - electric engines can (and often must) switch to different voltage while moving. They cut off power (put down the pantograph), switch while moving over an insulated section, and put the pantograph up again. God forbid anyone to pull the emergency brake and let the train stranded in the insulated section.  I'm not sure if switching between diesel and electric or battery and pantograph is possible while on move. Theoretically it should be possible, but probably it depends on specific vehicle. The question is if we want to simulate that. Simple solution would be to allow switching while moving. If we want to force switching modes on stops (perhaps as an option for each vehicle), we would have to find which mode is available all the way to the next stop, and store that somewhere. Also train may be able to switch AC/DC while running, but has to stop to switch from electric to diesel. This would make the pathfinding even more complicated, and I'm not sure it would be worth it.

[Flemmbrav]

That's what I meant, I really do not see any need in simulating that kind of switiching during moving.
Worst case you just put a waypoint on a section that provides both kinds of powers.

IIRC most locomotives have a small buffer battery for cases like that, so stopping in the small isolated section between systems should not be that much of an issue.


The other thing my suggestion simplifies is that the route does not need to be checked permanently and thus the whole issue with routes changing during movement would not be a thing

[Vladki]

IIRC most locomotives have a small buffer battery for cases like that, so stopping in the small isolated section between systems should not be that much of an issue.

I don't think so. Batteries in locos (or even trams) are usually low voltage (24-48 V) and good only to get the controls alive, to allow you to raise the pantograph. I can't imagine moving the whole train with such batteries at all. The battery car for czechoslovak class 210 (AC electric shunter), is wagon full of batteries, and yet it provides only 100 kW, and thus many auxiliary systems (compressors and cooling) are turned off to provide max power for moving. http://www.strojvedouciplzen.cz/img/soubory/159.jpg

Regarding the routing, for simplicity we can assume, that vehicles can switch systems at any time, so pathfinder has to find a route where the whole convoy has at least some power on every tile. So for trains with independent power, this is no-brainer. Just find the route as usual, and enjoy bonus from electrification if it happens to be there. It will be a little more complicated for electric-only convoys but seems to be feasible. There is still the issue of proper range calculation, if the train will switch modes between stops.

Also one small thing - do we know exact position of individual vehicles in convoy, or only the head tile? That position would have to be used to pick the right specs for physical model calculations. But IMHO it does not matter too much, if the electric engine on the rear of train will stop (and start) a few tiles earlier.