News:

Simutrans Chat Room
Where cool people of Simutrans can meet up.

Distant signals

Started by Erik, March 26, 2011, 10:32:13 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

jamespetts

Quote from: isidoro on May 07, 2013, 12:24:39 AM
Thanks, James, for your explanation.  Now it is clear.  Since the driver knows where the next signal is, even if he doesn't now its aspect if farther than the sighting distance, he can drive intelligently (at full speed, for instance, if he knows that there is enough space to bring the train to stop before the next signal).

Yes, indeed - that's exactly how it works on real railways.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

kierongreen

The 200km/h limit is because of the braking distance imposed by signal spacing and 4 phase signalling. 5 phases was one way around that, increasing signal spacing would be another. Moving all the signals would have been a much greater expense than adding the 5th phase of flashing greens, hence why that approach was adopted.

jamespetts

Yes, I understand that, but you wrote that this practice was discontinued because it was "deemed unsafe": it was deemed unsafe, I understand, because drivers cannot reliably see signals at all at 225km/h (presumably, especially if they are flashing on and off). Cab signalling would be required at that speed, from what I understand.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

kierongreen

I've done a bit of research on this just now... Unsafe seems a relative term. Restrictions on running trains above 125mph/200km/h seem to have applied to revenue service rather than passenger service as such - there are plenty of documented press runs for both Intercity 225 and APT when trains went up to around 225km/h. Test runs for both train types went above 250km/h but they should be disregarded. It seems like service APT trains regularly went above 125mph in the 1980s, before health and safety was as strict as it would be now.

Not sure how you'd best deal with this in Simutrans (Experimental). Certainly above 140mph should be prohibited using conventional signalling - but I don't know how you'd simulate the additional expenditure required to refit trains for in cab signalling.

Max-Max

Well we are an international community and we need a way to satisfy as many as possible.

If we start to put down the requirements to begin with, I can see if I can work out some system that will be able to satisfy the list.

So far I understand:

Main signal (block signal?):
On green: Set track speed.
On Red: stop.

Distand signal:
Green/red: Set speed depending on number of green signals ahead (this can be track speed or max speed limit)

With track speed I mean the speed the train would have on a "normal" clear track.
With max speed limit I mean the signal will decide a new max speed for the block. It is however caped to the track speed.
- My code doesn't have bugs. It develops random features...

kierongreen

Note - British signalling is significantly different from that on the continent. Hence cause of some confusion I think.

Max-Max

This is why I try to get all the requirements so I can work out a configurable system.
Try to break down the functionality for your country and list them here.

So far we have not mentioned ATC or the new ERTMS/ETCS systems that all European countries will adapt.
It sounds boring to have no signals but there are 3 levels.

Level 1 has signals and works pretty much as ATC does today. You do need eurobaliser along the track.
Level 2 has no signals and requires both eurobaliser, signal lines and RBC stations along the track.
Level 3 Has no signals and also allows moving block. It also doesn't requires any signal lines along the track, this is completely radio based.
- My code doesn't have bugs. It develops random features...

jamespetts

May I ask: what is eurobaliser?
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Erik

#78
With a quick search I found this:
http://www.ertms.net/ertms/ertms-signalling-levels.aspx

I've never heard from it earlier.
Also I thing it isn't suitable for Simutrans. I like to build a working rail system with the signals.


Max-Max

Well suitable or not, I can think of a whole range of things you could use in an ERTMS/ETCS system, but I do agree that it is more fun to watch a signal.

As I said before, no one is forcing anyone to use things they don't find fancy or fun.
- My code doesn't have bugs. It develops random features...

jamespetts

The ETRMS discussion is an interesting one. We must, however, seek to differentiate, on the one hand, the underlying technology, which we need not directly simulate, and the functionality, which we do. (We do not, for example, directly simulate block instruments or track circuits). From what I can make out, the functionality layers that we need to be able to simulate at some point are cab signalling and moving block signalling. I should note that moving block signalling is not limited to ETRMS - it also exists on a number of low speed lines in London, such as the Central Line and Docklands Light Railway.

Because of the way in which the code in Simutrans works, it is hard to have a system that is completely without signals. What I suggest that we do for moving block signalling is have a system like that on the Central line, which is backwards compatible with trains not equipped for moving block signalling by having special three aspect signals: the danger (red) and clear (green) aspects work as with normal absolute block signalling, but there is an additional special (white) aspect which allows only moving block equipped trains through it. This is a good way of doing things in Simutrans because it interacts well with the existing system (we do not have to define track tiles as having any special signalling property: we just work on the basis that the path between a moving block signal and the next signal operates according to moving block rules when a moving block equipped train passes).

