|
|
| (189 intermediate revisions by one other user not shown) |
| Line 1: |
Line 1: |
| == GenericIM == | | ;[[Special:Interwiki]] |
| | | ==Transclusion from the {{rml|2}} wiki== |
| The very first step for setting up an interlocking file is the definition of the generic types. Although virtually depicted in the bottom of the schema these generic types come first as they are referenced by the more detailed data later on. The container {{tag|IL|specificIMs}} takes the data of the individual {{tag|IL|specificIM}}. It shall be noted although the type is named {{doc|IL|GenericIM}} the instantiation as element is named {{tag|IL|specificIM}}.
| | ;(Not functioning) |
| | | *{{raw:wiki2:dummy}} |
| Each infrastructure manager (IM) has a couple of rather specific items, which have impact on interlocking issues and functions. In order to achieve a common exchange format it is vital to define such specific items within a fixed generic structure still allowing the individual characteristics. This is the purpose of the generic types. They are providing a mean of common classification of functions being rather individual for any IM. However, these types do not specify the operational rules of that IM.
| | *{{raw:aaa2:dummy}} |
| | | *{{wiki2:dummy}} |
| Beside the {{tag|IL|designator}} and {{@|id}} it comprises a reference to the related set of assets in {{tag|IL|ownsSetsOfAssets}}.
| | *{{aaa2:dummy}} |
| | | ==Internal transclusion== |
| <syntaxhighlight lang=xml>
| | ;(Not functioning) |
| <specificIM id="BaneNor">
| | *{{raw:wiki3:dummy}} |
| <designator register=„_SimpleRegister“ entry="BaneNor (JBV)"/>
| | *{{raw:aaa3:dummy}} |
| <ownsSetsOfAssets ref="ass_simpex_v0.9"/>
| | *{{wiki3:dummy}} |
| ……
| | *{{aaa3:dummy}} |
| </specificIM>
| | ==Transclusion from Wikipedia== |
| </syntaxhighlight>
| | ;(Functioning) |
| | | *{{wikipedia:wikify}} |
| The object {{tag|IL|specificIM}} is filled with the data of items specific for this IM. Such specific items are typical items like signal aspects or route handling.== Signal Aspects ==
| |
| | |
| Each IM has clearly his own set of signal aspects he uses for controlling train traffic. They are defined in {{tag|IL|hasAspect}}. Beside these individual characteristics, there are some common principles, which are considered here. At first the wide range of signal aspects can be categorised in several groups for the description of their meaning – the so-called {{@|genericAspect}}. There are the following possibilities on the list:
| |
| *{{enum|closed}} – This is used for any aspect with the meaning “Stop here”.
| |
| *{{enum|callOn” }}– This is used for any auxiliary aspect with the meaning “Pass at reduced speed with clear visibility over the route ahead” because the signal cannot be cleared normally. In most cases such aspect is used with a special call-on route. | |
| *{{enum|caution}} – This is used for an announcing aspect/slave aspect with the meaning “expect Stop” at next signal. | |
| *{{enum|warning}} – This is used for an announcing aspect/slave aspect with the meaning “expect any kind of proceed” at next signal. | |
| *{{enum|proceed}} – This is used for any aspect indicating the allowance to continue running without any speed restrictions, i.e. proceed with line speed. However, such aspect can be combined on a signal with a speed indicator restricting the allowed speed against the main aspect.
| |
| *{{enum|limitedProceed}} – This is used for any aspect indicating the allowance to continue running with restricted speed. This is typically used for diverging routes or ones with reduced braking distance. In addition this main aspect might be combined with a speed indicator restricting or relaxing the allowed speed against the main aspect.
| |
| *{{enum|combinedProceed}} – This is used for any proceed aspect where the master and the slave aspect is combined within one single aspect like this were common in OSShD<ref name="ftn1"> Organization for Cooperation of Railways as the equivalent of the International Union of Railways (UIC)</ref> networks. Of course, this applies only to proceed aspects as with the signal closed no slave aspect is given.
| |
| *{{enum|supplementary}} – These are any additional signal aspects which are combined with the main aspect without causing a restriction or giving pure information. Such combination shall be supervised by the interlocking and a failure will affect the main aspect as well. A good example is an additional indicator announcing the change onto the wrong track, i.e. line track normally used in the opposite direction. | |
| *{{enum|restriction}} – This aspect gives an additional restriction to the main aspect. A failure of such aspect will affect the main aspect of the signal. An example would be a speed indicator restricting the main proceed aspect. | |
| | |
| *{{enum|informative}} – In contrast to supplementary aspects they are giving pure information without any consequences neither to the main aspect nor the train traffic. A failure of this aspect would not affect the main aspect. An example for an informative aspect is any aspect from a direction indicator. It can be also a speed indication if it is relaxing the speed information of the main aspect. | |
| | |
| | |
| | |
| In addition to the generic meaning, the aspect shall have a specific naming in {{tag|IL|designator}} and {{@|id}} to refer to it.
| |
| | |
| The list of three main aspects for IM “BaneNor” would look like this in railML:
| |
| | |
| <syntaxhighlight lang=xml>
| |
| <hasAspect id="sig_closed_20" genericAspect="closed">
| |
| <designator register="_SimpleRegister" entry="Signal 20A/B «Stopp"/>
| |
| </hasAspect>
| |
| <hasAspect id="sig_reducproceed_21" genericAspect="limitedProceed">
| |
| <designator register="_SimpleRegister" entry="Signal 21 «Kjør med redusert hastighet"/>
| |
| </hasAspect>
| |
| <hasAspect id="sig_fullproceed_22" genericAspect="proceed">
| |
| <designator register="_SimpleRegister" entry="Signal 22 «Kjør"/>
| |
| </hasAspect>
| |
| </syntaxhighlight>
| |
| | |
| Just for illustration an extract from the operator’s manual (togframføringsforskriften) is given here including the optical appearance which is not included in {{@|genericAspect}}. The mapping between the aspect and the activated lamps might be done with another {{doc|IL|genericType}} but this is currently <span style="background-color:#ff00ff;">not yet implemented}}.
| |
| | |
| <div style="text-align:center;">[[Image:Grafik 1.png|top]]
| |
| | |
| The related distant signal aspects would look like this in railML:
| |
| | |
| <syntaxhighlight lang=xml>
| |
| <hasAspect id="sig_caution_23" genericAspect="caution">
| |
| <designator register="_SimpleRegister" entry="Signal 23 «Forvent stopp"/>
| |
| </hasAspect>
| |
| <hasAspect id="sig_warning_24" genericAspect="warning" >
| |
| <designator register="_SimpleRegister" entry="Signal 24 «Forvent kjør med redusert hastighet"/>
| |
| </hasAspect>
| |
| <hasAspect id="sig_warning_25" genericAspect="warning">
| |
| <designator register="_SimpleRegister" entry="Signal 25 «Forvent kjør"/>
| |
| </hasAspect>
| |
| </syntaxhighlight>
| |
| | |
| <div style="text-align:center;">[[Image:Grafik 2.png|top]]
| |
Template documentation
Latest appearance of this template (before deletion):
Template documentation