|
|
| Line 1: |
Line 1: |
| {{useCase|IS|2.3|title=Capacity planning|TT=1|IL=1|RS=1|reporter=Jernbaneverket}} | | {{mirror}} |
| | |
| {{UC title}}
| |
| Capacity planning at Jernbaneverket (JBV); {{Deu|Kapazitätsplanung bei Jernbaneverket (JBV)}}; {{Fra|nom descriptif en Francais}}
| |
| | |
| {{UC description}}
| |
| The capacity planning process is a large process in a small, but important group at each infrastructure manager. The capacity section at Jernbaneverket (JBV) is currently finishing a handbook that describes the process in Norwegian. An English version is envisioned by 2016. Here follows a short excerpt.
| |
| The process contains different methods, calculations, computer tools that simulate, calculate and analyze with internal and external databases that store the input and output data.
| |
| Here we describe the most important of many processes and their belonging methods and tools – the timetable creation process. The process starts with a service concept that describes the railroad service being provided. This service concept is shared with the traffic modeling department that do transport flow modeling and feedback how much transport the service concept generates (number of passengers/TEU). The desired service concept is then developed into a timetable model in a timetable tool with a macroscopic or mesoscopic infrastructure model of today and different future scenarios. Today’s infrastructure is pulled from an asset management database. Future infrastructure is designed by hand from technical drawings. The timetable model is tested either mesoscopically in an analysis tool or in a simulation tool that works with a microscopic infrastructure model. In short term scenarios the level of details are specific, where in long term scenarios the model is still microscopic, but generic.
| |
| | |
| {{UC flows}}
| |
| The service concept is created in an Excel macro. The data is shared with the transport flow simulation in a predefined Excel tabular format. The service concept is then transferred into the timetable tool Treno by hand (interface planned). Timetable work and infrastructure dimensioning is performed internally in a timetable tool. Parts of today’s infrastructure is pulled from an asset management database (Banedata) in Excel files that are transformed into IVT format tables (ETH IVT) that can be loaded into the timetable tool (Treno) and the simulation tool (Opentrack). The rest (mostly interlocking) is added manually from technical drawings. Jernbaneverket is planning a datahub that will pull in IBM Maximo DB data from Banedata and other sources and output them as needed, amongst others railML® 2.2 and 3.0 when it becomes available. Future infrastructure is designed manually from technical drawings. The timetable tool will transfer courses, itineraries, timetable (both Treno and Opentrack support railML 1.0 and 2.2 timetable scheme, but excess data demand an extension – that is not adopted) and delay distributions in XML (not railML – based on or similar) format to Opentrack. Transfer of macro/mesoscopic infrastructure in Treno to Opentrack by hand. Analysis of the simulation data again in Treno from XML format (not railML – based on or similar).
| |
| | |
| {{UC interference}}
| |
| * timetable
| |
| * interlocking
| |
| * rolling stock
| |
| | |
| {{UC data}}
| |
| This section serves to specify the required data regarding certain aspects.
| |
| | |
| {{UC update}}
| |
| * infrastructure: regular changes (Existing infrastructure is updated on a daily basis. But due to todays manual model work is only updated once a year today. Every half year would have been a nice update cycle. Planned infrastructure is updated when there are projects. Then they can be updated on a daily basis or even multiple times a day.)
| |
| | |
| * rolling stock: regular changes (Updated when new rolling stock becomes available or new features that describe behavior in greater detail in program.)
| |
| | |
| * timetable: regular changes (Existing timetable and short term planned: once a year. Long term planned is updated when there are projects. Then they can be updated on a daily basis or even multiple times a day)
| |
| | |
| {{UC complexity}}
| |
| * big (station/yard)
| |
| * huge (region)
| |
| * whole data set (network)
| |
| | |
| {{UC focus}}
| |
| * Signaling (microscopic level)
| |
| * Statistics
| |
| * Topology (schematic drawing) on micro, meso and macroscopic level, with description of data (values and position)
| |
| * Timetable graph, Platform occupation diagram
| |
| * Network graph
| |
| | |
| {{UC elements|IS}}
| |
| See Norwegian Excel list of 156 attributes for infrastructure (to be checked for extension need and translated)
| |
| | |
| See detail pages for rolling stock (to be developed).
| |
| | |
| Basically railML 2.2 is sufficient, but this must be verified.
| |
| | |
| See detail pages for timetable and rolling stock (to be developed).
| |
| | |
| As a basis RailML 2.2 is sufficient, but must be extended with attributes or link to service concept values and stochastic elements.
| |