UC:TT:FGIInTrain: Difference between revisions

From railML 3 Wiki
Jump to navigation Jump to search
[unchecked revision][unchecked revision]
(+reporter)
 
({{mirror}})
Line 1: Line 1:
{{UseCase|TT|2.3|title=Passenger Information Inside the Train|IL=1|IS=1|RS=1|reporter=Interautomation}}
{{mirror}}
 
{{UC title}}
Passenger Information Inside the Train; {{Deu|Fahrgastinformation im Zug}}
 
{{UC description}}
The use case describes the data of the timetable, which will be imported in a real time passenger information system (RTPIS) or Automatic Vehicle Monitoring System (AVMS) and will be used for generating passenger information inside the trains.
 
The RTPIS, which imports the timetable is also responsible for the monitoring and the data supply of the trains with passenger information data. The trains connected with the RTPIS will be described as "RTPIS-own trains" in the following chapters.
 
The imported timetable is used
* to show the progress of the journeys and
* to show the punctuality in comparison between the planned and the esti-mated arrival and departure times for RTPIS-own journeys.
 
Additionally it is used as the data base to supply extended information for passengers like connections/transfers at stations for RTPIS-own journeys. Commonly connections/transfers are not part of the imported timetable. These information belong to the responsibility of another RTPIS or an AVMS. Typically these information will be collected from a public transport cloud service by using a standardized interface, for example according to VDV-DFI (VDV-453).
 
The quality and the completeness of the timetable import are significant for the actuality and the accuracy of the passenger information inside the train, which will be generated by the RTPIS.
 
{{UC flows}}
The use case describes the data exchange between a planning system (for time-tables, rosterings and vehicle deployment) and a RTPI or an AVMS. For further usage the data has to be imported in the RTPIS or the AVMS.
 
According to the data contained in the timetable import, data amount and data complexity can vary.
 
At least this use case needs the following elements:
* the elements <train> and <trainPart> to supply information about line, direction and relevant information from the timetable to match the display content inside the train correctly to the other information
* <ocp> elements to refer to the infrastructure
Different levels of complexity of the data import are possible.
* a minimal level of information corresponding to the infrastructure (only the identification number of the ocp) or an extended level of information (e.g. short name, longer name, geo location data)
* the element <category> is used to decide between journeys with or with-out a relevance for passengers (e.g. operating drives)
* with or without <rostering>, but if <rostering> is included, the element <rollingstock> is also required
 
The elements <infrastructure> and <rollingstock> are master data for the use case "passenger information inside the train".
 
The information from the <timetable> are data which will be used individually for every train number and every vehicle circulation.
 
The usage of the <rostering> information is optional. If the system is provided with these information, no manually input action by the train conductor is required to show the correct passenger information on the displays.
 
{{UC interference}}
* Infrastructure is referenced:
** from <ocpTT>.ocpRef to <ocp>.id (mandatory)
* Rolling stock is referenced:
** from <formationTT>.formationRef to <formation>.id (optional)
** from <rostering>.formationRef to <formation>.id (optional)
** from <rostering>.vehicleRef to <vehicle>.id (optional)
 
{{UC data}}
 
{{UC update}}
* daily
* sometimes possibly several times on a day (short-term changes)
 
{{UC complexity}}
 
The size of the data varies depending to the usage of the data.
On the one hand there is the general data supply with the timetable e.g. for the next seven days in advance.
 
On the other hand there is the data supply for the next two days, which optionally also contains the vehicle deployment information to ensure the automated journey detection for automated passenger information inside the train.
 
Typically the data source is the commercial view of the timetable, which is also used in the AVMS of the public transport operator (PTO). It will be the basis data for generating real time information. These information will also be delivered to the public transport cloud service.
 
* infrastructure: medium (region), macroscopic
* timetable: medium (region; several up to some hundred trains)
* rolling stock: small (none, one or a few vehicles and formations) – kann für mittelfristigen Horizont entfallen, wenn keine Fahrzeugeinsatzplanung (ros-tering) vorhanden ist.
 
{| class="wikitable"
|-
! Size of Dataset !! (very) short-term planning (next 2 days) !! short-term planning (next week)
|-
| <infrastructure> || Medium || Medium
|-
| <timetable> || Medium ||Medium
|-
| ''<rostering>'' || ''Included (optional)'' || ''Not relevant''
|-
| <rollingstock> || Small (nur wenn <rostering>) || Not relevant
|}
 
{{UC focus}}
 
* Short-term planning (up to a week)
 
{{UC elements|TT}}
 
