Home » railML newsgroups » railml.infrastructure » Extension suggestion for <upTime> (uptime, railML 2.4nor, railML2.5, railML3 development)
Extension suggestion for <upTime> [message #2330] Mon, 17 February 2020 15:06 Go to next message
Torben Brand is currently offline  Torben Brand
Messages: 92
Registered: March 2016
Member
Dear railML-community,

For the Norwegian railway sector, we are looking for a way to model an ocp, that is unmanned on certain timely restrictions. The restrictions we would like to model are specific days, for example Saturdays or public holidays.

The element <upTime> (https://wiki2.railml.org/index.php?title=IS:uptime) makes it possible to state that an ocp is unmanned with @mode="unmanned". But it doesn't give us the possibility to restrict this property to certain days, but only certain times in a day with @from and @until.

The element <propOther/states/state> on the other hand would give us the option to refer to an operating period via @operatingPeriodRef and thus makes it possible to model restrictions for certain days (in the sub element <operatingDay>).

We would like to propose a solution to extend the element <upTime> with the time attributes of <state>: @operatingPeriodRef and @endDayOffset. The existing attributes @from and @until seem to be semantically equivalent to @startTime and @endTime. So, we suggest keeping them as is, but to change their semantic constraint from mandatory to optional.

Furthermore, we are looking for a description of the value "off" in <upTime>@mode. What does this value stand for?

What does the community think?
Description of <upTime>@mode (Re: Extension suggestion for <upTime>) [message #2339 is a reply to message #2330] Fri, 21 February 2020 21:40 Go to previous messageGo to next message
vpkolmorgen
Messages: 47
Registered: November 2004
Member
Dear Torben, dear all,

I don't want to anticipate the discussion by the community about the
proposed extensions, but I would like to contribute something to the
meaning of the individual values at <ocp> <propOperational><uptime>@mode:

Am 18.02.2020 um 03:06 schrieb Torben Brand:
> Furthermore, we are looking for a description of the value
> "off" in <upTime>@mode. What does this value stand for?

- „manned“: The <ocp> is operational/usable and staffed with IM's
personnel ready for operation on site (in the area of the <ocp>).
- „unmanned“: The <ocp> is operational/usable and not staffed with on
site personnel by the IM. Even the <ocp> is not controlled or is remote
controlled by any staff of the IM and there is no IM’s staff is
available in the area of the <ocp>.
- „off“: The <ocp> is temporarily not operational/usable. No
information about local staff is given by this value. Please note that
the values <ocp><states><state>@status={disabled|closed} shall be used
for a long-term non-defined or permanent disabling of an <ocp>.

Additonally the following semantic constraints should apply:
- an <ocp> with attribute @operationalType“blockSignal“ shall not have
<propOperational><uptime>@mode=“manned“ (as a manned blockSignal shall
be modelled in railML 2.x as blockPost),
- an <ocp> with attribute @operationalType=“stoppingPoint“ shall not
have <propOperational><uptime>@mode=“manned“ (as a stoppingPoint has no
operational usage and therefore no operational staff by the IM),
- an enumeration of several time periods by @from and @until for one
<ocp> shall not overlap so that for every time there shall be a unique
status of <uptime>.

What do you think about?
Are there additional semantic constraints to be described?

Best regards,
--
Vasco Paul Kolmorgen - Governance Coordinator
railML.org (Registry of Associations: VR 5750)
Phone railML.org: +49 351 47582911
Altplauen 19h; 01187 Dresden; Germany www.railML.org
Re: Description of <upTime>@mode (Re: Extension suggestion for <upTime>) [message #2344 is a reply to message #2339] Tue, 25 February 2020 10:46 Go to previous messageGo to next message
Torben Brand is currently offline  Torben Brand
Messages: 92
Registered: March 2016
Member
Excellent! This explains a lot! Could you post the definitions to the wiki?
Re: Extension suggestion for <upTime> [message #2355 is a reply to message #2330] Wed, 26 February 2020 21:58 Go to previous messageGo to next message
christian.rahmig is currently offline  christian.rahmig
Messages: 273
Registered: January 2016
Senior Member
Torben Brand wrote on Mon, 17 February 2020 15:06
Dear railML-community,

For the Norwegian railway sector, we are looking for a way to model an ocp, that is unmanned on certain timely restrictions. The restrictions we would like to model are specific days, for example Saturdays or public holidays.

The element <upTime> (https://wiki2.railml.org/index.php?title=IS:uptimeWink makes it possible to state that an ocp is unmanned with @mode="unmanned". But it doesn't give us the possibility to restrict this property to certain days, but only certain times in a day with @from and @until.

The element <propOther/states/state> on the other hand would give us the option to refer to an operating period via @operatingPeriodRef and thus makes it possible to model restrictions for certain days (in the sub element <operatingDay>).

We would like to propose a solution to extend the element <upTime> with the time attributes of <state>: @operatingPeriodRef and @endDayOffset. The existing attributes @from and @until seem to be semantically equivalent to @startTime and @endTime. So, we suggest keeping them as is, but to change their semantic constraint from mandatory to optional.

Dear Torben, dear all,

the current implementation of <ocp><propOperational><uptime> is not usable for regular/repeating time patterns as descibed by you. Your proposal to add an attribute @operatingPeriodRef as it is already available in <ocp><propOther><states><state> sounds reasonable.

However, for version compatibility reasons (within railML 2.x), we are not able to set <uptime> attributes @from and @to from mandatory to optional. Further, I see a semantic overlap between the usage of <ocp><propOperational><uptime> and <ocp><propOther><states><state>. I would like to solve this potential conflict by clarifying the current practical usage of both elements. Therefore, any feedback from the community is very much welcome.

Thank you very much and best regards
Christian


Christian Rahmig - Infrastructure scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
Re: Description of <upTime>@mode [message #2360 is a reply to message #2344] Fri, 28 February 2020 16:00 Go to previous message
Ferri Leberl is currently offline  Ferri Leberl
Messages: 24
Registered: September 2016
Junior Member
Dear Mr. Brand,
I have added the explanations and semantic constraints.
Let me know, if any adaptions are required.
Yours, Ferri
Previous Topic: Suggested definition of <ocpVis>
Next Topic: extension of <levelCrossing> in railML2.4nor
Goto Forum:
  


Current Time: Wed Aug 12 14:44:51 CEST 2020