[Csantucci]

Thanks Peter,
a very useful exercise. I'm writing a specification for a parametrizable TCS (including functions, sound and display features), leaving the door open for fully coded implementations. I will upload it here for discussion when and if I will get it finished. No easy task :handsdown: , but I think it is necessary if one does not want to think only at fully coded implementations.

[disc]

I think fixed TCS won't work. There are too may of them. Scriptable would be good. I've implemented PZB/Indusi and LZB, and other systems in railworks/ts, and these are needed for them:
-Distance to next signal
-speed limit or aspect of the next signal
-Distance to next permanent speed limit
-speed limit of the next permanent speed limit.
-current speed limit
-current speed of train
-current acceleration of train
-train type
-max acceleration and deceleration rate of the current train (optional for more realistic control)
-transponder custom message when passing it (for example at PZB/Indusi 500hz, 1000hz or 2000hz messages when passing a transponder)
-ability to control indicator lights in cab (PZB mode lights, and indicators, distance indicator for LZB like, and target speed indicator (both analog and textual)
-special controls to acknowledge warning, pass red light, and lift speed limitation
-AFB (holds the target speed by accelerating and braking if necessary (both with dynamic and airbrakes)), or the possibility to "script" these, as LZB controls AFB by using the computed target speed.
-sound notifications (one for "dead man's switch", one for penalty braking, one for feedback of the driver input, one for general event
-of course the ability to apply emergency brake.
If these are possible, i think every TCS can be implemented, including PZB/Indusi, LZB, AWS, ATP, ETCS level 0 to 2, EVM, Mirel, Integra signum, etc... Plus there are special things to be considered that would affect the signal system too, like moving blocks.

[roeter]

Csantucci, on 26 October 2013 - 12:42 PM, said:

Thanks Peter,
a very useful exercise. I'm writing a specification for a parametrizable TCS (including functions, sound and display features), leaving the door open for fully coded implementations. I will upload it here for discussion when and if I will get it finished. No easy task :handsdown: , but I think it is necessary if one does not want to think only at fully coded implementations.

Parametrization is the only viable option, given the many different systems.
I've spent some 20 years of my professional life converting specific costumer whishes into parametrized functions for more general use, so I might be able to help a bit here - you know where to find me.

Regards,
Rob Roeterdink

[gpz]

PA1930, on 26 October 2013 - 06:33 AM, said:

I loved how it worked because it worked rather really fine comparing to the real life. Maybe the only thing I'd make aditionally to it would be also showing next speeds (if they're slower than the actual speed) from speedposts and not only from the speed limits imposed by signals.

I think that should work when running an activity (though I haven't tested it), but for explorer mode that data is not exposed in an easily readable form, and I didn't want to invest more effort into this temporary solution.

Csantucci said:

I'm writing a specification for a parametrizable TCS (including functions, sound and display features), leaving the door open for fully coded implementations. I will upload it here for discussion when and if I will get it finished. No easy task :handsdown: , but I think it is necessary if one does not want to think only at fully coded implementations.

Carlo, I wish you good luck for this effort, I am really looking forward to have this implemented! It is not an easy task indeed. :derisive:

[Csantucci]

Peter and Rob,
thank you for your encouragement and your proposals for help!
What I can tell you now is that after the tests I did I found that MSTSbin (and I'm sure also MSTS) tolerates the additions I foresee to do within the file syntax of the .eng, .cvf and even .sms files, and that's very important. The spec will of course foresee the possibility of having more than one TCS in the loco, as well as the possibility of having the definition block of the TCS inside or outside of the .eng file. However I must be clear that I will only try to write a proposal specification to be used as a discussion basis ( as I spent part of my professional life doing this... ), but the implementation will be for sure beyond my capabilities. So volunteers for that are welcome...

disc,
in fact a full implementation of a TCS is very complex, which I don't know if it leads to a fully coded or to a fully parametrizable solution; maybe it leads to an intermediate solution. In my opinion implementation of every TCS can go stepwise. One can start putting at disposal the basic functionalities, and then he can add the more "hidden" ones.

[gpz]

Csantucci, on 27 October 2013 - 12:33 AM, said:

However I must be clear that I will only try to write a proposal specification to be used as a discussion basis ( as I spent part of my professional life doing this... ), but the implementation will be for sure beyond my capabilities. So volunteers for that are welcome...

Carlo, I am, at least, here for coding, so don't worry, it will be implemented eventually. :pleasantry:

[Csantucci]

Nice to read that, Peter! :pleasantry: . I'm working...

[Csantucci]

To my TCS friends, here I have found a nice short video on the German LZB

[Csantucci]

I have generated a first alpha release of a framework description on how to describe a train control system to be interpreted by ORTS.
It for sure has many missing parts and some inconsistencies, and it absolutely does not pretend to be fit for all available train control systems. I would even say that any newly train control system implemented for ORTS will require some additions to the document.

The document is here for discussion and I hope that after such discussion it can be upgraded (by myself or someone other) to a guideline for development of train control systems under MSTS.
 TCS_Rev1_0.zip (635.36K)
Number of downloads: 756

[JLChauvin]

Csantucci, on 31 October 2013 - 07:28 AM, said:

I have generated a first alpha release of a framework description on how to describe a train control system to be interpreted by ORTS.
It for sure has many missing parts and some inconsistencies, and it absolutely does not pretend to be fit for all available train control systems. I would even say that any newly train control system implemented for ORTS will require some additions to the document.

The document is here for discussion and I hope that after such discussion it can be upgraded (by myself or someone other) to a guideline for development of train control systems under MSTS.
TCS_Rev1_0.zip

Thank you very much Carlo for all your work.

Very promising signaling improvement.

Jean-Louis