|
|
| Line 1: |
Line 1: |
| {{UseCase|IS|3.2|title=Integrated Traffic Management System|TT=1|IL=1|abbr=ITMS|reporter=Bombardier}} | | {{mirror}} |
| | |
| {{UC title}}
| |
| Integrated Traffic Management System
| |
| | |
| {{UC description}}
| |
| The purpose of a TMS is to optimize rail traffic flow by providing decision support to dispatchers as well as automated functions. Typical tasks of TMS are automatic route setting, real time train graph display, conflict detection, conflict resolution and traffic regulation. For the completeness of the use case, traditional CTC functions are here also considered as part of TMS, i.e. real time track layout display, train describer tracking and command interface for route setting and wayside object control.
| |
| | |
| This use case aims to cover all data exchange necessary for the functions listed above. A major difference to previous railML use cases is that this includes also real time data, such as positions of trains and states of wayside objects. Hence, the target is not only a static railML file, but also on line data exchange, e.g. by messaging or web services.
| |
| | |
| {{UC flows}}
| |
| ''Need to make some drawing here. Main interfaces for TMS is CCS (i.e. IL and RBC), timetable planning system and (optionally) fleet management system.''
| |
| [[File:ITMS_dataFlows_01.png|thumb|Macroscopic view on infrastructure data flows between TMS sub-systems]]
| |
| [[File:ITMS_dataFlows_02b.png|thumb|Macroscopic view on timetable data flows between TMS sub-systems]]
| |
| [[File:ITMS_dataFlows_03.png|thumb|Macroscopic view on interlocking data flows between TMS sub-systems]]
| |
| | |
| | |
| {{UC interference}}
| |
| *IL
| |
| *IS
| |
| *TT
| |
| | |
| {{UC data}}
| |
| {{UC update}}
| |
| * tbd
| |
| {{UC complexity}}
| |
| * tbd
| |
| {{UC focus}}
| |
| * tbd
| |
| | |
| {{UC elements}}
| |
| tbd
| |
Revision as of 17:51, 24 November 2019