{| class="wikitable"
|-
! Element !! Mandatory/Optional
|-
| <infrastructure>.<operationsControlPoints>.<ocp>.id|| x
|-
| <infrastructure>.<operationsControlPoints>.<ocp>.number || x (railML 2.1)
|-
| <infrastructure>.<operationsControlPoints>.<ocp>.<designator register="IBNR">.entry || x (railML 2.3)
|-.
| <infrastructure>.<operationsControlPoints>.<ocp>.code || (railML 2.1)
|-
| <infrastructure>.<operationsControlPoints>.<ocp>.<designator register="RL100">.entry || (railML 2.3)
|-
| <infrastructure>.<operationsControlPoints>.<ocp>.name ||
|-
| <infrastructure>.<operationsControlPoints>.<ocp>.<propOperational>.operationalType ||
|-
| <infrastructure>.<operationsControlPoints>.<ocp>.<propService>.passenger ||
|-
| <infrastructure>.<operationsControlPoints>.<ocp>.<geoCoord> ||
|-
| <rollingstock>.<vehicles>.<vehicle>.id ||
|-
| <rollingstock>.<vehicles>.<vehicle>.code ||
|-
| <rollingstock>.<formations>.<formation>.id ||
|-
| <rollingstock>.<formations>.<formation>.<trainOrder>.vehicleRef ||
|-
| <timetable>.<timetablePeriods>.<timetablePeriod>.id || x
|-
| <timetable>.<timetablePeriods>.<timetablePeriod>.startDate || x
|-
| <timetable>.<timetablePeriods>.<timetablePeriod>.endDate || x
|-
| <timetable>.<operatingPeriods>.id || x
|-
| <timetable>.<operatingPeriods>.<operatingPeriod>.startDate || x
|-
| <timetable>.<operatingPeriods>.<operatingPeriod>.endDate || x
|-
| <timetable>.<operatingPeriods>.<operatingPeriod>.bitMask || x
|-
| <timetable>.<categories>.<category>.id|| x
|-
| <timetable>.<categories>.<category>.name||
|-
| <timetable>.<categories>.<category>.deadrun ||
|-
| <timetable>.<categories>.<category>.trainUsage ||
|-
| <timetable>.<trainparts>.<trainPart>.id || x
|-
| <timetable>.<trainparts>.<trainPart>.line || x
|-
| <timetable>.<trainparts>.<trainPart>.trainNumber || x
|-
| <timetable>.<trainparts>.<trainPart>.additionalTrainNumber ||
|-
| <timetable>.<trainparts>.<trainPart>.categoryRef || x
|-
| <timetable>.<trainparts>.<trainPart>.<formationTT>.formationRef ||
|-
| <timetable>.<trainparts>.<trainPart>.<operatingPeriodRef>.ref || x
|-
| <timetable>.<trainparts>.<trainPart>.<ocpsTT> || x
|-
| <timetable>.<trainparts>.<trainPart>.<ocpsTT>.<ocpTT> || x
|-
| <timetable>.<trainparts>.<trainPart>.<ocpsTT>.<ocpTT>.ocpType || x
|-
| <timetable>.<trainparts>.<trainPart>.<ocpsTT>.<ocpTT>.<times> || x
|-
| <timetable>.<trainparts>.<trainPart>.<ocpsTT>.<ocpTT>.<sectionTT> || x
|-
| <timetable>.<trainparts>.<trainPart>.<ocpsTT>.<ocpTT>.<sectionTT>.distance || x
|-
| <timetable>.<trains>.<train> || x
|-
| <timetable>.<trains>.<train>.id || x
|-
| <timetable>.<trains>.<train>.type || x
|-
| <timetable>.<trains>.<train>.trainNumber || x
|-
| <timetable>.<trains>.<train>.<trainPartSequence> || x
|-
| <timetable>.<trains>.<train>.<trainPartSequence>.sequence || x
|-
| <timetable>.<trains>.<train>.<trainPartSequence>.<trainPartRef> || x
|-
| <timetable>.<trains>.<train>.<trainPartSequence>.<trainPartRef>.position ||
|-
| <timetable>.<trains>.<train>.<trainPartSequence>.<trainPartRef>.ref || x
|-
| <timetable>.<rosterings> ||
|-
| <timetable>.<rosterings>.<rostering>.vehicleRef ||
|-
| <timetable>.<rosterings>.<rostering>.id || x
|-
| <timetable>.<rosterings>.<rostering>.<blockParts>.<blockPart>.begin || x
|-
| <timetable>.<rosterings>.<rostering>.<blockParts>.<blockPart>.beginDay || x
|-
| <timetable>.<rosterings>.<rostering>.<blockParts>.<blockPart>.end || x
|-
| <timetable>.<rosterings>.<rostering>.<blockParts>.<blockPart>.endDay || x
|-
| <timetable>.<rosterings>.<rostering>.<blockParts>.<blockPart>.startOcpRef ||
|-
| <timetable>.<rosterings>.<rostering>.<blockParts>.<blockPart>.endOcpRef ||
|-
| <timetable>.<rosterings>.<rostering>.<blockParts>.<blockPart>.trainPartRef ||
|-
| <timetable>.<rosterings>.<rostering>.<blockParts>.<blockPart>.operatingPeriodRef ||
|-
| <timetable>.<rosterings>.<rostering>.<blocks>.<block>.id || x
|-
| <timetable>.<rosterings>.<rostering>.<blocks>.<block>.<blockPartSequence>.sequence || x
|-
| <timetable>.<rosterings>.<rostering>.<blocks>.<block>.<blockPartSequence>.<blockPartRef>.ref || x
|-
| <timetable>.<rosterings>.<rostering>.<circulations>.blockRef || x
|-
| <timetable>.<rosterings>.<rostering>.<circulations>.startDate || x
|}

Revision as of 17:34, 24 November 2019

🗒️ This page is mirrored from page UC:TT:FGIInTrain in The railML® 2 wiki.  

Template loop detected: Template:Mirror