| [railML3] Suggested extension for RBC [message #2436] |
Wed, 13 May 2020 18:06  |
Karl-Friedemann Jerosch
Messages: 12
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 #2442 is a reply to message #2438] |
Tue, 19 May 2020 09:29  |
Jörg von Lingen
Messages: 91
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 |
christian.rahmig
Messages: 474
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
|
|
|
|
Members
Search
Help
Login
Home