Cab signalling in one sense is easier and another harder. In one sense, the present signalling system in Simutrans-Experimental is more or less equivalent to cab signalling, in that drivers are assumed always to know what the next signal aspect is. In principle, it is not too hard to assign rail vehicles a property of having or not having either moving block or cab signalling equipment (defined in the .dat files), and further operating only according to cab signalling principles when the train has cab signalling installed and the next signal is compatible with cab signalling. What might be slightly trickier is simulating the economics of retro fitting existing vehicles with cab signalling equipment - the only easy way of doing this is to have two versions of the vehicles in the .dat files, one with and one without cab signalling, and define an upgrade path between them. That is a trifle cumbersome, but it will probably have to do.

Returning to the earlier questions about absolute block signalling:

Quote
Main signal (block signal?):
On green: Set track speed.
On Red: stop.

This is still not quite correct. The signals do not, of themselves, set the track speed. The track speed is a property of the track itself (and the way object, too, if it has its own speed limit). The speed at which a train can go is determined by:

(1) the track/way object maximum speed;
(2) the train's own maximum speed;
(3) the curvature of the track; and
(4) the need to brake in time for any upcoming:
(a) speed limit reductions (of any type - whether track, way object or curvature);
(b) stations;
(c) reversing waypoints; or
(d) signals that might be at danger.

To that sublist list we might add "other trains" in a moving block or drive by sight system. As explained above, the train (driver) will know where the next stopping point is and start braking in good time to stop there, taking into account the current speed and the train's braking capabilities. In the absolute block system, we just need to add the concept of being ignorant of the aspect of the upcoming signal (and therefore whether the train needs to stop for it), and the means of overcoming that ignorance (the signal's sighting distance, and signals with a caution aspect).

There is one exception to that, and that is the signal sighting speed limit, which, as discussed with Kieron above, is 200km/h in the UK. This means that for any train not equipped with cab signalling or where the next stop signal is not compatible with cab signalling, it will not in any event be able to travel more than 200km/h. I suggest that the signal sighting speed limit be set in simuconf.tab.

QuoteDistand signal:
Green/red: Set speed depending on number of green signals ahead (this can be track speed or max speed limit)

In UK signalling practice, distant signals display yellow and green rather than red and green aspects - one should rather talk of "caution" and "clear" designations than use colours. Again, this does not actually set the speed as such, but gives information to the train as to whether it will have to stop at the next signal or not, so that it knows whether to start braking to stop for it or not.

Quote
With track speed I mean the speed the train would have on a "normal" clear track.
With max speed limit I mean the signal will decide a new max speed for the block. It is however caped to the track speed.

As stated above, we cannot really have speed signals with a fixed speed in Simutrans because it is not practical to have any means of reliably calculating what that speed should be. What is needed is a means of communicating to the trains whether the next signal (and the signal after next) will be at danger or not.

Perhaps it is best to conceptualise it in this way: in absolute block signalling, a signal can have any of the following states:

(1) stop: do not proceed beyond this signal;
(2) proceed, but assume that it will be necessary to stop at the next signal capable of displaying (1) unless and until the next signal is visible and shows otherwise; and
(3) proceed, and assume that it will not be necessary to stop at the next X number of signals capable of displaying (1).

