Skip to content
GitLab
Projects Groups Topics Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • railML 3 railML 3
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Graph
    • Compare revisions
  • Issues 70
    • Issues 70
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 0
    • Merge requests 0
  • Deployments
    • Deployments
    • Releases
  • Activity
  • Graph
  • Create a new issue
  • Commits
  • Issue Boards
Collapse sidebar
  • railML.orgrailML.org
  • railML 3railML 3
  • Issues
  • #305
Closed
Open
Issue created Mar 03, 2017 by IS Coordination@coordination.ISMaintainer

Introduction of a lock as new signalling infrastructure element

Description

Locks are physical railway infrastructure elements that are used for logical locking connections between switches, derailers, level crossings, or other signalling components.

Background

Railway signalling infrastructure plans visualize all the different signalling elements and their position. Since locks are also depicted, railML should include them into their data model.

Links

  • Forum discussion
  • Torben Brand, February 2017: [http://www.railml.org/forum/index.php?t=msg&th=484&start=0&]
  • Wiki documentation
  • IS:lock: [https://wiki.railml.org/index.php?title=IS:lock]

Proposed solution for railML 2.4

The lock can be considered being an operation and signalling system element. Therefore, it is suggested to add the as a child element of on the same level like and .

In a first step, this element shall have a child element, position attributes @pos and @absPos and a generic "any element / attribute" as anchor point for further specific extensions.

Proposed solution for railML 2.x

Based on the solution for railML 2.4, the element shall get further attributes and child elements:

The lock should reference the infrastructure elements that are locked together. Usually, there are two elements linked with one lock. It is proposed to model these linked elements in form of references as child elements. Further, it should be possible to define the part of the lock, where the key is kept by default. Therefore, the boolean attribute @hasKeyByDefault is proposed:

<lock>
  <lockedElement ref="le0815" hasKeyByDefault="yes"/>
  <lockedElement ref="le4711"/>
</lock>

There may be different types of locks. Consequently, we suggest to add a parameter for providing the information about the lock type: @type. Considering the fact that these types differ between the different countries, the attribute shall be a string value.

In order to specify the controller that controls the lock, an optional, repeatable child element is suggested.

Last, but not least, each lock may have one or more keys, that may be given as child elements with further attribute @code.

Proposed solution for railML 3.1

The element shall be named in infrastructure and in interlocking.

The infrastructure element has no further attributes.

In interlocking, the element provides the following child elements and attributes:

  • @automaticKeyRelease
  • @automaticKeyLock
  • @keyRequestTime
  • @keyAuthoriseTime
Edited Dec 13, 2021 by Administrator
Assignee
Assign to
Time tracking

railML.org e.V. (Registry of Associations: VR 5750) Phone: +49 351 47582911 Altplauen 19h; 01187 Dresden; Germany