Home » railML newsgroups » railml.interlocking » [railML3] Suggested extension for RBC (defining RBC properties and RBC controlled area)
[railML3] Suggested extension for RBC [message #2436] Wed, 13 May 2020 18:06 Go to next message
Karl-Friedemann Jerosch is currently offline  Karl-Friedemann Jerosch
Messages: 11
Registered: May 2020
Junior Member
Dear all,

first let me introduce myself: I am Karl Jerosch and I am working in the ETCS trackside engineering department of Siemens Mobility Germany and I am participant of the railML workgroup "ETCS Track Net".

To extend the schema of railML.interlocking for RBC (Radio Block Center),
the work group "ETCS Track Net" suggests to add the following information to be implemented in railML 3.2:

1.) new element <RBCs> as container for elements of kind <RBC>

2.) new element <RBC> providing information of one RBC with attributes:
- NID_C [integer 0, ..., 1023] according to UNISIG SUBSET-026 Section 7.5.1.86
- NID_RBC [integer 0, ..., 16382] according to UNISIG SUBSET-026 Section 7.5.1.96
- NID_RADIO [16 digits, each digit is a hex value with range of 0 to 9 or F] to provide the telephone number according to UNISIG SUBSET-026 Section 7.5.1.95
- NID_MN [6 digits, each digit is a hex value with range of 0 to 9 or F] to provide the GSM-R network id according to UNISIG SUBSET-026 Section 7.5.1.91.1

To detect automatically the RBC controlled area by sofware tools, information about the RBC border shall be provided in railML 3.2,
either as new elements <RBCborders> and <RBCborder> or by using (and extending) the already existing infrastructure elements <borders> and <border>.

3.) a new element <RBCborders> as container for elements of kind <RBCborder> (or use of exisiting element <borders>)

4.) new element <RBCborder> with attributes (or use of extension of existing element <border>):
- reference to an element <RBC>
- location (relativ position in relation to a netElement)
- direction
- kind of transition with a list of 4 different values: "entry/exit/handover/accepting"

See also the following attachment which illustrates the suggestion: https://forum.railml.org/userfiles/2020-05-08_siemens-railml 3-illustration-rbc-border.pdf

Does the community agree with the suggested extension of the data model in railML 3.2?

best regards

Karl Jerosch
Siemens Mobility GmbH
SMO RI ML PE ENG HW&SW

[Updated on: Fri, 29 May 2020 15:40] by Moderator

Report message to a moderator

Re: [railML3] Suggested extension for RBC [message #2438 is a reply to message #2436] Thu, 14 May 2020 15:11 Go to previous messageGo to next message
Henrik Roslund is currently offline  Henrik Roslund
Messages: 6
Registered: August 2019
Location: Zürich
Junior Member
Hello,

Very good inputs, Karl.

I agree with your suggestions, but I would like to have an optional attribute connected to "NID_RBC", "RBC Name", and there is the real name of the RBC written, e.g. "Gotthard".

Unfortunately doesn't the link work for me.

Kind regards,

Henrik Roslund
Senior Consultant ETCS, MIRSE
TÜV SÜD Schweiz AG

Member of the Workgroup «ETCS Track NET»
Re: [railML3] Suggested extension for RBC [message #2442 is a reply to message #2438] Tue, 19 May 2020 09:29 Go to previous messageGo to next message
Jörg von Lingen is currently offline  Jörg von Lingen
Messages: 86
Registered: March 2016
Member
Hi,

I would see the suggested new element <radioBlockCentre> in the interlocking
part of railML as it is a more functional item of train control which has not a
representation at a particular track.

If derived from class "SystemAsset" it would inherit @id for any railML internal
referencing (not NID_RBC), <designator> and <assetName>. The latter one can be
used to store the real name even in different languages. In that way it would be
in parallel to the elements of <controllers> (HMI, TMS) and <signalboxes>
(interlocking module).

The proposed additional attributes (NID_C, NID_RBC, NID_RADIO, NID_MN) can be
attached to the <radioBlockCentre> element. However, the naming should be more
reflect their function than the ETCS variable name. In XML they would be of type
NonNegativeInteger but the limitations as coming from ETCS spec is not that
straight forward. Are there any suggestions as to how model this?

The proposed element <radioBlockCentreBorder> I would see as a new entry in the
list <assetsForInterlocking>. Although there is the issue of defining a position
on a netElement for it. If placed only in IS part the referencing between IS and
IL elements might become a little bit weird, refer post "[railML3]: Referencing
between IS and IL".



Best regards,
Joerg v. Lingen - Interlocking Coordinator
Am 14.05.2020 um 15:11 schrieb Henrik Roslund:
> Hello,
>
> Very good inputs, Karl.
>
> I agree with your suggestions, but I would like to have an
> optional attribute connected to "NID_RBC", "RBC Name", and
> there is the real name of the RBC written, e.g. "Gotthard".
>
> Unfortunately doesn't the link work for me.
>
> Kind regards,
>
> Henrik Roslund
> Senior Consultant ETCS, MIRSE
> TÜV SÜD Schweiz AG
>
> Member of the Workgroup «ETCS Track NET»
Re: [railML3] Suggested extension for RBC [message #2487 is a reply to message #2442] Mon, 06 July 2020 16:28 Go to previous message
christian.rahmig is currently offline  christian.rahmig
Messages: 436
Registered: January 2016
Senior Member
Dear all,

railML 3.2 shall contain an option to model Radio Block Centers (RBC). After we discussed required parameters in the ETCS use case working group, we now face the central question: shall we add RBC in infrastructure or interlocking/signalling domain? What does the community think about it?

Any comments are highly appreciated...

Best regards
Christian



Christian Rahmig – Infrastructure scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
Previous Topic: [railML3.2]: AssetsForInterlocking
Next Topic: interlocking -> signalling
Goto Forum:
  


Current Time: Thu Mar 28 09:40:11 CET 2024