State (1) corresponds to the danger aspect of all double and multiple aspect signals. State (2) corresponds to clear on a double aspect signal (a semaphore stop signal or a two aspect colour light signal) or caution on a distant signal or a multiple aspect signal. State (3) where X = 1 corresponds to clear on a distant signal, clear on a three aspect signal, and double caution on a four aspect signal. State (3) where x = 2 corresponds to clear on a four aspect signal. (In Kieron's example of experimental five aspect signalling, the flashing green would be state (3) where X = 3).
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Max-Max

James,

I will try to be as frank as possible without the meaning of being rude, maybe I just have a hard time to explain my thoughts.

I'm trying to design a system that will work for as many countries as possible, not only UK. I have perfectly well understood the UK distant signals by following the very detailed corresponding in this thread and various information from Google.

This article explains in a very simple way the differences between the UK and US/European signal systems.

I'm trying to break down the functionality from a program design perspective. A distant signal may have the possibility in the PAK .dat file to be configured to set a maximum speed because this is how it work in many countries, including Sweden. It also has to be able for a configuration to work as an UK distant signal.

Here is a some what not fully translated (the original Swedish has more text) Wiki about Swedish signals. The German distant signals can also show a max speed limit as seen here and what I make out of it it is 40, 60 and 100km/h. This is another excellent site for German signals. The Italian distant signal can also indicates a maximum speed, and so can Polish etc...

I'm trying to figure out what functions do we need to create all these different signals in the PAK file, through the .dat configuration.
Some parameters would be more appropriate to put in the Simutrans.conf file I guess, like how far can the driver see? In theory, he would be able to see a light from an even further distance during the night. Should the terrain block line of sight? etc...

I wrote "track speed" to avoid a long novel about how the train's speed is calculated. As I understand, this is already implemented and has very little to do with this signal project, except that we need to recalculate the speed depending on the distant signal UK style, where we use train mass, speed, break ability and what ever we need to adjust the speed to the next indicated full stop. I can be completely wrong on this point, but please do correct me. I just feel that this is a far to detailed discussion at this point. Let us just say that the train must be able to stop in time at a certain point.

I agree that a signals colour is irrelevant for the discussion, let us continue on your definition of track clear, proceed with caution (at danger) and full stop. Now, I'm still on a very high level of brainstorm/design phase. So far I have concluded:

(1) That a signal needs to see X number of blocks ahead.

(2) One or more rules to "search" for a path through the blocks in (1).
    (i) "normal" path finding (as of a block signal today)
    (ii) "choose" path finding where more than one alternative can be chosen (as for a Choose signal of today).
    (iii) "crossing path" allow a train to proceed even if another train is crossing its path, the train will stop if it needs to avoid a collision (this is a
pure brainstorm but would allow us to create dwarf signals on shunting yards).
    (iiii) search for "road crossing". This would tell it to only look for a crossing of another type than itself. In this way we can create signals for road/tram crossings.

(3) It must react to the outcome of (2) in one of two ways.
    (a) adjust the speed to stop in time before next confirmed full stop (UK style).
    (b) adjust the speed against the the indicated max speed by the signal (non UK systems). The track's "track speed" has of course the highest priority, then the train and last the speed indicated by the signal. It is common sense that a train that can travel at max 30km/h can't suddenly go up to 80km/h on a 50km/h track just because a signal say "maximum speed allowed 80km/h". It would of course still proceed at 30km/h (unless other factors makes it go even more slow).

If we combine these 3 elements in the PAK .dat file, the PAK designer should be able to create the most kind of signals. Exactly how this would be done is to early to tell at this stage, just embrace the thought that it is possible. I'm tempted to write a simple scanner and parser for the .dat files. This would open up a lot more possibilities of what can be done in a .dat file.

The challenge with (1) is that we also need to give feedback to the signals behind us, up to X blocks, so they can be updated correctly as we pass each signal. One thought that comes to my mind would be to have the train carry a list of passed signals and remove them when we past the signals range.

If we now leave all the technical details for a while, is there a scenario I have missed? Can we create the signals we need with these components?

As a side note:
When It comes to ATC and the new ETRMS I think we can expand on this structure and replace signals with eurobaliser and radio stations covering covering them. ETRMS Level 1 and ACT still use signals but can adjust the speed between signals if the conditions change. ETRMS Level 2 and 3 will just require different elements to operate, like tracks, eurobaliser, radio and moving block algorithm.

The code and logic to drive the signals are mainly in the train, so to implement ACT or ETRMS would "simply" be a new set of rules (what block to look for and react on). But we can leave this for now.
- My code doesn't have bugs. It develops random features...

jamespetts

Thank you for the helpful reference to that article - signalling in the US is indeed very different (the most interesting difference seems to be the non-totality of signals, and the frequent use instead of the "track warrant" system).

We do indeed need to specify very carefully what functionality that we need to implement in a somewhat abstract way. One of the things that is particularly difficult for us to do properly is the (fixed) speed signal. Presumably, in real life applications, these speeds are not plucked out of the air, but based on the actual expected braking performance of trains combined with the spacing between the signals. We cannot really do that in Simutrans - at least not without a fiendishly complicated system for placing signals and spacing them automatically based on expected braking performance (where do we get that from? And then what happens when two sets of automatically spaced signals merge on a junction - etc.). Indeed, the article on Swedish signalling suggested that the distances between speed signals there are very precisely set. Presumably, the 40km/h speed (the only true limit that seems to be given by the signals themselves - the 80km/h limit appears to be Sweden's maximum speed without ATC, which seems to be a form of moving block or cab signalling) is based on the expected braking ability of trains, the spacing of signals, and the sighting distances such that a train travelling at 40km/h can stop by the next signal within sighting distance of it? (I daresay that the same applies to the seemingly rather convoluted Italian system).

As to the "crossing path" - how would this work? I am not sure what you mean here. As to road/tram crossings, all signals (including choose signals) ought not to allow a train to proceed beyond them if the path between them and the next signal is occupied by a level crossing that is not (1) free of traffic; and (2) closed to traffic.

As to a .dat file scanner and parser - what had you in mind here? How do you imagine this opening up new possibilities?

As to this point:

QuoteThe challenge with (1) is that we also need to give feedback to the signals behind us, up to X blocks, so they can be updated correctly as we pass each signal. One thought that comes to my mind would be to have the train carry a list of passed signals and remove them when we past the signals range.

I don't think that we actually need to do this - unless you want fully to simulate automatic signals on straight stretches of track even though this would largely be cosmetic. All that we have to do is have signals at danger unless a path is reserved from it to the next signal on an approaching train's route. There is no need for a train to communicate backwards to tell signals that it has passed what to do; all the logic can be put in what happens when a train requests that a route be reserved beyond a signal, as is the case now.

Quote
When It comes to ATC and the new ETRMS I think we can expand on this structure and replace signals with eurobaliser and radio stations covering covering them. ETRMS Level 1 and ACT still use signals but can adjust the speed between signals if the conditions change. ETRMS Level 2 and 3 will just require different elements to operate, like tracks, eurobaliser, radio and moving block algorithm.

The code and logic to drive the signals are mainly in the train, so to implement ACT or ETRMS would "simply" be a new set of rules (what block to look for and react on). But we can leave this for now.

I am not sure quite how you imagine implementing the "eurobalisers" here. For moving block signals, all that we have to do is work out the braking required to stop before the next train rather than signal on the path, taking into account the fact that, if moving, that next train itself will take time to stop, and update the reservation ahead every tile passed, rather than only when approaching a signal. We can use the same basic code to check for signals ahead and brake in time for them as is in the code already, just adapted instead to look for trains as well as signals.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

cy087

(Just passing by and noticed the question "is there any scenario missed?".)

To my mind there is one thing missing in simutrans regarding rail transport and that is "speed boards". In rural Australia there are many sections (somewhere between a simutrans signalling block and a simutrans track tile) that have absolute maximum speeds, regardless of the maximum rated speed of the road construction, curvature or control mechanism.  The reasons for speed board controlled sections ranges from the shunting/switching reasons already touched on in this discussion through to more complex conditions such as environmental hazard zones (for example, sections where track deformation due to extreme heat is possible; sections where advance visibility can change suddenly due to prevailing weather conditions (( I'll give this one a special mention as it includes sections in tropical or even temperate areas subject to sudden fogs)); sections where interfaces between normal & non-normal operating rules apply; sections with histories of SPAD incidences; etc.

My main point is, that these sections have a fixed maximum speed, regardless of anything at all but in particular regardless of the rated track speed.

As I indicated, this is just an observation on a fascinating topic and I have posted it only within my understanding of the intent of the experimental branch to make things more realistic.  I feel sure that speed boards have their equivalent in non-Australian rail systems.  The Australian system, by the way, appears to have borrowed signalling methodologies from where-ever as well as from it's English system heritage and then modified them to suit not only national but local conditions.  For example, (and beyond the discussion here) in central Sydney there are road guarantees as low as 6 minutes in some places in order to cater for metropolitan, inter-city and interstate passenger services AND freight consists all using the same main lines. Frankly, if you do not accept an offer and enter it within the six minutes then the section is closed and the offer is revoked. Fullstop.  Another anomaly is the hesitancy to adjust SafeWorking rules to accommodate in-cab signalling, possibly due to the wide age range of  operating equipment.  Finally, (AFAIK), reliance on ATC beyond metropolitan boundaries remains a dream, the Queensland "Tilt train" incident being a perfect example (refer section 2.1).

cheers
CY087



jamespetts

Interesting - thank you for your suggestion. May I ask, however, what exactly is the "rated track speed" if not the speed shown on what you describe as a "speed board"? Certainly, in the UK, the speed limit of any section of track is always shown on a board or sign of some or other sort, so the two are not conceptually distinct. In terms of simulating this, how might this fit in with the things that Simutrans actually simulates? What conditions that are already in themselves simulated would give rise to this "speed board"?
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Vladki

Hello,

I have read through this discussion, and as I would like to see distant signals working in Simutrans, I wanted to share some info about czech signalling so that you can compare.

Main lines have "autoblock" - three light signals evenly spaced with the following states:
green - clear, go at full speed
yellow - warning, start braking so that you can stop at the next signal
red - stop.
Some lines have four light signals at shorter distances. The extra signal is:
yellow and white - repeated warning - this is the last signal before red, yellow was on the signal before this one.
Autoblock signals so far away that trains can safely start braking after passing the yellow light. However the yellow and white signal is not far enough and the train should be already braking when approaching that signal.
For simutrans implementation I would suggest maybe simplistic solution - just keep the braking code as is, and modify only the display of signals. When the train is approaching a signal, try to reserve as far as the braking distance is, plus one more block. If it can be reserved - show green. If only the braking distance can be reserved - show yellow, and if we are closer to the red signal (end of reservation), show yellow and white.

On czech railways we have signals that tell the max speed, but they are used only when entering or leaving the station when the train goes through switches. They are never used on straight track. There are also distant signals telling the max speed on next signal. But I think this is a completely different stuff.

Tracks without autoblock use distant signals with yellow/green, and main signals with red/green. Distant signals are always put in safe braking distance from the main signal. There are also special crossing signals put in braking distance from road crossing, to inform the train driver whether the crossing is closed or not. Crossings close to other signals (or on autoblock lines) may be bound with them - signal goes green only when the crossing is closed.

So, I hope some of this info will be useful for you.

Vladki

jamespetts

This system seems very similar to the UK system described, except for the colours and sequence of the four aspect signals, and the absence of speed limits on all track. The way to implement this system is as already described for the UK signalling: to make it work for Czech signalling, one would just have to produce different signal graphics.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

cy087

Quote from: jamespetts on May 09, 2013, 09:42:56 AM
Interesting - thank you for your suggestion. May I ask, however, what exactly is the "rated track speed" if not the speed shown on what you describe as a "speed board"? Certainly, in the UK, the speed limit of any section of track is always shown on a board or sign of some or other sort, so the two are not conceptually distinct. In terms of simulating this, how might this fit in with the things that Simutrans actually simulates? What conditions that are already in themselves simulated would give rise to this "speed board"?

1. The rated track speed is the speed limit depending on track construction and track layout (and grade).  This is well implemented in the game.
2. Sometimes (in the game) where a high speed passenger service and a low speed freight service contend for a block a passing loop is built to enable the passenger service to overtake the freight.  While this is achievable using way-points in the freight line and a lower grade track on one section to "slow" the freight to the point that the passenger service can overtake that approach tends to look ugly to me, means the freight will always use the "low speed lane" and can be difficult to implement with interference from weight limits.  If the passing loop could be a controlled speed area perhaps the code could
a) slow the freight sufficiently to increase the probability that the following passenger service can overtake
b) route the freight over the slower side of the loop only if there is a following consist with a higher maximum speed (maybe this is harder).


jamespetts

Quote from: cy087 on May 10, 2013, 04:25:57 AM
1. The rated track speed is the speed limit depending on track construction and track layout (and grade).  This is well implemented in the game.
2. Sometimes (in the game) where a high speed passenger service and a low speed freight service contend for a block a passing loop is built to enable the passenger service to overtake the freight.  While this is achievable using way-points in the freight line and a lower grade track on one section to "slow" the freight to the point that the passenger service can overtake that approach tends to look ugly to me, means the freight will always use the "low speed lane" and can be difficult to implement with interference from weight limits.  If the passing loop could be a controlled speed area perhaps the code could
a) slow the freight sufficiently to increase the probability that the following passenger service can overtake
b) route the freight over the slower side of the loop only if there is a following consist with a higher maximum speed (maybe this is harder).

(a) does not make a great deal of sense - why should the freight train slow down on the loop unless there is a passenger train needing to overtake (in which case, why slow down, rather than just stop at the end of the loop?).

In order to make this work in a useful way (something like your (b)), what would be needed is contingent orders in schedules, which would be enormously complicated, not least from the user's perspective (what - exactly - would a user actually input to a revised schedule window to explain to the freight train what exactly it is looking for and where for it to trigger the relevant condition?) The easier thing is for users to construct what are in effect timetables using the spacing/offsetting procedure so that freight trains and passenger trains meet in predictable places; if a(n empty) freight station is placed on the loop, the freight train can be made to wait at the "station" (sidings) until a particular time.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

merry

Ok, lots of good work going on in here. As someone with an interest in signalling, I'd like to add some observations:

(0) All signalling systems are an effort to avoid trains colliding, either through long stopping distances or conflicting routes.

(1) all fixed-block systems of train control (semaphore, 2-aspect, 3 & 4-multiple-aspect [MAS], RETB, and even ERTMS level 1 & 2 and dispatcher-based systems) are fundamentally the same idea. One train per defined section, please! I think that the French TGV/Eurostar TVM430 (and predecessors like TVM380 [number might be wrong] are cab-based ways to do this with the addition of speed indication as below). The exact form colour and positioning of the signals is not important as the basic function is the same. Block based transmission based systems (including Eurobalise) will still need blocks to be defined.

(2) all speed signals are a way for the signalling to tell the train (& driver) what is the safe speed at which they can (a) travel over the infrastruture without risk of derailment or damage, and (b) expect to stop within the available blocks. TPWS is a UK example of a cab-based solution to this. Fixed track speed limits are speed signals with one indication, in all but name.

(3) The UK distant signal is, in effect, a 'speed signal', but in the UK the driver is expected to have 'route knowledge' and to know the permissible speeds at which a signal may be passed to stop safely at the next known danger indication.

(4) moving block systems are different: track speed is observed by the signalling too, but the train effectively reserves the necessary stopping distance ahead only [actually the signalling system gives a continually updated authority, but let's not worry about this, it's irrelevant for ST] . A complication for ST is to reserve routes correctly through single lines and junctions especially where trains can follow one another at short safe separations - you can't reserve the whole block ahead, but you need to book the route for reservation when available and prevent opposing moves on single lines. This could provide an improved way of handling

(5) Level crossings: not all require to be closed when a train enters the block:
   (a) Busier crossings are directly protected by signals, and require to be closed to conflicting traffic before the signal can show a proceed aspect
   (b) other crossings are closed to road traffic upon the approach of a train. In semaphore days, this required a crossing keeper but was not a block post. In the UK, many had distant signals but were not block posts. Nowadays a good example is the AHB (for all the associated risks of users ignoring them) or the open crossing with warning lights (on slow tracks) - they operate automatically and only when the train approaches. This allows crossings to be protected in long block sections without being closed to the road for an unreasonable time
   (c) 'accommodation crossings' [Uk term, but the idea occurs in many countries] are normally closed to road traffic, and opened by the road user upon the authority of a signaller, or simply upon adequate visibility. Obviously these are only on low/medium speed lines and for low road traffic, such as farm or individual properly access!

(6) All the above require a singalling control point - some are quite local (traditional signal boxes), others cover huge areas, e.g. the UK regional operations centres, or central radio dispatcher centres. In the middle are Power signalling centres, covering districts or route sections.

(7) <pedantry>
To clarify & avoid confusing false descriptions, a single-aspect signal is an end of line! Semaphores and colour light distant+stop signal systems are 2-aspect (where each signal has either red/green or yellow/green). Note London Underground only uses 2-aspect - many LUL distants are mounted on the same post as the preceding 'stop' but are not 3-aspect signals!
</pedantry>

( 8 ) Drive on sight is what James describes above, but it still needs signalling or dispatcher control for single lines and for junctions. There may be a need to be able to define the end of 'block signalling' after a signalled portion of line if this is implemented.

What i'm trying to get at is that there are really only two types of signalling - fixed or moving block - and everything else is an implementation of these. Speed signals are implemented by the braking distance and infrastructure limits in ST and are not actually needed.

As a thought, the discussion includes systems requiring a central control point (e.g. ERTMS or Dispatchers). To have these explicitly woudl be nice, but this implies a need for signal control points of different types and grades - from a crossing cabin to a regional control centre. Lots of change for some realism but I wonder it the work is worth it for the game improvement?

To add a personal opinion, I'd very much like to support james suggestion of  removal of the 'pre-signal' and the implicit platform signal, and replacement by a proper train control system to allow single lines to be handled without deadlock. I am fairly sure that amongst the desirable  moves would be to make all signals able to be passed in the reverse direction [noting that this is always real-life practice; where bidirectoinality undesirable there is a 'fixed stop' signal or a lack of track authority in the other direction, which in ST would be a 'rail close' signal, commonly found is ST standard already but not in PakBritain!] thus enabling bidirectional platform signalling instead of the current implicit platform signals. it would also allow two trains to follow through a section with mid-section signals on a single line, etc, etc.

Hope this helps the debate, please keep up the excellent development!

TTFN
Merry
last edit reason: remove auto-generated smileys!

cy087

#90
@James

Yes, exactly. I don't know enough about the internal workings of Simutrans to offer a functional specification of how this could be done, but contingent orders would seem to be the "most obvious way" to resolve that scenario.  As far as I know, those contingent orders are far beyond the capabilities and expectations of the game. So be it. 

But now we are digressing from the matter of speed boards. 

The simple aspect is this.  As you said, (in real life) sign posted speed restrictions over road sections (not blocks) are a general way to provide safe working conditions for any traffic.  I was looking for a game oriented example of how speed boarding can "make things easier" for the player. But, yes it "makes it more complicated". Culpe mea!

Such is life.  We may have digressed a little bit from the intent of the thread and I apologize for that   --  it was just the question about "is their anything forgotten".  So to get it down to its' simplest and within the intent of what I originally posted. There is a non-signalled road control mechanism in the real world, and (apart from the fact that it is missing in the game) that was all I wanted to say.  So, having said that, let me now say this this. "This!" :-)

Anyway,  the game is still fascinating and I applaud all of you adding more and more to it.  So stop listening to me and get on with making those signals work.

@merry
Nice synopsis. Some really good real life scenarios raised and much better than I could put them.

best regards
CY087

Max-Max

Regarding speed boards.

I do see little function to have a speed board limiting the speed, more a cosmetic detail for the player. However for roads, we can today put up a minimum speed board to divert faster trucks onto a faster route. AFIK these speed boards doesn't exist in reality, we are just told that we aren't allowed to drive 50 on a 110 highway. However this is implemented as a game feature to solve a problem.

If we made the same kind of speed boards for trains we could easily solve the same issue without adding way points. When the train looks for a path, it will tray to select the fastest (km/h) path. This solves a problem and adds to the realism in Simutrans, without having a counterpart in the real world.
- My code doesn't have bugs. It develops random features...

Vladki

Quote from: Max-Max on May 11, 2013, 12:14:14 PM
If we made the same kind of speed boards for trains we could easily solve the same issue without adding way points. When the train looks for a path, it will tray to select the fastest (km/h) path. This solves a problem and adds to the realism in Simutrans, without having a counterpart in the real world.

Minimum speed signs for railroad exist - see here: http://forum.simutrans.com/index.php?topic=10813

Max-Max

- My code doesn't have bugs. It develops random features...

AP

Quote from: Vladki on May 11, 2013, 12:24:50 PM
Minimum speed signs for railroad exist - see here: http://forum.simutrans.com/index.php?topic=10813
They just aren't in all paks yet (e.g. not in Pak.britain or pak.britain.experimental, although eagerly awaited!).

Max-Max

Yes, I figured that if the code is in place :)

