Home » railML newsgroups » railML.infrastructure » [railML 3] Areas in railML 3
Re: [railML 3] Areas in railML 3 [message #2837 is a reply to message #2836] Tue, 12 October 2021 14:42 Go to previous messageGo to previous message
Thomas Langkamm is currently offline  Thomas Langkamm
Messages: 25
Registered: April 2019
Junior Member
I like the idea. The only change I would like to suggest is a typization, as this would allow the users to distinguish different area types.

In general, if we reference areas required by other software systems (for example, work zones for a maintainance system, that defines which track areas allow certain types of work), we would use the designator as a way to pass references to this other software system. But it might make the structure easier (for a human to read, and for a machine to analyze) if we had an optional "areaType" string attribute, perhaps with some standard entries (as enum that could be extended by the user).

Some area types that I would consider as fairly common, so we might want to define a standard type:

  • Interlocking areas. This would be strictly part of the rail network as follows:

    1. Influence area, the area controlled by one interlocking
    2. Track sections, the "atoms" of the interlocking configuration where the interlocking shows/tracks occupations (a train currently in the region, or a train scheduled to enter the region). In many cases these will be identical to tvdSections, but there may be instances (and interlockings) where we group several tvdSections to one track section, or split a tvdSection into two or more track section (on account of having another train detection element in the tvdSection).
    3. Areas that can be used in interlocking operations, for example an area that could be controlled by one "shutdown" button (used to set all signals to red, for example used if some unauthorized humans are observed in the track area).
    4. Other interlocking-derived areas listed in the ticket https://trac.railml.org/ticket/393
  • Track regions belonging to different states, federal provinces or counties. These are typically needed to track commercial differences (like different penalties for delays or cancelled train journeys) or different legal requirements. In duty scheduling we might have different duty rules depending on the state.

  • Areas that allow a certain type of maintainance work, often as part of a maintainance system.

  • Areas grouped for a specific use in train operations. For example, we may have a group of tracks designated for overnight parking, while another group of tracks might be used as temporary storage for trains that need to be shunted to a different location (like a workshop) before their next journey starts.

  • GPS areas. For example, we could identify a train as "being near a station" if its GPS coordinates are in a certain circle or rectangle.
 
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Previous Topic: [railML3] switch reference point
Next Topic: [railML 2] ocp modeling
Goto Forum:
  


Current Time: Sat May 04 15:57:22 CEST 2024