(23-09-2010, 06:40 AM)jenni.joseph9 Wrote: Hi,
Awaiting further comments and very grateful for the analysis done, so far.
Reasonable attempt at
Points Control Tables.
I have notices a few one-off mistakes and particularly some missing routes, but some more generic things are:
1. You tend to show overlap track sections to the end of the overlap whereas you should restrict to those that are locking the points. Typical SSI practice is to list up to the sub-route prior to the deadlocking track.
2. Conditioning out of route locking by track occupied for time should be shown to apply only to those track sections that could reasonably be occupied; you place the opening bracket wrongly.
3. Where there are a pair of tracks in a platform, then occupancy of either would generally be used to release overlap locking.
4. You should only list those tracks in the overlap beyond the signal up to but EXCLUDING the track containing the points
5. If there is a foul track, then the route locking should be shown to extend onto that track circuit section.
6. Do a cross check that the last track listed as route locking holding the points is the last applicable deadlocking / foul track circuit.
Even though switch diamonds do not provide effective flank protection, suggest that it is worth setting and locking (although not detecting) appropriately as often does help keep things safer when handsignalling.
Recommend that when it is not very clear from the layout depiction that you state assumption re IRJs being clear / foul.
Didn't understand why you wrote info re 237R>N on 236 point CT
Notice that you wasted all the time it took to include swinging overlap and time of operation loccking on your blank CT since these boxes were never used. Hence that is why I recommend a simplified CT without these boxes and that you write in on theose occasions when is actually needed.
Route Control Tables
Column headings OK apart from recommendation to distinguish between ppoint availability at route level and the aspect level proving of points set, locked and detected.
Not bad attempts; see my annotations.
Missing some opposing locking, particularly those that are prevented initially by ovrlap point locking but then need the opposing locking when the overlaps time out.
Also the opposing from routes which read into the CT route from beyond the exit signal; don't look far enough.
For swinging overlaps, either combine the track conditions in with the point conditions and cover all overlaps separately, or do as you have and write in the point conditions and separately hace different entries for the tracks but in which case be careful to get the point conditioning correct relative to those tracks.
Auto signals have no Approach Locking so can't really be ARAFOAL. Easiest thing is just to disregard and take lookback through them unconditionally (although we sometimes provide a functionality that is a form of pseudo A/L)
Do consider the possibility of SPAD where there are converging signals- either the traditional flank tracks otr the modern iverrun protection.
Do put in some approximate time values rather than "t"
Differentiate re which is the pre-setting route and which is the route that is pre-set
Ovrerall though reasonably good, so if you can do them in the time allowance then you'll be ok