James,

I'm starting to have some questions about the actual code now... Should we do this in a new forum thread?
- My code doesn't have bugs. It develops random features...

jamespetts

Merry - thank you for your contribution: that is most detailed and helpful.

Max-Max - yes, it is probably sensible to have a separate thread about the coding mechanics of this, and this thread can remain comprehensible by non-coders to discuss in principle how things ought to work.

Thank you all very much for your contributions to this subject!
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Max-Max

One more thought...

The current implementation of distant signals (pre-signals) stops a train if the next signal isn't clear. This creat a chain reaction where all cascading distant signals has to be clear before the path up to the next main signal is clear.


---t2>---P2-\
            |    /---S1
---t1>---P1-+-C-+----S2
                 \---S3


Asume train t2's path goes through pre-signal P2, chose signal C to enter a free station S1 to S3. If S1, S2 and S3 are occupied we don't want t2 to stop in front of C blocking t1. With the distant signal we have talked about here, this scenario hasn't been addressed. How do we create the current pre-signal behaviour in our "new" system? It is basically a main signal with a condition; show clear if we can reserve path to next main signal.

Maybe we need to add one more rule to our basic needs of signal functions?

James asked what benefits we would get out of a parser? The parser is a structured way to easily classify characters and words. With a parser we can do proper syntax check and add reserved words in a centralised way.

