User:Christian Rößiger: Difference between revisions

From railML 2 Wiki
Jump to navigation Jump to search
mNo edit summary
No edit summary
Line 1: Line 1:
railML developer at iRFP e. K.
'''Use case / {{Deu|Anwendungsfall}} / {{Fra|Scénario d’utilisation}}:'''


Since 1997, the Institute for Traffic Planning Systems iRFP, detached from the Dresden University of Technology, has been following this path and further developed the whole programme package for computer-aided construction of all timetable documents necessary for railroading. This enables to plan graphic timetables for today’s European railway traffic and to design station timetable programmes for the biggest main stations.
Exchange of formation data; {{Deu|Austausch von Wagenreihungen/Behängungsdaten}}; {{Fra|???}}
 
'''Description / {{Deu|Beschreibung}} / {{Fra|Description}}'''
 
''What is the application behind the use case? Which data are required? Who or which tool/application provides these data? Which data are not included (if not obvious)? Define the boundaries of the use case and the relevant data. (max. 200 words, English)''
 
'''Data Flows and Interfaces / {{Deu|Datenflüsse und Schnittstellen}} / {{Fra|Flux de données et interfaces}}'''
 
The usecase covers the exchange of the following data:
* the composition of <trainPart>s of <vehicle>s (using <formation>s)
* <operationalPeriod>s of <trainPart>s
* commercial and technical properties of <trainPart>s/<formation>s
* added and removed <trainPart>s within a <train>
 
The usecase does not cover the exchange of data concerning the <train>, e.g.
* changes of the train path or times (<ocpsTT>)
* added or removed <train>s
 
As a consequence, it is assumed that both source and target system of the exchanged data must refer to the same set of <train>s, i.e. the <train>s must have the same external identifier an identical train paths<ref>the train path must be equal at least concerning the <ocp>s, at which <trainPart>s of the <train>s begin or end</ref>. Since the usecase mainly modifies existing objects in the target system, it is necessary that the railML data can be assigned to the correspoding objects in the target system. For this usecase the following railML object types
 
{{reflist}}
 
'''Interference with other railML<sup>®</sup> schemas / {{Deu|Interferenz mit anderen railML<sup>®</sup>-Schemen}} / {{Fra|Interaction avec autres schemas railML<sup>®</sup>}}'''
 
* ''infrastructure''
* ''rolling stock''
* ''interlocking''
* ''other ..............''
 
'''Characterizing Data / {{Deu|Charakterisierung der Daten}} / {{Fra|Caractérisation des données}}'''
 
This section serves to specify the required data regarding certain aspects.
 
<u>How often do the data change (update)?</u>
 
*''static (not changing)''
*''yearly''
*''regular changes''
*''monthly''
*''weekly''
*''daily''
* ''realtime (seconds)''
 
<u>How big are the data fragments to be exchanged (complexity)?</u>
 
*''tiny (attribute)''
*''very small (element)''
*''small (single train run)''
*''big (line)''
*''huge (region)''
*''whole data set (detailed operational concept network)''
 
<u>Which views are represented by the data (focus)?</u>
 
*''Long term planning (eg. for infrastructure dimensioning)''
*''Mid term planning (eg. for yearly timetable disposition)''
*''Short term planning (eg. for trackworks)''
*''Real term planning (eg. for dispatching)''
*''Statistics''
*''Fare collection''
*''Passenger information''
*''...''
 
<u>Which specific timetable data do you expect to receive/send (elements)?</u>
 
''Fill in your application-specific data structure elements, which you are using and want to see modelled in railML 3.''<br>
''Please describe also structures which should be modeled in another way (so called "code refactoring") in railML 3.''<br>
''Attention: This is the most important part of this questionaire. Please define as detailed as possible, the length isn't limited here.''

Revision as of 11:57, 12 February 2015

Use case / Anwendungsfall / :

Exchange of formation data; Austausch von Wagenreihungen/Behängungsdaten;

Description / Beschreibung /

What is the application behind the use case? Which data are required? Who or which tool/application provides these data? Which data are not included (if not obvious)? Define the boundaries of the use case and the relevant data. (max. 200 words, English)

Data Flows and Interfaces / Datenflüsse und Schnittstellen /

The usecase covers the exchange of the following data:

  • the composition of <trainPart>s of <vehicle>s (using <formation>s)
  • <operationalPeriod>s of <trainPart>s
  • commercial and technical properties of <trainPart>s/<formation>s
  • added and removed <trainPart>s within a <train>

The usecase does not cover the exchange of data concerning the <train>, e.g.

  • changes of the train path or times (<ocpsTT>)
  • added or removed <train>s

As a consequence, it is assumed that both source and target system of the exchanged data must refer to the same set of <train>s, i.e. the <train>s must have the same external identifier an identical train paths[1]. Since the usecase mainly modifies existing objects in the target system, it is necessary that the railML data can be assigned to the correspoding objects in the target system. For this usecase the following railML object types

Template:Reflist

Interference with other railML® schemas / Interferenz mit anderen railML®-Schemen /

  • infrastructure
  • rolling stock
  • interlocking
  • other ..............

Characterizing Data / Charakterisierung der Daten /

This section serves to specify the required data regarding certain aspects.

How often do the data change (update)?

  • static (not changing)
  • yearly
  • regular changes
  • monthly
  • weekly
  • daily
  • realtime (seconds)

How big are the data fragments to be exchanged (complexity)?

  • tiny (attribute)
  • very small (element)
  • small (single train run)
  • big (line)
  • huge (region)
  • whole data set (detailed operational concept network)

Which views are represented by the data (focus)?

  • Long term planning (eg. for infrastructure dimensioning)
  • Mid term planning (eg. for yearly timetable disposition)
  • Short term planning (eg. for trackworks)
  • Real term planning (eg. for dispatching)
  • Statistics
  • Fare collection
  • Passenger information
  • ...

Which specific timetable data do you expect to receive/send (elements)?

Fill in your application-specific data structure elements, which you are using and want to see modelled in railML 3.
Please describe also structures which should be modeled in another way (so called "code refactoring") in railML 3.
Attention: This is the most important part of this questionaire. Please define as detailed as possible, the length isn't limited here.

  1. ↑ the train path must be equal at least concerning the <ocp>s, at which <trainPart>s of the <train>s begin or end
Retrieved from "https://wiki2.railml.org/index.php?title=User:Christian_Rößiger&oldid=3952"