| Re: railML 2.3 infrastructure extension proposal - controller [message #1467] |
Mon, 02 January 2017 17:28 |
christian.rahmig
Messages: 474
Registered: January 2016
|
Senior Member |
|
|
Dear Torben,
*** This post has been cross-posted in infrastructure and interlocking
forum. Please only reply in the infrastructure forum. Thank you. ***
Am 20.12.2016 um 18:24 schrieb Torben Brand:
> [...]
> controller
> The controller (DE:Stellwerk) needs to be defined on a
> macroscopic level for what type and system is used. This as
> to give the capacity planner generic values of some capacity
> related values of the stations features. Thus I have added the three
> new attributes:,@NO:model,
> @NO:type, @NO:technologyType and @NO:swVersion.
> @NO:model: [datatype:string] Defines the model/system used.
> Examples are: SIMIS-C,Thales L-90, NSB-77, NSI-63,...
> @NO:type [datatype:enumeration] Defines the type of
> controller on a general level. This is predefined with three
> Norwegian national presets, the value "none" and "other:"
> The presets are "NO:plussStasjon" (English: full
> interlocking), "NO:enkeltSikringsanlegg" (English:
> simplified interlocking) and "NO:enkeltInnkjørsignal"
> (English:simplified entry signal).
> @NO:technologyType [datatype: enumeration] The predefined
> values are: "electric", "electromechanic", "electronic",
> "mechanic"
Until railML version 2.3 the <controller> element has been just a
placeholder element, which indicates that the railway infrastructure is
controlled from some kind of interlocking. All the detailed features of
the controller that describe its functionality etc. are part of the
upcoming interlocking schema. So, let me comment on your proposal from
an infrastructure point of view:
<controller>@NO:model
I agree with putting the product (interlocking) name here. In order to
avoid misspelling I prefer implementing an enumeration here or - if
there would be too many entries - to use a codelist as it has been done
for the TrainProtectionSystem. A codelist - though released and
maintained by railML.org - is not an essential part of the schema and
may change (new entries) on short notice. Thus, a codelist ist more
flexible than an enumeration value. In any case, for railML v3 the
attribute @model should be part of the new interlocking schema.
<controller>@NO:type
The idea of this parameter is to provide some classification of
interlockings/controllers regarding their complexity or responsibility.
I think that this is useful as other countries and railways do the same
in order to create some hierarchy of their interlocking network. For a
later implementation within the railML schema, I suggest to find a
generic classification that is compatible to the different national
class structures. Is "none" a useful entry? In any case, for railML v3
the attribute @type should be part of the interlocking schema.
<controller>@NO:technologyType
The current railML version 2.3 already contains an enumeration data type
tInterlockingTypes, which is used by the parameter
<ocp><propEquipment><summary>@signalBox, and which provides the
following values:
* none
* mechanical
* electro-mechanical
* electrical
I suggest to recycle this enumeration data type and to use it for the
attribute <controller>@technologyType. In any case, for railML v3 the
attribute @technologyType should be part of the interlocking schema.
<controller>@NO:swVersion
Is that needed? Please provide some more explanation.
> PS. The terms @type, @model, @system, @mode need to be
> defined more clearly in railML in general to be consistent
> throughout.
I agree that railML should provide clear definitions for the content of
the attributes @type, @model, @system, @kind and @mode. However, we will
not change it with railML v2.x, but only with railML v3. In the
meantime, we will try to bring more clarity in the documentation of
these parameters in the wiki.
Best regards
Christian
--
Christian Rahmig - Infrastructure scheme coordinator
railML.org (Registry of Associations: VR 5750)
Phone Coordinator: +49 173 2714509; railML.org: +49 351 47582911
Altplauen 19h; 01187 Dresden; Germany www.railml.org
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