This could be handy when we define our new signals and their states (.dat file).
- My code doesn't have bugs. It develops random features...

jamespetts

Hmm - would the solution in the above scenario not simply be to remove signal "C" and replace "P1" and "P2" with choose signals? As to the parser, can you elaborate on how this would be used in practice, perhaps with an example? I am not sure that I really follow.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Max-Max

#99
The signals was just an example, maybe a bad one. Okay here is another one.

---<-B1-\
t1->-B2-+-<->-+--<->--
              |
              \-P--<-t2


Train t2 wants to go on the green path, P on to a 2 way track turn make a turn to block signal B1 on a one way track. In this case B1 shows STOP. Without P, t2 would occupy the double way line and wait for B1 to clear. Meanwhile train t2 comes but has to wait for B1 to get t2 out of the way before B2 shows clear.

If we put P into place, t2 will stop at P instead and t1 can pass meanwhile t2 is waiting for B1 to clear.

One may argue that B1 can be moved just further away, but since it is a block signal, this would not help, unless B2 is a pre-signal. There can be other reasons why B1 can't be moved. Again this is only an example to show how powerful the pre-signals are today. I use them all the time to keep waiting times as short as possible and not block the line.

Regarding a parser.
I don't know if you are familiar with a "standard" compiler/interpreter design. The scanner classifies each character such as white space characters, digits (0-9), letter a-z and A-Z, symbols etc... These are then turned into tokens such as integer, real, reserved words etc...

