Source: http://eur-lex.europa.eu/legal-content/PL/TXT/?uri=CELEX:32014R1305
Timestamp: 2017-12-18 22:12:31
Legal References Found: art. 2
 art. 6
 art. 1
 art. 29
 art. 29
 art. 2
 art. 1
 art. 5
 art. 38
 art. 48
 art. 5
 art. 27
 art. 4
 art. 5
 art. 2
 art. 3
 art. 3
 art. 3
 art. 23

Document Content:
Rozporządzenie Komisji (UE) nr 1305/2014 z dnia 11 grudnia 2014 r. dotyczące technicznej specyfikacji interoperacyjności odnoszącej się do podsystemu aplikacji telematycznych dla przewozów towarowych wchodzącego w skład systemu kolei w Unii Europejskiej i uchylające rozporządzenie (WE) nr 62/2006 Tekst mający znaczenie dla EOG
ROZPORZĄDZENIE KOMISJI (UE) NR 1305/2014
dotyczące technicznej specyfikacji interoperacyjności odnoszącej się do podsystemu aplikacji telematycznych dla przewozów towarowych wchodzącego w skład systemu kolei w Unii Europejskiej i uchylające rozporządzenie (WE) nr 62/2006
Zgodnie z art. 2 lit. e) dyrektywy 2008/57/WE system kolei jest podzielony na podsystemy strukturalne i funkcjonalne. Każdy z tych podsystemów powinien być objęty techniczną specyfikacją interoperacyjności (TSI).
Rozporządzeniem Komisji (WE) nr 62/2006 (2) ustanowiono techniczną specyfikację interoperacyjności odnoszącą się do podsystemu aplikacji telematycznych dla przewozów towarowych transeuropejskiego systemu kolei.
Zgodnie z art. 6 ust. 1 dyrektywy 2008/57/WE Europejskiej Agencji Kolejowej („agencja”) udzielono w 2010 r. mandatu do opracowania technicznych specyfikacji interoperacyjności („TSI”) w odniesieniu do podsystemu aplikacji telematycznych dla przewozów towarowych (ang. telematics applications for freight, „TAF”).
W dniu 10 grudnia 2013 r. agencja wydała zalecenie ERA/REC/106-2013/REC, aby zaktualizować załącznik A do rozporządzenia (WE) nr 62/2006.
TSI TAF nie powinna zawierać wymagań wykorzystania szczególnych technologii lub rozwiązań technicznych, za wyjątkiem sytuacji, kiedy jest to niezbędne w celu zapewnienia interoperacyjności transeuropejskiego systemu kolei.
Organy przedstawicielskie sektora kolei opracowały plan generalny wdrażania TSI TAF. W planie tym określono etapy konieczne do przejścia od fragmentarycznego podejścia krajowego do jednolitego systemu wymiany informacji w całym europejskim systemie kolei.
TAF TSI została oparta na najlepszej dostępnej wiedzy specjalistycznej. Postęp w zakresie rozwiązań technologicznych i operacyjnych może jednak spowodować konieczność wprowadzenia dalszych poprawek do niniejszej TSI TAF. Z tego względu należy opracować proces zarządzania zmianami, służący konsolidacji i aktualizacji wymagań zawartych w TSI TAF.
Wszystkie podmioty, zwłaszcza małe przedsiębiorstwa zajmujące się przewozami towarowymi, które nie są członkami organów przedstawicielskich europejskiego sektora kolei, powinny zostać poinformowane o spoczywających na nich obowiązkach wynikających z TSI TAF.
Należy zatem uchylić rozporządzenie (WE) nr 62/2006.
Niniejszym przyjmuje się przedstawioną w załączniku techniczną specyfikację interoperacyjności odnoszącą się do podsystemu aplikacji telematycznych dla przewozów towarowych wchodzącego w skład europejskiego systemu kolei.
1. Przedmiotowa TSI ma zastosowanie do podsystemu „aplikacje telematyczne” wchodzącego w skład systemu kolei w Unii Europejskiej i zdefiniowanego w sekcji 2.6 lit. b) załącznika II do dyrektywy 2008/57/WE.
sieć transeuropejskiego systemu kolei konwencjonalnych (TEN), określona w sekcji 1.1 załącznika I do dyrektywy 2008/57/WE;
sieć transeuropejskiego systemu kolei dużych prędkości, określona w sekcji 2.1 załącznika I do dyrektywy 2008/57/WE;
Zakres TSI nie obejmuje natomiast przypadków, o których mowa w art. 1 ust. 3 dyrektywy 2008/57/WE.
3. TSI ma zastosowanie do sieci o następujących nominalnych szerokościach toru: 1 435 mm, 1 520 mm, 1 524 mm, 1 600 mm i 1 668 mm.
Aktualizacja dokumentów technicznych i sprawozdawczość w tym zakresie
Agencja udostępnia za pośrednictwem swej strony internetowej kody lokalizacji i kody przedsiębiorstw, o których mowa w pkt 4.2.11.1 (lit. b) i d)) oraz dokumenty techniczne, o których mowa w pkt 7.2 załącznika, a także składa Komisji sprawozdanie dotyczące ich aktualizacji.
Komisja informuje państwa członkowskie o aktualizacji wspomnianych dokumentów za pośrednictwem komitetu ustanowionego zgodnie z art. 29 ust. 1 dyrektywy 2008/57/WE.
Zgodność z sieciami w państwach nienależących do UE
W odniesieniu do kolejowych przewozów towarowych wykonywanych z lub do państw trzecich zgodność z wymaganiami zawartymi w TSI przedstawionej w załączniku jest uzależniona od dostępności informacji ze strony podmiotów spoza UE, chyba że wymiana informacji zgodna z TSI jest przewidziana w umowach dwustronnych.
1. Agencja ocenia i nadzoruje wdrażanie niniejszego rozporządzenia w celu ustalenia, czy uzgodnione cele i terminy zostały osiągnięte, a także przedstawia komitetowi sterującemu TAF, o którym mowa w sekcji 7.1.4 załącznika, sprawozdanie oceniające.
2. Komitet sterujący TAF, w oparciu o sprawozdanie oceniające przedstawione przez agencję, dokonuje oceny wdrażania niniejszego rozporządzenia i podejmuje odpowiednie decyzje w sprawie dalszych działań, jakie podjąć ma odnośny sektor.
3. Państwa członkowskie zapewniają, aby wszystkie przedsiębiorstwa kolejowe i wszyscy zarządcy infrastruktury, działający na ich terytorium, a także wszyscy posiadacze wagonów zarejestrowani na ich terytorium zostali powiadomieni o niniejszym rozporządzeniu, oraz wyznaczają krajowy punkt kontaktowy odpowiedzialny za nadzorowanie wykonywania rozporządzenia, jak określono w dodatku III.
4. Do dnia 31 grudnia 2018 r. państwa członkowskie przesyłają Komisji sprawozdanie z wdrożenia niniejszego rozporządzenia. Sprawozdanie to zostanie omówione na forum komitetu ustanowionego zgodnie z art. 29 ust. 1 dyrektywy 2008/57/WE. W stosownych przypadkach dostosowuje się TSI przedstawioną w załączniku do niniejszego rozporządzenia.
Rozporządzenie (WE) nr 62/2006 zostaje uchylone z dniem wejścia w życie niniejszego rozporządzenia.
(2) Rozporządzenie Komisji (WE) 62/2006 z dnia 23 grudnia 2005 r. dotyczące technicznej specyfikacji dla interoperacyjności odnoszącej się do podsystemu aplikacji telematycznych dla przewozów towarowych transeuropejskiego systemu kolei konwencjonalnych (Dz.U. L 13 z 18.1.2006, s. 1).
WPROWADZENIE 443
Skróty 443
Dokumenty referencyjne 444
Zakres techniczny 445
Zakres geograficzny 445
Treść niniejszej TSI TAF 445
DEFINICJA PODSYSTEMU I ZAKRES 446
Funkcja wchodząca w zakres TSI 446
Funkcje nie wchodzące w zakres TSI 446
Przegląd opisu podsystemu 446
Uczestniczące podmioty 446
Rozpatrywane procesy 448
Uwagi ogólne 449
WYMAGANIA ZASADNICZE 450
Zgodność z wymaganiami zasadniczymi 450
Aspekty wymagań zasadniczych 450
Aspekty związane z wymaganiami ogólnymi 451
Bezpieczeństwo 451
Niezawodność i dostępność 451
Zdrowie 451
Ochrona środowiska 451
Zgodność techniczna 451
Aspekty dotyczące w szczególności podsystemu „Aplikacje telematyczne dla przewozów towarowych” 451
Zdrowie 452
Bezpieczeństwo 452
CHARAKTERYSTYKA PODSYSTEMU 452
Wstęp 452
Funkcjonalne i techniczne specyfikacje podsystemu 452
Dane listu przewozowego 453
Wniosek o przydzielenie trasy 454
Przygotowanie pociągu 455
Prognoza jazdy pociągu 456
Informacje o zakłóceniu usługi 457
ETI/ETA przesyłki 458
Ruch wagonów 459
Raportowanie o wymianie 460
Wymiana danych w celu poprawy jakości 461
Główne dane referencyjne 462
Lista plików referencyjnych i referencyjnych baz danych 463
Łączność sieciowa i komunikacja 466
Funkcjonalne i techniczne specyfikacje dotyczące interfejsów 468
Interfejsy z TSI „Infrastruktura” 468
Interfejsy z TSI „Sterowanie ruchem kolejowym” 468
Interfejsy z podsystemem „Tabor kolejowy” 468
Interfejsy z TSI „Ruch kolejowy” 468
Interfejsy z podsystemem „Aplikacje telematyczne dla przewozów pasażerskich” 469
Zasady eksploatacji 469
Jakość danych 469
Obsługa centralnego repozytorium 471
Zasady utrzymania 471
Kwalifikacje zawodowe 471
Warunki bezpieczeństwa i higieny pracy 471
SKŁADNIKI INTEROPERACYJNOŚCI 471
Definicja 471
Wykaz składników 471
Charakterystyki wydajnościowe i specyfikacje dotyczące składników 472
OCENA ZGODNOŚCI SKŁADNIKÓW LUB ICH PRZYDATNOŚCI DO STOSOWANIA ORAZ WERYFIKACJA PODSYSTEMU 472
Składniki interoperacyjności 472
Procedury oceny 472
Moduł 472
Posystem „Aplikacje telematyczne dla przewozów towarowych” 472
WDROŻENIE 473
Tryb stosowania niniejszej TSI 473
Wstęp 473
Etap pierwszy — szczegółowe specyfikacje informatyczne i plan generalny 473
Etap 2 i 3 — opracowanie i wdrożenie 473
Zarządzanie, role i podział odpowiedzialności 473
Zarządzanie zmianami 475
Proces zarządzania zmianami 475
Szczególny proces zarządzania zmianami dotyczący dokumentów wymienionych w dodatku I do niniejszego rozporządzenia 475
Wykaz dokumentów technicznych 476
Glosariusz 477
Zadania krajowego punktu kontaktowego ds. TAF/TAP 488
1.1. Skróty
Amerykański Narodowy Instytut Normalizacyjny (American National Standards Institute)
Wspólny interfejs (ang. Common Interface)
Wniosek o wprowadzenie zmian (ang. Change Request)
Europejska Agencja Kolejowa (zwana dalej również „agencją”)
Europejski system sterowania pociągiem (ang. European Train Control System)
Zarządca infrastruktury (ang. Infrastructure Manager)
Lokalna sieć komputerowa (ang. Local Area Network)
Przesyłki drobnicowe (ang. Less than Container Loads)
Wiodące przedsiębiorstwo kolejowe (ang. Lead Railway Undertaking)
Otwarta sieć obliczeniowa (ang. Open Network Computing)
Międzyrządowa Organizacja Międzynarodowych Przewozów Kolejami (Intergovernmental Organization for International Carriage by Rail)
Stały obwód wirtualny (ang. Permanent Virtual Circuit)
Komitet ds. interoperacyjności i bezpieczeństwa kolei
Przedsiębiorstwo kolejowe (ang. Railway Undertaking)
Aplikacje telematyczne dla przewozów towarowych (ang. Telematics Applications for Freight)
Aplikacje telematyczne dla przewozów pasażerskich (ang. Telematics Applications for Passengers)
Protokół sterowania transmisją (ang. Transmission Control Protocol)/Protokół internetowy
Posiadacze wagonów (ang. Wagon Keepers)
Grupa robocza (ang. Working Party) powołana przez ERA
1.2. Dokumenty referencyjne
Tytuł skrócony/odniesienie
Data ostatniego wydania:
Dyrektywa Parlamentu Europejskiego i Rady 2008/57/WE z dnia 17 czerwca 2008 r. w sprawie interoperacyjności systemu kolei we Wspólnocie (Dz.U. L 191 z 18.7.2008, s. 1)
Rozporządzenie Komisji (UE) nr 454/2011 dotyczące TSI TAP
Rozporządzenie Komisji (UE) nr 454/2011 z dnia 5 maja 2011 r. w sprawie technicznej specyfikacji interoperacyjności odnoszącej się do podsystemu „Aplikacje telematyczne dla przewozów pasażerskich” transeuropejskiego systemu kolei (Dz.U. L 123 z 12.5.2011, s. 11)
Dyrektywa Parlamentu Europejskiego i Rady 2012/34/UE z dnia 21 listopada 2012 r. w sprawie utworzenia jednolitego europejskiego obszaru kolejowego (Dz.U. L 343 z 14.12.2012, s. 32).
TAF TSI — ANNEX D. 2: APPENDIX F — TAF TSI DATA AND MESSAGE MODEL [Załącznik D.2: Dodatek F — Model danych i komunikatów TSI TAF]
Rozporządzenie Komisji (UE) nr 62/2006 dotyczące TSI TAF
Rozporządzenie Komisji (WE) nr 62/2006 z dnia 23 grudnia 2005 r. dotyczące technicznej specyfikacji dla interoperacyjności odnoszącej się do podsystemu aplikacji telematycznych dla przewozów towarowych transeuropejskiego systemu kolei konwencjonalnych (Dz.U. L 13 z 18.1.2006, s. 1)
Rozporządzenie Komisji (UE) nr 280/2013
Rozporządzenie Komisji (UE) nr 280/2013 z dnia 22 marca 2013 r. zmieniające rozporządzenie (WE) nr 62/2006 dotyczące technicznej specyfikacji dla interoperacyjności odnoszącej się do podsystemu aplikacji telematycznych dla przewozów towarowych transeuropejskiego systemu kolei konwencjonalnych (Dz.U. L 84 z 23.3.2013, s. 17)
Rozporządzenie Komisji (UE) nr 328/2012 z dnia 3 maja 2012 r. zmieniające rozporządzenie (WE) nr 62/2006 dotyczące technicznej specyfikacji dla interoperacyjności odnoszącej się do podsystemu aplikacji telematycznych dla przewozów towarowych transeuropejskiego systemu kolei konwencjonalnych (Dz.U. L 106 z 18.4.2012, s. 14)
Decyzja Komisji z dnia 29 kwietnia 2010 r. dotycząca mandatu dla Europejskiej Agencji Kolejowej do opracowania i przeprowadzenia przeglądu technicznych specyfikacji interoperacyjności w celu rozszerzenia ich zakresu na cały system kolei w Unii Europejskiej
Dyrektywa 2004/49/WE
Dyrektywa 2004/49/WE Parlamentu Europejskiego i Rady z dnia 29 kwietnia 2004 r. w sprawie bezpieczeństwa kolei wspólnotowych oraz zmieniająca dyrektywę Rady 95/18/WE w sprawie przyznawania licencji przedsiębiorstwom kolejowym, oraz dyrektywę 2001/14/WE w sprawie alokacji zdolności przepustowej infrastruktury kolejowej i pobierania opłat za użytkowanie infrastruktury kolejowej oraz certyfikację w zakresie bezpieczeństwa (Dyrektywa w sprawie bezpieczeństwa kolei) (Dz.U. L 164 z 30.4.2004, s. 44)
Dyrektywa 2001/13/WE
Dyrektywa 2001/13/WE Parlamentu Europejskiego i Rady z dnia 26 lutego 2001 r. zmieniająca dyrektywę Rady 95/18/WE w sprawie przyznawania licencji przedsiębiorstwom kolejowym (Dz.U. L 75 z 15.3.2001, s. 26)
1.3. Zakres techniczny
Niniejsza techniczna specyfikacja interoperacyjności (dalej zwana „TSI TAF”) odnosi się do elementu „aplikacje telematyczne dla przewozów towarowych” podsystemu „aplikacje telematyczne” wymienionego w wykazie podsystemów eksploatacyjnych (funkcjonalnych) zamieszczonym w załączniku II do dyrektywy 2008/57/WE [1].
Niniejsza TSI TAF została opracowana w celu zapewnienia sprawnej wymiany informacji poprzez ustanowienie ram technicznych umożliwiających osiągnięcie możliwie jak najbardziej opłacalnego ekonomicznie procesu transportu. W zakres tej specyfikacji wchodzą aplikacje dla przewozów towarowych oraz zarządzania połączeniami z innymi rodzajami transportu, co oznacza, że skoncentrowano się w niej nie tylko na samej eksploatacji pociągów, ale i na usługach transportowych RU. Kwestie bezpieczeństwa zostały uwzględnione jedynie w odniesieniu do istniejących elementów danych; wartości nie będą miały wpływu na bezpieczną eksploatację pociągu, a zgodności z wymogami TSI TAF nie można uznawać za zgodność z wymogami bezpieczeństwa.
TAF TSI ma również wpływ na warunki wykorzystywania transportu kolejowego przez użytkowników. W tym kontekście termin „użytkownicy” oznacza nie tylko zarządców infrastruktury lub przedsiębiorstwa kolejowe, lecz także wszystkich innych dostawców usług, takich jak firmy wagonowe, operatorów intermodalnych, a nawet klientów.
Zakres techniczny niniejszej TSI został również określony w art. 2 ust. 1 i 3 niniejszego rozporządzenia.
1.4. Zakres geograficzny
Zakres geograficzny niniejszej TSI obejmuje sieć całego systemu kolei składającą się z:
sieci transeuropejskiego systemu kolei konwencjonalnej (TEN) opisanej w sekcji 1.1 „Sieć” załącznika I do dyrektywy 2008/57/WE [1],
sieci transeuropejskiego systemu kolei dużych prędkości (TEN) opisanej w sekcji 2.1 „Sieć” załącznika I do dyrektywy 2008/57/WE [1],
pozostałych części sieci całego systemu kolei, w wyniku rozszerzenia zakresu zgodnie z opisem zawartym w sekcji 4 załącznika I do dyrektywy 2008/57/WE [1].
Zakres ten nie obejmuje natomiast przypadków, o których mowa w art. 1 ust. 3 dyrektywy 2008/57/WE [1].
1.5. Treść niniejszej TSI TAF
Treść niniejszej TSI TAF jest zgodna z art. 5 dyrektywy 2008/57/WE [1].
W niniejszej TSI zawarto również w rozdziale 4 („Charakterystyka podsystemu”) wymagania dotyczące eksploatacji i utrzymania, których zakres odpowiada zakresowi określonemu w ustępach 1.1 („Zakres techniczny”) i 1.2 („Zakres geograficzny”).
2. DEFINICJA PODSYSTEMU I ZAKRES
2.1. Funkcja wchodząca w zakres TSI
Podsystem „Aplikacje telematyczne dla przewozów towarowych” został określony w załączniku II do dyrektywy 2008/57/WE [1], sekcja 2.5 lit. b).
W jego skład wchodzą w szczególności:
aplikacje dla przewozów towarowych, w tym systemy informatyczne (monitorowanie towarów i pociągów w czasie rzeczywistym),
systemy zestawcze i przydziałowe, przy czym systemy przydziałowe są rozumiane jako skład pociągów,
systemy rezerwacyjne, przy czym są one tu rozumiane jako rezerwacja tras pociągów,
zarządzanie połączeniami z innymi rodzajami transportu i sporządzanie elektronicznych dokumentów towarzyszących.
2.2. Funkcje niewchodzące w zakres TSI
W zakres niniejszej TSI nie wchodzą systemy płatności i fakturowania dla klientów ani też podobne systemy obsługi płatności i fakturowania pomiędzy różnymi dostawcami usług, takimi jak przedsiębiorstwa kolejowe lub zarządcy infrastruktury. Jednakże informacje stanowiące podstawę do płatności za usługi transportowe dostarczane są za pomocą rozwiązania systemowego, na którym opiera się wymiana danych zgodnie z rozdziałem 4.2 („Specyfikacje funkcjonalne i techniczne podsystemu”).
Długoterminowe planowanie rozkładów jazdy nie wchodzi w zakres niniejszej TSI „Aplikacje telematyczne”. Niemniej jednak w niektórych punktach umieszczono odniesienie do wyniku długoterminowego planowania, o ile istnieje związek ze sprawną wymianą informacji koniecznych do eksploatacji pociągów.
2.3. Przegląd opisu podsystemu
2.3.1. Uczestniczące podmioty
W niniejszej TSI uwzględniono obecnych dostawców usług oraz różnych możliwych przyszłych dostawców usług w zakresie transportu towarowego działających w następujących dziedzinach (wykaz ten nie jest wyczerpujący):
wagony towarowe,
manewrowanie i rozrządzanie,
sprzedaż przedziałów czasowych,
zarządzanie przesyłką,
skład pociągu,
eksploatacja pociągu,
monitorowanie pociągu,
sterowanie pociągiem,
monitorowanie przesyłki,
kontrole i naprawy wagonów lub lokomotyw,
obsługa terminali intermodalnych,
zarządzanie przewozami.
Pewni określeni dostawcy usług są zdefiniowani bezpośrednio w tekście dyrektyw 2012/34/UE [3], 2008/57/WE [1] i 2004/49/WE [9]. Ponieważ wspomniane dyrektywy muszą zostać uwzględnione, w TSI wzięto pod uwagę w szczególności poniższe definicje:
„Zarządca infrastruktury” (IM) (dyrektywa 2012/34/UE [3]) oznacza każdy podmiot lub przedsiębiorstwo, które są odpowiedzialne w szczególności za założenie infrastruktury kolejowej, zarządzanie nią i jej utrzymanie, w tym za prowadzenie ruchu pociągów, urządzenia bezpiecznej kontroli jazdy i urządzenia sterowania ruchem kolejowym (srk); funkcje zarządcy infrastruktury na sieci lub części sieci mogą być przydzielane różnym podmiotom lub przedsiębiorstwom. W przypadku gdy zarządca infrastruktury pod względem prawnym, organizacyjnym lub w zakresie podejmowania decyzji nie jest niezależny od któregokolwiek przedsiębiorstwa kolejowego, funkcje, o których mowa w sekcjach 2 i 3 rozdziału IV, są wykonywane odpowiednio przez organ pobierający opłaty i przez organ alokujący, które są niezależne w swojej formie prawnej, organizacyjnej i w zakresie podejmowania decyzji od któregokolwiek przedsiębiorstwa kolejowego.
W oparciu o tę definicję w ramach niniejszej TSI za IM uważa się dostawcę usług w zakresie przydzielania tras, sterowania/monitorowania pociągów oraz sprawozdawczości związanej z pociągami/trasami.
„Wnioskodawca” (dyrektywa 2012/34/UE [3]) oznacza przedsiębiorstwo kolejowe lub międzynarodowe ugrupowanie przedsiębiorstw kolejowych lub inne osoby lub podmioty prawne, takie jak właściwe organy w rozumieniu rozporządzenia (WE) nr 1370/2007 oraz spedytorzy, nadawcy towarów i operatorzy transportu kombinowanego, którzy ze względu na świadczenie usługi publicznej lub ze względów handlowych są zainteresowani uzyskaniem zdolności przepustowej infrastruktury.
„Przedsiębiorstwo kolejowe” (dyrektywa 2004/49/WE [9]) oznacza przedsiębiorstwo zdefiniowane w dyrektywie 2001/14/WE oraz każde publiczne lub prywatne przedsiębiorstwo, którego działalność polega na dokonywaniu transportu towarów i/lub pasażerów koleją, z zastrzeżeniem, że przedsiębiorstwo to musi zapewnić trakcję; obejmuje to również przedsiębiorstwa, które dostarczają wyłącznie trakcję.
W oparciu o tę definicję w ramach niniejszej TSI za RU uważa się dostawcę usług w zakresie eksploatacji pociągów.
W odniesieniu do przydziału trasy pociągu na potrzeby przewozu pociągiem należy również wziąć pod uwagę art. 38 dyrektywy 2012/34/UE [3]:
zdolność przepustowa infrastruktury jest alokowana przez zarządcę infrastruktury. Po dokonaniu alokacji na rzecz wnioskodawcy nie może być ona przekazywana przez otrzymującego innemu przedsiębiorstwu lub innym rodzajom przewozów.
Wszelki obrót zdolnością przepustową infrastruktury jest zakazany i prowadzi do wykluczenia z dalszej alokacji zdolności przepustowej.
Wykorzystywanie zdolności przepustowej przez przedsiębiorstwo kolejowe przy wykonywaniu działalności gospodarczej wnioskodawcy, który nie jest przedsiębiorstwem kolejowym, nie jest uważane za przekazanie.
W przypadku scenariuszy komunikacji pomiędzy zarządcami infrastruktury a wnioskodawcami w trybie wykonawczym transportu należy brać pod uwagę tylko IM i RU, a nie wszystkie rodzaje wnioskodawców, którzy mogą być stosowni dla trybu planowania. W trybie wykonawczym zawsze istnieje zdefiniowana zależność IM — RU, w odniesieniu do której specyfikacje dotyczące wymiany wiadomości i przechowywania informacji określono w niniejszej TSI. Nie ma to wpływu na definicję wnioskodawcy oraz wynikające z niej możliwości przydziału trasy.
Na potrzeby transportu towarowego zapewnione muszą zostać różnorodne usługi. Jedną z takich usług jest na przykład dostarczanie wagonów. Usługę tę można powiązać z zarządcą floty pojazdów. Jeżeli ta usługa na potrzeby transportu jest jedną z usług oferowanych przez RU, to RU działa również jako zarządca floty pojazdów. Zarządca floty pojazdów może z kolei zarządzać swoimi własnymi wagonami lub wagonami innego posiadacza (innego dostawcy usług w zakresie wagonów towarowych). Zapotrzebowanie na tego rodzaju dostawcę usług jest uwzględniane niezależnie od tego, czy osoba prawna zarządcy floty pojazdów jest jednocześnie RU, czy nie.
W niniejszej TSI nie wprowadza się nowych osób prawnych, ani nie wymaga się od RU angażowania zewnętrznych dostawców do świadczenia usług, które świadczy samo RU, jednakże w stosownych przypadkach usługę określono nazwą odpowiedniego dostawcy usług. Jeśli usługa jest świadczona przez RU, to RU działa jako dostawca usług w odniesieniu do danej usługi.
Biorąc pod uwagę potrzeby klienta, jedną z usług jest organizowanie linii transportowej i zarządzanie nią, zgodnie ze zobowiązaniem wobec klienta. Usługa ta jest dostarczana przez wiodące przedsiębiorstwo kolejowe (wiodące RU lub LRU). LRU stanowi jeden centralny punkt kontaktowy dla klienta. Jeżeli w łańcuchu transportowym uczestniczy więcej niż jedno przedsiębiorstwo kolejowe, to LRU jest także odpowiedzialne za koordynację z innymi przedsiębiorstwami kolejowymi.
Usługa ta może być również realizowana przez spedytora lub dowolny inny podmiot.
Zakres działalności RU jako LRU może różnić się w zależności od typu przepływu transportu. W działalności intermodalnej zarządzanie objętością załadowczą w pociągach odcinkowych bezpośrednich oraz przygotowywanie listów przewozowych jest wykonywane przez integratora usług intermodalnych, który może wówczas być klientem LRU.
Podstawową kwestią jest jednak to, że RU i IM oraz wszyscy pozostali dostawcy usług (w znaczeniu zdefiniowanym w niniejszym załączniku) muszą ze sobą współpracować, w drodze wspólnego działania lub otwartego dostępu oraz poprzez sprawną wymianę informacji, aby zapewnić klientowi ciągłość usług.
2.3.2. Rozpatrywane procesy
Zakres niniejszej TSI dotyczącej sektora kolejowego transportu towarowego jest ograniczony zgodnie z dyrektywą 2008/57/WE [1] do IM i RU/LRU w odniesieniu do ich bezpośrednich klientów. Zgodnie z porozumieniem umownym LRU dostarcza klientowi informacje, w szczególności:
informacje o trasie,
informacje o kursowaniu pociągu w odniesieniu do uzgodnionych punktów raportowania, w tym przynajmniej punktu początkowego trasy, punktu wymiany/przekazania i punktu docelowego transportu będącego przedmiotem umowy,
przewidywany czas przyjazdu (ang. Estimated Time of Arrival, ETA) do miejsca docelowego, w tym stacji rozrządowych i terminali intermodalnych,
informacje o zakłóceniu usługi. Jeżeli wiodące RU uzyska informację o zakłóceniu usługi, przekazuje ją ono klientowi w należytym terminie.
Na użytek dostarczania powyższych informacji w rozdziale 4 określono odpowiednie komunikaty zgodne z wymaganiami w zakresie TAF.
Przy wykonywaniu transportu towarowego działalność LRU dotycząca przesyłki rozpoczyna się wraz z otrzymaniem listu przewozowego od klienta oraz, na przykład, w przypadku wagonów ładownych — wraz z czasem zwolnienia wagonów. LRU tworzy wstępny plan podróży (w oparciu o doświadczenie lub umowę) dla danego transportu. Jeżeli LRU zamierza wykonywać transport wagonów ładownych pociągiem w trybie otwartego dostępu (LRU wykonuje transport danym pociągiem na całej trasie), to wstępny plan podróży jest zarazem planem ostatecznym. Jeżeli LRU zamierza przemieszczać wagony ładowne w ramach transportu pociągiem wykonywanego przy współpracy z innymi RU, musi najpierw dowiedzieć się, do których RU powinien się zwrócić i w jakim czasie może nastąpić wymiana pomiędzy dwoma kolejnymi RU. LRU przygotowuje wówczas wstępne zamówienia przewozów indywidualnie dla każdego RU, jako poszczególne części listu przewozowego. Szczegóły dotyczące zamówień przewozów zawarto w rozdziale 4.2.1 („Dane listu przewozowego”).
RU, do którego zwrócono się, sprawdza dostępność zasobów potrzebnych do eksploatacji wagonów oraz dostępność trasy pociągu. Odpowiedzi otrzymane od poszczególnych RU pozwalają LRU na dopracowanie planu podróży lub prowadzą do wznowienia zapytania — być może nawet skierowania go do innych RU — aż plan podróży zostanie w pełni dostosowany do wymagań klienta.
RU/LRU musi zasadniczo posiadać przynajmniej zdolność:
OKREŚLANIA usług pod względem ceny i czasów przejazdu, dostawy wagonów (w stosownych przypadkach), danych dotyczących wagonów/jednostek intermodalnych (lokalizacja, status oraz przewidywany czas przyjazdu (ETA) wagonów/jednostek intermodalnych), w przypadku gdy przesyłki mogą być załadowywane do pustych wagonów, kontenerów itp.,
DOSTARCZANIA określonej usługi w sposób niezawodny i niezakłócony poprzez stosowanie powszechnych procesów gospodarczych i powiązanych systemów. RU, IM oraz inni dostawcy usług i zainteresowane strony, takie jak urzędy celne, muszą dysponować możliwością wymiany informacji drogą elektroniczną,
MIERZENIA jakości dostarczanej usługi w porównaniu do określonych wcześniej parametrów, to jest pokrywania się wystawionych rachunków z podaną wcześniej ceną, rzeczywistych czasów przejazdu z podjętymi zobowiązaniami, wagonów zamówionych z dostarczonymi, ETA z faktycznym czasem przyjazdu,
DZIAŁANIA w sposób produktywny pod względem wykorzystania: zdolności przepustowej pociągów, infrastruktury i floty pojazdów poprzez stosowanie procesów gospodarczych, systemów i wymiany informacji koniecznych do właściwej eksploatacji wagonów/jednostek intermodalnych i sporządzania rozkładu jazdy pociągu.
RU/LRU jako wnioskodawcy muszą również zapewnić posiadanie (poprzez umowy z IM) wymaganej trasy pociągu i muszą wykonać transport pociągiem w obrębie swojego odcinka przejazdu. Jeżeli chodzi o trasę pociągu, mogą oni wykorzystać zarezerwowane już (w trybie planowania) trasy lub muszą zwrócić się z wnioskiem ad hoc o przydzielenie trasy pociągu do zarządców infrastruktury (IM) właściwych dla odcinków przejazdu, na których RU wykonuje transport pociągiem. W dodatku I podano przykład scenariusza dotyczącego wniosku o przydzielenie trasy.
Ważna dla komunikacji pomiędzy IM a RU podczas ruchu pociągu jest także własność trasy. Komunikacja musi być zawsze oparta o numer pociągu oraz numer trasy, przy użyciu których IM komunikuje się z RU, które zarezerwowało trasę pociągu należącą do infrastruktury danego IM (zob. także dodatek I).
Jeżeli RU zapewnia transport na całej trasie przejazdu A–F (RU działa w trybie otwartego dostępu, nie uczestniczą inne RU), każdy uczestniczący IM komunikuje się bezpośrednio tylko z tym RU. Taka działalność RU w trybie „otwartego dostępu” może być realizowana przez zarezerwowanie całości trasy pociągu w centralnym punkcie obsługi (ang. One Stop Shop) lub dokonywanie osobnych rezerwacji poszczególnych odcinków bezpośrednio u każdego IM. TSI uwzględnia obydwa przypadki, jak przedstawiono w rozdziale 4.2.2.1: „Wniosek o przydzielenie trasy. Uwagi wstępne”.
Przebieg dialogu pomiędzy RU i IM w celu ustalenia trasy pociągu towarowego określono w rozdziale 4.2.2 („Wniosek o przydzielenie trasy”). Funkcja ta odnosi się do art. 48 ust. 1 dyrektywy 2012/34/UE [3]. W zakres takiego dialogu nie wchodzi uzyskiwanie licencji przez RU świadczące usługi zgodnie z dyrektywą 2001/13/WE [10], certyfikacji zgodnie z dyrektywą 2012/34/UE [3] ani praw dostępu zgodnie z dyrektywą 2012/34/UE [3].
W rozdziale 4.2.3 („Przygotowanie pociągu”) określono wymianę informacji dotyczącą składu pociągu oraz procedury odjazdu pociągu. Wymianę danych podczas jazdy pociągu w przypadku zwykłego przejazdu przedstawiono w rozdziale 4.2.4 („Prognoza jazdy pociągu”), a komunikaty na wypadek sytuacji wyjątkowych określono w rozdziale 4.2.5 („Informacja o zakłóceniu usługi”). Wszystkie te komunikaty są wymieniane pomiędzy RU i IM i odnoszą się do konkretnych pociągów.
Dla klienta najważniejszą informacją jest zawsze przewidywany czas przyjazdu (ETA) jego przesyłki. ETA może zostać ustalony na podstawie wymiany informacji pomiędzy LRU a IM (w przypadku otwartego dostępu). W przypadku trybu współpracy z różnymi RU, ETA oraz przewidywany czas wymiany (ang. estimated time of interchange, ETI) mogą zostać ustalone na podstawie wymiany komunikatów pomiędzy RU i IM, a wynik ustaleń dostarczony LRU przez poszczególne RU (rozdział 4.2.6 „ETI/ETA przesyłki”).
Wymiana informacji pomiędzy IM a RU stanowi dla LRU również źródło następujących informacji:
kiedy wagony wyjechały ze stacji rozrządowej lub przyjechały do niej albo w inne określone miejsca (rozdział 4.2.7 „Ruch wagonów”),
kiedy odpowiedzialność za wagony została przeniesiona z jednego RU na kolejne RU w łańcuchu transportowym (rozdział 4.2.8 „Raportowanie o wymianie”).
Na podstawie nie tylko wymiany danych pomiędzy IM i RU, lecz także wymiany danych pomiędzy poszczególnymi RU i LRU, można opracować różnorodne statystyki:
na potrzeby — w perspektywie średnioterminowej — bardziej szczegółowego planowania procesu produkcji, oraz
na potrzeby — w perspektywie długoterminowej — realizacji zadań planowania strategicznego oraz badań zdolności (np. analiz sieci, określania bocznic i stacji rozrządowych, planowania taboru), lecz przede wszystkim
w celu poprawy jakości usług transportowych i wydajności (rozdział 4.2.9 „Wymiana danych służąca poprawie jakości”).
Obsługiwanie pustych wagonów nabiera szczególnego znaczenia, jeśli weźmie się pod uwagę wagony eksploatowane w trybie interoperacyjności. W zasadzie nie ma różnicy w obsługiwaniu wagonów załadowanych i pustych. Transport pustych wagonów jest również dokonywany na podstawie zleceń przewozu, w związku z czym zarządca floty takich pustych wagonów musi być uważany za klienta.
2.3.3. Uwagi ogólne
O jakości systemu informacyjnego decyduje wiarygodność zawartych w nim danych. Dlatego dane, które odgrywają decydującą rolę w ekspediowaniu przesyłki, wagonu lub kontenera, muszą być precyzyjne i uzyskane w ekonomiczny sposób, co znaczy, że określone dane powinny być wprowadzane do systemu tylko raz.
Z tych względów aplikacje i komunikaty, o których mowa w niniejszej TSI, umożliwiają uniknięcie wielokrotnego ręcznego wprowadzania danych dzięki dostępowi do wpisanych już do systemu danych, np. danych referencyjnych o taborze. Wymagania dotyczące danych referencyjnych o taborze określono w rozdziale 4.2.10 („Główne dane referencyjne”). Określone referencyjne bazy danych taboru muszą umożliwiać łatwy dostęp do danych technicznych. Zawartość baz danych musi być dostępna, na podstawie usystematyzowanych praw dostępu zależnych od uprawnień, dla wszystkich IM, RU i zarządców floty pojazdów, w szczególności do celów zarządzania flotą i utrzymania taboru. Bazy te muszą zawierać wszystkie dane techniczne niezbędne do celów transportu, takie jak:
identyfikacja taboru kolejowego,
dane techniczne/projektowe,
ocena zgodności z infrastrukturą,
ocena stosownej charakterystyki załadunku,
charakterystyka dotycząca hamowania,
dane dotyczące utrzymania,
charakterystyka pod kątem kwestii związanych ze środowiskiem.
W intermodalnej działalności transportowej w różnych punktach (zwanych terminalami przeładunkowymi) nie tylko wagon jest podłączany do innego pociągu, lecz także jednostka intermodalna może być przeniesiona z jednego wagonu do drugiego. W związku z tym w działalności tej nie można opierać się jedynie na planie podróży sporządzonym w odniesieniu do wagonów, należy również opracować plan podróży w odniesieniu do jednostek intermodalnych.
W rozdziale 4.2.11 („Lista plików referencyjnych”) wymieniono kilka plików referencyjnych i różne bazy danych, wśród nich operacyjną bazę danych wagonów i jednostek intermodalnych. Baza ta zawiera dane o statusie operacyjnym taboru, informacje o ciężarze i niebezpiecznych towarach, informacje dotyczące jednostek intermodalnych oraz informacje o lokalizacji.
W TSI dotyczącej podsystemu „Aplikacje telematyczne dla przewozów towarowych” określono wymagane informacje, które muszą być wymieniane pomiędzy różnymi partnerami biorącymi udział w łańcuchu transportowym, co umożliwia wdrożenie standardowego procesu wymiany obowiązkowych danych. W TSI przedstawiono również strategię dotyczącą architektury takiej platformy komunikacyjnej. Została ona opisana w rozdziale 4.2.12 („Łączność sieciowa i komunikacja”), z uwzględnieniem:
interfejsu podsystemu „Ruch kolejowy”, o którym mowa w art. 5 ust. 3 dyrektywy 2008/57/WE [1],
wymagań dotyczących treści regulaminu sieci, określonych w art. 27 dyrektywy 2012/34/WE [3] i w załączniku IV do tej dyrektywy,
dostępnych informacji o taborze wagonów towarowych oraz wymagań dotyczących konserwacji, pochodzących z TSI dotyczącej taboru kolejowego.
Nie ma bezpośredniej transmisji danych z podsystemu „Aplikacje telematyczne dla przewozów towarowych” do pociągu, maszynisty lub do części podsystemu „Sterowanie ruchem kolejowym”, a fizyczna sieć transmisyjna jest zupełnie inna niż sieć wykorzystywana przez podsystem „Sterowanie ruchem kolejowym”. System ERTMS/ETCS wykorzystuje GSM-R. W przypadku tej otwartej sieci w specyfikacjach ETCS wyjaśniono, że bezpieczeństwo jest osiągane poprzez odpowiednie zarządzanie zagrożeniami otwartych sieci w protokole EURORADIO.
Interfejsy podsystemów strukturalnych: „Tabor kolejowy” i „Bezpieczna kontrola jazdy pociągu” określone są jedynie za pośrednictwem referencyjnych baz danych taboru kolejowego (rozdział 4.2.10.2: „Referencyjne bazy danych taboru kolejowego”), które znajdują się pod kontrolą posiadaczy taborów. Interfejsy podsystemów: „Infrastruktura”, „Bezpieczna kontrola jazdy pociągu” i „Energia” określone są w ramach definicji trasy (rozdział 4.2.2.3: „Komunikat »Szczegółowe dane o trasie«”) podawanej przez IM, która zawiera odnoszące się do pociągu parametry związane z infrastrukturą, oraz w treści informacji o ograniczeniach w infrastrukturze, dostarczanej przez IM (rozdział 4.2.2 „Wniosek o przydzielenie trasy” oraz rozdział 4.2.3 „Przygotowanie pociągu”).
Zgodnie z art. 4 ust. 1 dyrektywy 2008/57/WE [1] transeuropejski system kolei, podsystemy i ich składniki interoperacyjności muszą spełniać wymagania zasadnicze zawarte w ogólnych warunkach określonych w załączniku III do dyrektywy.
W zakresie TSI w niniejszej wersji spełnianie przez podsystem stosownych wymagań zasadniczych podanych w rozdziale 3 zostanie zapewnione dzięki zastosowaniu się do specyfikacji opisanych w rozdziale 4 „Charakterystyka podsystemu”.
3.2. Aspekty wymagań zasadniczych
Wymagania zasadnicze dotyczą:
Zgodnie z dyrektywą 2008/57/WE [1] wymagania zasadnicze mogą mieć ogólne zastosowanie w odniesieniu do całego transeuropejskiego systemu kolei lub mogą dotyczyć jedynie poszczególnych podsystemów i ich składników.
3.3. Aspekty związane z wymaganiami ogólnymi
Zakres stosowania wymagań ogólnych do podsystemu „Aplikacje telematyczne dla przewozów towarowych” jest określony następująco:
3.3.1. Bezpieczeństwo
Wymagania zasadnicze 1.1.1, 1.1.2, 1.1.3, 1.1.4 i 1.1.5 określone w załączniku III do dyrektywy 2008/57/WE [1] nie odnoszą się do podsystemu „Aplikacje telematyczne”.
„Monitorowanie i konserwacja nieruchomych i ruchomych elementów uczestniczących w ruchu pociągów muszą być zorganizowane, przeprowadzane i określane ilościowo w taki sposób, aby utrzymać ich funkcjonowanie w zamierzonych warunkach”
To wymaganie zasadnicze jest spełnione poprzez zgodność ze specyfikacjami w następujących rozdziałach:
rozdział 4.2.10: „Główne dane referencyjne”,
rozdział 4.2.11: „Lista plików referencyjnych i referencyjnych baz danych”,
rozdział 4.2.12: „Łączność sieciowa i komunikacja”.
Wymagania zasadnicze 1.3.1 i 1.3.2 określone w załączniku III do dyrektywy 2008/57/WE [1] nie odnoszą się do podsystemu „Aplikacje telematyczne”.
3.3.4. Ochrona środowiska
Wymagania zasadnicze 1.4.1, 1.4.2, 1.4.3, 1.4.4 i 1.4.5 określone w załączniku III do dyrektywy 2008/57/WE [1] nie odnoszą się do podsystemu „Aplikacje telematyczne”.
3.3.5. Zgodność techniczna
Wymaganie zasadnicze 1.5 określone w załączniku III do dyrektywy 2008/57/WE [1] nie odnosi się do podsystemu „Aplikacje telematyczne”.
3.4. Aspekty dotyczące w szczególności podsystemu „Aplikacje telematyczne dla przewozów towarowych”
3.4.1. Zgodność techniczna
Wymaganie zasadnicze 2.7.1 określone w załączniku III do dyrektywy 2008/57/WE [1]:
„Zasadnicze wymogi dla aplikacji telematycznych gwarantują minimalny poziom jakości usług dla pasażerów i przewoźników towarów, w szczególności w zakresie zgodności technicznej.
Należy podjąć działania zapewniające:
rozwój baz danych, oprogramowania i protokołów transmisji danych w sposób pozwalający na maksymalną wzajemną wymianę danych między różnymi aplikacjami i operatorami, z wyłączeniem poufnych danych handlowych,
łatwy dostęp użytkownika do informacji”
Powyższe wymaganie zasadnicze jest spełnione w szczególności poprzez zgodność ze specyfikacjami w następujących rozdziałach:
3.4.2. Niezawodność i dostępność
Wymaganie zasadnicze 2.7.2 określone w załączniku III do dyrektywy 2008/57/WE [1]:
„Sposoby użytkowania, zarządzania, aktualizacji oraz utrzymania tych baz danych, oprogramowania i protokołów transmisji danych muszą zapewniać wydajność tych systemów oraz jakość usług”
Powyższe wymaganie jest spełnione w szczególności poprzez zgodność ze specyfikacjami w następujących rozdziałach:
To wymaganie zasadnicze, zwłaszcza w odniesieniu do sposobu użytkowania zapewniającego wydajność tych aplikacji telematycznych oraz jakość usług, jest podstawą całej TSI, tak więc zakres jego zastosowania nie ogranicza się do rozdziałów 4.2.10, 4.2.11 oraz 4.2.12.
3.4.3. Zdrowie
Wymaganie zasadnicze 2.7.3 określone w załączniku III do dyrektywy 2008/57/WE [1]:
„Płaszczyzny współpracy między tymi systemami a użytkownikami muszą być zgodne z minimalnymi zasadami ergonomii i ochrony zdrowia”
W niniejszej TSI nie określono żadnych dodatkowych wymagań wykraczających poza istniejące krajowe i europejskie uregulowania dotyczące minimalnych zasad ergonomii i ochrony zdrowia w odniesieniu do płaszczyzny współpracy (interfejsu) między aplikacjami telematycznymi a użytkownikami.
3.4.4. Bezpieczeństwo
Wymaganie zasadnicze 2.7.4 określone w załączniku III do dyrektywy 2008/57/WE [1]:
„Zapewniony zostać musi odpowiedni poziom uczciwości i niezawodności w zakresie gromadzenia i przekazywania informacji dotyczących bezpieczeństwa”
Powyższe wymaganie spełnione jest poprzez zgodność ze specyfikacjami w następujących rozdziałach:
System kolei, do którego zastosowanie ma dyrektywa 2008/57/WE i którego częścią jest podsystem „Aplikacje telematyczne”, jest systemem zintegrowanym, którego spójność musi być zweryfikowana. Należy sprawdzać w szczególności, czy zachowana jest spójność: w specyfikacjach podsystemu, między jego interfejsami a systemem, z którymi jest on zintegrowany, jak również w zasadach dotyczących jego eksploatacji i utrzymania.
Biorąc pod uwagę wszystkie mające zastosowanie wymagania zasadnicze, podsystem „Aplikacje telematyczne dla przewozów towarowych” charakteryzuje się podanymi poniższej cechami.
W świetle wymagań zasadniczych przedstawionych w rozdziale 3 (Wymagania zasadnicze) specyfikacje funkcjonalne i techniczne podsystemu obejmują informacje dotyczące następujących kwestii:
dane listu przewozowego,
wniosek o przydzielenie trasy,
przygotowanie pociągu,
prognoza jazdy pociągu,
informacje o zakłóceniu usługi,
ETI/ETA wagonów/jednostek intermodalnych,
ruch wagonów,
raportowanie o wymianie,
wymiana danych w celu poprawy jakości,
główne dane referencyjne,
lista plików referencyjnych i referencyjnych baz danych,
łączność sieciowa i komunikacja.
Szczegółowe specyfikacje określone są w pełnym katalogu danych. Wymagane formaty komunikatów i danych we wspomnianym katalogu określono w wymienionym w dodatku I dokumencie „TAF TSI — Annex D.2: Appendix F — TAF TSI Data and Message Model”. W tym samym celu można ponadto wykorzystać inne obowiązujące normy, o ile istnieje szczególne porozumienie pomiędzy zaangażowanymi stronami, umożliwiające wykorzystywanie takich norm, w szczególności na terytoriach państw członkowskich UE graniczących z państwami trzecimi.
Ogólne uwagi na temat struktury komunikatów
Każdy komunikat składa się z dwóch zestawów danych:
— dane kontrolne: określone poprzez wskazany w katalogu komunikatów obowiązkowy tytuł komunikatu,
— dane informacyjne: określone poprzez obowiązkową/opcjonalną treść danego komunikatu oraz obowiązkowy/opcjonalny zestaw danych wskazany w katalogu.
Jeżeli komunikat lub element danych określony jest w niniejszym rozporządzeniu jako opcjonalny, zainteresowane strony podejmują decyzję dotyczącą stosowania go. Zasady stosowania takich komunikatów i elementów danych muszą zostać zawarte w porozumieniu umownym. Jeżeli zawarte w katalogu danych elementy opcjonalne w pewnych okolicznościach stają się obowiązkowe, informacja o tym musi zostać zawarta w katalogu danych.
4.2.1. Dane listu przewozowego
4.2.1.1. List przewozowy klienta
List przewozowy musi zostać wysłany przez klienta do wiodącego RU. W liście tym muszą zostać wskazane wszystkie dane potrzebne do przewiezienia przesyłki od nadawcy do odbiorcy zgodnie z „Przepisami ujednoliconymi o umowie międzynarodowego przewozu towarów kolejami (CIM)”, „Przepisami ujednoliconymi o umowach użytkowania pojazdów w międzynarodowej komunikacji kolejowej (CUV)” i obowiązującymi przepisami krajowymi. LRU musi uzupełnić te dane o dodatkowe informacje. Podzbiór danych listu przewozowego, w tym wspomniane dodatkowe informacje, opisano w dokumentach: „TAF TSI — Annex D.2: Appendix A (WAGON/ILU TRIP PLANNING)” oraz „TAF TSI — Annex D.2: Appendix F — TAF TSI Data and Message Model” [4]), wymienionych w tabeli w dodatku I do niniejszego rozporządzenia.
W przypadku otwartego dostępu wiodące RU zawierające umowę z klientem posiada wszystkie dane po uzupełnieniu ich o informacje dodatkowe. Nie jest wymagana wymiana komunikatów z innymi RU. Dane te są także podstawą do wystosowania wniosku o przydzielenie trasy ad hoc, jeśli jest to konieczne do wykonania listu przewozowego.
Poniższe komunikaty dotyczą przypadku, w którym przewóz nie jest wykonywany na zasadzie otwartego dostępu. Treść tych komunikatów może także być podstawą do wystosowania wniosku o przydzielenie trasy ad hoc, jeśli jest to konieczne do wykonania listu przewozowego.
4.2.1.2. Zlecenia przewozu
Zlecenie przewozu jest zasadniczo podzbiorem informacji zawartych w liście przewozowym. Musi ono zostać dostarczone przez LRU przedsiębiorstwom kolejowym uczestniczącym w łańcuchu transportowym. Treść zlecenia przewozu musi zawierać istotne informacje, które są potrzebne RU do wykonania transportu na etapie, za który to RU odpowiada, aż do przekazania przesyłki kolejnemu RU. Dlatego treść ta zależy od pełnionej przez przedsiębiorstwo kolejowe roli: początkowego RU, tranzytowego RU lub odbiorczego RU.
Struktura danych obowiązkowych w zleceniu przewozu oraz szczegóły dotyczące formatu odnośnego komunikatu wskazane zostały w pozycji zatytułowanej „ConsignmentOrderMessage” w wymienionym w dodatku I dokumencie „TAF TSI — Annex D.2: Appendix F — TAF TSI Data and Message Model”.
Główne elementy zlecenia przewozu to:
dane dotyczące nadawcy i odbiorcy,
dane dotyczące przebiegu trasy,
identyfikacja przesyłki,
dane o wagonach,
dane o miejscu i czasie.
Niektóre dane zawarte w liście przewozowym muszą być również dostępne dla wszystkich partnerów (np. dla IM, posiadacza itd.) w łańcuchu transportowym, w tym dla klientów. Są to w szczególności następujące dane w odniesieniu do poszczególnych wagonów:
ciężar ładunku (ciężar brutto ładunku),
numer CN/HS,
informacja o niebezpiecznych towarach,
jednostka transportu.
Wersję papierową stosować można tylko w wyjątkowych przypadkach, wyłącznie wówczas, gdy danych tych nie można przesłać za pomocą komunikatów określonych powyżej.
4.2.2. Wniosek o przydzielenie trasy
4.2.2.1. Uwagi wstępne
Informacje dotyczące trasy oznaczają wnioskowane, przyjęte i faktyczne dane, które mają być przechowywane, dotyczące trasy i charakterystyki pociągu w odniesieniu do każdego odcinka trasy. W poniższym opisie przedstawiono dane, które muszą być dostępne dla zarządcy infrastruktury. Dane te muszą być aktualizowane za każdym razem, gdy nastąpi zmiana. W danych dotyczących trasy ustalonej na rok musi być zatem możliwe wyszukanie danych na potrzeby wprowadzania krótkoterminowych zmian. W szczególności, jeżeli zmiany te są istotne dla klienta, musi on być o nich informowany przez LRU.
Wniosek o przydzielenie trasy ad hoc
Wskutek wyjątkowych okoliczności podczas jazdy pociągu lub z powodu pilnych zapotrzebowań transportowych przedsiębiorstwo kolejowe musi mieć możliwość otrzymania ad hoc trasy w sieci.
W pierwszym przypadku muszą zostać podjęte natychmiastowe działania, przy czym znany jest rzeczywisty skład pociągu w oparciu o wykaz pojazdów kolejowych w składzie pociągu.
W drugim przypadku przedsiębiorstwo kolejowe musi dostarczyć zarządcy infrastruktury wszystkie niezbędne dane o tym, kiedy i dokąd wymagana jest jazda pociągu, wraz z wszystkimi parametrami fizycznymi, które mają znaczenie w odniesieniu do infrastruktury.
Parametr podstawowy „wnioski o przydzielenie trasy ad hoc” powinien być spełniany w drodze współpracy między RU a zarządcą infrastruktury (IM). W zakresie tego parametru podstawowego termin IM może odnosić się do zarządcy infrastruktury oraz, w stosownych przypadkach, do organów alokujących (zob. dyrektywa 2012/34/UE [3]).
Wymagania te obowiązują w odniesieniu do wszystkich wniosków o przydzielenie trasy ad-hoc.
Niniejszy parametr podstawowy nie uwzględnia kwestii związanych z zarządzaniem ruchem. Rozgraniczenie czasowe pomiędzy przydzieleniem trasy ad-hoc a zmianami trasy w związku z zarządzaniem ruchem jest przedmiotem porozumień miejscowych.
Przedsiębiorstwo kolejowe (RU) musi dostarczyć zarządcy infrastruktury (IM) wszystkie niezbędne dane o tym, kiedy i dokąd wymagana jest jazda pociągu, wraz z wszystkimi parametrami fizycznymi, które maja znaczenie dla infrastruktury.
Każdy zarządca infrastruktury jest odpowiedzialny za odpowiedniość trasy w ramach swojej infrastruktury, natomiast przedsiębiorstwo kolejowe ma obowiązek porównać parametry techniczne pociągu z wartościami podanymi w szczegółowych danych dotyczących zamówionej trasy.
Bez uszczerbku dla warunków użytkowania trasy zawartych w regulaminie sieci lub dla zasad odpowiedzialności w razie jakichkolwiek ograniczeń w infrastrukturze wyjaśnionych w TSI „Ruch kolejowy”, przed przygotowaniem pociągu RU musi wiedzieć, czy istnieją jakieś ograniczenia na odcinkach linii lub stacjach (węzłach) wpływające na skład jego pociągu opisany w umowie o trasę.
Porozumienie o przydzieleniu trasy ad hoc na przejazd pociągu zawierane jest w oparciu o dialog między RU a IM. Wnioskodawcy mogą składać wnioski o przyznanie zdolności przepustowej infrastruktury. Aby wykorzystać tę zdolność przepustową infrastruktury, wnioskodawcy wyznaczają przedsiębiorstwo kolejowe, które zawrze umowę z zarządcą infrastruktury zgodnie z dyrektywą 2012/34/UE [3]. W odnośnym dialogu biorą udział wszystkie RU i wszyscy IM uczestniczące(-y) w przemieszczaniu pociągu po wnioskowanej trasie, jednakże ich wkład w proces znajdowania trasy może być różny.
4.2.2.2. Komunikat „Wniosek o przydzielenie trasy”
Komunikat ten wysłany jest przez RU do zarządcy infrastruktury (IM) w celu zwrócenia się z wnioskiem o przydzielenie trasy.
Definicję obowiązkowej struktury tego komunikatu oraz wymagane elementy podano w wymienionym w dodatku I dokumencie „TAF TSI — Annex D.2: Appendix F — TAF TSI Data and Message Model”.
4.2.2.3. Komunikat „Szczegółowe dane o trasie”
IM wysyła taki komunikat do RU jako odpowiedź na złożony przez to RU wniosek o przydzielenie trasy.
Definicję obowiązkowej struktury komunikatu „Szczegółowe dane o trasie” oraz wymagane elementy podano w wymienionym w dodatku I dokumencie „TAF TSI — Annex D.2: Appendix F — TAF TSI Data and Message Model”.
4.2.2.4. Komunikat „Trasa potwierdzona”
RU wnioskujące o przydzielenie trasy wykorzystuje ten komunikat do zamówienia lub potwierdzenia trasy proponowanej przez IM.
Definicję obowiązkowej struktury komunikatu „Trasa potwierdzona” oraz wymagane elementy podano w wymienionym w dodatku I dokumencie „TAF TSI — Annex D.2: Appendix F — TAF TSI Data and Message Model”.
4.2.2.5. Komunikat „Odmowa szczegółowych danych o trasie”
RU wnioskujące o przydzielenie trasy wykorzystuje ten komunikat do odrzucenia szczegółowych danych o trasie proponowanej przez odpowiedniego zarządcę infrastruktury.
Definicję obowiązkowej struktury komunikatu „Odmowa szczegółowych danych o trasie” oraz wymagane elementy podano w wymienionym w dodatku I dokumencie „TAF TSI — Annex D.2: Appendix F — TAF TSI Data and Message Model”.
4.2.2.6. Komunikat „Trasa odwołana”
Komunikat ten jest wykorzystywany przez RU wnioskujące o przydzielenie trasy do rezygnacji z całości lub części zamówionej trasy.
Definicję obowiązkowej struktury komunikatu „Trasa odwołana” oraz wymagane elementy podano w wymienionym w dodatku I dokumencie „TAF TSI — Annex D.2: Appendix F — TAF TSI Data and Message Model”.
4.2.2.7. Komunikat „Trasa niedostępna”
IM wysyła ten komunikat do RU, które zamówiło trasę, w przypadku gdy trasa ta nie jest już dostępna.
Definicję obowiązkowej struktury komunikatu „Trasa niedostępna” oraz wymagane elementy podano w wymienionym w dodatku I dokumencie „TAF TSI — Annex D.2: Appendix F — TAF TSI Data and Message Model”.
4.2.2.8. Komunikat „Potwierdzenie odbioru”
Komunikat ten jest wysyłany przez odbiorcę komunikatu do nadawcy pierwotnego komunikatu w celu potwierdzenia, że do systemu, z którego korzysta odbiorca, pierwotny komunikat dotarł w określonym przedziale czasu.
Definicję obowiązkowej struktury komunikatu „Potwierdzenie odbioru” oraz wymagane elementy podano w wymienionym w dodatku I dokumencie „TAF TSI — Annex D.2: Appendix F — TAF TSI Data and Message Model”.
4.2.3. Przygotowanie pociągu
Niniejszy parametr podstawowy określa komunikaty, które muszą być wymieniane na etapie przygotowania pociągu do czasu rozpoczęcia jazdy pociągu.
Przygotowanie pociągu obejmuje sprawdzenie zgodności między pociągiem a drogą. Zgodność tę sprawdza RU, na podstawie dostarczonych przez odpowiednich IM informacji zawierających opis infrastruktury i jej ograniczeń.
W ramach przygotowania pociągu RU musi wysłać dane o składzie pociągu do kolejnych RU. Zgodnie z porozumieniem umownym RU musi wysłać ten komunikat również do IM, u którego (u których) zamówił poszczególne odcinki danej trasy.
Jeżeli skład pociągu ulegnie zmianie w pewnym miejscu trasy, komunikat ten musi zostać wysłany jeszcze raz, z informacjami zaktualizowanymi przez odpowiadające za to RU.
W celu przygotowania pociągu RU musi mieć dostęp do powiadomień o ograniczeniach w infrastrukturze, do technicznych danych o wagonach (referencyjne bazy danych taboru kolejowego, rozdział 4.2.10.2 „Referencyjne bazy danych taboru kolejowego”), do informacji o niebezpiecznych towarach oraz do bieżących, aktualizowanych informacji o wagonach (rozdział 4.2.11.2: „Inne bazy danych: Operacyjna baza danych wagonów i jednostek intermodalnych”). Dotyczy to wszystkich wagonów pociągu. Na koniec RU musi wysłać dane o składzie pociągu do kolejnych RU. Komunikat ten RU musi wysłać również do każdego IM, u którego zamówił odcinek trasy, jeśli taki wymóg zawarto w odnoszącej się do kolei konwencjonalnych TSI „Ruch kolejowy” lub w umowie (umowach) między RU a IM.
W każdym punkcie, np. w punkcie początkowym i w punkcie wymiany, w którym następuje zmiana RU, na którym spoczywa odpowiedzialność, obowiązkowe jest przeprowadzenie między IM a RU dialogu przewidzianego na początku procedury: „Pociąg gotowy — Informacja o jeździe pociągu”.
4.2.3.2. Komunikat „Skład pociągu”
Komunikat ten RU musi wysłać do kolejnego RU, określając w nim skład pociągu. Zgodnie z regulaminem sieci RU musi wysłać ten komunikat również do IM. Za każdym razem, gdy następuje zmiana składu podczas przejazdu pociągu, RU dokonujące tej zmiany musi zaktualizować informacje w tym komunikacie i przekazać je LRU, które przekazuje odnośne informacje wszystkim uczestniczącym stronom.
Definicję obowiązkowej struktury komunikatu „Skład pociągu” oraz wymagane elementy podano w wymienionym w dodatku I dokumencie „TAF TSI — Annex D.2: Appendix F — TAF TSI Data and Message Model”.
Minimalny zakres informacji, jakie muszą zostać dostarczone na potrzeby wymiany komunikatu „Skład pociągu” pomiędzy RU a IM został określony w rozdziale 4.2.2.7.2 decyzji 2012/757/UE w sprawie TSI „Ruch kolejowy”.
4.2.3.3. Komunikat „Pociąg gotowy”
Przedsiębiorstwo kolejowe wysyła do zarządcy infrastruktury komunikat „Pociąg gotowy” za każdym razem, gdy pociąg jest gotowy do jazdy po zakończeniu jego przygotowania, chyba że zgodnie z przepisami krajowymi zarządca infrastruktury uznaje rozkład jazdy za komunikat „Pociąg gotowy”.
Definicję obowiązkowej struktury komunikatu „Pociąg gotowy” oraz wymagane elementy podano w wymienionym w dodatku I dokumencie „TAF TSI — Annex D.2: Appendix F — TAF TSI Data and Message Model”. W tym samym celu można ponadto wykorzystać inne obowiązujące normy, o ile uczestniczące podmioty zawarły szczególne porozumienie umożliwiające wykorzystywanie takich norm.
4.2.4. Prognoza jazdy pociągu
4.2.4.1. Uwagi ogólne
Niniejszy parametr podstawowy określa informacje o jeździe pociągu i prognozę jazdy pociągu. Wskazuje się w nim, w jaki sposób ma być prowadzony dialog pomiędzy zarządcą infrastruktury a przedsiębiorstwem kolejowym, aby zapewnić wymianę informacji o jeździe pociągu i prognoz jazdy pociągu.
Niniejszy parametr podstawowy określa, w jaki sposób zarządca infrastruktury musi w odpowiednim momencie wysłać informację o jeździe pociągu do przedsiębiorstwa kolejowego oraz do kolejnego sąsiedniego zarządcy infrastruktury zaangażowanego w przejazd pociągu.
Prognoza jazdy pociągu jest wykorzystywana do udzielania informacji na temat przewidywanego czasu w wynikających z umowy punktach prognozy. Komunikat ten musi zostać wysłany przez zarządcę infrastruktury do przedsiębiorstwa kolejowego oraz sąsiedniego zarządcy infrastruktury zaangażowanego w przejazd.
W porozumieniach umownych określa się punkty raportowania w odniesieniu do jazdy pociągu.
Ta wymiana informacji pomiędzy RU a IM odbywa się zawsze pomiędzy IM zarządzającym odnośną infrastrukturą a RU, które zamówiło trasę, po której pociąg faktycznie się porusza.
Na podstawie porozumienia umownego LRU zapewnia klientowi prognozę jazdy pociągu i informację o jeździe pociągu. Punkty raportowania są uzgadniane przez obie strony w ramach umowy.
4.2.4.2. Komunikat „Prognoza jazdy pociągu”
Komunikat ten musi zostać wysłany przez IM do RU, które wykonuje przejazd pociągiem, w odniesieniu do punktów przekazania, punktów wymiany oraz do punktu docelowego pociągu, zgodnie z opisem w rozdziale 4.2.4.1 („Prognoza jazdy pociągu. Uwagi ogólne”).
Ponadto komunikat ten musi być wysłany przez IM do RU w odniesieniu do innych punktów raportowania zgodnie z umowami między RU a IM (np. w odniesieniu do punktów obsługi lub stacji).
Prognozę jazdy pociągu można także wysłać zanim pociąg rozpocznie jazdę. W odniesieniu do dodatkowych opóźnień mających miejsce pomiędzy dwoma punktami raportowania w umowie pomiędzy przedsiębiorstwem kolejowym a zarządcą infrastruktury należy określić wartość progową, na podstawie której podejmowana jest decyzja o wysłaniu pierwotnej lub nowej prognozy. Jeżeli stopień opóźnienia nie jest znany, zarządca infrastruktury musi wysłać „Komunikat o zakłóceniu usługi” (zob. rozdział 4.2.5. „Informacje o zakłóceniu usługi”).
Definicję obowiązkowej struktury komunikatu „Prognoza jazdy pociągu” oraz wymagane elementy podano w wymienionym w dodatku I dokumencie „TAF TSI — Annex D.2: Appendix F — TAF TSI Data and Message Model”.
4.2.4.3. Komunikaty „Informacja o jeździe pociągu” i „Przyczyna opóźnienia pociągu”.
Komunikat „Informacja o jeździe pociągu” musi zostać wysłany przez IM do RU wykonującego przejazd pociągiem przy:
odjeździe z punktu odjazdu, przyjeździe do punktu docelowego;
przyjeździe i odjeździe z punktów przekazania, punktów wymiany oraz punktów raportowania wynikających umowy (np. punktów obsługi).
Jeżeli znana jest przyczyna opóźnienia (pierwsze założenie) informację o niej należy przesłać w osobnym komunikacie „Przyczyna opóźnienia pociągu”.
Definicję obowiązkowej struktury komunikatów „Informacja o jeździe pociągu” i „Przyczyna opóźnienia pociągu” oraz wymagane elementy podano w wymienionym w dodatku I dokumencie „TAF TSI — Annex D.2: Appendix F — TAF TSI Data and Message Model”.
4.2.5. Informacje o zakłóceniu usługi
4.2.5.1. Uwagi ogólne
Niniejszy parametr podstawowy określa, w jaki sposób informacje o zakłóceniu usługi są wymieniane pomiędzy przedsiębiorstwem kolejowym a zarządcą infrastruktury.
Jeśli RU uzyska informację o zakłóceniu usługi podczas wykonywania przejazdu pociągiem, za który jest odpowiedzialny, musi niezwłocznie powiadomić stosownego IM (informacja może zostać przekazana przez RU ustnie). Jeżeli dochodzi do wstrzymania jazdy pociągu, zarządca infrastruktury wysyła komunikat „Wstrzymana jazda pociągu” do RU, z którym zawarł umowę, oraz do kolejnego sąsiedniego zarządcy infrastruktury zaangażowanego w jazdę pociągu.
Jeżeli wielkość opóźnienia jest znana, zarządca infrastruktury musi zamiast komunikatu „Wstrzymana jazda pociągu” wysłać komunikat „Prognoza jazdy pociągu”.
4.2.5.2. Komunikat „Wstrzymana jazda pociągu”
Jeżeli jazda pociągu zostaje wstrzymana IM wysyła ten komunikat do kolejnego sąsiedniego IM zaangażowanego w przejazd pociągu i do RU.
Definicję obowiązkowej struktury komunikatu „Wstrzymana jazda pociągu” oraz wymagane elementy podano w wymienionym w dodatku I dokumencie „TAF TSI — Annex D.2: Appendix F — TAF TSI Data and Message Model”.
4.2.6. ETI/ETA przesyłki
4.2.6.1. Uwaga wstępna
W rozdziale 4.2.2 („Wniosek o przydzielenie trasy”) opisano głównie komunikację między RU i IM. Indywidualne monitorowanie wagonów lub jednostek intermodalnych nie wchodzi w zakres takiej wymiany informacji. Monitorowanie to odbywa się na poziomie RU/LRU na podstawie komunikatów dotyczących pociągu, co zostało opisane w poniższych rozdziałach, od 4.2.6 („ETI/ETA przesyłki”) do 4.2.8 („Raportowanie o wymianie”).
Podstawę wymiany i aktualizacji informacji dotyczących wagonów i jednostek intermodalnych stanowią zasadniczo przechowywane w bazach „plany podróży” i dane o ruchach wagonów (rozdział 4.2.11.2: „Inne bazy danych”).
Jak już wspomniano w rozdziale 2.3.2 („Rozpatrywane procesy”), dla klienta najważniejszą informacją jest zawsze przewidywany czas przyjazdu (ETA) jego przesyłki. ETA dotyczący wagonów, a także ETI są również podstawowymi informacjami w komunikacji pomiędzy LRU i RU. Informacje te są dla LRU głównym instrumentem monitorowania fizycznego transportu przesyłki oraz sprawdzania zgodności przebiegu tego transportu z zobowiązaniami wobec klienta.
Wszystkie prognozowane czasy zawarte w komunikatach dotyczących pociągu odnoszą się do przyjazdu pociągu do pewnego punktu, którym może być punkt przekazania, punkt wymiany, punkt docelowy pociągu lub inny punkt raportowania. Wszystkie te pozycje są przewidywanymi czasami przyjazdu pociągu (ang. Train Estimated Times of Arrivals, TETA). Znaczenie TETA może zmieniać się w zależności od poszczególnych wagonów lub jednostek intermodalnych w pociągu. Na przykład TETA w odniesieniu do punktu wymiany może oznaczać w przypadku pewnych wagonów lub jednostek intermodalnych przewidywany czas wymiany (ETI). W przypadku innych wagonów pozostających w składzie pociągu do dalszego transportu przez to samo RU TETA może nie być istotny. Zadaniem RU otrzymującego informacje o TETA jest zidentyfikowanie i przetworzenie tych informacji, zachowanie ich w operacyjnej bazie danych wagonów i jednostek intermodalnych jako danych o ruchu wagonów i przekazanie ich LRU, jeżeli jazda pociągu nie odbywa się w trybie otwartego dostępu. Odnośny opis zawarto w poniższych rozdziałach.
Zgodnie z porozumieniem umownym LRU podaje klientowi przewidywany czas przyjazdu (ETA) oraz przewidywany czas wymiany (ETI) w odniesieniu do danej przesyłki. Stopień szczegółowości uzgadniany jest przez obie strony w ramach umowy.
W przypadku transportu intermodalnego w komunikatach zawierających identyfikatory jednostek ładunkowych (np. kontenerów, nadwozi wymiennych i naczep) stosuje się kody BIC lub kody ILU zgodnie z, odpowiednio, normą ISO 6346 i normą EN 13044.
4.2.6.2. Obliczanie ETI/ETA
Obliczanie ETI/ETA oparte jest o informacje otrzymane od zarządcy odnośnej infrastruktury, który w komunikacie „Prognoza jazdy pociągu” podaje przewidywany czas przyjazdu pociągu (TETA) do określonych punktów raportowania (w każdym przypadku w odniesieniu do punktów przekazania, wymiany lub przyjazdu, w tym również terminali intermodalnych) na uzgodnionej trasie, np. czas przyjazdu do punktu przekazania między danym IM a kolejnym IM (w takim przypadku TETA odpowiada ETH).
W odniesieniu do punktów wymiany lub innych określonych punktów raportowania na uzgodnionej trasie RU musi obliczyć na użytek kolejnego RU w łańcuchu przesyłki transportowej przewidywany czas wymiany (ETI) dla wagonów lub jednostek intermodalnych.
Ponieważ RU może mieć w pociągu wagony o różnych trasach przejazdu i pochodzące od różnych LRU, punkt wymiany przyjmowany w obliczeniach ETI może różnić się w zależności od wagonu. (Prezentację graficzną odnośnych scenariuszy oraz przykłady zamieszczono w wymienionym w dodatku I dokumencie „TAF TSI — Annex A.5: Figures and Sequence Diagrams of the TAF TSI messages” w rozdziale 1.4, natomiast schemat proceduralny odnoszący się do przykładu 1 dla punktu wymiany C przedstawiono w wymienionym w dodatku I dokumencie „TAF TSI — Annex A.5: Figures and Sequence Diagrams of the TAF TSI messages” w rozdziale 5).
Kolejne RU, na podstawie danych dotyczących ETI dostarczonych przez poprzednie RU, oblicza z kolei ETI wagonów w następnym punkcie wymiany. Kroki te są wykonywane przez każde kolejne RU. Gdy ostatnie RU (np. RU n) w łańcuchu transportowym wagonu otrzyma od poprzedzającego je RU (np. RU n-1) ETI wagonu pomiędzy RU n-1 a RU n, ostatnie RU (RU n) musi obliczyć przewidywany czas przyjazdu wagonów do punktu docelowego. Ma to na celu zapewnienie zestawienia wagonów w kolejności zgodnej ze zleceniem przewozu oraz stosownie do zobowiązania LRU wobec klienta. Jest to ETA wagonu i musi on zostać wysłany do LRU. Dane dotyczące ETA muszą być przechowywane w formacie elektronicznym wraz z danymi o ruchu wagonów. LRU musi udzielać klientowi stosownych informacji zgodnie z warunkami porozumienia umownego.
Uwaga dotycząca jednostek intermodalnych: W przypadku jednostek intermodalnych w wagonie ETI wagonu stanowi również ETI jednostek intermodalnych. W odniesieniu do ETA jednostek intermodalnych należy zauważyć, że RU nie jest w stanie obliczyć takiego ETA poza ramami transportu kolejowego. Dlatego RU może dostarczyć tylko ETI odnoszące się do terminalu intermodalnego.
Wiodące RU jest odpowiedzialne za porównywanie ETA ze zobowiązaniem wobec klienta.
W przypadku odchyleń ETA od czasu określonego w zobowiązaniu wobec klienta należy postępować zgodnie z umową; odchylenia takie mogą prowadzić do wszczęcia przez LRU procesu zarządzania alertem. Do przekazywania informacji o wyniku tego procesu stosuje się komunikat „Alert”.
LRU musi posiadać możliwość wystosowania dotyczącego wagonów zapytania o odchylenia, stanowiącą podstawę procesu zarządzania alertem. To zapytanie LRU i odpowiedź RU zostały również określone poniżej.
4.2.6.3. Komunikat „ETI/ETA wagonów”
Komunikat ten RU wysyła w celu poinformowania kolejnego RU w łańcuchu transportowym o ETI lub zaktualizowanym ETI. Ostatni RU w łańcuchu transportowym wagonów wysyła ETA lub zaktualizowany ETA do LRU. Definicję obowiązkowej struktury komunikatu „ETI/ETA wagonów” oraz wymagane elementy podano w wymienionym w dodatku I dokumencie „TAF TSI — Annex D.2: Appendix F — TAF TSI Data and Message Model”.
4.2.6.4. Komunikat „Alert”
W wyniku porównania ETA z zobowiązaniem wobec klienta LRU może wysłać komunikat „Alert” do uczestniczących RU. Definicję obowiązkowej struktury komunikatu „Alert” oraz wymagane elementy podano w wymienionym w dodatku I dokumencie „TAF TSI — Annex D.2: Appendix F — TAF TSI Data and Message Model”.
Uwaga: W przypadku otwartego dostępu obliczenie ETI i ETA jest wewnętrznym procesem RU. W takim przypadku RU jest równocześnie wiodącym RU.
4.2.7. Ruch wagonów
4.2.7.1. Uwagi wstępne
Dane zawarte w wymienionych poniżej komunikatach muszą być przechowane i elektronicznie dostępne do celów raportowania o ruchu wagonu. Muszą one również być wymieniane między upoważnionymi stronami w ramach komunikatu na podstawie umowy.
Powiadomienie o zwolnieniu wagonu
Powiadomienie o odjeździe wagonu
Przyjazd wagonu do stacji rozrządowej
Wyjazd wagonu ze stacji rozrządowej
Komunikat o wyjątkowej sytuacji wagonu
Powiadomienie o przyjeździe wagonu
Powiadomienie o dostawie wagonu
Raportowanie o wymianie wagonu zostało opisane oddzielnie w rozdziale 4.2.8 „Raportowanie o wymianie”.
Na podstawie porozumienia umownego LRU musi udzielać klientowi informacji o ruchu wagonów za pomocą komunikatów opisanych poniżej.
4.2.7.2. Komunikat „Powiadomienie o zwolnieniu wagonu”
Wiodące RU niekoniecznie jest pierwszym RU w łańcuchu transportowym. W takim przypadku LRU musi powiadomić RU odpowiadające za dany przejazd, że wagon jest gotowy do zabrania z bocznicy klienta (miejsce odjazdu zgodnie ze zobowiązaniem LRU) o danym czasie zwolnienia (data i czas odjazdu).
Dane o takich zdarzeniach muszą być przechowywane w operacyjnej bazie danych wagonów i jednostek intermodalnych. Definicję obowiązkowej struktury komunikatu „Powiadomienie o zwolnieniu wagonu” oraz wymagane elementy podano w wymienionym w dodatku I dokumencie „TAF TSI — Annex D.2: Appendix F — TAF TSI Data and Message Model”.
4.2.7.3. Komunikat „Powiadomienie o odjeździe wagonu”
RU musi powiadomić LRU o rzeczywistej dacie i czasie, kiedy wagon został zabrany z miejsca odjazdu.
Dane o takich zdarzeniach muszą być przechowywane w operacyjnej bazie danych wagonów i jednostek intermodalnych. Poprzez wymianę tego komunikatu odpowiedzialność za wagon przechodzi z klienta na RU. Definicję obowiązkowej struktury komunikatu „Powiadomienie o odjeździe wagonu” oraz wymagane elementy podano w wymienionym w dodatku I dokumencie „TAF TSI — Annex D.2: Appendix F — TAF TSI Data and Message Model”.
4.2.7.4. Komunikat „Przyjazd wagonu do stacji rozrządowej”
RU musi powiadomić LRU, że wagon przybył do jego stacji rozrządowej. Komunikat ten może być oparty o komunikat „Informacja o jeździe pociągu” opisany w rozdziale 4.2.4 („Prognoza jazdy pociągu”). Dane o tym zdarzeniu muszą być przechowywane w operacyjnej bazie danych wagonów i jednostek intermodalnych. Definicję obowiązkowej struktury komunikatu „Przyjazd wagonu do stacji rozrządowej” oraz wymagane elementy podano w wymienionym w dodatku I dokumencie „TAF TSI — Annex D.2: Appendix F — TAF TSI Data and Message Model”.
4.2.7.5. Komunikat „Wyjazd wagonu ze stacji rozrządowej”
RU musi powiadomić LRU, że wagon opuścił jego stację rozrządową. Komunikat ten może być oparty o komunikat „Informacja o jeździe pociągu” opisany w rozdziale 4.2.4 („Prognoza jazdy pociągu”). Dane o tym zdarzeniu muszą być przechowywane w operacyjnej bazie danych wagonów i jednostek intermodalnych. Definicję obowiązkowej struktury komunikatu „Wyjazd wagonu ze stacji rozrządowej” oraz wymagane elementy podano w wymienionym w dodatku I dokumencie „TAF TSI — Annex D.2: Appendix F — TAF TSI Data and Message Model”.
4.2.7.6. Komunikat „Wyjątkowa sytuacja wagonu”
RU musi powiadomić LRU, jeśli z wagonem zdarzyło się coś nieoczekiwanego, co mogłoby mieć wpływ na ETI/ETA lub co wymaga dodatkowego działania. W większości przypadków komunikat ten wymaga również obliczenia nowego ETI/ETA. Jeżeli LRU zdecyduje, że konieczne jest określenie nowego ETI/ETA, odsyła komunikat do RU, które wysłało komunikat o wyjątkowej sytuacji, i zawiera w nim wskazanie „Wnioskuje się o ETI/ETA” (komunikaty: „Wyjątkowa sytuacja wagonu”, „Wnioskuje się o ETI/ETA”). Obliczenie nowego ETI/ETA musi być wykonane zgodnie z procedurą podaną w rozdziale 4.2.6 (ETI/ETA przesyłki).
Informacja ta musi zostać zachowana w operacyjnej bazie danych wagonów i jednostek intermodalnych. Definicję obowiązkowej struktury komunikatu „Wyjątkowa sytuacja wagonu” oraz wymagane elementy podano w wymienionym w dodatku I dokumencie „TAF TSI — Annex D.2: Appendix F — TAF TSI Data and Message Model”.
4.2.7.7. Komunikat „Powiadomienie o przyjeździe wagonu”
Ostatnie RU w łańcuchu transportowym wagonów lub jednostek intermodalnych musi powiadomić LRU, że wagon przybył do jego stacji rozrządowej (lokalizacja RU). Definicję obowiązkowej struktury komunikatu „Powiadomienie o o przyjeździe wagonu” oraz wymagane elementy podano w wymienionym w dodatku I dokumencie „TAF TSI — Annex D.2: Appendix F — TAF TSI Data and Message Model”.
4.2.7.8. Komunikat „Powiadomienie o dostawie wagonu”
Ostatni RU w łańcuchu transportowym wagonów musi powiadomić LRU, że wagon został umieszczony na bocznicy odbiorcy.
Uwaga: W przypadku otwartego dostępu opisany ruch wagonu jest wewnętrznym procesem RU (LRU). Niemniej jednak wszystkie obliczenia i przechowanie danych muszą być wykonane przez niego jako LRU posiadającego umowę i zobowiązanie wobec klienta.
Schemat proceduralny w odniesieniu do tych komunikatów, oparty na przykładzie 1 obliczenia ETI dla wagonów 1 i 2 (zob. rozdział 4.2.6.2 „Obliczanie ETI/ETA”) został zintegrowany ze schematem raportowania wymiany przedstawionym w wymienionym w dodatku I dokumencie „TAF TSI — Annex A.5: Figures and Sequence Diagrams of the TAF TSI messages”, w rozdziale 6.
4.2.8. Raportowanie o wymianie
4.2.8.1. Uwaga wstępna
Raportowanie o wymianie obejmuje komunikaty wysyłane w związku z następującym w punktach wymiany przeniesieniem odpowiedzialności za wagon z jednego przedsiębiorstwa kolejowego na kolejne. Nakazuje również nowemu RU wykonanie obliczenia ETI i przeprowadzenie procesu opisanego w rozdziale 4.2.6 („ETI/ETA przesyłki”).
Wymienione muszą zostać następujące komunikaty:
powiadomienie o wymianie wagonu,
powiadomienie o wymianie wagonu oraz zastępstwie,
odebranie wagonu przy wymianie,
odmówienie wagonu przy wymianie.
Dane informacyjne tych komunikatów muszą być przechowywane w operacyjnej bazie danych wagonów i jednostek intermodalnych. W przypadku jakiegokolwiek odchylenia nowy ETI/ETA musi zostać wygenerowany i przekazany zgodnie z procesem opisanym w rozdziale 4.2.6 „ETI/ETA przesyłki”. Schemat proceduralny w odniesieniu do tych komunikatów został przedstawiony w wymienionym w dodatku I dokumencie „TAF TSI — Annex A.5: Figures and Sequence Diagrams of the TAF TSI messages”, w związku z komunikatami dotyczącymi ruchu wagonów.
Powiadomienia o wymianie wagonów oraz powiadomienia o wymianie wagonów/zastępstwie, jak również komunikaty o odebraniu wagonów mogą być przekazywane w formie wykazu różnych wagonów, zwłaszcza jeśli wszystkie wagony znajdują się w jednym pociągu. W takim przypadku wszystkie wagony mogą być wymienione w pojedynczym przekazie komunikatu.
W przypadku otwartego dostępu nie ma punktów wymiany. W punkcie obsługi podmiot, na którym spoczywa odpowiedzialność za wagony, nie zmienia się. Dlatego też nie ma potrzeby wymiany odnośnych komunikatów. Zawarte w komunikacie „Informacja o jeździe pociągu” w tym punkcie raportowania informacje odnoszące się do wagonów lub jednostek intermodalnych — dotyczące daty/czasu przyjazdu i odjazdu — muszą jednak zostać przetworzone i zachowane w operacyjnej bazie danych wagonów i jednostek intermodalnych.
Na podstawie porozumienia umownego LRU musi udzielać klientowi informacji wchodzących w zakres raportowania o wymianie za pomocą komunikatów opisanych poniżej.
Definicję obowiązkowej struktury tych komunikatów podano w wymienionym w dodatku I dokumencie „TAF TSI — Annex D.2: Appendix F — TAF TSI Data and Message Model”.
4.2.8.2. Komunikat „Powiadomienie o wymianie wagonu”
Za pomocą komunikatu „Powiadomienie o wymianie wagonu” przedsiębiorstwo kolejowe (RU 1) pyta kolejne przedsiębiorstwo kolejowe (RU 2) w łańcuchu transportowym, czy przyjmuje ono odpowiedzialność za wagon. Za pomocą komunikatu „Powiadomienie o wymianie wagonu/Zastępstwo” RU 2 informuje swojego IM, że przyjęło odpowiedzialność. Definicję obowiązkowej struktury komunikatu „Powiadomienie o o wymianie wagonu” oraz wymagane elementy podano w wymienionym w dodatku I dokumencie „TAF TSI — Annex D.2: Appendix F — TAF TSI Data and Message Model”.
4.2.8.3. Komunikat „Powiadomienie o wymianie wagonu/Zastępstwo”
Za pomocą komunikatu „Powiadomienie o wymianie wagonu/Zastępstwo” RU 2 informuje IM, że przejęło odpowiedzialność za określony wagon. Definicję obowiązkowej struktury komunikatu „Powiadomienie o o wymianie wagonu/Zastępstwo” oraz wymagane elementy podano w wymienionym w dodatku I dokumencie „TAF TSI — Annex D.2: Appendix F — TAF TSI Data and Message Model”.
4.2.8.4. Komunikat „Odebranie wagonu przy wymianie”
Za pomocą komunikatu „Odebranie wagonu przy wymianie” RU 2 informuje RU 1, że przyjmuje odpowiedzialność za wagon. Definicję obowiązkowej struktury komunikatu „Odebranie wagonu przy wymianie” oraz wymagane elementy podano w wymienionym w dodatku I dokumencie „TAF TSI — Annex D.2: Appendix F — TAF TSI Data and Message Model”.
4.2.8.5. Komunikat „Odmowa wagonu przy wymianie”
Za pomocą komunikatu „Odmowa wagonu przy wymianie” RU 2 informuje RU 1, że odmawia przejęcia odpowiedzialności za wagon. Definicję obowiązkowej struktury komunikatu „Odmowa wagonu przy wymianie” oraz wymagane elementy podano w wymienionym w dodatku I dokumencie „TAF TSI — Annex D.2: Appendix F — TAF TSI Data and Message Model”.
4.2.9. Wymiana danych w celu poprawy jakości
Aby zachować konkurencyjność, europejskie kolejnictwo musi poprawić jakość usług świadczonych swym klientom (zob. również pkt 2.7.1 w załączniku III do dyrektywy 2008/57/WE [1]). Proces pomiarowy stanowi zasadniczy proces odbywający się po podróży, mający na celu wspieranie działań na rzecz poprawy jakości. Oprócz mierzenia jakości usługi świadczonej na rzecz klienta LRU, RU i IM muszą mierzyć jakość wszystkich składników usługi, które składają się na produkt dostarczany klientowi. W procesie tym uczestniczą IM i RU (zwłaszcza jeśli są one wiodącymi RU), którzy/które wybierają indywidualny parametr jakości, drogę lub lokalizację oraz okres pomiaru, w odniesieniu do których mają być mierzone rzeczywiste wyniki w stosunku do z góry ustalonych kryteriów, które zazwyczaj są określane w umowie. Wyniki procesu pomiarowego muszą wyraźnie pokazywać poziom osiągnięć względem wartości docelowych, które zostały uzgodnione między stronami umowy.
4.2.10. Główne dane referencyjne
4.2.10.1. Wstęp
Dane o infrastrukturze (regulamin sieci oraz powiadomienia o ograniczeniach w infrastrukturze) oraz dane o taborze kolejowym (w referencyjnych bazach danych taboru kolejowego i w operacyjnej bazie danych wagonów i jednostek intermodalnych) są najważniejszymi danymi na potrzeby eksploatacji pociągów towarowych w sieci europejskiej. Obydwa rodzaje danych wspólnie pozwalają na ocenę zgodności taboru kolejowego z infrastrukturą, pomagają uniknąć wielokrotnego wprowadzania danych, co podnosi zwłaszcza jakość danych, a ponadto dają jasny obraz wszystkich dostępnych instalacji i urządzeń w dowolnym momencie, umożliwiając w ten sposób szybkie podejmowanie decyzji podczas eksploatacji.
4.2.10.2. Referencyjne bazy danych taboru kolejowego
Posiadacz taboru kolejowego jest odpowiedzialny za przechowywanie danych o taborze kolejowym w referencyjnej bazie danych taboru kolejowego.
Informacje, które muszą być zachowywane w indywidualnych referencyjnych bazach danych taboru kolejowego, opisane są szczegółowo w wymienionym w dodatku I dodatku C. W ich skład muszą wchodzić wszystkie dane konieczne do:
identyfikacji taboru kolejowego,
oceny zgodności z infrastrukturą,
oceny charakterystyki stosownego załadunku,
scharakteryzowania hamowania,
podania danych dotyczących utrzymania,
podania charakterystyki pod kątem kwestii związanych ze środowiskiem.
Referencyjne bazy danych taboru kolejowego muszą umożliwiać łatwy dostęp (jednorodny wspólny sposób dostępu jest zapewniony za pomocą wspólnego interfejsu) do technicznych danych w celu ograniczenia do minimum objętości danych przesyłanych w ramach każdej operacji. Zawartość baz danych musi być dostępna, na podstawie usystematyzowanych praw dostępu zależnych od uprawnień, dla wszystkich dostawców usług (IM, RU, dostawców usług logistycznych i zarządców floty pojazdów), w szczególności do celów zarządzania flotą i utrzymania taboru.
Wpisy w referencyjnej bazie danych taboru kolejowego mogą być pogrupowane w następujących kategoriach:
dane administracyjne związane z elementami certyfikacji i rejestracji, takimi jak odniesienie do pliku rejestracji WE, identyfikator jednostki notyfikowanej itd.; w ich zakres mogą wchodzić historyczne dane dotyczące własności, wynajmu itp. Dodatkowo, zgodnie z art. 5 rozporządzenia (UE) nr 445/2011, posiadacze wagonów mogą przechowywać w indywidualnych referencyjnych bazach danych taboru kolejowego numer identyfikacyjny certyfikacji podmiotu odpowiedzialnego za utrzymanie. Należy uwzględnić informacje dotyczące następujących kwestii:
certyfikacja WE,
rejestracja w „rodzimym” państwie,
data oddania do eksploatacji w państwie rejestracji,
rejestracja w innych krajach do użytku w ich krajowych sieciach,
certyfikacja bezpieczeństwa całego taboru kolejowego, który nie odpowiada wymogom TSI „Tabor kolejowy”.
Posiadacz jest zobowiązany zapewnić, że dane te są dostępne i że odpowiadające im procesy zostały przeprowadzone;
dane projektowe, które muszą obejmować wszystkie składowe (fizyczne) elementy taboru kolejowego, w tym charakterystykę dotyczącą kwestii związanych ze środowiskiem, oraz wszelkie informacje, wobec których można oczekiwać, że pozostaną ważne przez cały okres eksploatacji taboru kolejowego — ta część może zawierać historię ważniejszych modyfikacji, kapitalnej konserwacji, remontu itp.
4.2.10.3. Dane operacyjne o taborze kolejowym
Oprócz danych referencyjnych dotyczących taboru kolejowego, dane odzwierciedlające faktyczny stan taboru kolejowego są najważniejszymi danymi do celów operacyjnych.
Dane te muszą zawierać dane o ograniczonym okresie ważności, takie jak ograniczenia, bieżące i przewidywane działania w zakresie utrzymania, stan liczników kilometrów i usterek itp. oraz wszelkie dane, które można uznać za dane dotyczące „stanu” (tymczasowe ograniczenia prędkości, odłączenie hamulca, opis potrzebnych napraw, opis usterek itp.).
Przy wykorzystywaniu danych operacyjnych o taborze kolejowym należy uwzględnić trzy różne podmioty, biorąc pod uwagę różne strony odpowiedzialne za tabor kolejowy podczas wykonywania transportu:
przedsiębiorstwo kolejowe jako odpowiedzialne na odcinkach, na których wykonuje ono transport,
posiadacz taboru kolejowego, oraz
użytkownik (najemca) taboru kolejowego.
W przypadku wszystkich trzech podmiotów dane operacyjne o taborze kolejowym muszą być dostępne dla upoważnionego użytkownika, zgodnie z zakresem posiadanych przez niego z góry określonych praw dostępu, przy użyciu pojedynczego klucza w postaci identyfikatora wagonu (numeru wagonu).
Dane operacyjne o taborze kolejowym są częścią operacyjnej bazy danych wagonów i jednostek intermodalnych opisanej w rozdziale 4.2.11.2 „Inne bazy danych”.
4.2.11. Lista plików referencyjnych i referencyjnych baz danych
4.2.11.1. Pliki referencyjne
Na potrzeby eksploatacji pociągów towarowych w sieci europejskiej dostawcy usług (IM, RU, dostawcy usług logistycznych i zarządcy floty pojazdów) muszą mieć dostęp do wskazanych poniżej plików referencyjnych. Dane te muszą w każdym momencie odzwierciedlać rzeczywisty stan rzeczy. W przypadku gdy plik referencyjny jest użytkowany wspólnie z TSI TAP [2], rozwijanie jego zawartości i wprowadzane w nim zmiany muszą być zgodne z TSI TAP [2] w celu osiągnięcia jak najwyższego stopnia synergii.
Przechowywane i administrowane lokalnie:
referencyjny plik służb ratunkowych, skorelowany z rodzajem niebezpiecznego towaru.
Przechowywane i administrowane centralnie:
referencyjny plik kodowania dla wszystkich IM, RU, firm będących dostawcami usług;
referencyjny plik kodowania dla klientów korzystających z usług transportu towarowego;
referencyjny plik kodowania lokalizacji (podstawowych i drugorzędnych);
Europejska Agencja Kolejowa zachowuje kopię referencyjnego pliku kodów lokalizacji i kodów przedsiębiorstw. Na indywidualne żądanie i bez uszczerbku dla praw własności intelektualnej, dane te powinny być dostępne dla ogółu społeczeństwa.
Pozostałe listy kodów zostały określone w wymienionym w dodatku I dokumencie „TAF TSI — Annex D.2: Appendix F — TAF TSI Data and Message Model”.
4.2.11.2. Inne bazy danych
Aby umożliwić śledzenie ruchu pociągów i wagonów, podane poniżej bazy danych muszą być zainstalowane i aktualizowane w czasie rzeczywistym przy każdym stosownym zdarzeniu. Upoważnione podmioty, takie jak posiadacze i zarządcy floty pojazdów muszą mieć dostęp do danych istotnych dla pełnienia przez nich ich funkcji zgodnie z warunkami umów.
Operacyjna baza danych wagonów i jednostek intermodalnych,
Plan podróży wagonu/jednostki intermodalnej.
Te bazy danych muszą być dostępne za pośrednictwem wspólnego interfejsu (rozdziały: 4.2.12.1 „Ogólna architektura” oraz 4.2.12.6 „Wspólny interfejs”).
Operacyjna baza danych wagonów i jednostek intermodalnych
Komunikacja pomiędzy LRU a RU w trybie współpracy opiera się na numerach wagonów lub jednostek intermodalnych. Dlatego RU, który komunikuje się z IM w odniesieniu do pociągu, musi rozbić podawane informacje na informacje dotyczące wagonów i jednostek intermodalnych. Informacje dotyczące wagonów i jednostek intermodalnych muszą być przechowywane w operacyjnej bazie danych wagonów i jednostek intermodalnych. Napływające informacje o ruchu pociągu powodują konieczność nowych wpisów/aktualizacji danych w operacyjnej bazie danych wagonów i jednostek intermodalnych, podawanych do wiadomości klientowi. Część odnosząca się do danych dotyczących ruchu wagonu lub jednostki intermodalnej jest tworzona w bazie danych najpóźniej w momencie otrzymania od klienta czasu zwolnienia wagonu lub jednostki intermodalnej. Czas zwolnienia jest pierwszym wpisem dotyczącym ruchu wagonu dokonywanym w operacyjnej bazie danych wagonów i jednostek intermodalnych i związanym z rzeczywistą trasą przejazdu. Komunikaty dotyczące ruchu wagonów zostały określone w rozdziałach 4.2.8 („Ruch wagonów”) oraz 4.2.9 („Raportowanie o wymianie”). Ta baza danych musi być dostępna za pośrednictwem wspólnego interfejsu (rozdziały: 4.2.12.1 „Ogólna architektura” oraz 4.2.12.6 „Wspólny interfejs”).
Operacyjna baza danych wagonów i jednostek intermodalnych jest najważniejszą bazą danych na potrzeby śledzenia ruchu wagonów, a przez to również na potrzeby komunikacji pomiędzy uczestniczącymi RU a LRU. Baza ta zawiera dane odzwierciedlające ruch wagonu lub jednostki intermodalnej począwszy od odjazdu po końcową dostawę na bocznicę klienta, wraz z ETI i rzeczywistymi czasami w różnych miejscach, aż po ETA ostatecznej dostawy. Baza zawiera również informację o określonym statusie taboru kolejowego, na przykład:
Status: załadowywanie taboru kolejowego
Status ten jest wymagany do wymiany informacji pomiędzy RU a IM oraz przekazywania ich do innych przedsiębiorstw kolejowych zaangażowanych w wykonywanie transportu pociągiem.
Status: załadowany wagon w trasie
Status ten jest wymagany do wymiany informacji pomiędzy IM a RU, z innymi zarządcami infrastruktury oraz z innymi przedsiębiorstwami kolejowymi zaangażowanymi w wykonywanie transportu pociągiem.
Status: pusty wagon w trasie
Status ten jest wymagany do wymiany informacji pomiędzy IM a RU, z innymi zarządcami infrastruktury oraz innymi przedsiębiorstwami kolejowymi zaangażowanymi w wykonywanie transportu pociągiem.
Status: rozładowywanie taboru kolejowego
Status ten jest wymagany do wymiany informacji pomiędzy RU w punkcie docelowym a LRU zaangażowanym w dany transport.
Status: pusty wagon pod kontrolą zarządcy floty pojazdów
Status ten jest wymagany do uzyskania informacji o dostępności pojazdu o określonej charakterystyce.
Bazy danych planów podróży wagonów
Pociągi mogą składać się z wagonów transportujących ładunki różnych klientów. Dla każdego wagonu LRU (RU pełniące rolę integratora usług) musi sporządzić, a następnie uaktualniać plan podróży, który odpowiada trasie pociągu na poziomie pociągu. Wprowadzenie nowej trasy pociągu — np. w razie zakłóceń usługi — prowadzi do rewidowania planów podróży wagonów w danym pociągu. Plan podróży zostaje utworzony z chwilą otrzymania listu przewozowego od klienta.
Plany podróży wagonów muszą być przechowywane w bazie danych przez każde LRU. Te bazy danych muszą być dostępne za pośrednictwem wspólnego interfejsu (rozdziały: 4.2.14.1 „Ogólna architektura” oraz 4.2.12.6 „Wspólny interfejs”).
Oprócz obowiązkowych baz danych wymienionych powyżej, każdy IM może mieć zainstalowaną bazę danych pociągów.
Taka należąca do zarządy infrastruktury baza danych pociągów odpowiada części odnoszącej się do ruchu zawartej w operacyjnej bazie danych wagonów i jednostek intermodalnych. Podstawowymi wpisami w tej bazie są dane o pociągu pochodzące z otrzymanego od RU komunikatu o składzie pociągu. Wszelkie zdarzenia dotyczące pociągu prowadzą do aktualizacji danych w tej odnoszącej się pociągów bazie. Alternatywnym miejscem przechowywania takich danych jest baza danych tras (rozdział 4.2.2 „Wniosek o przydzielenie trasy”). Te bazy danych muszą być dostępne za pośrednictwem wspólnego interfejsu (rozdziały: 4.2.12.1 „Ogólna architektura” oraz 4.2.12.6 „Wspólny interfejs”).
4.2.11.3. Dodatkowe wymagania dotyczące baz danych
W poniższych punktach wymieniono dodatkowe wymagania, jakie muszą spełniać poszczególne bazy danych.
Baza danych musi obsługiwać funkcję uwierzytelnienia użytkowników systemów poprzedzającego ewentualne udzielenie im dostępu do danej bazy.
Baza danych musi spełniać wymogi bezpieczeństwa pod względem kontrolowania dostępu do danej bazy danych. Ewentualne szyfrowanie samej zawartości bazy danych nie jest wymagane.
Wybrana baza danych musi być zgodna z zasadą ACID (niepodzielność, spójność, izolacja, trwałość).
Baza danych musi zapewniać dostęp do danych użytkownikom lub systemom, którym udzielone zostało odnośne pozwolenie. Kontrola dostępu powinna być stosowana aż do poziomu pojedynczego atrybutu rekordu danych. Baza danych musi obsługiwać konfigurowalną, opartą na kryterium roli użytkownika kontrolę dostępu w odniesieniu do wprowadzania do bazy, aktualizacji lub usuwania rekordów danych.
Baza danych musi posiadać funkcję rejestrowania wszystkich czynności dokonywanych w tej bazie, tak by możliwe było odtworzenie szczegółów dotyczących przetwarzania danych (kto i kiedy dokonał jakiej zmiany w zawartości).
Strategia blokady
W bazie danych musi być wdrożona strategia blokady, dzięki której możliwy jest dostęp do danych nawet wtedy, gdy inni użytkownicy dokonują w tym samym czasie edycji rekordów.
Równoczesny dostęp
Baza danych musi zapewniać możliwość dostępu do danych kilku użytkownikom i systemom równocześnie.
Baza danych musi wykazywać dostępność na żądanie wynoszącą co najmniej 99,9 %.
Naprawialność bazy danych musi pozwalać na zachowanie wymaganej dostępności.
Bazy danych jako takie nie mają związku z bezpieczeństwem. Dlatego też kwestie bezpieczeństwa nie są w odniesieniu do nich istotne. Nie należy mylić tego z faktem, iż dane — np. niepoprawne lub nieaktualne dane — mogą mieć wpływ na bezpieczeństwo eksploatacji pociągu.
Baza danych musi obsługiwać powszechnie przyjęty język przetwarzania danych, na przykład SQL lub XQL.
Baza danych musi posiadać funkcję, która umożliwia wprowadzenie danych do bazy poprzez import sformatowanych danych zamiast wprowadzania ręcznego.
Baza danych musi posiadać funkcję, która umożliwia eksport zawartości całej bazy danych lub jej części w postaci sformatowanych danych.
W bazie danych istnieć muszą obowiązkowe pola, które muszą zostać wypełnione zanim odnośny rekord zostanie zaakceptowany jako wpis w bazie danych.
Kontrole wiarygodności
Baza danych musi posiadać funkcję konfigurowalnych kontroli wiarygodności przed zaakceptowaniem wprowadzenia, aktualizacji lub usunięcia rekordów danych.
Czasy reakcji bazy danych muszą umożliwiać użytkownikom wprowadzanie, aktualizowanie lub usuwanie rekordów danych bez nadmiernych opóźnień.
Aspekty związane z wydajnością
Referencyjne pliki i bazy danych muszą w odpowiedzi na zapytania dostarczać w sposób ekonomicznie efektywny informacji niezbędnych do umożliwienia efektywnego dokonywania wszystkich stosownych przejazdów pociągów i wagonów, które wchodzą w zakres przepisów niniejszej TSI.
Aspekty związane z pojemnością
Baza danych musi umożliwiać przechowywanie stosownych danych w odniesieniu do wszystkich wagonów towarowych bądź do sieci. Należy zapewnić możliwość rozszerzenia pojemności w prosty sposób (np. przez dodanie pojemności pamięci i zwiększenie ilości komputerów). Rozszerzenie pojemności nie może wymagać wymiany podsystemu.
Baza danych musi umożliwiać zarządzanie danymi historycznymi w sensie udostępniania danych, które zostały już umieszczone w archiwum.
Strategia sporządzania kopii zapasowych
Wdrożona musi być strategia sporządzania kopii zapasowych zapewniająca odtworzenie pełnej zawartości bazy danych za okres do 24 godzin.
Wykorzystany w bazie danych system musi być dostępny w handlu jako produkt gotowy (produkt COTS — dostępny od ręki) lub być dostępny w domenie publicznej (oprogramowanie otwarte).
Powyższe wymagania muszą być spełnione w ramach standardowego Systemu Zarządzania Bazami Danych (DBMS).
Używanie różnorodnych baz danych jest integralną częścią poszczególnych opisanych powyżej procesów. Zasadniczym procesem jest mechanizm zapytanie/odpowiedź, w którym zainteresowana strona wystosowuje zapytanie o informacje z bazy danych wykorzystując wspólny interfejs (rozdziały: 4.2.12.1 „Ogólna architektura” oraz 4.2.12.6 „Wspólny interfejs”). DBMS odpowiada na to zapytanie poprzez dostarczenie żądanych danych lub poprzez udzielenie odpowiedzi, że dane nie mogą zostać udostępnione (dane takie nie istnieją lub zgodnie z ustawieniami kontroli dostępu odmawia się dostępu do nich).
4.2.12. Łączność sieciowa i komunikacja
4.2.12.1. Architektura ogólna
W ramach omawianego podsystemu rozwinie się z czasem duża i złożona społeczność użytkowników aplikacji telematycznych w sektorze interoperacyjności kolei, w której będzie miała miejsce interakcja pomiędzy setkami uczestniczących podmiotów (RU, IM itd.), które będą konkurować lub współpracować przy zaspokajaniu potrzeb rynku.
Infrastruktura sieci i komunikacji, wspierająca taką społeczność w sektorze interoperacyjności kolei, oparta będzie na wspólnej architekturze wymiany informacji, znanej wszystkim uczestniczącym podmiotom i przez nie przyjętej.
Proponowana architektura wymiany informacji:
ma minimalny wpływ na istniejące architektury informatyczne wdrożone przez każdy z podmiotów,
chroni dokonane już inwestycje informatyczne.
Architektura wymiany informacji sprzyja interakcji, zazwyczaj typu peer-to-peer („równy z równym”), między wszystkimi podmiotami, gwarantując przy tym integralność i spójność ogółu społeczności w sektorze interoperacyjności kolei poprzez dostarczanie zestawu scentralizowanych usług.
Model interakcji peer-to-peer umożliwia najlepszy podział kosztów między różne podmioty w oparciu o faktyczne użytkowanie i na ogół stwarza mniej problemów związanych ze skalowalnością. Prezentację graficzną architektury ogólnej zawarto w wymienionym w dodatku I dokumencie „TAF TSI — Annex A.5:Figures and Sequence Diagrams of the TAF TSI messages”, w rozdziale 1.5.
4.2.12.2. Sieć
Łączność sieciowa w tym przypadku oznacza metodę i filozofię komunikacji, a nie fizyczną sieć połączeń.
Interoperacyjność kolei oparta jest na wspólnej architekturze wymiany informacji, znanej wszystkim uczestnikom i przez nich przyjętej, co stanowi zachętę dla nowych podmiotów na rynku, zwłaszcza klientów, i zmniejsza stojące przed nimi przeszkody.
Kwestie bezpieczeństwa będą zatem rozwiązywane nie w ramach samej sieci (VPN, tunelowanie itd.), lecz poprzez wymienianie bezpiecznych komunikatów i zarządzanie nimi. Sieć VPN nie jest więc wymagana (administrowanie dużą siecią VPN jest zadaniem złożonym i kosztownym), co pozwala uniknąć problemów związanych z przydzielaniem odpowiedzialności i własności. Tunelowanie nie jest uważane za niezbędny środek do osiągnięcia odpowiedniego poziomu bezpieczeństwa.
Jeżeli jednak niektóre podmioty muszą lub chcą wprowadzić różnorodne stopnie zabezpieczenia na wybranych partycjach sieci, to mogą to zrobić.
W ramach ogólnodostępnej sieci internetowej możliwe jest wdrożenie hybrydowego modelu peer-to-peer ze wspólnym interfejsem w węźle każdego uczestnika i centralnym centrum certyfikacji.
Następnie realizowana jest komunikacja peer-to-peer pomiędzy uczestniczącymi podmiotami.
Komunikacja typu „peer-to-peer” oparta jest na normach technicznych dotyczących wspólnego interfejsu opisanych w zawartym w dodatku I dokumencie „TAF TSI — Annex D.2: Appendix F — TAF TSI Data and Message Model”.
4.2.12.3. Bezpieczeństwo
Aby osiągnąć wysoki poziom bezpieczeństwa, wszystkie komunikaty muszą być autonomiczne, co oznacza, że informacje zawarte w komunikatach są zabezpieczone i odbiorca może zweryfikować autentyczność komunikatu. Można to zapewnić przy użyciu systemu szyfrowania i podpisywania podobnego do szyfrowania poczty elektronicznej.
4.2.12.4. Szyfrowanie
Należy stosować szyfrowanie asymetryczne lub rozwiązanie hybrydowe oparte na szyfrowaniu symetrycznym z zabezpieczeniem w formie klucza publicznego, ze względu na fakt, że stosowanie wspólnego tajnego klucza przez różnych uczestników w pewnym momencie zawodzi. Wyższy poziom zabezpieczenia jest łatwiejszy do osiągnięcia, jeśli każdy podmiot bierze na siebie odpowiedzialność za swoją własną parę kluczy, mimo że wymagany jest wysoki poziom integralności centralnego repozytorium (serwera kluczy).
4.2.12.5. Centralne repozytorium
metadanych — uporządkowanych danych opisujących zawartość komunikatów,
infrastruktury klucza publicznego (ang. Public Key Infrastructure, PKI),
centrum certyfikacji (ang. Certification Authority, CA).
Zarządzanie centralnym repozytorium powinno zostać powierzone niekomercyjnej organizacji ogólnoeuropejskiej. W przypadku gdy plik referencyjny jest użytkowany wspólnie z TSI TAP [2], rozwijanie jego zawartości i wprowadzane w nim zmiany muszą być zgodne z TSI TAP [2] w celu osiągnięcia jak najwyższego stopnia synergii.
4.2.12.6. Wspólny interfejs
Wspólny interfejs jest obowiązkowy dla każdego podmiotu, aby mógł on przystąpić do społeczności interoperacyjności kolei.
kontrole zgodności przychodzących komunikatów przeprowadzane na podstawie metadanych,
jednorodny wspólny sposób dostępu do różnych baz danych.
Każda instalacja wspólnego interfejsu u każdego posiadacza wagonów, LRU, RU, IM itp. będzie zapewniać dostęp do wszystkich danych wymaganych zgodnie z TSI, bez względu na to, czy odnośne bazy danych są centralne czy indywidualne (zob. również wymieniony w dodatku I dokument „TAF TSI — Annex A.5: Figures and Sequence Diagrams of the TAF TSI messages” rozdział 1.6).
W przypadku gdy wspólny interfejs użytkowany jest wspólnie z TSI TAP [2], rozwijanie zawartości i wprowadzane zmiany muszą być zgodne z TSI TAP [2] w celu osiągnięcia jak najwyższego stopnia synergii. Na podstawie wyników weryfikacji autentyczności komunikatów przychodzących można wdrożyć minimalny poziom potwierdzenia komunikatu:
pozytywny, wyślij ACK;
negatywny, wyślij NACK.
Do zarządzania powyższymi zadaniami wspólny interfejs wykorzystuje informacje zawarte w centralnym repozytorium.
Podmiot może sporządzić lokalną kopię „lustrzaną” centralnego repozytorium, aby skrócić czas reakcji.
4.3. Funkcjonalne i techniczne specyfikacje dotyczące interfejsów
W świetle wymagań zasadniczych przedstawionych w rozdziale 3 funkcjonalne i techniczne specyfikacje dotyczące interfejsów są następujące:
Podsystem „Infrastruktura” obejmuje systemy zarządzania ruchem, śledzenia i nawigacji: techniczne instalacje do przetwarzania danych i telekomunikacji przeznaczone na potrzeby dalekobieżnych przewozów pasażerskich oraz przewozów towarowych w sieci w celu zagwarantowania bezpiecznej i harmonijnej eksploatacji sieci oraz sprawnego zarządzania ruchem.
Podsystem „Aplikacje telematyczne dla przewozów towarowych” wykorzystuje podane w umowie o trasę dane konieczne do celów operacyjnych, w miarę możliwości uzupełnione danymi dotyczącymi ograniczeń w infrastrukturze, dostarczonymi przez IM. Zatem nie istnieje bezpośredni interfejs pomiędzy niniejszą TSI a TSI dotyczącą infrastruktury.
4.3.2. Interfejsy z TSI „Sterowanie ruchem kolejowym”
Jedyne połączenie ze sterowaniem ruchem kolejowym stanowią:
umowa o trasę, w której w ramach opisu odcinka trasy podane są stosowne informacje o dostępnych urządzeniach do sterowania ruchem kolejowym, oraz
różnorodne referencyjne bazy danych taboru kolejowego, w których muszą być przechowane dane urządzeń taboru kolejowego do sterowania ruchem kolejowym.
4.3.3. Interfejsy z podsystemem „Tabor kolejowy”
Podsystem „Aplikacje telematyczne dla przewozów towarowych” określa techniczne i operacyjne dane, które muszą być dostępne w odniesieniu do taboru kolejowego.
W TSI „Tabor kolejowy” określono charakterystykę wagonu. Jeżeli charakterystyka wagonu zmieni się, odpowiednie dane muszą zostać zaktualizowane w referencyjnych bazach danych taboru kolejowego w ramach normalnego procesu utrzymania bazy danych. Zatem nie istnieje bezpośredni interfejs pomiędzy niniejszą TSI a TSI dotyczącą taboru kolejowego.
4.3.4. Interfejsy z TSI „Ruch kolejowy”
Podsystem „Ruch kolejowy” określa procedury i związane z nimi urządzenia umożliwiające spójną obsługę różnych podsystemów strukturalnych, zarówno w normalnych, jak i pogorszonych warunkach eksploatacji, w tym w szczególności prowadzenie pociągu oraz planowanie i zarządzanie ruchem.
Podsystem „Aplikacje telematyczne dla przewozów towarowych” określa głównie aplikacje na potrzeby usług przewozu towarowego, służące między innymi monitorowaniu w czasie rzeczywistym transportu i pociągów oraz zarządzaniu połączeniami z innymi rodzajami transportu.
W celu zapewnienia spójności pomiędzy obydwiema TSI obowiązuje podana poniżej procedura.
W przypadku uzupełniania TSI „Ruch kolejowy” o wymagania związane z wymaganiami zawartymi w niniejszej TSI lub wprowadzania w nich zmian należy skonsultować się z organem odpowiedzialnym za niniejszą TSI.
W przypadku wprowadzania zmian w specyfikacjach niniejszej TSI związanych z wymaganiami operacyjnymi określonymi w TSI „Ruch kolejowy” należy skonsultować się z organem odpowiedzialnym za TSI „Ruch kolejowy”.
4.3.5. Interfejsy z podsystemem „Aplikacje telematyczne dla przewozów pasażerskich”
Referencyjna TSI dotycząca aplikacji telematycznych dla przewozów towarowych
Referencyjna TSI dotycząca aplikacji telematyczne dla przewozów pasażerskich
Komunikat „Prognoza jazdy pociągu” w odniesieniu do wszystkich pociągów
Informacja o jeździe pociągu
Komunikat „Informacje o jeździe pociągu” w odniesieniu do wszystkich pociągów
Wstrzymana jazda pociągu (komunikat do RU)
Wniosek o przydzielenie trasy
Wspólny interfejs w odniesieniu do komunikacji RU/IM
W świetle wymagań zasadniczych przedstawionych w rozdziale 3 zasady eksploatacji odnoszące się do podsystemu, którego dotyczy niniejsza TSI, są następujące:
Do celów zapewnienia jakości danych nadawca każdego komunikatu TSI odpowiada za poprawność danych zawartych w komunikacie w momencie jego wysyłania. Jeśli dane źródłowe do celów zapewnienia jakości danych są dostępne w bazach danych wskazanych w niniejszej TSI, dane zawarte w tych bazach danych muszą zostać wykorzystane do zapewnienia jakości danych.
Jeśli dane źródłowe do celów zapewnienia jakości danych nie są dostępne w bazach danych wskazanych w niniejszej TSI, nadawca komunikatu musi we własnym zakresie dokonać weryfikacji w celu zapewnienia jakości danych.
Zapewnienie jakości danych obejmuje porównanie danych z baz danych wskazanych w niniejszej TSI, jak opisano powyżej, a ponadto, w stosownych przypadkach, weryfikację logiczną w celu zapewnienia terminowości i ciągłości danych i komunikatów.
Dane odznaczają się wysoką jakością, jeżeli są odpowiednie do ich przewidzianych zastosowań, to znaczy:
są wolne od błędów: dostępne, ścisłe, terminowe, kompletne, zgodne z innymi źródłami itp. oraz
posiadają pożądane cechy: są istotne, wyczerpujące, o odpowiednim poziomie szczegółowości, łatwe do odczytania, łatwe do interpretacji itp.
Jakość danych charakteryzuje przede wszystkim ich:
Ścisłość:
Wymagane informacje (dane) należy pozyskiwać w sposób możliwie jak najbardziej ekonomiczny. Jest to wykonalne tylko wówczas, gdy zapisywane są jedynie dane pierwotne, w miarę możliwości tylko jednokrotnie w odniesieniu do całego transportu. Z tego względu dane pierwotne powinny być wprowadzane do systemu możliwie jak najbliżej ich źródła, tak by mogły zostać w pełni zintegrowane z każdą późniejszą operacją przetwarzania.
Przed wysłaniem komunikatów należy przy użyciu metadanych sprawdzić kompletność i składnię. Pozwala to również uniknąć niepotrzebnego ruchu informacji w sieci.
Sposób wdrażania tych reguł biznesowych zależy od złożoności danej reguły. W przypadku prostych reguł wystarczają ograniczenia i wyzwalacze w bazach danych. W przypadku bardziej złożonych reguł, które wymagają danych z różnych tabel, należy wdrożyć procedury walidacji służące sprawdzeniu spójności wersji danych, zanim zostaną wygenerowane dane na potrzeby interfejsu i nowa wersja danych zostanie udostępniona. Należy zagwarantować, że przesyłane dane są poddawane walidacji w oparciu o zdefiniowane reguły biznesowe.
Istotne jest, aby informacje były udzielane we właściwym czasie. Jeśli uruchomienie rejestracji danych lub wysłanie komunikatu następuje w wyniku zdarzenia bezpośrednio w systemie informatycznym, terminowość nie stanowi problemu, pod warunkiem że system jest zaprojektowany w sposób prawidłowy i zgodnie z potrzebami procesów biznesowych. Jednak w większości przypadków wysłanie komunikatu inicjowane jest przez operatora lub przynajmniej wymaga wykonania przez niego dodatkowej czynności (na przykład wysłanie danych o składzie pociągu lub aktualizacja danych dotyczących pociągu lub wagonu). Aby spełnić wymagania dotyczące terminowości należy możliwie jak najwcześniej dokonywać aktualizacji danych — także w celu zagwarantowania, by dane zawarte w komunikatach były zawsze aktualne w momencie, gdy są rozsyłane automatycznie przez system.
W odniesieniu do kompletności (odsetek pól danych do których wpisano wartości) danych obowiązkowych oraz spójności danych (odsetek odpowiadających sobie wartości w obrębie tabel/plików/rekordów) należy osiągnąć poziom 100 %.
W odniesieniu do terminowości danych (odsetek danych dostępnych w określonych progowych ramach czasowych) należy osiągnąć poziom 98 %. W przypadku gdy wartości progowe nie zostały określone w niniejszej TSI, wartości te muszą zostać określone w umowach pomiędzy uczestniczącymi podmiotami.
Wymagana ścisłość (odsetek zachowanych w bazie wartości, które są zgodne z wartościami faktycznymi) musi osiągnąć poziom ponad 90 %. Dokładne wartości i kryteria należy określić w umowach pomiędzy uczestniczącymi podmiotami.
4.4.2. Obsługa centralnego repozytorium
Funkcje centralnego repozytorium zostały określone w rozdziale 4.2.12.5 („Centralne repozytorium”). Na potrzeby zapewnienia jakości danych podmiot obsługujący centralne repozytorium jest odpowiedzialny za aktualizację oraz jakość metadanych i katalogu, a także za administrowanie kontrolą dostępu. Jakość metadanych pod względem kompletności, spójności, terminowości i ścisłości powinna umożliwić odpowiednie funkcjonowanie do celów niniejszej TSI.
W świetle wymagań zasadniczych przedstawionych w rozdziale 3 zasady utrzymania odnoszące się do podsystemu, którego dotyczy niniejsza TSI, są następujące:
Jakość usługi transportowej musi być zagwarantowana, nawet gdyby sprzęt do przetwarzania danych uległ całkowitej lub częściowej awarii. W związku z tym zalecane jest zainstalowanie systemów dupleksowych lub komputerów o szczególnie wysokim stopniu niezawodności, w przypadku których zapewnione jest ich nieprzerwane działanie podczas utrzymania.
Aspekty utrzymania dotyczące poszczególnych baz danych wymienione zostały w rozdziale 4.2.11.3 („Dodatkowe wymagania dotyczące baz danych”) w pkt 10 i 21.
Kwalifikacje zawodowe personelu wymagane do eksploatacji i utrzymania podsystemu i do wdrożenia TSI są następujące:
Wdrożenie niniejszej TSI nie wymaga ani zupełnie nowego systemu w zakresie sprzętu i oprogramowania, ani nowego personelu. Działania mające na celu spełnienie wymagań określonych w TSI związane są jedynie z wprowadzaniem zmian, unowocześnień lub rozszerzeń funkcjonalnych w eksploatacji, dokonywanym — tak jak dotychczas — przez istniejący personel. W związku z tym nie określono dodatkowych wymagań do istniejących krajowych lub europejskich przepisów dotyczących kwalifikacji zawodowych.
Gdyby wystąpiła konieczność przeprowadzenia dodatkowych szkoleń dla personelu, nie powinny one polegać jedynie na zademonstrowaniu, jak należy obsługiwać sprzęt. Członek personelu musi znać i rozumieć swoją konkretną rolę, jaką ma do odegrania w całym procesie transportu. Personel musi w szczególności być świadomy wymogu utrzymania wysokiej jakości wykonywanej przez niego pracy, gdyż jest to czynnikiem decydującym o rzetelności informacji, które będą przetwarzane na kolejnym etapie.
Kwalifikacje zawodowe potrzebne do zestawiania i eksploatacji pociągów zostały określone w TSI „Ruch kolejowy”.
Warunki BHP personelu wymagane w odniesieniu do obsługi i utrzymania przedmiotowego podsystemu (lub zakresu technicznego określonego w ust. 1.1) oraz do wdrożenia niniejszej TSI są następujące:
Nie określono dodatkowych wymagań do istniejących krajowych i europejskich przepisów w zakresie BHP.
Zgodnie z art. 2 lit. f) dyrektywy 2008/57/WE [1]:
„»składniki interoperacyjności« oznaczają wszelkie elementarne składniki, grupy części składowych, podzespoły lub pełne zespoły sprzętowe, włączone lub mające być włączone do podsystemu, od których bezpośrednio lub pośrednio zależy system kolei. Pojęcie »składnik« obejmuje zarówno przedmioty materialne, jak i niematerialne, takie jak oprogramowanie”.
Składniki interoperacyjności są objęte stosownymi przepisami dyrektywy 2008/57/WE [1].
W odniesieniu do podsystemu „Aplikacje telematyczne dla przewozów towarowych” składniki interoperacyjności nie zostały określone.
Do spełnienia wymagań określonych w niniejszej TSI potrzebny jest jedynie standardowy sprzęt informatyczny, wobec którego nie stawia się żadnych szczególnych wymogów związanych z interoperacyjnością w środowisku kolejowym. Dotyczy to zarówno części składowych sprzętu, jak i stosowanego standardowego oprogramowania, takiego jak system operacyjny i bazy danych. Oprogramowanie użytkowe stanowi indywidualny wybór każdego użytkownika i może być dostosowywane i udoskonalane stosownie do jego faktycznych funkcji i potrzeb. Proponowana „architektura integracji aplikacji” zakłada, że aplikacje mogą nie być oparte na tym samym wewnętrznym modelu informacyjnym. Integrację aplikacji zdefiniowano jako proces umożliwiający współpracowanie ze sobą niezależnie zaprojektowanych systemów aplikacji.
5.3. Charakterystyki wydajnościowe i specyfikacje dotyczące składników
Zob. rozdział 5.2, nie dotyczy TSI „Aplikacje telematyczne dla przewozów towarowych”.
Procedura oceny zgodności składników interoperacyjności lub ich przydatności do stosowania musi być przeprowadzana w oparciu o europejskie specyfikacje lub specyfikacje zatwierdzone zgodnie z dyrektywą 2008/57/WE [1].
W przypadku przydatności do stosowania w odnośnych specyfikacjach określa się wszystkie parametry, które mają być mierzone, monitorowane lub obserwowane, i opisuje związane z nimi metody badań i procedury pomiarów przewidziane do stosowania w symulacji laboratoryjnej bądź w próbach w rzeczywistym środowisku kolejowym.
Procedury oceny zgodności lub przydatności do stosowania:
Wykaz specyfikacji, opis metod badawczych:
Nie dotyczy TSI „Aplikacje telematyczne dla przewozów towarowych”.
Na wniosek producenta lub jego przedstawiciela mającego siedzibę we Wspólnocie jednostka notyfikowana przeprowadza procedurę zgodnie z przepisami decyzji Komisji 2010/713/UE dotyczącymi stosownych modułów przedstawionymi, poprawionymi i uzupełnionymi w dodatku do niniejszej TSI.
Moduły należy łączyć i używać wybiórczo stosownie do konkretnego składnika.
6.1.3. Podsystem „Aplikacje telematyczne dla przewozów towarowych”
Na wniosek organu przyznającego lub jego przedstawiciela mającego siedzibę we Wspólnocie jednostka notyfikowana przeprowadza procedurę weryfikacji WE zgodnie z załącznikiem VI do dyrektywy 2008/57/WE [1].
Zgodnie z załącznikiem II do dyrektywy 2008/57/WE [1] podsystemy można podzielić na podsystemy strukturalne i eksploatacyjne (funkcjonalne).
Ocena zgodności jest obowiązkowa w przypadku TSI dotyczącej podsystemu strukturalnego. Podsystem „Aplikacje telematyczne dla przewozów towarowych” stanowi podsystem funkcjonalny, w związku z tym w niniejszej TSI nie określono żadnych modułów służących ocenie zgodności.
Niemniej jednak centralne repozytorium i wspólny interfejs w węźle każdego uczestnika stanowią podstawę integracji aplikacji. Model wymiany informacji jest przechowywany w scentralizowanym repozytorium integracji aplikacji, w którym metadane na potrzeby interfejsu są przechowywane w jednym fizycznym miejscu. Te metadane zawierają informacje o treści komunikacji (co znajduje się w przesyłanych danych), dane identyfikacyjne punktów kontaktowych nadawców i odbiorców oraz protokoły biznesowe mechanizmu interakcji na poziomie aplikacji.
Należy podkreślić następujące kwestie:
Centralne repozytorium zawiera również centrum certyfikacji (otwarte CA PKI). Jest to zasadniczo akt administracyjny, który został wdrożony fizycznie. Nieprawidłowe wpisy wykrywane są natychmiast. Procedura oceny jest zbędna.
Centralne repozytorium zawiera metadane komunikatów (zgodnie z dokumentem „TAF TSI — Annex D.2: Appendix F — TAF TSI Data and Message Model”, wymienionym w dodatku I) stanowiące podstawę do wymiany komunikatów w heterogenicznym środowisku informatycznym. Metadane muszą być administrowane i aktualizowane w centralnym repozytorium. Wszelka niezgodność w strukturze lub treści komunikatu przy wysyłaniu i odbieraniu danych zostanie natychmiast rozpoznana i nastąpi odmowa przekazu. Procedura oceny jest zbędna.
Wspólny interfejs w węźle każdego uczestnika zawiera przede wszystkim lokalną kopię „lustrzaną” centralnego repozytorium, sporządzoną w celu skrócenia czasu reakcji i zmniejszenia obciążenia repozytorium. Należy zapewnić, by centralne repozytorium i wspólny interfejs zawierały zawsze tę samą wersję danych. Z tego względu aktualizacji danych należy dokonywać na poziomie centralnym i z niego też muszą być pobierane nowe wersje. Procedura oceny jest zbędna.
7.1. Tryb stosowania niniejszej TSI
Niniejsza TSI dotyczy podsystemu „Aplikacje telematyczne dla przewozów towarowych”. Zgodnie z załącznikiem II do dyrektywy 2008/57/WE [1] jest to podsystem eksploatacyjny (funkcjonalny). Dlatego stosowanie niniejszej TSI nie opiera się na koncepcji nowego, odnowionego czy zmodernizowanego podsystemu, jak dzieje się zazwyczaj w przypadku TSI dotyczących podsystemów strukturalnych, z wyjątkiem przypadków określonych w TSI.
TSI wdrażana jest etapowo:
etap pierwszy: szczegółowe specyfikacje informatyczne i plan generalny,
etap drugi: opracowanie,
etap trzeci: wdrożenie.
7.1.2. Etap pierwszy — szczegółowe specyfikacje informatyczne i plan generalny
Specyfikacje zawierające wymagania funkcjonalne, które należy wykorzystać jako podstawę wspomnianej powyżej architektury technicznej na etapie opracowywania i wdrażania systemu skomputeryzowanego, zawarto w dodatkach A–F wymienionych w dodatku I do niniejszego rozporządzenia.
Obowiązkowy plan generalny, który obejmuje wszystkie etapy od koncepcji po gotowy system skomputeryzowany i jest oparty na strategicznym europejskim planie wdrożeniowym (SEDP) przygotowanym przez sektor kolei, zawiera kluczowe elementy architektury systemu oraz wskazanie najważniejszych działań do wykonania.
7.1.3. Etap 2 i 3 — opracowanie i wdrożenie
Przedsiębiorstwa kolejowe, zarządcy infrastruktury i posiadacze wagonów opracowują i wdrażają skomputeryzowany system TAF zgodnie z przepisami niniejszego rozdziału.
Etap opracowywania i etap wdrożenia podlegają strukturze zarządzania obejmującej wymienione poniżej podmioty.
Komitet sterujący ma następujące zadania i obowiązki:
Komitet sterujący zapewnia strukturę zarządzania strategicznego w celu skutecznego zarządzania pracami zmierzającymi do wdrożenia TSI TAF oraz koordynacji takich prac. Obejmuje to ustalanie polityki, kierunku strategicznego i priorytetów. W ramach tych zadań komitet sterujący uwzględnia również interesy małych przedsiębiorstw, nowych podmiotów i przedsiębiorstw kolejowych wykonujących usługi specjalne.
Komitet sterujący monitoruje postępy wdrażania. Co najmniej cztery razy do roku przedkłada Komisji Europejskiej regularne sprawozdania na temat osiągniętych postępów w porównaniu z planem generalnym. Komitet sterujący podejmuje niezbędne działania w celu dostosowania przebiegu prac w przypadku odstępstw od planu generalnego.
organy przedstawicielskie sektora kolejowego działające na szczeblu europejskim, określone w art. 3 ust. 2 rozporządzenia (WE) nr 881/2004 („organy przedstawicielskie sektora kolei”),
Komitetowi sterującemu przewodniczą wspólnie: a) Komisja; oraz b) osoba wyznaczona przez organy przedstawicielskie sektora kolei. Komisja, przy wsparciu członków komitetu sterującego, opracowuje regulamin wewnętrzny przedmiotowego komitetu sterującego, na który komitet sterujący musi wyrazić zgodę.
zapewniają działania i zasoby niezbędne do wdrożenia niniejszego rozporządzenia,
zapewniają, aby wszyscy uczestnicy rynku mieli dostęp do wszystkich wymienianych danych niezbędnych do spełnienia ich obowiązków prawnych oraz do wykonywania ich funkcji zgodnie z wymaganiami funkcjonalnymi TSI TAF,
ustanawiają mechanizm umożliwiający „spóźnionym” podmiotom dołączenie do opracowywania TAF i skorzystanie z dotychczasowych osiągnięć TAF w zakresie elementów wspólnych w sposób zadowalający zarówno dla wspomnianych zainteresowanych podmiotów, jak i dla nowych podmiotów, w szczególności pod względem sprawiedliwego podziału kosztów,
składają komitetowi sterującemu TAF sprawozdania dotyczące postępów w zakresie realizacji planów wdrażania. W sprawozdaniach tych uwzględnia się, w stosownych przypadkach, informacje o odstępstwach od planu generalnego.
Organy przedstawicielskie sektora kolei działające na szczeblu europejskim, określone w art. 3 ust. 2 rozporządzenia (WE) nr 881/2004 Parlamentu Europejskiego i Rady (1), mają następujące zadania i obowiązki:
reprezentują poszczególne zainteresowane podmioty członkowskie w komitecie sterującym TSI TAF,
zapewniają wszystkim wspomnianym zainteresowanym podmiotom terminowy, bieżący i pełny dostęp do informacji na temat stanu prac komitetu sterującego i wszelkich innych grup w celu zabezpieczenia interesów każdego przedstawiciela w ramach wdrażania TSI TAF,
zapewniają skuteczny przepływ informacji od komitetu sterującego TAF do poszczególnych zainteresowanych podmiotów członkowskich, tak aby zainteresowane podmioty były odpowiednio informowane o decyzjach mających wpływ na opracowywanie i wdrażanie TAF.
Należy opracować procedury zarządzania zmianami w celu zapewnienia, by koszty i korzyści każdej zmiany zostały odpowiednio przeanalizowane, a zmiany były wprowadzane w kontrolowany sposób. Procedury te są określane, wdrażane, wspierane i zarządzane przez Europejską Agencję Kolejową i obejmują:
procedurę walidacji zmian, które mają być wdrażane,
politykę zarządzania, zwolnienia, migracji i wprowadzenia zmiany,
W skład komisji kontroli zmian (ang. Change Control Board, CCB) wchodzą Europejska Agencja Kolejowa, organy przedstawicielskie sektora kolei i krajowe organy ds. bezpieczeństwa. Taki skład zapewni odpowiednie podejście do zmian, które mają być wprowadzone, oraz wszechstronną ocenę ich konsekwencji. Komisja może dokooptować kolejne strony do CCB, jeżeli uzna ich uczestnictwo za konieczne. CCB przejdzie ostatecznie pod egidę Europejskiej Agencji Kolejowej.
7.2.2. Szczególny proces zarządzania zmianami dotyczący dokumentów wymienionych w dodatku I do niniejszego rozporządzenia
Europejska Agencja Kolejowa ustanawia zarządzanie zmianami w odniesieniu do dokumentów wymienionych w dodatku I do niniejszego rozporządzenia zgodnie z następującymi kryteriami:
Wnioski o wprowadzenie zmian mających wpływ na dokumenty są składane za pośrednictwem krajowych organów ds. bezpieczeństwa, organów przedstawicielskich sektora kolei działających na szczeblu europejskim, określonych w art. 3 ust. 2 rozporządzenia (WE) nr 881/2004, lub za pośrednictwem komitetu sterującego TSI TAF. Komisja może dodać kolejne strony uprawnione do składania wniosków, jeżeli uzna ich wkład za konieczny.
Europejska Agencja Kolejowa przedkłada Komisji zalecenie dotyczące aktualizacji dokumentów wymienionych w dodatku I, wraz z projektem nowej wersji dokumentów, wnioskami o wprowadzenie zmian i ich oceną ekonomiczną.
Po opublikowaniu aktualizacji dokumentów wymienionych w dodatku I w Dzienniku Urzędowym Unii Europejskiej Europejska Agencja Kolejowa udostępnia nową wersję dokumentów na swojej stronie internetowej.
W przypadkach gdy zarządzanie zmianami ma wpływ na elementy pozostające we wspólnym użytkowaniu w ramach TSI TAP [2], zmian dokonuje się w taki sposób, aby pozostać jak najbliżej już wdrożonej TSI TAP [2], w celu osiągnięcia jak największego stopnia synergii.
(1) Rozporządzenie (WE) nr 881/2004 Parlamentu Europejskiego i Rady z dnia 29 kwietnia 2004 r. ustanawiające Europejską Agencję Kolejową (Rozporządzenie w sprawie Agencji) (Dz.U. L 164 z 30.4.2004, s. 1).
Atomicity (niepodzielność), Consistency (spójność), Isolation (izolacja), Durability (trwałość)
Są to cztery podstawowe atrybuty zapewnione dla każdej transakcji.
Niepodzielność. W transakcji, w której występują dwie lub większa ilość odrębnych informacji, zatwierdzone zostają albo wszystkie informacje, albo żadna z nich nie zostaje zatwierdzona.
Spójność. Wynikiem transakcji jest nowy, poprawny stan danych lub, w razie wystąpienia awarii, następuje przywrócenie wszystkich danych do stanu sprzed rozpoczęcia transakcji.
Izolacja. Transakcja będąca w toku i jeszcze niezatwierdzona musi pozostać odizolowana od każdej innej transakcji.
Trwałość. Zatwierdzone dane zostają zapisane przez system w taki sposób, aby w razie awarii i ponownego uruchomienia systemu były dostępne w swoim prawidłowym stanie.
Koncepcja ACID została opisana w normie ISO/IEC 10026-1:1992, sekcja 4. Każdy z tych atrybutów można porównać ze wzorcem. Zasadniczo jednak do realizacji koncepcji ACID wyznaczony jest zarządca transakcji lub monitor transakcji. W systemie rozproszonym jednym ze sposobów na osiągnięcie ACID jest wykorzystanie zatwierdzania dwufazowego (2PC), które zapewnia, że do zakończenia transakcji muszą zobowiązać się wszystkie uczestniczące lokalizacje lub że nie zobowiązuje się żadna z nich, a wówczas transakcja zostaje wycofana.
Organ alokujący
Zob. IM.
Oznacza przedsiębiorstwo kolejowe lub międzynarodowe ugrupowanie przedsiębiorstw kolejowych lub inne osoby lub podmioty prawne, takie jak właściwe organy w rozumieniu rozporządzenia (WE) nr 1370/2007 oraz spedytorzy, nadawcy towarów i operatorzy transportu kombinowanego, którzy ze względu na świadczenie usługi publicznej lub ze względów handlowych są zainteresowani uzyskaniem zdolności przepustowej infrastruktury (dyrektywa 2012/34/UE [3]). Organ alokujący: zob. definicja IM.
Pociąg odcinkowy bezpośredni
Szczególna postać pociągu bezpośredniego zawierającego tylko tyle wagonów, ile jest potrzebne, kursującego pomiędzy dwoma punktami przeładunku bez pośredniego zestawiania.
Proces dokonywania rezerwacji miejsca w środku transportu w celu przewozu towaru.
Lista 8-cyfrowych kodów produktów, używanych przez urzędy celne.
Transport kombinowany drogowo — kolejowy
Transport intermodalny, w którym większa część europejskiej podróży odbywa się koleją, a jakikolwiek początkowy lub końcowy odcinek pokonywany drogą jest możliwie jak najkrótszy.
Strona, która ma odebrać towar.
Synonim: odbiorca towaru.
Ładunek wysyłany w ramach jednej umowy przewozu. W transporcie kombinowanym termin ten może być stosowany do celów statystycznych, do pomiaru jednostek ładunkowych lub pojazdów drogowych.
Dokument, który jest świadectwem umowy o dokonanie przez przewoźnika transportu jednej przesyłki z podanego miejsca przyjęcia do podanego miejsca dostawy. Zawiera on szczegóły dotyczące przesyłki, która jest przedmiotem transportu.
Strona, która poprzez umowę z integratorem usług nadaje lub wysyła towar przez przewoźnika, lub zleciła mu przewiezienie tego towaru.
Synonimy: wysyłający, nadawca towaru.
Sposób eksploatacji pociągu, w którym różne RU współpracują z sobą pod przewodnictwem jednego RU (LRU). Każde uczestniczące RU zawiera we własnym zakresie umowę o trasę potrzebną do wykonania przejazdu transportowego.
Produkty gotowe ogólnodostępne w handlu.
Jest podmiotem, który wystawia list przewozowy dla wiodącego RU.
Data (i godzina) odjazdu środka transportu.
Pociąg wraz z odnośnymi wagonami jadący pomiędzy dwoma punktami przeładunku (początkowym źródłowym — końcowym przeznaczenia) bez pośredniego zestawiania.
Każda osoba fizyczna lub prawna odpowiedzialna za ryzyko, które wprowadza do sieci, tj. RU.
Kodowanie wiadomości.
Rozszyfrowywanie: przekształcanie zaszyfrowanych danych z powrotem do pierwotnej postaci.
Wymagania zasadnicze oznaczają wszystkie warunki przedstawione w załączniku III do dyrektywy 2001/16/WE Parlamentu Europejskiego i Rady (1), które muszą być spełnione przez transeuropejski system kolei konwencjonalnej, podsystemy, składniki interoperacyjności, w tym interfejsy.
Przewidywany czas przyjazdu.
Przewidywany czas przekazania pociągu przez jednego IM drugiemu IM.
Przewidywany czas wymiany wagonów, dokonywanej przez jedno RU na rzecz innego.
Prognozowany czas
Możliwie najdokładniejsze oszacowanie czasu przyjazdu, odjazdu lub przejazdu pociągu.
Protokół przesyłania plików (ang. File Transfer Protocol).
Protokół służący do przekazywania plików pomiędzy systemami komputerowymi w sieci TCP/IP.
Stacja w granicach trasy przejazdu pociągu z jednostkami intermodalnymi, gdzie ładunek zmienia wagony.
Protokół międzybramowy (ang. Gateway to Gateway Protocol).
Zob. również: IP.
Ciężar ładunku brutto
Zarezerwowany/rzeczywisty całkowity ciężar (masa) towaru wraz z opakowaniem, lecz wyłączając sprzęt przewoźnika.
Stacja, gdzie RU może zmienić skład pociągu, lecz gdzie pozostaje ono odpowiedzialne za wagony, nie następuje zmiana odpowiedzialności.
Punkt, w którym odpowiedzialność przechodzi z jednego IM na drugiego.
Przewóz transportem drogowym
Dowolna osoba fizyczna lub prawna wskazana jako najemca przez posiadacza/właściciela wagonu.
Lista 6-cyfrowych kodów produktów, używanych przez urzędy celne, identycznych z pierwszymi 6 cyframi kodu CN.
Protokół przesyłania hipertekstu (ang. Hypertext Transfer Protocol).
Protokół klient/serwer służący do łączenia się z serwerami w sieci.
Internetowy protokół komunikatów kontrolnych (ang. Internet Control Message Protocol).
W pewnych przypadkach brama (zob. GGP) lub host docelowy (zob. IP) wysyła komunikat do hosta źródłowego, aby na przykład powiadomić o błędach w przetwarzaniu datagramów. Do tego celu służy internetowy protokół komunikatów kontrolnych (ICMP). ICMP wykorzystuje podstawowe funkcje IP, zachowując się jak protokół wysokiego poziomu, jednak w rzeczywistości stanowi integralną część IP i musi być wdrożony w każdym module IP. Komunikaty ICMP wysyłane są w kilku różnych sytuacjach: na przykład wtedy, gdy datagram nie może dotrzeć do adresata, gdy brama nie ma możliwości buforowania datagramu przed jego przekazaniem oraz gdy brama może wydać hostowi polecenie wysłania ruchu krótszą trasą. Protokół IP nie jest zaprojektowany jako bezwzględnie niezawodny. Celem komunikatów kontrolnych jest dostarczenie informacji zwrotnych o problemach w środowisku komunikacyjnym, nie zaś uczynienie IP niezawodnym. Nadal nie ma gwarancji, że datagram zostanie dostarczony lub że komunikaty kontrolne zostaną odesłane. Niektóre datagramy mogą pozostać niedostarczone bez jakiejkolwiek informacji o ich utracie. W protokołach wysokiego poziomu, które wykorzystują IP, muszą być wdrożone ich własne procedury niezawodności, jeśli wymagana jest niezawodna komunikacja. Komunikaty ICMP zwykle powiadamiają o błędach w przetwarzaniu datagramów. Aby uniknąć nieskończonego regresu komunikatów o komunikatach itp., nie są wysyłane komunikaty ICMP o komunikatach ICMP. Ponadto wysyłane są tylko komunikaty ICMP o błędach obsługi fragmentu zerowego fragmentowanych datagramów. (Fragment zerowy posiada przesunięcie równe zeru).
Zarządca infrastruktury: oznacza każdy podmiot lub przedsiębiorstwo, które są odpowiedzialne w szczególności za założenie infrastruktury kolejowej, zarządzanie nią i jej utrzymanie, w tym za prowadzenie ruchu pociągów, urządzenia bezpiecznej kontroli jazdy i urządzenia sterowania ruchem kolejowym; funkcje zarządcy infrastruktury na sieci lub części sieci mogą być przydzielane różnym podmiotom lub przedsiębiorstwom. W przypadku gdy zarządca infrastruktury pod względem prawnym, organizacyjnym lub w zakresie podejmowania decyzji nie jest niezależny od któregokolwiek przedsiębiorstwa kolejowego, funkcje, o których mowa w sekcjach 2 i 3 rozdziału IV, są wykonywane odpowiednio przez organ pobierający opłaty i przez organ alokujący, które są niezależne w swojej formie prawnej, organizacyjnej i w zakresie podejmowania decyzji od któregokolwiek przedsiębiorstwa kolejowego. (Dyrektywa 2012/34/UE [3]).
Zarządca infrastruktury (IM)
Przeniesienie kontroli z jednego przedsiębiorstwa kolejowego na inne z praktycznych względów operacyjnych oraz względów związanych z bezpieczeństwem. Następuje na przykład w przypadku:
usług mieszanych,
usług z dzieloną odpowiedzialnością za przewóz,
przekazywania informacji pomiędzy różnymi zarządami kolejowymi,
przekazywania informacji pomiędzy właścicielami wagonów i przewoźnikami kolejowymi.
Punkt, w którym następuje przeniesienie odpowiedzialności za wagony pociągu z jednego RU na inne RU.
W przypadku jazdy pociągu, pociąg zostaje przejęty od jednego RU przez inne RU, które posiada teraz trasę dla następnego odcinka przejazdu.
Lokalizacja, która określa punkt początkowy lub końcowy odcinka przejazdu. Może to być np. punkt wymiany, przekazania lub obsługi.
Każdy podmiot, który zawiera umowę transportu multimodalnego i przyjmuje na siebie całą odpowiedzialność za transport intermodalnych jednostek ładunkowych.
Integrator usług intermodalnych
Dowolna jednostka lub przedsiębiorstwo, które zawarły umowę z klientami dotyczącą transportu jednostek intermodalnych. Przygotowuje on listy przewozowe, zarządza objętością załadowczą w pociągach odcinkowych bezpośrednich itp.
Lokalizacja, w której zapewniona jest przestrzeń, sprzęt i środowisko robocze, w którym odbywa się przekazywanie jednostek ładunkowych (kontenerów, nadwozi wymiennych i naczep lub przyczep).
Przewóz towaru w jednej i tej samej jednostce ładunkowej lub pojeździe, z wykorzystaniem kolejno kilku rodzajów transportu bez przeładunku samego towaru przy zmianie rodzaju transportu.
Jednostka intermodalna
Jednostka ładunkowa przystosowana do przewozu różnymi rodzajami transportu, np. kontener, nadwozie wymienne, naczepa, przyczepa.
Dowolna duża sieć składająca się z szeregu mniejszych sieci.
Grupa sieci, które są wzajemnie połączone, tak że wydają się jedną dużą, ciągłą siecią i mogą być adresowane w sposób płynny na poziomie warstwy sieciowej modelu OSI przy wykorzystaniu routerów.
Nazwa własna sieci wykorzystywanej jako źródło informacji, do przesyłania poczty elektronicznej, uczestniczenia w czatach internetowych, przeznaczonej dla użytkowników na całym świecie.
Oznacza dowolny podstawowy składnik, grupę składników, podzespół lub zespół urządzeń włączony lub przeznaczony do włączenia do podsystemu, od którego bezpośrednio lub pośrednio zależy interoperacyjność transeuropejskiego systemu kolei konwencjonalnej. Pojęcie „składnik” obejmuje zarówno przedmioty materialne, jak i niematerialne, takie jak oprogramowanie.
Protokół internetowy.
Protokół internetowy służy do obsługi datagramów przesyłanych pomiędzy hostami w systemie wzajemnie połączonych sieci.
Urządzenia łączące sieci zwane są bramami. Bramy te komunikują się ze sobą nawzajem do celów kontrolnych za pośrednictwem protokołu „brama do bramy” (Gateway to Gateway Protocol — GGP).
„Podróż” oznacza przesłanie w przestrzeni załadowanego lub pustego wagonu ze stacji spedycyjnej do stacji docelowej.
Odcinek podróży
Jest to część podróży odbywająca się w jednym sektorze infrastruktury jednego zarządcy infrastruktury; lub
Część podróży od wejściowego punktu przekazania do wyjściowego punktu przekazania w infrastrukturze jednego zarządcy.
Osoba, która będąc właścicielem lub posiadając prawo do dysponowania pojazdem, wykorzystuje ten pojazd gospodarczo i w sposób ciągły jako środek transportu oraz jest zarejestrowana jako posiadacz w Rejestrze Taboru Kolejowego.
Wiodące przedsiębiorstwo kolejowe
Odpowiedzialne RU, które organizuje linię transportową i zarządza nią zgodnie ze zobowiązaniem wobec klienta. LRU stanowi jeden centralny punkt kontaktowy dla klienta. Jeżeli w łańcuchu transportowym uczestniczy więcej niż jedno przedsiębiorstwo kolejowe, to LRU jest także odpowiedzialne za koordynację zaangażowanych przedsiębiorstw kolejowych. Klientem może być, zwłaszcza w przypadku transportu intermodalnego, integrator usług intermodalnych.
Niepowtarzalny numer identyfikacyjny jednostki trakcyjnej.
Zob. Wiodące przedsiębiorstwo kolejowe.
Użycie tego słowa lub przymiotnika „OPCJONALNY” oznacza, że element jest całkowicie nieobowiązkowy. Dany sprzedawca może zdecydować o uwzględnieniu tego elementu, ponieważ potrzebę taką dyktuje dany rynek lub ponieważ sprzedawca uważa, iż element ten zwiększa jakość produktu, podczas gdy inny sprzedawca może ten sam element pominąć.
Wdrożony system, który nie zawiera określonej opcji, MUSI być przygotowany do współdziałania, ewentualnie w ograniczonym zakresie funkcji, z innym wdrożonym systemem, która zawiera tę opcję. Analogicznie wdrożony system, który zawiera określoną opcję,
MUSI być przygotowany do współdziałania (oczywiście w zakresie, z którego wyłączona jest funkcja, którą ta opcja zapewnia) z innym wdrożonym systemem, który tej opcji nie zawiera.
W uproszczeniu są to dane o danych. Opisują one dane, usługi oprogramowania oraz inne składniki zawarte w systemach informacyjnych przedsiębiorstwa. Przykładowe typy metadanych to m.in. definicje danych standardowych, informacje o lokalizacji i routingu oraz zarządzanie synchronizacją w zakresie dystrybucji współdzielonych danych.
Użycie tego słowa lub wyrażeń „WYMAGANY” bądź „NALEŻY” oznacza, że definicja dotyczy bezwzględnego wymogu w specyfikacji.
Zwrot ten lub zwrot „NIE NALEŻY” oznaczają, że definicja dotyczy bezwzględnego zakazu w specyfikacji.
Sieciowy system plików (ang. Network File System) jest protokołem rozproszonego systemu plików.
Protokół NFS zapewnia przejrzysty, zdalny dostęp do rozproszonego systemu plików we wszystkich sieciach. Protokół NFS jest zaprojektowany tak, aby był niezależny od komputera, systemu operacyjnego, architektury sieci, mechanizmu zabezpieczeń oraz protokołu transportu. Niezależność ta osiągana jest dzięki zastosowaniu prymitywów RPC (zdalnego wywołania procedury) i wykorzystywaniu przez nie XDR (zewnętrznej reprezentacji danych).
Jednostki odpowiedzialne za ocenę zgodności składników interoperacyjności lub ich przydatności do stosowania, bądź za ocenę procedur WE dotyczących weryfikacji podsystemów (Dyrektywa 91/440/WE (2)).
Punkt kompleksowej obsługi (ang. One Stop Shop, OSS)
Międzynarodowe partnerstwo zarządców infrastruktury kolejowej udostępniające klientom z sektora kolei pojedynczy punkt kompleksowej obsługi do celów:
monitorowania całego ruchu pociągu,
zazwyczaj także fakturowania należności za dostęp do torów w imieniu IM.
Tryb eksploatacji pociągu, w którym uczestniczy tylko jedno RU, które prowadzi pociąg w ramach różnych infrastruktur. RU to zawiera umowy o potrzebne trasy ze wszystkimi uczestniczącymi IM.
Połączenie systemów otwartych (ang. Open Systems Interconnection)
Opisuje protokół komunikacyjny systemów otwartych w oparciu o model odniesienia OSI. Systemy otwarte są zdolne do komunikowania się niezależnie od rozwiązań dedykowanych.
Standardowy opis sposobu przekazywania komunikatów pomiędzy dowolnymi dwoma punktami sieci. W modelu OSI określonych zostało 7 warstw funkcji, które występują po obu stronach komunikacji. Warstwy te stanowią jedyne uznane na szczeblu międzynarodowym ramy standardów komunikacji.
Punkt kompleksowej obsługi (One Stop Shop).
Trasa oznacza zdolność przepustową infrastruktury niezbędną do wykonania przejazdu pociągiem pomiędzy dwoma miejscami w danym okresie czasu (droga określona w czasie i przestrzeni).
Zespół tras
Połączenie indywidualnych tras pociągów w celu przedłużenia trasy w czasie i przestrzeni.
Numer określonej trasy pociągu.
Termin „peer-to-peer” („równy z równym”) odnosi się do klasy systemów i aplikacji, które wykorzystują zasoby rozproszone do wykonywania krytycznej funkcji w sposób zdecentralizowany. Zasoby te obejmują moc obliczeniową, dane (pamięć i zawartość), szerokość pasma sieci oraz obecność (komputerów, ludzi oraz innych zasobów). Krytyczną funkcją może być przetwarzanie rozproszone, współużytkowanie danych lub zawartości, komunikacja i współpraca oraz usługi platformy. Decentralizacja może odnosić się do algorytmów, danych i metadanych, bądź do wszystkich tych pozycji. Nie wyklucza to zachowania centralizacji w pewnych częściach systemów i aplikacji, jeśli spełnia to ich wymagania.
Infrastruktura klucza publicznego (ang. Public Key Infrastructure).
Miejsce, w którym następuje dostawa (podaje się odjazdową stację kolejową); miejsce w którym następuje przeniesienie odpowiedzialności za wagon.
Miejsce, z którego środek transportu ma według planu odjechać lub odjechał.
Miejsce, do którego środek transportu ma przyjechać lub przyjechał.
Synonim: Miejsce przyjazdu.
Okres przedodjazdowy
Jest to czas delta przed planowanym czasem odjazdu. Okres przedodjazdowy zaczyna się o planowym czasie odjazdu minus czas delta, a kończy się o planowanym czasie odjazdu.
Podstawowe dane stanowiące referencyjne dane wejściowe na potrzeby komunikatów lub podstawę do realizacji funkcji i obliczania danych pochodnych.
Procedura zależna od technicznego zatwierdzenia wagonu oraz umowy z RU o użytkowanie, umożliwiająca komercyjną eksploatację wagonu.
Przedsiębiorstwo kolejowe (RU)
Zob. Niezawodność, dostępność, naprawialność, bezpieczeństwo.
Odwrotny protokół rozróżniania adresów (ang. Reverse Address Resolution Protocol)
Data/czas zwolnienia
Data/godzina, kiedy spodziewane jest zwolnienie towaru lub kiedy towar został zwolniony przez klienta.
Czas zwolnienia wagonów
Data i godzina, kiedy wagony są gotowe do zabrania z podanego miejsca na bocznicy klienta.
Niezawodność, dostępność, naprawialność, bezpieczeństwo (RAMS)
Niezawodność— wyrażona matematycznie zdolność do rozpoczęcia i kontynuowania działania w wyznaczonych warunkach przez wyznaczony okres czasu;
Dostępność— wyrażony matematycznie czas działania w stosunku do czasu wyłączenia z eksploatacji;
Naprawialność— wyrażona matematycznie zdolność systemu do przywrócenia do eksploatacji po awarii;
Bezpieczeństwo— wyrażone matematycznie prawdopodobieństwo zainicjowania przez system niebezpiecznego zdarzenia.
Lokalizacja na trasie przejazdu pociągu, w której odpowiedzialny IM musi przekazać RU, które zawarło z nim umowę o trasę, komunikat „Prognoza jazdy pociągu” wraz z TETA.
Repozytorium jest podobne do bazy danych i słownika danych, obejmuje ono jednak zwykle kompleksowe środowisko systemów zarządzania informacjami. Musi zawierać nie tylko opisy struktur danych (tj. jednostek i elementów), lecz również będące przedmiotem zainteresowania przedsiębiorstwa metadane, ekrany danych, raporty, programy i systemy. Zazwyczaj zawiera wewnętrzny zestaw oprogramowania narzędziowego, system zarządzania bazą danych (DBMS), metamodel, wypełnione metadane oraz oprogramowanie umożliwiające dostęp do danych w repozytorium oraz ich wprowadzanie.
Przepisy dotyczące wzajemnego użytkowania wagonów w ruchu międzynarodowym.
Przepisy dotyczące wzajemnego użytkowania urządzenia załadowczego, kontenera i palet w ruchu międzynarodowym.
Geograficzna droga, która ma być przebyta od punktu początkowego do punktu docelowego.
Część drogi.
Zdalne wywołanie procedur (ang. Remote Procedure Call).
Protokół RPC jest określony w specyfikacji protokołu RPC, wersja 2 [RFC1831].
Planowy czas odjazdu
Data i godzina odjazdu, w odniesieniu do których składany jest wniosek o trasę.
Planowy rozkład jazdy
Chronologicznie określone zajęcie infrastruktury kolejowej dla ruchu pociągu na otwartej linii lub na stacjach. Zmiany rozkładów jazdy IM dostarcza co najmniej 2 dni przed początkiem dnia, w którym pociąg odjeżdża ze swojego punktu początkowego. Taki rozkład jazdy stosuje się do określonego dnia. W niektórych krajach nazywany jest „operacyjnym rozkładem jazdy”.
Przewoźnik odpowiedzialny za określony etap transportu. Strona, która odbiera lub obsługuję rezerwację.
Pakiet towaru przesyłany przez jednego nadawcę jednemu odbiorcy, który jest załadowany na jedną lub więcej kompletnych jednostek ładunkowych bądź na jeden lub więcej kompletnych wagonów.
Indywidualny wniosek o przydzielenie trasy zgodnie z art. 23 dyrektywy 2001/14/WE składany w związku z dodatkowym zapotrzebowaniem na transport lub potrzebami operacyjnymi.
Użycie tego słowa lub przymiotnika „ZALECANY” oznacza, że w określonych okolicznościach zasadne może być pominięcie danego elementu, lecz przed wybraniem innego kierunku działania należy poznać i dokładnie rozważyć wszystkie konsekwencje.
Użycie takiego wyrażenia lub wyrażenia „NIEZALECANE” oznacza, że w określonych okolicznościach mogą istnieć zasadne powody, by uznać dane postępowanie za dopuszczalne lub nawet pożyteczne, jednak przed przyjęciem postępowania określonego przy użyciu takiego wyrażenia należy poznać wszystkie konsekwencje i dokładnie rozważyć przedmiotowy przypadek.
Prosty protokół przesyłania poczty (ang. Simple Mail Transfer Protocol).
Prosty protokół zarządzania siecią (ang. Simple Network Management Protocol).
Strukturalny język zapytań (ang. Structured Query Language).
Stworzony przez IBM, a następnie znormalizowany przez ANSI i ISO język, który służy do tworzenia danych, zarządzania nimi i wyszukiwania ich w relacyjnych bazach danych.
Każda osoba lub organ wykazujące uzasadnione zainteresowanie świadczeniem usług kolejowych, np.:
przedsiębiorstwo kolejowe (RU),
dostawca usług monitorowania przesyłek,
dostawca górek rozrządowych,
dostawca mechanizmów zwrotnicowych,
integrator usług,
dostawca przedziałów czasowych (IM),
dyspozytor (IM),
zarządca ruchu,
dostawca usług transportu promem,
inspektor wagonów i lokomotyw,
dostawca usług naprawczych wagonów i lokomotyw,
zarządca przesyłek,
dostawca usług manewrowych i rozrządowych,
dostawca usług logistycznych,
odbiorca przesyłki,
nadawca przesyłki;
dodatkowo w przypadku jednostek intermodalnych:
dostawca kontenerów,
operator terminalu intermodalnego,
dostawca platform/firma przewozowa,
transport parowcem,
linie transportu barkowego.
Protokół sterowania transmisją (ang. Transmission Control Protocol).
Oznacza specyfikacje dotyczące podsystemu lub jego części, określone w celu spełnienia wymagań zasadniczych oraz zapewnienia interoperacyjności transeuropejskiego systemu kolei konwencjonalnej.
Zob. Przewidywany czas przyjazdy pociągu.
Odtwarzanie przemieszczania
Działanie podjęte na wniosek o znalezienie i zrekonstruowanie historii transportu danej przesyłki, pojazdu, sprzętu, paczki lub ładunku.
Działanie polegające na systematycznym monitorowaniu i rejestrowaniu aktualnej lokalizacji i statusu danej przesyłki, pojazdu, sprzętu, paczki lub ładunku.
Przewidywany czas przyjazdu pociągu
Przewidywany czas przyjazdu pociągu do określonego punktu, np. punktu przekazania, punktu wymiany lub punktu docelowego pociągu.
Droga przejazdu pociągu określona w czasie i przestrzeni.
Trasa pociągu/przedziały czasowe
Określenie drogi przejazdu pociągu za pomocą czasu i lokalizacji (punktów znacznikowych), w których będzie się ona zaczynać i kończyć, wraz ze szczegółowymi danymi o tych lokalizacjach, które pociąg minie lub w których zatrzyma się na swej drodze. Dane te mogą również zawierać wszelkie dotyczące pociągu działania, które zostaną wykonane po drodze, takie jak zmiana drużyny pociągowej, lokomotywy lub inne zmiany składu.
Sieć kolejowa opisana w załączniku 1 do dyrektywy 2001/16/WE (1).
Operacja przeładowywania intermodalnych jednostek ładunkowych z jednego środka transportu na inny.
Przedstawia planowaną podróż wzorcową wagonu lub jednostki intermodalnej.
Techniczna specyfikacja interoperacyjności.
Proces, za pomocą którego prywatne pakiety IP zostają upakowane (kapsułkowanie) w publicznym pakiecie IP.
Protokół datagramów użytkownika (ang. User Datagram Protocol).
Protokół STUN (proste przeglądanie protokołu datagramów użytkownika (UDP) poprzez translatory adresów sieciowych (NAT)) jest lekkim protokołem, który pozwala na wykrywanie przez aplikacje obecności i typów translatorów i zapór sieciowych (firewalls) pomiędzy nimi a publicznym internetem. Umożliwia także identyfikację przez aplikacje publicznych adresów protokołu internetowego (IP) przydzielonych im przez NAT. STUN współpracuje z wieloma istniejącymi translatorami i nie wymaga od nich żadnego szczególnego zachowania. Dzięki temu umożliwia on współpracę całego szeregu aplikacji z istniejącą infrastrukturą NAT.
UIC to Międzynarodowy Związek Kolei.
UITP to Międzynarodowa Unia Transportu Publicznego.
Europejskie Stowarzyszenie Przemysłu Kolejowego (UNIFE) jest organizacją, która dba o interesy dostawców w sektorze kolejowym. Aktualnie około 100 dostawców i poddostawców jest reprezentowanych bezpośrednio, a około 1 000 pośrednio poprzez organizacje krajowe.
Wykorzystana pojemność jednostki
Kod używany do podawania, w jakim stopniu sprzęt jest załadowany lub pusty (np. pełny, pusty, LCL).
Ładunek jednostkowy
Pewna ilość indywidualnych pakietów połączonych ze sobą, umieszczonych na palecie lub związanych razem i tworzących w ten sposób pojedynczą jednostkę w celu sprawniejszego przenoszenia ich przez urządzenia mechaniczne.
Pociąg marszrutowy
Pociąg towarowy odprawiony tylko z jednym listem przewozowym i tylko jednym rodzajem towaru oraz złożony z jednorodnych wagonów jadących od nadawcy do odbiorcy bez pośredniego zestawiania.
Wirtualna sieć prywatna (ang. Virtual Private Network).
Termin „wirtualna sieć prywatna” służy do opisu niemal dowolnego systemu zdalnej łączności, takiego jak publiczna sieć telefoniczna oraz stałe obwody wirtualne z komutacją pakietów (Frame Relay PVC).
Wraz z wprowadzeniem internetu wirtualna sieć prywatna stała się synonimem zdalnej łączności sieciowej opartej na protokole IP. W uproszczeniu VPN składa się z dwu lub więcej sieci prywatnych, które komunikują się w bezpieczny sposób poprzez sieć publiczną.
VPN może istnieć pomiędzy indywidualną maszyną i siecią prywatną (klient-serwer) lub pomiędzy zdalną siecią lokalną i siecią prywatną (serwer-serwer). Sieci prywatne mogą łączyć się przez tunelowanie. VPN zazwyczaj wykorzystuje internet jako podstawową sieć transportową, lecz szyfruje dane przesyłane pomiędzy klientem VPN a bramą VPN, aby uniemożliwić ich odczytanie nawet w przypadku ich przechwycenia podczas przesyłania.
Wagon ładowny
Ładunek jednostkowy, gdy jednostką jest wagon.
Zlecenie przewozu
Podzbiór danych zawartych w liście przewozowym zawierający istotne dla RU informacje potrzebne mu do przeprowadzenia transportu na etapie, za który jest odpowiedzialny, aż do przekazania transportu następnemu RU.
Polecenie transportu przesyłki wagonowej.
Dokument wystawiony przez przewoźnika lub w imieniu przewoźnika, stanowiący dowód zawarcia umowy o przewóz ładunku.
usługa internetowa, która łączy dokumenty poprzez udostępnienie hipertekstowych łączy (linków) pomiędzy serwerami, tak aby użytkownik mógł przechodzić z jednego dokumentu do innego związanego z nim dokumentu bez względu na to, gdzie jest on przechowany w internecie.
Zewnętrzna reprezentacja danych (ang. External Data Representation).
Specyfikacje dotyczące protokołu XDR zawarto w standardzie XDR [RFC1832].
XDR jest standardem opisu i kodowania danych. Umożliwia przesyłanie danych pomiędzy systemami o odmiennych architekturach. XDR wpisuje się w warstwę prezentacji danych modelu ISO i jest w przybliżeniu analogiczny pod względem pełnionej przez niego funkcji do standardu X.409, abstrakcyjnej notacji składniowej ISO. Główna różnica pomiędzy nimi polega na tym, że XDR używa niejawnej konwersji typu, natomiast X.409 — jawnej. XDR używa języka do opisu formatów danych. Język ten może być używany tylko do opisu danych, nie jest to język programowania. Umożliwia on opisywanie złożonych formatów danych w zwięzły sposób. Alternatywny sposób opisu przy użyciu reprezentacji graficznej (język sam w sobie nieformalny) szybko prowadzi do niezrozumiałych opisów w przypadku złożonych formatów. Język XDR podobny jest do języka C. Protokoły takie jak ONC RPC (zdalne wywołanie procedur) oraz NFS (sieciowy system plików) używają XDR do opisywania formatu swoich danych. Standard XDR opiera się na założeniu, że bajty (lub oktety) są przenośne, przy czym bajt jest zdefiniowany jako 8 bitów danych. Dane urządzenie sprzętowe powinno kodować bajty na różnych nośnikach w taki sposób, aby inne urządzenia sprzętowe mogły dekodować te bajty bez utraty znaczenia.
XML-RPC to protokół zdalnego wywołania procedur oparty na języku XML (Extensible Mark-up Language), stosowany do wymiany danych przez internet. Określa on format XML komunikatów przesyłanych pomiędzy klientami i serwerami przy użyciu protokołu HTTP. Komunikat XML-RPC koduje albo procedurę, która ma być wywołana przez serwer, wraz z parametrami używanymi przy wywołaniu, albo wynik wywołania. Parametrami i wynikami procedury mogą być skalary, liczby, ciągi, daty itd.; mogą to być również złożone struktury rekordów i list. Niniejszy dokument określa, w jaki sposób stosować protokół BEEP (Blocks Extensible Exchange Protocol) do przesyłania pomiędzy klientami i serwerami komunikatów zakodowanych w formacie XML-RPC.
Rozszerzony strukturalny język zapytań (ang. Extended Structured Query Language).
(1) Dyrektywa 2001/16/WE Parlamentu Europejskiego i Rady z dnia 19 marca 2001 r. w sprawie interoperacyjności transeuropejskiego systemu kolei konwencjonalnych (Dz.U. L 110 z 20.4.2001, s. 1).
(2) Dyrektywa 91/440/WE z dnia 29 lipca 1991 r. w sprawie rozwoju kolei wspólnotowych (Dz.U. L 237 z 24.8.1991, s. 25).
Zadania krajowego punktu kontaktowego ds. TAF/TAP
Pełnienie funkcji punktu pośredniczącego w kontaktach między ERA, komitetem sterującym TAF/TAP a podmiotami z sektora kolei (zarządcy infrastruktury, przedsiębiorstwa kolejowe, posiadacze wagonów, zarządcy stacji, sprzedawcy biletów, operatorzy intermodalni, klienci usług transportu towarowego koleją i odpowiednie stowarzyszenia) w państwie członkowskim w celu zapewnienia, aby podmioty z sektora kolei angażowały się w działania związane z TAF i/TAP oraz były poinformowane o ogólnym rozwoju sytuacji i decyzjach komitetu sterującego.
Przekazywanie informacji o problemach i kwestiach zgłaszanych przez podmioty z sektora kolei w państwie członkowskim wiceprzewodniczącym komitetu sterującego TAF/TAP.
Kontaktowanie się z członkiem Komitetu ds. Interoperacyjności i Bezpieczeństwa Kolei (RISC) z danego państwa członkowskiego w celu zapewnienia, by był on należycie poinformowany o krajowych kwestiach dotyczących TAF/TAP przed każdym posiedzeniem RISC, oraz by zainteresowane podmioty z sektora kolei były należycie poinformowane o decyzjach tego komitetu dotyczących TAF/TAP.
Państwo członkowskie zapewnia, by skontaktowano się ze wszystkimi licencjonowanymi przedsiębiorstwami kolejowymi i innymi podmiotami z sektora kolei (zarządcy infrastruktury, przedsiębiorstwa kolejowe, posiadacze wagonów, zarządcy stacji, operatorzy intermodalni, klienci usług transportu towarowego koleją i odpowiednie stowarzyszenia) i przekazano im szczegółowe informacje dotyczące krajowego punktu kontaktowego oraz zalecono im skontaktowanie się z krajowym punktem kontaktowym, jeżeli nie nawiązano jeszcze takiego kontaktu.
W zakresie, w jakim podmioty z sektora kolei w państwie członkowskim są znane, uświadomienie im ich obowiązków wynikających z przepisów dotyczących TAF i TAP i konieczności ich spełnienia.
Współpraca z państwem członkowskim w celu zapewnienia wyznaczenia podmiotu odpowiedzialnego za wprowadzenie podstawowych kodów lokalizacji do centralnej domeny referencyjnej. Dane wyznaczonego podmiotu przekazuje się do DG MOVE na potrzeby odpowiedniego przekazywania informacji.
Wspieranie wymiany informacji między podmiotami z sektora kolei (zarządcy infrastruktury, przedsiębiorstwa kolejowe, posiadacze wagonów, zarządcy stacji, sprzedawcy biletów, operatorzy intermodalni, klienci usług transportu towarowego koleją i odpowiednie stowarzyszenia) w państwie członkowskim.