This element does not appear in railML® 3.2 within the IL subschema. It is available only in railML® 3.1. Do not hesitate to contact railML.org for further questions.
IL:specificIM: Difference between revisions
Jump to navigation
Jump to search
| [unchecked revision] | [unchecked revision] |
(Created page with "{{subst:docBase |element=specificIM |subschema=IL}}") |
|||
| Line 10: | Line 10: | ||
{{importComment}} | {{importComment}} | ||
=={{examples}}== | =={{examples}}== | ||
{{ | == GenericIM == | ||
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}}. | |||
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. | |||
Beside the {{tag|IL|designator}} and {{@|id}} it comprises a reference to the related set of assets in {{tag|IL|ownsSetsOfAssets}}. | |||
<syntaxhighlight lang=xml> | |||
<specificIM id="BaneNor"> | |||
<designator register=„_SimpleRegister“ entry="BaneNor (JBV)"/> | |||
<ownsSetsOfAssets ref="ass_simpex_v0.9"/> | |||
…… | |||
</specificIM> | |||
</syntaxhighlight> | |||
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.<div> | |||
== 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}}. | |||
[[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> | |||
[[Image:Grafik 2.png|top]] | |||
=={{Additional Information}}== | =={{Additional Information}}== | ||
==={{Notes}}=== | ==={{Notes}}=== | ||
==={{Open issues}}=== | ==={{Open issues}}=== | ||
Revision as of 18:06, 16 January 2020
Introduction
Documentation
Syntax
Autoexport from the XML-Schema for element IL:specificIM of railML® version 3.1 | |
| Documentation | Container with the generic classification of types used by a specific infrastructure manager. |
| Subschema | interlocking |
| Parents* | specificIMs |
| Children | any (0..*), designator (0..1), ownsSetsOfAssets (0..*), usesTypes (1..1) |
Attributes:
| |
| *Notice: Elements may have different parent elements. As a consequence they may be used in different contexts. Please, consider this as well as a user of this wiki as when developing this documentation further. Aspects that are only relevant with respect to one of several parents should be explained exclusively in the documentation of the respective parent element. | |
Changes 3.1→3.2
Removed with version 3.2.
Semantics
Best Practice / Examples
GenericIM
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 <specificIMs> takes the data of the individual <specificIM>. It shall be noted although the type is named GenericIM the instantiation as element is named <specificIM>.
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.
Beside the <designator> and @id it comprises a reference to the related set of assets in <ownsSetsOfAssets>.
<specificIM id="BaneNor"> <designator register=„_SimpleRegister“ entry="BaneNor (JBV)"/> <ownsSetsOfAssets ref="ass_simpex_v0.9"/> …… </specificIM>
The object <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 <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:
- closed – This is used for any aspect with the meaning “Stop here”.
- 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.
- caution – This is used for an announcing aspect/slave aspect with the meaning “expect Stop” at next signal.
- warning – This is used for an announcing aspect/slave aspect with the meaning “expect any kind of proceed” at next signal.
- 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.
- 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.
- 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[1] networks. Of course, this applies only to proceed aspects as with the signal closed no slave aspect is given.
- 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.
- 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.
- 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 <designator> and @id to refer to it.
The list of three main aspects for IM “BaneNor” would look like this in railML:
<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>
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 genericType but this is currently not yet implemented}}.
The related distant signal aspects would look like this in railML:
<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>
Additional Information
Notes
Open Issues
- ↑ Organization for Cooperation of Railways as the equivalent of the International Union of Railways (UIC)