The parser basically asks the scanner for the next token and executes its. It doesn't need to know anything about white space or how to read a number. From there you can add simple expressions such as 2+3*6-(alpha/beta). The dat files could with some effort have small "scripts" defining the signal's function.

signal(mainSignal) {

  States {
    Clear:
      Block(1) status clear

    Stop:
      Block(1) status not clear
  }
}

Here we define a "mainSignal" and the condition to signal "Clear" is; the following block has to be clear. A stop condition is when the following block is not clear.

To create a combined main and distant signal one may script:

signal(comboSignal) {

  States {
    Clear:
      Block(1) status clear
      Speed(UK)

    caution:
      Block(1) status clear and Block(2) status not clear
      Speed(UK)

    Stop:
      Block(1) status not clear
      Speed(0)
  }
}


These is only brainstorming, but with a parser it is more easy to implement some more flexibility into the .dat files.
- My code doesn't have bugs. It develops random features...

TurfIt

Quote from: Max-Max on May 12, 2013, 01:59:27 AM
The signals was just an example, maybe a bad one. Okay here is another one.
You've just shown the exact use for Simutrans two block signals (those signal with the unfortunate pre-signal name stuck to them). In real life, signal P would not be an automatic signal. It would be controlled by a signaler/dispatcher who would make the regulation decision on whether T1 or T2 should go first. Simutrans signals are all automatic, and hence sometimes need different logic from any real life signal to prevent deadlocks. Unless someone cares to implement a super smart dispatcher algorithm, real life signaling cannot just be inserted and expected to work...

Erik

Sometimes I'm thinking about how to make the route search and signaling smarter. It will be nice to have that the trains aren't jammed each other in a circle when the train network gets more complicated.

I use Pre-signal barely by my self. Mostly I prevent to need them, because often they will work for the one direction but not for the other.

About programming.
The current Pre-signal (a.k.a. 2Block signal) has something like this:
Signal(Pre-signal){
   if(first block clear){
      if(next signal clear){
         Clear
         }
      else {
         block
      }
   else {
      block
   }
}


So for the distant signal it has to become:
Signal(Pre-signal){
   if(first block clear){
      if(next signal clear){
         Clear
         }
      else {
         Limit speed()
         Clear
      }
   else {
      block
   }
}



jamespetts

As to your example, what is the purpose of signal B1? Can it not be removed entirely? If a train will only ever get to approach it if it is clear (by going through P1), then is exactly the same effect not achieved by removing it and letting trains wait until they have a clear path through to the next signal? Indeed, is that not generally the answer in pre-signal cases: to remove the first stop signal along the line so as to make the block twice as large? Currently, pre-signals might be useful where some trains do and some trains do not stop at a station (with its implicit signal, making variable length blocks depending on stopping at stations); but, if this functionality is removed, it seems difficult to imagine this being relevant.

As to the parser - you mean effectively having our own scripting language for signals? Interesting, certainly, but perhaps a tad ambitious? There is a great deal of coding to go into that, and therefore a great deal to go wrong. Are we sure that what can be achieved with this cannot just as well be achieved with a few conventional parameters, and, if so, that the extra that can be achieved is on its own worth all the work of writing then debugging a parser?
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Max-Max

Even if B1 is moved you may end up with a train in front of it. If train t2 doesn't block t1's path, it is inside the B1 block, preveting B1 from showing clear.

Maybe I have missed something here... I use pre-signals all the time, can't imagine how to be without them. I will try to play around without the use of any pre-signals to see how that would be done.

But I can see now how this would work in a new system (thank you Erik) :)

signal(preSignal) {

  States {
    Clear:
      Block(1) status clear and Block(2) status clear

    Stop:
      status not clear
  }
}


When it comes to the parser, I think the code will be a lot more clean and more stable if we had a parser, even if it only supports the .dat files of today.

In the future it would be quite easy to implement more functions. In theory we can create different parser objects for different type of .dat files, without involving code scattered all over Simutrans. We already have a symbol table, but it is only used to insert symbols (when parsing .dat files). We could easily also use it for using variables values in the .dat file like (again just an example)

BaseDir= ./images/signals/
signal(combo3blockSignal) {

  States {
    Clear:
      Block(1) status clear and Block(2) status clear and Block(3) status clear
      // set speed and other params for this condition

    Caution1:
      Block(1) status clear and Block(2) status clear and Block(3) status not clear
      // set speed and other params for this condition

    Caution2:
      Block(1) status clear and Block(2) status not clear
      // set speed and other params for this condition

    Stop:
      status not (Clear | Caution1 | Caution2)
      // set speed and other params if next block status isn't one of the above
  }

  image[Clear] = BaseDir + sg01
  image[Caution1] = BaseDir + sg02
  image[Caution2] = BaseDir + sg03
  image[Stop] = BaseDir + sg04
}


If we have different variants we would like to test in the development process, we can simply just change BaseDir.
I'm not saying we should implement all this scripting right away, but if we have the vision in mind, we can design the code to be prepared for it. This small snippet is just a thought of how it might work. The state definition isn't static, the PAK designer can define his own states and attach graphics to it.
- My code doesn't have bugs. It develops random features...

Max-Max

James,

I forgot to reply on your comment regarding:

QuoteThe challenge with (1) is that we also need to give feedback to the signals behind us, up to X blocks, so they can be updated correctly as we pass each signal. One thought that comes to my mind would be to have the train carry a list of passed signals and remove them when we past the signals range.

The thought came up on the topic of 3,4,x aspect signals. Elaborate on the following setup:

---t1>---A3------B1------B2------B3------B4------

Train t1 aproach a 3 aspect signal A3 (maybe the wrong term here, but what I mean is that it shows the status for 3 blocks ahead, you get the picture). Block B1,B2,B3 and B4 are clear so A3 is reflecting this state.

When the train pass B1 the aspect signal is updated, now one block behind t1.
------A3------B1--t1>----B2------B3------B4------

As the train moves, the A3 signals needs to be updated for each block t1 passes.
------A3------B1------B2--t1>----B3------B4------

------A3------B1------B2------B3--t1>----B4------

------A3------B1------B2------B3------B4--t1>----

A3 will be located further and further away from the train and because the train is driving the signal, it needs to know where it is and when to stop updating it.

But I think I have a solution for it (as I mentioned before). This is why I think
Quote...need to give feedback to the signals behind us, up to X blocks...
is needed.
- My code doesn't have bugs. It develops random features...