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

(Tekst mający znaczenie dla EOG)

KOMISJA WSPÓLNOT EUROPEJSKICH,

uwzględniając Traktat ustanawiający Wspólnotę Europejską,

uwzględniając dyrektywę 2001/16/WE z dnia 19 marca 2001 r. Parlamentu Europejskiego i Rady w sprawie interoperacyjności systemu kolei konwencjonalnych (1), w szczególności jej art. 6 ust. 1,

a także mając na uwadze, co następuje:

TSI Telematyka oparta została na najlepszej wiedzy specjalistycznej dostępnej w czasie przygotowania projektu odpowiedniej specyfikacji. Zmiany technologiczne, operacyjne w zakresie bezpieczeństwa lub wymagań społecznych mogą powodować konieczność zmiany lub uzupełnienia niniejszej TSI. W tym celu zostanie opracowany proces zarządzania zmianami, służący konsolidacji i aktualizacji wymagań zawartych w TSI. Proces aktualizacji zostanie umieszczony w zakresie odpowiedzialności Europejskiej Agencji Kolejowej, ustanowionej na mocy rozporządzenia (WE) 881/2004 Parlamentu Europejskiego i Rady (4) , po uzyskaniu przez tę agencję zdolności operacyjnej, czyli najpóźniej do kwietnia 2006 r. Tam gdzie to właściwe wszczęta zostanie, zgodnie z art. 6 ust. 3 dyrektywy 2001/16/WE, szersza i bardziej kompleksowa analiza lub procedura aktualizacyjna, obejmująca modyfikacje procesów określonych w niniejszej TSI.

TSI Aplikacje telematyczne powinna uwzględniać szczególne kryteria odnoszące się do zgodności technicznej i operacyjnej wprowadzanych do użytku infrastruktury i taborów kolejowych oraz systemów, z którymi mają być zintegrowane. Wymienione wymagania dotyczące zgodności obejmują kompleksową analizę techniczną i ekonomiczną, którą należy przeprowadzić na podstawie poszczególnych przypadków. Analizy takie powinny uwzględniać interfejsy między różnymi podsystemami wymienionymi w dyrektywie 2001/16/WE, różne kategorie linii i taboru kolejowego wymienionego w tej dyrektywie oraz środowisko techniczne i operacyjne istniejących sieci.

Bardzo ważnym jest, aby analiza taka została przygotowana w ramach spójnych zasad i wytycznych dotyczących wdrażania. Będzie to wymagało ustanowienia przez organy przedstawicielskie sektora kolejowego, działające na poziomie europejskim, europejskiej strategii wdrażania TSI Telematyka. Taka strategia powinna wskazywać kolejne etapy wymagane do przejścia od obecnego częściowego podejścia krajowego w zarządzaniu informacją do jednolitego systemu wymiany informacji dla całej sieci kolejowej w Unii Europejskiej.

System docelowy, opisany w załączonej TSI, powinien opierać się na technologii komputerowej o przewidywanym czasie eksploatacji znacznie krótszym od obecnie stosowanych tradycyjnych kolejowych instalacji sygnalizacyjnych i telekomunikacyjnych. Z powyższego powodu wymagał będzie proaktywnej, a nie reaktywnej strategii wdrożeniowej, celem uniknięcia potencjalnej dezaktualizacji przed pełnym ustanowieniem wszystkich połączeń. Ponadto przyjęcie zbyt rozdrobnionej strategii wdrożeniowej w całym europejskim systemie kolejowym spowodowałoby znaczące koszty i narzuty operacyjne. Opracowanie spójnego transeuropejskiego planu wdrożeniowego dla systemu docelowego przyczyni się do harmonijnego rozwoju całości transeuropejskiego systemu kolejowego, zgodnie ze strategią Wspólnoty dla sieci transportowej TEN. Plan taki powinien opierać się na odpowiednich krajowych planach wdrożeniowych i zapewniać odpowiednie podstawy wiedzy dla wsparcia procesu decyzyjnego różnych podmiotów, w szczególności Komisji, w odniesieniu do przydziału wsparcia finansowego dla projektów kolejowych. Należy pozwolić Komisji na ułatwienie wprowadzenia w życie właściwych środków, zapewniających koordynację wysiłków stron na rzecz opracowania takiego planu.

TSI dla aplikacji telematycznych dla przewozów towarowych ma charakter funkcjonalny. W konsekwencji głównymi adresatami przepisów zawartych w niniejszej TSI będą podmioty rynkowe. Rozporządzenie skierowane do właściwego kręgu podmiotów jest więc w świetle wdrażania przepisów TSI bardziej właściwe niż decyzja skierowana do Państw Członkowskich.

PRZYJMUJE NINIEJSZE ROZPORZĄDZENIE:

Artykuł 1

Techniczna specyfikacja dla interoperacyjności (zwana dalej TSI), odnosząca się do podsystemu „aplikacje telematyczne dla przewozów towarowych” transeuropejskiego systemu kolei konwencjonalnych, wskazana w art. 6 ust. 1 dyrektywy 2001/16/WE, jest określona w Załączniku do niniejszego rozporządzenia.

TSI jest w pełni stosowana do infrastruktury i taboru kolejowego transeuropejskiego systemu kolei konwencjonalnych, określonych w załączniku I do dyrektywy 2001/16/WE.

Artykuł 2

Przewoźnicy kolejowi i zarządcy infrastruktury wnoszą swój udział poprzez zapewnienie wszelkich informacji funkcjonalnych i technicznych na temat poszczególnych istniejących aplikacji telematycznych dla przewozów towarowych, zgodnie z definicją zawarta w rozdziale 2 Załącznika, nie później niż w ciągu sześciu miesięcy od wejścia w życie niniejszego rozporządzenia.

Artykuł 3

Organy przedstawicielskie sektora kolejowego działające na poziomie europejskim, określone w art. 3 ust. 2 rozporządzenia (WE) 881/2004, ustanawiają Strategiczny Europejski Plan Wdrożeniowy dla załączonej TSI, zgodnie z kryteriami podanymi w rozdziale 7 Załącznika do niniejszego rozporządzenia.

Organy te przekazują następnie wymieniony Plan Strategiczny Państwom Członkowskim i Komisji nie później niż w ciągu jednego roku od wejścia w życie niniejszego rozporządzenia.

Artykuł 4

Przepisy decyzji Komisji 2004/446/WE dotyczące podstawowych parametrów transeuropejskiego systemu kolei konwencjonalnych nie mają zastosowania od dnia wejścia w życie niniejszego rozporządzenia.

Artykuł 5

Niniejsze rozporządzenie wchodzi w życie następnego dnia po jego opublikowaniu w Dzienniku Urzędowym Unii Europejskiej.

(1) Dz.U. L 110 z 20.4.2001, str. 1. Dyrektywa zmieniona dyrektywą 2004/50/WE (Dz.U. L 164 z 30.4.2004, str. 114, sprostowanie w Dz.U. L 220 z 21.6.2004, str. 40).

(2) Dz.U. L 155 z 30.4.2004, str. 1, sprostowanie w Dz.U. L 193 z 1.6.2004, str. 1.

(3) Dz.U. L 235 z 17.9.1996, str. 6. Dyrektywa zmieniona dyrektywą 2004/50/WE.

(4) Dz.U. L 164 z 30.4.2004, str. 1, sprostowanie w Dz.U. L 220 z 21.6.2004, str. 3).

ZAŁĄCZNIK

Techniczna specyfikacja dla interoperacyjności odnoszącej się do podsystemu aplikacji telematycznych dla przewozów towarowych transeuropejskiego systemu kolei konwencjonalnych

SPIS TREŚCI:

1. WSTĘP

1.1. Zakres techniczny

1.2. Zakres geograficzny

1.3. Zawartość niniejszej TSI

2. DEFINICJA PODSYSTEMU/ZAKRES

2.1. Funkcja w zakresie TSI

2.2. Funkcje poza zakresem TSI

2.3. Przegląd opisu podsystemu

2.3.1. Uczestniczące jednostki

2.3.2. Rozpatrywane procesy

2.3.3. Uwagi ogólne

3. WYMAGANIA ZASADNICZE

3.1. Spełnienie wymagań zasadniczych

3.2. Aspekty wymagań zasadniczych

3.3. Aspekty związane z wymaganiami ogólnymi

3.3.1. Bezpieczeństwo

3.3.2. Niezawodność i dostępność

3.3.3. Zdrowie

3.3.4. Ochrona środowiska

3.3.5. Zgodność techniczna

3.4. Aspekty dotyczące specjalnie podsystemu „Aplikacje telematyczne dla przewozów towarowych”

3.4.1. Zgodność techniczna

3.4.2. Niezawodność i dostępność

3.4.3. Zdrowie

3.4.4. Bezpieczeństwo

4. CHARAKTERYSTYKA PODSYSTEMU

4.1. Wstęp

4.2. Specyfikacje funkcjonalne i techniczne podsystemu

4.2.1. Dane listu przewozowego

4.2.2. Żądanie trasy

4.2.3. Przygotowanie pociągu

4.2.4. Prognoza jazdy pociągu

4.2.5. Informacja o zakłóceniu służby

4.2.6. Położenie pociągu

4.2.7. ETI/ETA przesyłki

4.2.8. Ruch wagonów

4.2.9. Raportowanie o wymianie

4.2.10. Wymiana danych dla poprawy jakości

4.2.11. Pierwotne dane źródłowe

4.2.12. Różnorodne źródłowe pliki i bazy danych

4.2.13. Elektroniczne przesyłanie dokumentów

4.2.14. Łączność sieciowa i komunikacja

4.3. Specyfikacje funkcjonalne i techniczne interfejsów

4.3.1. Interfejsy z TSI „Infrastruktura”

4.3.2. Interfejsy z TSI „Sterowanie ruchem kolejowym”

4.3.3. Interfejsy z podsystemem „Tabor kolejowy”

4.3.4. Interfejsy z TSI „Ruch kolejowy”

4.4. Zasady operacyjne

4.4.1. Jakość danych

4.4.2. Obsługa centralnego repozytorium

4.5. Zasady utrzymania

4.6. Kwalifikacje zawodowe

4.7. Warunki BHP

4.8. Rejestry infrastruktury i taboru kolejowego

5. SKŁADNIKI INTEROPERACYJNOŚCI

5.1. Definicja

5.2. Wykaz składników

5.3. Charakterystyki sprawnościowe i specyfikacje składników

6. OCENA ZGODNOŚCI I/LUB PRZYDATNOŚCI DO UŻYCIA SKŁADNIKÓW ORAZ WERYFIKACJA PODSYSTEMU

6.1. Składniki interoperacyjności

6.1.1. Procedury oceny

6.1.2. Moduł

6.2. Podsystem „Aplikacje telematyczne dla przewozów towarowych”

7. WDROŻENIE

7.1. Modalności stosowania niniejszej TSI

7.1.1. Wstęp

7.1.2. Strategiczny Europejski Plan Rozwoju (SEDP)

7.1.3. Modalności wdrażania

7.2. Strategia migracji

7.3. Zarządzanie zmianą

7.3.1. Wstęp

7.3.2. Ustalanie poziomu bazowego

7.3.3. Wydanie poziomu bazowego

7.3.4. Rozwój nowych poziomów bazowych

7.3.5. Proces zarządzania zmianą – wymagania

7.3.6. Plan zarządzania konfiguracją – wymagania

7.4. Szczególne przypadki

7.4.1. Wstęp

7.4.2. Wykaz szczególnych przypadków

ZAŁĄCZNIK A: WYKAZ DOŁĄCZONYCH DOKUMENTÓW

ZAŁĄCZNIK B: GLOSARIUSZ

TABELE:

Tabela 1: Żądanie trasy

Tabela 2: Anulowanie trasy przez RU

Tabela 3: Anulowanie trasy przez IM

Tabela 4: Potwierdzenie otrzymania

Tabela 5: Przygotowanie pociągu

Transeuropejski system kolei konwencjonalnej

Specyfikacja techniczna dla interoperacyjności Podsystem: Aplikacje telematyczne dla przewozów towarowych

1. WSTĘP

1.1. Zakres techniczny

Niniejsza TSI dotyczy podsystemu „Aplikacje telematyczne” dla przewozów towarowych, wykazanego w punkcie 1 lit. b) załącznika II do dyrektywy 2001/16/WE.

Handlowa eksploatacja pociągów, wagonów i jednostek intermodalnych w transeuropejskiej sieci kolejowej wymaga sprawnej wymiany informacji pomiędzy poszczególnymi zarządcami infrastruktury, przewoźnikami kolejowymi oraz innymi dostawcami usług. Od takiej zgodności wymiany zależą poziomy osiągów, bezpieczeństwa, jakości usługi oraz kosztów, a także w szczególności interoperacyjność transeuropejskiego systemu kolei konwencjonalnej.

Na warunki używania transportu kolejowego przez użytkowników ma również wpływ specyfikacja techniczna dla interoperacyjności. W tym względzie określenie „użytkownicy” rozumiane jest jako oznaczające nie tylko zarządców infrastruktury lub przewoźników kolejowych, lecz także wszystkich innych dostawców usług, takich jak firmy wagonowe, operatorów intermodalnych, a nawet klientów.

Ostatnią, choć nie mniej ważną sprawą jest to, że korzyści wynikające z interoperacyjności systemu kolei konwencjonalnej zostały wzięte pod uwagę, aby stworzyć warunki dla lepszej interoperacyjności pomiędzy poszczególnymi rodzajami transportu, w szczególności pomiędzy konwencjonalnym transportem kolejowym a kombinowanym transportem kolejowym.

Celem niniejszej TSI jest zapewnienie również sprawnej wymiany informacji zawsze jak najlepiej dostosowanej pod względem jakości i ilości do zmieniających się wymagań, tak aby proces transportu mógł pozostawać możliwie jak najbardziej opłacalny ekonomicznie i aby transport towarów koleją utrzymywał swoją pozycję na rynku w obliczu silnej konkurencji.

Z tym wszystkim wiąże się potrzeba budowy lub modernizacji transeuropejskiego systemu kolei konwencjonalnej dla konwencjonalnego transportu kolejowego i intermodalnego transportu kolejowego. Potrzeba takiej modernizacji kolejowej części systemu transportu może być także zauważona poprzez analizę punktów krytycznych (połączeń pomiędzy poszczególnymi uczestniczącymi partnerami) w drogowym transporcie towarów w porównaniu do punktów krytycznych kolejowego transportu towarów dla jednego uproszczonego scenariusza, który przedstawiono w załączniku A indeks 5 rozdział 1.1.

Zarządzanie przesyłką w warunkach tak wielu połączeń przy zastosowaniu wymiany informacji na podstawie dyrektyw 2001/14/WE (1) i 2001/16/WE Parlamentu Europejskiego i Rady jest ostatecznym celem niniejszej TSI.

To krótkie wyjaśnienie zakresu TSI „Aplikacje telematyczne dla przewozów towarowych” kolei konwencjonalnej pokazuje również różnicę w stosunku do TSI „Ruch kolejowy” kolei konwencjonalnej. TSI „Ruch kolejowy” obejmuje – zwłaszcza w aspektach bezpieczeństwa – procedury i związane urządzenia umożliwiające spójną eksploatację różnych podsystemów strukturalnych, w tym w szczególności prowadzenie pociągu, planowanie i zarządzanie ruchem, które stanowią główny przedmiot działalności przewoźników kolejowych (zwanych dalej RU) zgodnie z definicją (patrz: rozdział 2.3: Przegląd opisu podsystemu).

TSI „Aplikacje telematyczne” obejmuje aplikacje dla przewozów towarowych oraz zarządzania połączeniami z innymi rodzajami transportu, co oznacza, że koncentruje się ona na usługach transportowych RU, oprócz samej eksploatacji pociągów. Aspekty bezpieczeństwa są rozpatrywane nie tylko w zakresie, w jakim istnienie elementów danych, np. nieprawidłowych lub nieaktualnych wartości, może mieć wpływ na bezpieczne prowadzenie pociągu.

1.2. Zakres geograficzny

Geograficznie zakres niniejszej TSI obejmuje transeuropejski system kolei konwencjonalnej opisany w załączniku I do dyrektywy 2001/16/WE. Niniejsza TSI może jednak być również stosowana do kompletnej sieci kolejowej transportu towarowego Państw Członkowskich UE przy zastrzeżeniu, że wymagania niniejszej TSI nie są obowiązujące dla transportu towarów przychodzącego z lub wychodzącego do kraju nienależącego do UE.

1.3. Zawartość niniejszej TSI

Zgodnie z art. 5 ust. 3 dyrektywy 2001/16/WE niniejsza TSI:

a) podaje zamierzony zakres podsystemu „Aplikacje telematyczne dla przewozów towarowych”– rozdział 2: Definicja podsystemu/zakres ;

b) określa wymagania zasadnicze dla tego podsystemu i jego interfejs z innymi systemami – rozdział 3: Wymagania zasadnicze;

c) ustala specyfikacje funkcjonalne i techniczne, jakie mają być spełnione przez jego interfejsy z innymi podsystemami – rozdział 4: Charakterystyka podsystemu;

d) określa składniki interoperacyjności i interfejsy objęte specyfikacjami europejskimi, w tym również normami europejskimi, które są niezbędne do osiągnięcia interoperacyjności w transeuropejskim systemie kolei konwencjonalnej – rozdział 5: Składniki interoperacyjności;

e) podaje w każdym rozważanym przypadku procedury dla oceny zgodności lub przydatności do użycia. Obejmuje to w szczególności moduły określone w decyzji Rady 93/465/EWG (2) lub, w stosownym wypadku, specjalne procedury używane do oceny zgodności lub przydatności do użycia składników interoperacyjności oraz wspólnotowej weryfikacji podsystemów – rozdział 6: Ocena zgodności i/lub przydatności do użycia składników oraz weryfikacja podsystemu;

f) podaje strategię wdrażania TSI. W szczególności niezbędne jest określenie etapów, jakie należy pokonać w celu dokonania stopniowego przejścia z istniejącej sytuacji do sytuacji docelowej, w której spełnienie TSI będzie normą – rozdział 7: Wdrożenie;

g) podaje dla zainteresowanego personelu kwalifikacje zawodowe oraz warunki BHP wymagane dla użytkowania i utrzymania podsystemu, jak również dla wdrożenia TSI – rozdział 4: Charakterystyka podsystemu.

Ponadto zgodnie z art. 5 ust. 5 przewidziano szczególne przypadki dla niniejszej TSI; są one podane w rozdziale 7.3: Szczególne przypadki .

I wreszcie, niniejsza TSI zawiera również w rozdziale 4 (Charakterystyka podsystemu) wymagania dotyczące eksploatacji i utrzymania dla zakresu podanego w ustępach 1.1 (Zakres techniczny) i 1.2 (Zakres geograficzny) powyżej.

2. DEFINICJA PODSYSTEMU/ZAKRES

2.1. Funkcja w zakresie TSI

Podsystem „Aplikacje telematyczne dla przewozów towarowych” jest określony w załączniku II do dyrektywy 2001/16/EWG, sekcja 2.5 lit. b).

Obejmuje on 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 tworzeniem elektronicznych dokumentów towarzyszących.

2.2. Funkcje poza zakresem TSI

W zakresie niniejszej TSI nie mieszczą się systemy płatności i fakturowania dla klientów ani też podobne systemy do obsługi płatności i fakturowania pomiędzy różnymi dostawcami usług, takimi jak przewoźnicy kolejowi lub zarządcy infrastruktury. Jednakże informacji potrzebnych jako podstawa dla płatności za usługi transportowe dostarcza projekt systemu, na którym opiera się wymiana danych, zgodnie z rozdziałem 4.2 (Specyfikacje funkcjonalne i techniczne podsystemu).

Również długoterminowe planowanie rozkładów jazdy wykracza poza zakres niniejszej TSI „Aplikacje telematyczne”. Niemniej jednak w niektórych punktach będzie odwołanie do wyniku długoterminowego planowania, o ile istnieje związek ze sprawną wymianą informacji koniecznych do prowadzenia pociągów.

2.3. Przegląd opisu podsystemu

2.3.1. Uczestniczące jednostki

Niniejsza TSI uwzględnia obecnych dostawców usług oraz różnych możliwych przyszłych dostawców usług w zakresie transportu towarowego w następujących dziedzinach (wykaz ten nie jest wyczerpujący):

— wagony,

— lokomotywy,

— maszyniści,

— manewrowanie i rozrządzanie,

— sprzedaż automatów biletowych,

— zarządzanie przesyłką,

— skład pociągu,

— prowadzenie pociągu,

— monitorowanie pociągu,

— sterowanie pociągiem,

— monitorowanie przesyłki,

— kontrole i naprawy wagonów i/lub lokomotyw,

— odprawa celna,

— obsługa terminali intermodalnych,

— zarządzanie przewozami.

Niektórzy konkretni dostawcy usług są wyraźnie określeni w dyrektywach 2001/14/WE i 2001/16/WE. Ponieważ obie dyrektywy muszą być uwzględnione, TSI bierze pod uwagę w szczególności poniższą definicję (patrz również: załącznik A indeks 6):

„»Zarządca infrastruktury (dalej IM)« oznacza organ lub przedsiębiorstwo, które jest odpowiedzialne w szczególności za ustanowienie i utrzymywanie infrastruktury. Może to również obejmować zarządzanie systemami kontroli i bezpieczeństwa infrastruktury. Funkcje zarządcy infrastruktury w sieci lub części sieci mogą być przydzielone innym organom lub przedsiębiorstwom.”

W oparciu o tę definicję w rozumieniu niniejszej TSI uważa się IM za dostawcę usług w zakresie przydzielania tras, sterowania/monitorowania pociągów oraz raportowania związanego z pociągami/trasami.

Zgodnie z dyrektywą 2001/14/WE organ lub przedsiębiorstwo, któremu IM przydziela drogę, jest zdefiniowane jako ubiegający się.

„»Ubiegający się« oznacza licencjonowanego przewoźnika kolejowego i/lub międzynarodowe ugrupowanie przewoźników kolejowych oraz, w Państwach Członkowskich, które przewidują taką możliwość, inne osoby i/lub jednostki prawne mające wynikające ze służby publicznej lub komercyjne interesy w nabywaniu mocy przepustowych infrastruktury, takie jak organy publiczne zgodnie z rozporządzeniem (EWG) nr 1191/69 oraz załadowcy, spedytorzy oraz przewoźnicy transportu kombinowanego, w celu prowadzenia usług kolejowych na ich odnośnych terytoriach. Natomiast »przewoźnik kolejowy« jest zdefiniowany jako dowolne publiczne lub prywatne przedsiębiorstwo licencjonowane zgodnie z obowiązującym prawodawstwem wspólnotowym, którego główna działalność polega na świadczeniu usług przewozu towarów i/lub osób koleją przy wymaganiu, ż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 rozumieniu niniejszej TSI uważa się RU za dostawcę usług w zakresie prowadzenia pociągów.

Odnośnie do przydziału trasy pociągu dla prowadzenia pociągu należy również wziąć pod uwagę art. 13 dyrektywy 2001/14/WE:

„Zdolność przepustowa infrastruktury jest alokowana przez zarządcę infrastruktury, a z chwilą przydzielenia wnioskodawcy nie może być 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 stosunku do scenariuszy komunikacji pomiędzy zarządcami infrastruktury a ubiegającymi się w trybie wykonawczym transportu należy wziąć pod uwagę tylko IM i RU, a nie innego rodzaju ubiegających się, którzy mogą być stosowni dla trybu planowania. W trybie wykonawczym zawsze jest dana określona zależność IM – RU, dla której wymiana wiadomości i przechowywanie informacji jest określone w niniejszej TSI. Pozostaje to bez wpływu na definicję ubiegającego się oraz wynikających z niej możliwości przydziału trasy.

Jak już wspomniano, dla transportu towarowego muszą być zapewnione różne usługi. Jedną z nich 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 i/lub wagonami innego dysponenta (innego dostawcy usług w zakresie wagonów towarowych). Potrzeby tego rodzaju dostawcy usług są brane pod uwagę niezależnie od tego, czy osoba prawna zarządcy floty pojazdów jest jednocześnie przewoźnikiem kolejowym (RU) czy nie.

Niniejsza TSI nie tworzy nowych osób prawnych i nie zmusza RU do angażowania zewnętrznych dostawców usług, które RU sam świadczy, ale, tam gdzie jest to stosowne, określa usługę nazwą odpowiedniego dostawcy usług. Jeśli usługa jest świadczona przez RU, to RU działa jako dostawca usług w zakresie tejże usługi.

Biorąc pod uwagę potrzeby klienta, jedną z usług jest organizowanie i zarządzanie linią transportową zgodnie ze zobowiązaniem wobec klienta. Usługa ta jest dostarczana przez „wiodącego przewoźnika kolejowego” (wiodącego RU lub LRU). LRU jest jedynym punktem kontaktu dla klienta. Jeżeli w łańcuchu transportowym uczestniczy więcej niż jedne przewoźnik kolejowy, to LRU jest także odpowiedzialny za koordynację z innymi przewoźnikami kolejowymi.

Usługa ta może być również realizowana przez spedytora lub przez dowolną inną jednostkę.

Uczestnictwo 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 marszrutowych bezpośrednich oraz przygotowywanie listów przewozowych jest wykonywane przez integratora usług intermodalnych, który może wówczas być klientem dla LRU.

Podstawową kwestią jest jednak to, że RU i IM oraz inni dostawcy usług (w znaczeniu zdefiniowanym powyżej) muszą działać wspólnie poprzez współpracę i/lub otwarty dostęp, jak również poprzez sprawną wymianę informacji, aby świadczyć niezakłócone usługi dla klienta.

2.3.2. Rozpatrywane procesy

Niniejsza TSI dla branży kolejowego transportu towarowego jest ograniczona zgodnie z dyrektywą 2001/16/WE do IM i RU/LRU w zakresie ich bezpośrednich klientów.

Przy wykonywaniu transportu towarowego działalność LRU dotycząca przesyłki rozpoczyna się wraz z otrzymaniem listu przewozowego od klienta oraz, na przykład, dla ładunków przesyłanych wagonami – wraz z czasem zwolnienia wagonów. LRU tworzy wstępny plan podróży (w oparciu o doświadczenie i/lub umowę) dla danego transportu. Jeżeli LRU zamierza mieć załadowane wagony w pociągu w trybie otwartego dostępu (LRU prowadzi pociąg przez całą drogę), to wstępny plan podróży jest sam w sobie planem ostatecznym. Jeżeli LRU zamierza umieścić załadowane wagony w pociągu w sposób, który zakłada współpracę z innym RU, musi najpierw dowiedzieć się, do których RU powinien się zwrócić i w jakim czasie może nastąpić przekazanie pomiędzy dwoma kolejnymi RU. LRU przygotowuje wówczas wstępne zamówienia wagonów indywidualnie dla każdego RU, jako poszczególne części listu przewozowego. Zamówienia wagonów są określone w rozdziale 4.2.1 (Dane listu przewozowego).

RU, do którego zwrócono się, sprawdza dostępność zasobów do eksploatacji wagonów oraz dostępność trasy pociągu. Odpowiedzi otrzymane od poszczególnych RU pozwalają LRU na dopracowanie planu podróży lub wznowienie zapytania – być może nawet skierowanie go do innych RU – aż plan podróży będzie ostatecznie dostosowany do wymagań klienta.

RU/LRU musi ogólnie posiadać co najmniej zdolność:

— OKREŚLANIA usług pod względem ceny i czasów przejazdu, dostawy wagonów (o ile ma to zastosowanie), danych dotyczących wagonów/jednostek intermodalnych (lokalizacja, status oraz szacowany czas przyjazdu (ETA) wagonów/jednostek intermodalnych), 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 przez zastosowanie 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ą mieć możliwość wymiany informacji drogą elektroniczną,

— MIERZENIA jakości dostarczanej usługi w porównaniu do tego, co zostało określone, np. ścisłości wystawionych rachunków w stosunku do podanej ceny, rzeczywistych czasów przejazdu w stosunku do zobowiązań, wagonów zamówionych w stosunku do dostarczonych, ETA w stosunku do faktycznego czasu 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 wymaganych do wspomagania sporządzania harmonogramu wagonów/jednostek intermodalnych i pociągów.

RU/LRU jako ubiegający się muszą również dostarczyć (poprzez umowy z IM) wymaganą trasę pociągu i musi prowadzić pociąg w obrębie swojego odcinka trasy przejazdu. Jeżeli chodzi o trasę pociągu, mogą oni wykorzystać zarezerwowane już trasy (w trybie planowania) lub muszą zażądać doraźnej trasy pociągu od zarządców infrastruktury (IM) właściwych dla odcinków trasy przejazdu, na których RU prowadzi pociąg. W załączniku A indeks 5 rozdział 1.2 podano przykład scenariusza dla żądania trasy.

Ważna dla komunikacji pomiędzy IM a RU podczas jazdy pociągu jest także własność trasy. Komunikacja musi być zawsze oparta o numer pociągu oraz numer trasy, za pomocą których IM komunikuje się z RU, który zarezerwował trasę pociągu w swojej infrastrukturze (patrz również: załącznik A indeks 5 rozdział 1.2).

Jeżeli RU zapewnia pełny przejazd A – F (otwarty dostęp przez RU, nie uczestniczą inni RU), każdy uczestniczący IM komunikuje się bezpośrednio tylko z tym RU. Ten „otwarty dostęp” przez RU może być zrealizowany przez zarezerwowanie trasy pociągu w ramach „jednego okienka” lub w poszczególnych odcinkach, bezpośrednio u każdego IM. TSI uwzględnia obydwa przypadki, jak przedstawiono to w rozdziale 4.2.2.1: Żądanie trasy. Uwagi wstępne.

Dialog pomiędzy RU i IM w celu ustalenia trasy pociągu towarowego jest określony w rozdziale 4.2.2 (Żądanie trasy). Funkcja nawiązuje do art. 23 ust. 1 dyrektywy 2001/14/WE. Procedura dialogu nie obejmuje uzyskiwania licencji dla RU świadczącego usługi zgodnie z dyrektywą 2001/13/WE Parlamentu Europejskiego i Rady (3), certyfikacji zgodnie z dyrektywą 2001/14/WE oraz praw dostępu zgodnie z dyrektywą Rady 91/440/EWG (4).

W rozdziale 4.2.3 (Przygotowanie pociągu) jest zdefiniowana wymiana informacji odnośnie do składu pociągu oraz procedury odjazdu pociągu. Wymianę danych podczas jazdy pociągu w przypadku normalnego prowadzenia podano w rozdziale 4.2.4 (Prognoza jazdy pociągu), a dla wyjątków komunikaty zdefiniowano w rozdziale 4.2.5 (Informacja o zakłóceniu służby). Odtwarzanie informacji o lokalizacji pociągu określono w rozdziale 4.2.6 (Lokalizacja pociągu). Wszystkie te komunikaty są wymieniane pomiędzy RU i IM i oparte o pociągi.

Dla klienta najważniejszą informacją jest zawsze szacowany czas przyjazdu (ETA) jego przesyłki. Czas ETA może być obliczony na podstawie wymiany informacji pomiędzy LRU a IM (w przypadku otwartego dostępu). W wypadku trybu współpracy z różnymi RU, ETA a także szacowany czas wymiany (ETI) mogą być określone na podstawie wymiany komunikatów pomiędzy RU i IM i dostarczone LRU przez RU (rozdział 4.2.7).

Na podstawie wymiany informacji pomiędzy IM a RU LRU wie także na przykład:

— kiedy wagony wyjechały ze stacji rozrządowej lub przyjechały do niej albo w inne określone miejsca (rozdział 4.2.8 Ruch wagonów), lub

— kiedy odpowiedzialność za wagony została przeniesiona z jednego RU na następnego RU w łańcuchu transportowym (rozdział 4.2.9: Raportowanie o wymianie).

Na podstawie nie tylko wymiany danych pomiędzy IM i RU, lecz także wymiany danych pomiędzy różnymi RU i LRU, można określić różne statystyki:

— w średnim okresie — dla bardziej szczegółowego planowania procesu produkcji,

— w długim okresie — dla realizacji zadań planowania strategicznego oraz badań zdolności (np. analiz sieci, określania bocznic i stacji rozrządowych, planowania taboru), lecz przede wszystkim,

— dla poprawy jakości usług transportowych i wydajności (rozdział 4.2.10: Wymiana danych dla poprawy jakości).

Obsługiwanie pustych wagonów nabiera szczególnego znaczenia, gdy bierze się pod uwagę wagony podlegające interoperacyjności. W zasadzie nie ma różnicy w obsługiwaniu wagonów załadowanych i pustych. Transport pustych wagonów jest również oparty o zamówienia wagonów, wskutek czego zarządca parku takich pustych wagonów musi być uważany za klienta.

2.3.3. Uwagi ogólne

O wartości systemu informatycznego decyduje rzetelność zawartych w nim danych. Dlatego dane, które odgrywają decydującą rolę w ekspediowaniu przesyłki, wagonu lub kontenera, muszą być ścisłe i uzyskane w ekonomiczny sposób, co znaczy, że dane powinny być wprowadzone do systemu tylko raz.

Na tej podstawie aplikacje i komunikaty, o których mowa w niniejszej TSI, nie pozwalają na wielokrotne ręczne wprowadzanie danych przez dostęp do już zapisanych danych, np. danych źródłowych o taborze. Wymagania dotyczące danych źródłowych o taborze określono w rozdziale 4.2.11 (Pierwotne dane źródłowe). Określone źródłowe bazy danych taboru muszą pozwalać na łatwy dostęp do danych technicznych. Zawartość baz danych musi być dostępna, na podstawie zorganizowanych praw dostępu zależnych od uprawnień, dla wszystkich IM, RU i zarządców parku pojazdowego, w szczególności do celów zarządzania parkiem i utrzymania taboru. Bazy te muszą zawierać wszystkie istotne dane techniczne dotyczące transportu, takie jak:

— identyfikacja taboru,

— dane techniczne/projektowe,

— ocena zgodności z infrastrukturą,

— ocena istotnych charakterystyk obciążenia,

— istotne charakterystyki hamulców,

— dane dotyczące konserwacji i utrzymania,

— charakterystyki środowiskowe.

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 nie wystarczy pracować tylko przy pomocy planu podróży dla wagonów i dlatego musi zostać opracowany również plan podróży dla jednostek intermodalnych.

W rozdziale 4.2.12 (Różnorodne pliki źródłowe) wymieniono niektóre źródłowe pliki i 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 rozdziale 4.2.13 (Elektroniczne przesyłanie dokumentów) podano wymagania dotyczące elektronicznego przesyłania dokumentów.

TSI dla podsystemu „Aplikacje telematyczne dla przewozów towarowych” określa wymagane informacje, które muszą być wymieniane pomiędzy różnymi partnerami biorącymi udział w łańcuchu transportowym oraz pozwala na instalację standardowego procesu wymiany obowiązkowych danych. Przedstawia również strategię architektury dla takiej platformy komunikacyjnej. Jest to w skrócie opisane w rozdziale 4.2.14 (Łączność sieciowa i komunikacja) z uwzględnieniem:

— połączenia z podsystemem „Ruch kolejowy” transeuropejskiego systemu kolei konwencjonalnej wymienionego w art. 5 ust. 3 dyrektywy Rady 2001/16/WE,

— wymagań dotyczących treści oświadczenia w sprawie sieci, które są przedstawione w dyrektywie 2001/14/WE, art. 3 i załączniku I,

— dostępnych informacji o taborze wagonów towarowych oraz wymagań dotyczących konserwacji, pochodzących z TSI 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/ETSC używa GSM-R. W tej otwartej sieci specyfikacje ETCS wyjaśniają, że bezpieczeństwo jest osiągane przy odpowiednim zarządzaniu zagrożeniami otwartych sieci w protokole EURORADIO.

Połączenia z podsystemami „Tabor kolejowy” i „Bezpieczna kontrola jazdy pociągu” są podane jedynie za pośrednictwem baz źródłowych danych taboru kolejowego (rozdział 4.2.11.3: Źródłowe bazy danych taboru kolejowego), które znajdują się pod kontrolą dysponentów. Połączenia z podsystemami „Infrastruktura”, „Bezpieczna kontrola jazdy pociągu” i „Energia” są podane z określeniem trasy (rozdział 4.2.2.3: Komunikat „Dane o trasie”) otrzymanym od IM, gdzie określone są wartości dla pociągu związane z infrastrukturą oraz z informacjami dostarczonymi przez IM odnośnie do ograniczeń w infrastrukturze (rozdział 4.2.11.2: Bazy danych powiadomień o ograniczeniach w infrastrukturze).

3. WYMAGANIA ZASADNICZE

3.1. Spełnienie wymagań zasadniczych

Zgodnie z art. 4 ust. 1 dyrektywy 2001/16/WE transeuropejski system kolei konwencjonalnej, podsystemy i ich składniki interoperacyjności muszą spełniać wymagania zasadnicze przedstawione w ogólnych warunkach w załączniku III do dyrektywy.

W zakresie obecnej TSI spełnienie odnośnych wymagań zasadniczych podanych w rozdziale 3 niniejszej TSI będzie zapewnione dla podsystemu poprzez zastosowanie się do specyfikacji opisanych w rozdziale 4: Charakterystyka podsystemu.

3.2. Aspekty wymagań zasadniczych

Wymagania zasadnicze dotyczą:

— bezpieczeństwa,

— niezawodności i dostępności,

— zdrowia,

— ochrony środowiska,

— zgodności technicznej.

Zgodnie z dyrektywą 2001/16/WE wymagania zasadnicze mogą generalnie stosować się do całego transeuropejskiego systemu kolei konwencjonalnej lub mogą być specyficzne dla każdego podsystemu i jego składników.

3.3. Aspekty związane z wymaganiami ogólnymi

Stosowność wymagań ogólnych do podsystemu „Aplikacje telematyczne dla przewozów towarowych” jest określona następująco:

3.3.1. Bezpieczeństwo

Zgodnie z załącznikiem III do dyrektywy 2001/16/WE do podsystemu „Aplikacje telematyczne dla przewozów towarowych” mają zastosowanie następujące wymagania zasadnicze związane z bezpieczeństwem:

— Wymaganie zasadnicze 1.1.1 załącznika III do dyrektywy 2001/16/WE: „Projektowanie, konstrukcja lub montaż, utrzymanie i monitorowanie składników mających krytyczne znaczenie dla bezpieczeństwa, a konkretnie składników występujących w ruchach pociągów musi być takie, aby gwarantowało bezpieczeństwo na poziomie odpowiadającym celom ustalonym dla sieci, w tym również dla szczególnych pogorszonych sytuacji.” To wymaganie zasadnicze nie odnosi się do podsystemu „Aplikacje telematyczne”.

— Wymaganie zasadnicze 1.1.2 załącznika III do dyrektywy 2001/16/WE: „Parametry występujące w kontakcie koło/szyna muszą spełniać wymagania stabilności niezbędne do zagwarantowania bezpiecznego ruchu przy maksymalnej dopuszczonej prędkości.” To wymaganie zasadnicze nie odnosi się do podsystemu „Aplikacje telematyczne”.

— Wymaganie zasadnicze 1.1.3 załącznika III do dyrektywy 2001/16/WE: „Zastosowane składniki muszą wytrzymywać wszelkie normalne i wyjątkowe naprężenia, które zostały określone podczas okresu ich eksploatacji. Konsekwencje wszelkich przypadkowych awarii dla bezpieczeństwa muszą być ograniczone za pomocą odpowiednich środków.” To wymaganie zasadnicze nie odnosi się do podsystemu „Aplikacje telematyczne”.

— Wymaganie zasadnicze 1.1.4 załącznika III do dyrektywy 2001/16/WE: „Projektowanie stałych instalacji i taboru kolejowego oraz wybór zastosowanych materiałów muszą mieć na uwadze ograniczenie wytwarzania, rozprzestrzeniania oraz skutków ognia i dymu w razie pożaru.” To wymaganie zasadnicze nie odnosi się do podsystemu „Aplikacje telematyczne”.

— Wymaganie zasadnicze 1.1.5 załącznika III do dyrektywy 2001/16/WE: „Wszelkie urządzenia, którymi mają posługiwać się użytkownicy, muszą być tak zaprojektowane, aby nie wpływały ujemnie na bezpieczną pracę urządzeń lub na zdrowie i bezpieczeństwo użytkowników, jeśli zostaną użyte w przewidywalny sposób niezgodny z wywieszonymi instrukcjami.” To wymaganie zasadnicze nie odnosi się do podsystemu „Aplikacje telematyczne”.

3.3.2. Niezawodność i dostępność

„Monitorowanie i utrzymanie stałych lub ruchomych składników, które biorą udział w ruchach pociągów musi być zorganizowane, przeprowadzone i określone ilościowo w taki sposób, aby utrzymać ich działanie w zamierzonych warunkach.”

To wymaganie zasadnicze jest spełnione przez następujące rozdziały:

rozdział 4.2.11: Pierwotne dane źródłowe,

rozdział 4.2.12: Różnorodne źródłowe pliki i bazy danych,

rozdział 4.2.14: Łączność sieciowa i komunikacja.

3.3.3. Zdrowie

— Wymaganie zasadnicze 1.3.1 załącznika III do dyrektywy 2001/16/WE: „Materiały, które z racji sposobu, w jaki są używane, mogą stanowić zagrożenie dla zdrowia tych, którzy mają do nich dostęp, nie mogą być stosowane w pociągach i infrastrukturze kolejowej.” To wymaganie zasadnicze nie odnosi się do podsystemu „Aplikacje telematyczne”.

— Wymaganie zasadnicze 1.3.2 załącznika III do dyrektywy 2001/16/WE: „Materiały te muszą zostać wybrane, rozmieszczone i użyte w taki sposób, aby ograniczyć emisję szkodliwych i niebezpiecznych dymów i gazów, szczególnie w razie pożaru.” To wymaganie zasadnicze nie odnosi się do podsystemu „Aplikacje telematyczne”.

3.3.4. Ochrona środowiska

— Wymaganie zasadnicze 1.4.1 załącznika III do dyrektywy 2001/16/WE: „Wpływ na środowisko spowodowany ustanowieniem i eksploatacją transeuropejskiego systemu kolei konwencjonalnej musi zostać oceniony i uwzględniony na etapie projektowania systemu zgodnie z obowiązującymi wspólnotowymi przepisami.” To wymaganie zasadnicze nie odnosi się do podsystemu „Aplikacje telematyczne”.

— Wymaganie zasadnicze 1.4.2 załącznika III do dyrektywy 2001/16/WE: „Materiały zastosowane w pociągach i infrastrukturze muszą uniemożliwiać emisję dymów lub gazów szkodliwych lub niebezpiecznych dla środowiska, zwłaszcza w razie pożaru.” To wymaganie zasadnicze nie odnosi się do podsystemu „Aplikacje telematyczne”.

— Wymaganie zasadnicze 1.4.3 załącznika III do dyrektywy 2001/16/WE: „Tabor kolejowy i systemy zasilania energią muszą być zaprojektowane i wykonane w taki sposób, aby były zgodne pod względem elektromagnetycznym z instalacjami, urządzeniami oraz publicznymi lub prywatnymi sieciami, z którymi mogłyby kolidować.” To wymaganie zasadnicze nie odnosi się do podsystemu „Aplikacje telematyczne”.

— Wymaganie zasadnicze 1.4.4 załącznika III do dyrektywy 2001/16/WE: „Eksploatacja transeuropejskiego systemu kolei konwencjonalnej musi respektować istniejące przepisy dotyczące zanieczyszczenia hałasem.” To wymaganie zasadnicze nie odnosi się do podsystemu „Aplikacje telematyczne”.

— Wymaganie zasadnicze 1.4.5 załącznika III do dyrektywy 2001/16/WE: „Eksploatacja transeuropejskiego systemu kolei konwencjonalnej nie może prowadzić do wytwarzania niedopuszczalnego poziomu drgań gruntu dla działalności i terenów będących w pobliżu infrastruktury i w normalnym stanie utrzymania.” To wymaganie zasadnicze nie odnosi się do podsystemu „Aplikacje telematyczne”.

3.3.5. Zgodność techniczna

— Wymaganie zasadnicze 1.5 załącznika III do dyrektywy 2001/16/WE: „Charakterystyki techniczne infrastruktury i stałych instalacji muszą być zgodne ze sobą oraz z charakterystykami pociągów, które będą używane w transeuropejskim systemie kolei konwencjonalnej. Jeżeli zgodność z tymi charakterystykami okaże się trudna na niektórych odcinkach sieci, można wprowadzić tymczasowe rozwiązania, które zapewnią zgodność w przyszłości.” To wymaganie zasadnicze nie odnosi się do podsystemu „Aplikacje telematyczne”.

3.4. Aspekty dotyczące specjalnie podsystemu „Aplikacje telematyczne dla przewozów towarowych”

3.4.1. Zgodność techniczna

— Wymaganie zasadnicze 2.7.1 załącznika III do dyrektywy 2001/16/WE: „Wymagania zasadnicze dla aplikacji telematycznych gwarantują minimalną jakość usługi dla pasażerów i przewoźników towarów, zwłaszcza pod względem zgodności technicznej. Należy podjąć kroki w celu zapewnienia: — że bazy danych, oprogramowanie i protokoły komunikacji danych są opracowane w sposób pozwalający na maksymalną wymianę danych pomiędzy różnymi aplikacjami i operatorami, z wyłączeniem poufnych danych handlowych, — łatwego dostępu użytkownikom do informacji.” To wymaganie zasadnicze jest szczególnie spełnione przez następujące rozdziały: — rozdział 4.2.11: Pierwotne dane źródłowe, — rozdział 4.2.12: Różnorodne źródłowe pliki i bazy danych, — rozdział 4.2.14: Łączność sieciowa i komunikacja.

3.4.2. Niezawodność i dostępność

— Wymaganie zasadnicze 2.7.2 załącznika III do dyrektywy 2001/16/WE: „Metody użycia, zarządzanie, uaktualnianie i utrzymanie tych baz danych, oprogramowania i protokołów komunikacji danych muszą gwarantować sprawność tych systemów oraz jakość usługi.” To wymaganie jest szczególnie spełnione przez następujące rozdziały: — Rozdział 4.2.11: Pierwotne dane źródłowe, — Rozdział 4.2.12: Różnorodne źródłowe pliki i bazy danych, — Rozdział 4.2.14: Łączność sieciowa i komunikacja. Lecz to wymaganie zasadnicze, zwłaszcza metoda użycia w celu zagwarantowania sprawności tych aplikacji telematycznych oraz jakości usługi jest podstawą dla całej TSI i nie ogranicza się tylko wymienionych wyżej rozdziałów.

3.4.3. Zdrowie

— Wymaganie zasadnicze 2.7.3 załącznika III do dyrektywy 2001/16/WE: „Interfejsy pomiędzy tymi systemami a użytkownikami muszą odpowiadać minimalnym zasadom ergonomii i ochrony zdrowia.” Niniejsza TSI nie określa żadnych dodatkowych określeń ponad istniejące krajowe i europejskie reguły dotyczące minimalnych zasad ergonomii i ochrony zdrowia połączenia pomiędzy tymi aplikacjami telematycznymi i użytkownikami.

3.4.4. Bezpieczeństwo

— Wymaganie zasadnicze 2.7.4 załącznika III do dyrektywy 2001/16/WE: „Należy zapewnić odpowiednie poziomy integralności i niezawodności przechowywania lub przesyłania informacji dotyczących bezpieczeństwa.” To wymaganie jest spełnione przez następujące rozdziały: — rozdział 4.2.11: Pierwotne dane źródłowe, — rozdział 4.2.12: Różnorodne źródłowe pliki i bazy danych, — rozdział 4.2.14: Łączność sieciowa i komunikacja.

4. CHARAKTERYSTYKA PODSYSTEMU

4.1. Wstęp

Transeuropejski system kolei konwencjonalnej, do którego stosuje się dyrektywa 2001/16/WE i którego częścią jest podsystem „Aplikacje telematyczne”, jest integralnym systemem, którego zgodność musi być zweryfikowana. Zgodność ta musi być sprawdzona w szczególności pod względem specyfikacji podsystemu, jego połączeń z systemem, z którym jest zintegrowany, jak również zasad eksploatacji i utrzymania.

Biorąc pod uwagę wszystkie stosujące się wymagania zasadnicze, podsystem „Aplikacje telematyczne dla przewozów towarowych” jest scharakteryzowany przez:

4.2. Specyfikacje funkcjonalne i techniczne podsystemu

W świetle wymagań zasadniczych przedstawionych w rozdziale 3 (Wymagania zasadnicze) specyfikacje funkcjonalne i techniczne podsystemu są następujące:

— dane listu przewozowego,

— żądanie trasy,

— przygotowanie pociągu,

— prognoza jazdy pociągu,

— informacja o zakłóceniu służby,

— lokalizacja pociągu,

— ETI/ETA wagonów/jednostek intermodalnych,

— ruch wagonów,

— raportowanie o wymianie,

— wymiana danych dla poprawy jakości,

— pierwotne dane źródłowe,

— różnorodne źródłowe pliki i bazy danych,

— elektroniczne przesyłanie dokumentów,

— łączność sieciowa i komunikacja.

Szczegółowe specyfikacje są przedstawione poniżej. Dalsze szczegóły oraz formaty komunikatów określono w załączniku A indeks 1.

Ogólne uwagi na temat struktury komunikatów

Komunikaty są podzielone na dwa zbiory danych:

— Dane kontrolne: wyjaśnienie – patrz: poniżej

— Dane informacyjne: informacje o aplikacji

Dane kontrolne pokazują następujące elementy:

— Status: Status komunikatu może być następujący: — „Nowy komunikat”, jeśli jest to nowy komunikat — „Zmiana”, jeśli jest to modyfikacja poprzednio wysłanego komunikatu — „Usunięcie”, jeśli poprzednio wysłany komunikat powinien zostać usunięty.

— Oznaczenie komunikatu z podaniem: — Typu komunikatu: np. „żądanie trasy” lub „zapytanie o jazdę pociągu” — Daty i czasu: faktycznego dnia i czasu wysłania komunikatu — Numeru komunikatu: numeru wygenerowanego przez wysyłającego komunikat

— Związane oznaczenie, tylko jeśli komunikat jest odpowiedzią na otrzymany komunikat (identyczne z „Oznaczeniem komunikatu” otrzymanego komunikatu) z podaniem: — Związanego typu: typu otrzymanego komunikatu — Związanej daty i czasu: dnia i czasu otrzymanego komunikatu — Związanego numeru: numeru otrzymanego komunikatu

— Wysyłający komunikat

— Odbiorca komunikatu

W następnym rozdziałach rozpatrzony jest głównie status „Nowy komunikat”. W rozdziale 4.2.2 „Żądanie trasy” nawiązano również do statusu „Usunięcie” odnoszącego się do komunikatu „Żądanie trasy”.

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 (LRU). Musi on wykazywać wszystkie dane potrzebne do przewiezienia przesyłki od nadawcy do odbiorcy. LRU musi uzupełnić te dane o dodatkowe informacje. Dane te wraz z dodatkowymi danymi (opis danych można znaleźć w załączniku A indeks 3) są wymienione w załączniku A indeks 3 z podaniem w wierszu „Dane w liście przewozowym”, czy są one obowiązkowe czy opcjonalne, i czy muszą być dostarczone przez nadawcę lub uzupełnione przez LRU.

W wypadku otwartego dostępu wiodący RU zawierający umowę z klientem posiada wszystkie informacje po uzupełnieniu dostępnych danych. Nie jest wymagana wymiana komunikatów z innymi RU. Dane te są także podstawą do natychmiastowego żądania trasy, jeśli jest to wymagane do wykonania listu przewozowego.

Poniższe komunikaty dotyczą przypadku nie otwartego dostępu. Treść tych komunikatów może także być podstawą do natychmiastowych żądań trasy, jeśli jest to wymagane do wykonania listu przewozowego.

4.2.1.2. Zamówienia wagonów

Zamówienie wagonów jest zasadniczo podzbiorem informacji zawartych w liście przewozowym. Musi ono być wysłane do RU uczestniczących w łańcuchu transportowym, gdyż może stać się daną wejściową dla doraźnego żądania trasy (rozdział 4.2.2: Żądanie trasy). Treść zamówienia wagonów musi zawierać istotne informacje, które są potrzebne RU do wykonania transportu w czasie jego odpowiedzialności aż do przekazania jej następnemu RU. Dlatego treść ta zależy od pełnionej przez przewoźnika kolejowego roli, jako: początkowego, tranzytowego lub odbiorczego RU (ORU, TRU, DRU).

— Zamówienie wagonów dla początkowego RU (ORU),

— Zamówienie wagonów dla tranzytowego RU (TRU),

— Zamówienie wagonów dla odbiorczego RU (DRU).

Dane, zamieszczane w zamówieniach wagonów w zależności od różnych ról pełnionych przez RU, są wymienione szczegółowo w załączniku A indeks 3, z zaznaczeniem, czy są one obowiązkowe czy opcjonalne. Szczegółowe formaty tych komunikatów są określone w załączniku A indeks 1.

Główną treść zamówień wagonów stanowią:

— dane dotyczące nadawcy i odbiorcy,

— dane dotyczące przebiegu trasy,

— identyfikacja przesyłki,

— dane o wagonach,

— dane o miejscu i czasie.

Wybrane dane spośród danych listu przewozowego muszą być również dostępne dla wszystkich partnerów (np. IM, dysponent…) w łańcuchu transportowym obejmującym klientów. Są to w szczególności następujące dane dla każdego wagonu:

— ciężar ładunku (ciężar brutto ładunku),

— numer CN/HS,

— informacja o niebezpiecznych towarach,

— jednostka transportu.

4.2.2. Żądanie trasy

4.2.2.1. Uwagi wstępne

Planowanie długoterminowe

Trasa pociągu określa żądane, przyjęte i faktyczne dane, które mają być przechowane, dotyczące trasy pociągu oraz charakterystyk pociągu dla każdego odcinka tejże trasy. Poniższy opis przedstawia dane, które muszą być dostępne dla zarządcy infrastruktury. Bardziej szczegółowy opis można znaleźć w załączniku A indeks 4.

Dane te muszą być uaktualnione za każdym razem, gdy nastąpi zmiana.

Głównymi danymi trasy muszą być:

— Identyfikacja trasy pociągu (numer trasy). Trasa może być planowanym wykorzystaniem mocy przepustowej wzdłuż pewnego odcinka drogi bądź faktyczną trasą przebiegu pociągu wzdłuż określonej linii w obrębie drogi przebiegu. Dokładny charakter zależy od procesów, które są używane przez IM.

— Punkt początkowy trasy, który oznacza miejsce, od którego rozpoczyna się trasa wraz z datą i czasem odjazdu pociągu na tejże drodze.

— Punkt docelowy trasy pociągu, który oznacza miejsce, w którym kończy się trasa wraz z datą i czasem, kiedy pociąg ma przybyć do tego punktu docelowego.

— Opis odcinka przejazdu, który określa dane dostarczone przez IM dla każdego przyjętego odcinka trasy przejazdu – od początku do pierwszego pośredniego przystanku, dalszych pośrednich przystanków oraz od końcowego pośredniego przystanku do końca przyjętej trasy przejazdu. Opis ten może zawierać: — pośrednie przystanki lub inne wyznaczone punkty wzdłuż proponowanej trasy wraz z datą i czasem przyjazdu, odjazdu lub przejazdu w tych pośrednich punktach, jak również z kodem działania, który określa działanie, jakie ma być podjęte w tymże pośrednim punkcie drogi, — identyfikację IM odpowiedzialnego za zarządzanie ruchem dla bieżącego odcinka przejazdu oraz identyfikację IM odpowiedzialnego za zarządzanie ruchem dla następnego odcinka przejazdu, — opis urządzeń (systemu sterowania ruchem, systemu radiowego itp.) przenoszonych przez pociąg; muszą one być zgodne z infrastrukturą w celu umożliwienia trakcji i łączności pomiędzy pociągiem a systemem kontroli IM, — dane dotyczące pociągu dla odcinka trasy przejazdu: maks. ciężar, maks. długość, maks. prędkość, maks. nacisk na oś, min. siła hamulca, maks. ciężar na metr, dane dotyczące wyjątkowych pomiarów, identyfikatory niedozwolonych niebezpiecznych towarów, — numer trasy, — dodatkowy czas przebiegu odcinka drogi uwzględniający powrót do sprawności, problemy związane z trasą itp.

Umowa o wykonanie trasy: Przed uruchomieniem pociągu odcinek trasy przejazdu musi zostać uaktualniony i uzupełniony faktycznymi wartościami. Tryb wykonania jest niezależny od trybu planowania.

Pilne żądanie trasy

Wskutek wyjątkowych okoliczności podczas jazdy pociągu lub z powodu pilnych zapotrzebowań transportowych przewoźnik kolejowy musi mieć możliwość otrzymania doraźnej trasy w sieci.

W pierwszym przypadku muszą zostać rozpoczęte natychmiastowe działania, które pozwolą na poznanie rzeczywistego składu pociągu w oparciu o wykaz zestawienia pociągu.

W drugim przypadku przewoźnik kolejowy musi dostarczyć zarządcy infrastruktury wszystkie niezbędne dane o tym, kiedy i dokąd wymagana jest jazda pociągu wraz z fizycznymi charakterystykami, o ile oddziaływają one z infrastrukturą. Dane te są podawane głównie w uzupełnionym liście przewozowym bądź w zamówieniach wagonów.

Uzgodnienie trasy ruchu pociągu w trybie natychmiastowym opiera się na dialogu pomiędzy RU i IM. W dialogu tym biorą udział wszyscy RU i IM uczestniczący w przemieszczaniu pociągu po żądanej trasie, lecz być może o różnym wkładzie w proces znajdywania trasy. Zgodnie z dyrektywą 2001/14/WE, art. 13, dla transportu towarowego działającego w infrastrukturach kilku IM można głównie wyróżnić dwa ogólne ważne różne scenariusze (patrz również: załącznik A indeks 5 rozdział 1.3).

— Scenariusz A: RU kontaktuje się ze wszystkimi uczestniczącymi IM bezpośrednio (przypadek A) lub poprzez OSS (przypadek B) w celu zorganizowania tras dla całego przejazdu. W tym przypadku RU musi również prowadzić pociąg w ciągu całego przejazdu zgodnie z art. 13 dyrektywy 2001/14/WE.

— Scenariusz B: Każdy RU uczestniczący w przejeździe transportowym kontaktuje się z miejscowymi IM bezpośrednio lub poprzez OSS, żądając trasy dla odcinka przejazdu, po którym prowadzi pociąg.

Uwaga: Jak już wspomniano w rozdziale 2 ( ), w trybie wykonania IM zawsze komunikuje się z RU, który zarezerwował trasę. Dlatego „własność trasy” jest ważna dla wymiany komunikatów podczas prowadzenia pociągu.

W obydwóch scenariuszach procedura rezerwowania trasy w trybie natychmiastowym odbywa się na podstawie dialogu pomiędzy RU i uczestniczącym IM, jak opisano na następnej stronie.

W poniższej tabeli przedstawiono komunikaty używane w dialogu dla żądania trasy:

Tabela 1

Żądanie trasy

Komunikat Objaśnienie Komunikaty używane w dialogu dla żądania trasy Żądanie trasy RU do uczestniczących IM, ten komunikat musi być wysłany w wypadku żądania trasy w trybie natychmiastowym. Dane o trasie Ten komunikat musi być wysłany od IM do RU z potwierdzeniem danych o trasie w odpowiedzi na „Żądanie trasy” przez RU, ewentualnie ze zmienionymi wartościami lub, jeśli IM nie może obsłużyć żądania trasy, z podaniem „Brak dostępnych alternatyw”. Trasa potwierdzona Komunikat ten musi być wysłany od RU do IM w celu akceptacji „Danych o trasie” otrzymanych od IM w odpowiedzi na pierwotne żądanie RU. Odmowa danych o trasie Komunikat ten musi być wysłany od RU do IM w razie nieakceptowania „Danych o trasie” otrzymanych od IM w odpowiedzi na pierwotne żądanie RU, jeśli są zmienione wartości, których RU nie może zaakceptować.

Dialog ten kończy RU przy użyciu komunikatu „Trasa potwierdzona” lub przez usunięcie żądania trasy (komunikat „Żądanie trasy” ze statusem „Usunięcie”, patrz: rozdział 4.2: Specyfikacje funkcjonalne i techniczne podsystemu, Ogólne uwagi na temat struktury komunikatów). Komunikat „Odmowa danych o trasie” od RU musi zawsze być serwowany z nowym komunikatem „Dane o trasie”. Jeżeli IM nie może spełnić żądania trasy za pomocą nowej propozycji w komunikacie „Dane o trasie”, musi on wysłać komunikat „Dane o trasie” z podaniem „Brak dostępnych alternatyw”, co kończy dialog z IM.

Bez względu na to, czy trasa była zarezerwowana w planowaniu długoterminowym czy w trybie natychmiastowym, RU musi zawsze mieć możliwość anulowania zarezerwowanej trasy. W celu anulowania zarezerwowanej trasy musi być wysłany następujący komunikat.

Tabela 2

Anulowanie trasy przez RU

Komunikat Objaśnienie Komunikat anulowania zarezerwowanej trasy przez RU Trasa anulowana Zawiadomienie od RU do IM o anulowaniu poprzednio zarezerwowanej trasy lub jej części.

Na podstawie uzgodnienia trasy RU może oczekiwać, że zarezerwowana trasa jest również dostępna. Dlatego jeżeli coś wydarzy się i zarezerwowana trasa nie jest już dostępna, IM musi powiadomić RU, jak tylko dowie się o tym fakcie. Powodem tego może być na przykład zakłócenie na trasie. Może to zdarzyć się w dowolnym czasie pomiędzy momentem zakontraktowania trasy a odjazdem pociągu. IM jest zobowiązany przesłać alternatywną propozycję wraz ze wskazaniem „Trasa niedostępna”. Jeśli nie jest to możliwe, IM musi wysłać propozycję możliwie jak najszybciej. Wraz z komunikatem „Trasa niedostępna” rozpoczyna się dialog w sprawie uzgodnienia nowej trasy, zainicjowany przez IM.

Komunikaty używane w dialogu w sprawie anulowania przez IM zarezerwowanej trasy.

Tabela 3

Anulowanie trasy przez IM

Komunikat Objaśnienie Komunikaty używane w procesie anulowania trasy zainicjowanym przez IM Trasa niedostępna Zawiadomienie wysłane od IM do RU, że zarezerwowana trasa nie jest dostępna. Dane o trasie Komunikat ten musi wysłać IM do RU, proponując alternatywną trasę po zawiadomieniu wysłanym od IM do RU, że zarezerwowana trasa nie jest dostępna. Trasa potwierdzona Komunikat ten musi wysłać RU do IM w celu akceptacji trasy zaproponowanej w komunikacie „Trasa niedostępna”. Odmowa danych o trasie Komunikat ten musi wysłać RU do IM, gdy nie akceptuje propozycji otrzymanej od IM w komunikacie „Trasa niedostępna”. W tym przypadku IM musi wysłać nową propozycję. Dialog ten kończy RU komunikatem „Trasa anulowana” związanym z komunikatem IM „Trasa niedostępna”.

Ogólnie, jeżeli odbiorca żądania lub zapytania nie może odpowiedzieć w czasie rzeczywistym, to musi powiadomić twórcę komunikatu (na przykład gdy komunikat „Dane o trasie” jako odpowiedź na „Żądanie trasy” nie może być wysłany natychmiast). Należy tego dokonać używając następującego komunikatu:

Tabela 4

Potwierdzenie otrzymania

Komunikat Objaśnienie Ten komunikat jest ważny ogólnie Potwierdzenie otrzymania Komunikat ten musi zostać wysłany od odbiorcy komunikatu do twórcy komunikatu, gdy wymagana odpowiedź nie może być udostępniona w przedziale czasu określonym w rozdziale 4.4 (Zasady operacyjne) sekcja „Punktualność”.

Komunikaty te opisane są przez wymienienie głównych punktów w następujących rozdziałach. Szczegółowe formaty są określone w załączniku A indeks 1. Logiczna kolejność tych komunikatów jest przedstawiona w schematach w załączniku A indeks 5 rozdziały 2.1-2.3.

4.2.2.2. Komunikat „Żądanie trasy”

Jest to żądanie skierowane od RU do IM w sprawie trasy pociągu. Żądanie takie musi zawierać:

— punkt początkowy trasy: miejsce, z którego rozpocznie się proponowana trasa,

— datę/czas odjazdu trasy: datę/czas, na kiedy trasa jest żądana,

— punkt docelowy trasy: miejsce docelowe pociągu dla żądanej trasy,

— datę/czas przyjazdu do punktu docelowego trasy: datę/czas, kiedy proponowany pociąg ma przybyć do swojego miejsca docelowego,

— odcinek żądanego przejazdu: — pośrednie przystanki lub inne wyznaczone punkty na proponowanej trasie wraz z datą/czasem, kiedy proponowany pociąg ma przybyć do pośredniego punktu oraz datą/czasem, kiedy pociąg ma odjechać od pośredniego punktu. Pusty wpis oznacza, że pociąg nie zatrzyma się w tym punkcie, — dostępne urządzenia w pociągu: typ trakcji, system kontroli jazdy pociągu, w tym pokładowe urządzenia radiowe, — ciężar pociągu, — długość pociągu, — układ hamulcowy, który ma być używany, oraz charakterystyka hamowania, — maksymalna prędkość pociągu, — maksymalny nacisk na oś pociągu, — maksymalny ciężar na metr, — informacje dotyczące wyjątkowego pomiaru, — numery UN/RID dotyczące ewentualnych niebezpiecznych towarów, — określenia działania, które ma być podjęte w każdym pośrednim punkcie drogi, — odpowiedzialny RU: identyfikacja RU odpowiedzialnego za pociąg dla bieżącego odcinka przejazdu, — odpowiedzialny IM: identyfikacja IM odpowiedzialnego za pociąg dla bieżącego odcinka przejazdu, — następny odpowiedzialny IM: identyfikacja IM odpowiedzialnego za pociąg dla (ewentualnego) następnego odcinka przejazdu.

W celu uzyskania wsparcia informacyjnego dla sformułowania żądania trasy RU może sprawdzić w oświadczeniu w sprawie sieci, czy dane o rozważanym pociągu są zgodne z infrastrukturą. Należy również wziąć pod uwagę takie dane, jak informacje o niebezpiecznych towarach.

Dysponenci wagonów muszą dać wszystkim RU dostęp do danych technicznych o wagonach.

RU muszą sami zapewnić dostęp do plików informacyjnych, np. do pliku z informacjami o niebezpiecznych towarach, jeśli jest to wymagane.

4.2.2.3. Komunikat „Dane o trasie”

Komunikat ten jest odpowiedzią IM na „Żądanie trasy” otrzymane od RU. W wypadku gdy IM nie może spełnić żądania trasy, musi wysłać ten komunikat z zaznaczeniem „Brak dostępnych alternatyw”. W innym wypadku musi on odpowiedzieć na żądanie RU przez odesłanie numeru trasy wraz z tymi samymi danymi, co w żądaniu o trasę pociągu, lecz ewentualnie ze zmienionymi wartościami.

W wypadku zaproponowanej przez IM alternatywy muszą być wysłane następujące dane:

— nowy numer trasy,

— punkt początkowy trasy: miejsce, z którego rozpocznie się proponowana trasa,

— datę/czas odjazdu trasy: datę/czas, na kiedy trasa jest proponowana,

— punkt docelowy trasy: Miejsce docelowe pociągu dla proponowanej trasy,

— datę/czas przyjazdu do punktu docelowego trasy: Datę/czas, kiedy pociąg ma przybyć do swojego miejsca docelowego,

— odcinek zmodyfikowanej trasy przejazdu: — pośrednie przystanki lub inne wyznaczone punkty na proponowanej trasie wraz z datą/czasem, kiedy proponowany pociąg ma przybyć do pośredniego punktu oraz datą/czasem, kiedy pociąg ma odjechać od pośredniego punktu. Pusty wpis oznacza, że pociąg nie zatrzyma się w tym punkcie, — żądane urządzenia w pociągu: Typ trakcji, system kontroli jazdy pociągu, w tym pokładowe urządzenia radiowe, — ciężar pociągu, — długość pociągu, — układ hamulcowy, który ma być używany oraz charakterystyka hamowania, — maksymalna prędkość pociągu, — maksymalny nacisk na oś pociągu, — maksymalny ciężar na metr, — informacje dotyczące wyjątkowego pomiaru, — numery UN/RID dotyczące ewentualnych niebezpiecznych towarów, — określenia działania, które ma być podjęte w każdym pośrednim punkcie drogi, — odpowiedzialny RU: Identyfikacja RU odpowiedzialnego za pociąg dla bieżącego odcinka przejazdu, — odpowiedzialny IM: Identyfikacja IM odpowiedzialnego za pociąg dla bieżącego odcinka przejazdu, — następny odpowiedzialny IM: Identyfikacja IM odpowiedzialnego za pociąg dla (ewentualnego) następnego odcinka przejazdu.

4.2.2.4. Komunikat „Trasa potwierdzona”

Komunikat ten musi być wysłany od RU do IM z akceptacją zaproponowanej trasy w odpowiedzi na pierwotne żądanie RU. Za pomocą tego komunikatu trasa zostaje zarezerwowana. Główna treść komunikatu zawiera:

— numer trasy w celu identyfikacji trasy,

— punkt początkowy trasy: miejsce, z którego pociąg ma odjechać,

— datę/czas: Datę/czas, na kiedy trasa jest żądana,

— punkt docelowy trasy: miejsce docelowe pociągu dla żądanej trasy,

— datę/czas przyjazdu do punktu docelowego trasy: datę/czas, kiedy proponowany pociąg ma przybyć do swojego miejsca docelowego,

— znaczy, że RU zaakceptował proponowaną trasę.

4.2.2.5. Komunikat „Odmowa danych o trasie”

W wypadku odmowy proponowanej trasy podanej przez IM w komunikacie „Dane o trasie” RU musi wysłać ten komunikat do IM, powiadamiając go, że nie akceptuje proponowanej trasy podanej w komunikacie „Dane o trasie”. Dane pierwotne zawierają:

— numer trasy w celu identyfikacji trasy,

— oznaczają odmowę danych o trasie.

Jako dodatkowe informacje mogą być przesłane następujące dane:

— punkt początkowy trasy: miejsce, z którego pociąg odjedzie,

— data/czas: data/czas, na które trasa jest żądana,

— punkt docelowy trasy: miejsce docelowe pociągu dla żądanej trasy,

— data/czas przyjazdu do punktu docelowego trasy: data/czas, kiedy proponowany pociąg ma przybyć do swojego miejsca docelowego.

4.2.2.6. Komunikat „Trasa anulowana”

Jest to wysłane przez RU powiadomienie o anulowaniu poprzednio zarezerwowanej trasy. Wraz ze wskaźnikiem anulowania (odpowiada typowi komunikatu) musi być wysłany numer trasy w celu jednoznacznej identyfikacji trasy. Stosuje się to do rezerwowania trasy w trybie planowania i natychmiastowego powiadomienia:

— numer trasy w celu identyfikacji trasy,

— numer pociągu (jeśli jest już znany IM),

— oznacza anulowanie zarezerwowanej trasy pociągu.

Jako dodatkowe informacje mogą być wysłane następujące dane:

— punkt początkowy trasy: miejsce, z którego pociąg odjedzie,

— data/czas: data/czas, na które trasa jest żądana,

— punkt docelowy trasy: miejsce docelowe pociągu dla żądanej trasy,

— data/czas przyjazdu do punktu docelowego trasy: data/czas, kiedy proponowany pociąg ma przybyć do swojego miejsca docelowego.

4.2.2.7. Komunikat „Trasa niedostępna”

IM musi powiadomić RU, jak tylko dowie się, że trasa pociągu nie jest dostępna. Komunikat „Trasa pociągu niedostępna” może zostać wysłany w dowolnym czasie od chwili zakontraktowania trasy pociągu do odjazdu pociągu. Powodem tego komunikatu może być np. zakłócenie na trasie. Główna treść komunikatu zawiera:

— numer trasy, która nie jest dostępna,

— numer pociągu przewidzianego na anulowaną trasę (jeśli jest już znany IM),

— punkt początkowy trasy wraz z datą i czasem, na kiedy trasa została zarezerwowana,

— punkt docelowy trasy wraz z datą i czasem, kiedy pociąg ma przybyć do punktu swojego przeznaczenia,

— wskazanie niedostępności trasy pociągu,

— podanie przyczyny.

Wraz z tym komunikatem IM musi możliwie jak najwcześniej wysłać alternatywną propozycję bez dalszego żądania ze strony RU. Dokonuje się tego za pomocą komunikatu „Dane o trasie” związanego z tymże komunikatem „Trasa niedostępna”.

4.2.2.8. Komunikat „Potwierdzenie odbioru”

Potwierdzenie to musi być wysłane od odbiorcy komunikatu do twórcy komunikatu, gdy żądana odpowiedź nie może udostępniona w ramach czasowych określonych w rozdziale 4.4 (Zasady operacyjne). Komunikat ten musi mieć identyfikator, do którego odnosi się (wpisy w związanym komunikacie, patrz: rozdział 4.2: podsystemu, Ogólne uwagi na temat struktury komunikatów) oraz wskazanie: (Poziom aplikacji)

— Potwierdzenie komunikatu: podaje, że odbiorca otrzymał komunikat i będzie działał na jego podstawie, gdy będzie to niezbędne.

4.2.3. Przygotowanie pociągu

4.2.3.1. Uwagi ogólne

W niniejszej sekcji określono komunikaty, które muszą być wymieniane w fazie przygotowania pociągu do czasu rozpoczęcia jazdy pociągu. Komunikaty te przedstawiono w tabeli 5 poniżej.

W celu przygotowania pociągu RU musi mieć dostęp do powiadomień o ograniczeniach w infrastrukturze („Źródłowe bazy danych taboru kolejowego”, rozdział 4.2.11.3: Źródłowe bazy danych taboru kolejowego), do pliku z informacjami o niebezpiecznych towarach oraz do bieżącego, uaktualnionego stanu informacji o wagonach (rozdział 4.2.12.2: Inne bazy danych: Operacyjna baza danych wagonów i jednostek intermodalnych). Dotyczy to wszystkich wagonów w pociągu. Na koniec RU musi wysłać dane o składzie pociągu do następnych RU. Komunikat ten musi RU wysłać również do IM, u których zarezerwował część trasy, jeśli jest to żądane przez TSI „Ruch kolejowy” kolei konwencjonalnej lub przez umowy pomiędzy RU i IM.

Jeżeli skład pociągu ulegnie zmianie w pewnym miejscu, komunikat ten musi zostać wymieniony jeszcze raz z informacjami uaktualnionymi przez odpowiedzialnego RU.

W każdym punkcie, np. w punkcie początkowym i w punkcie wymiany, gdzie odpowiedzialność po stronie RU zmienia się, obowiązkowy jest dialog procedury startowej pomiędzy IM i RU „Pociąg gotowy – Informacja o jeździe pociągu”.

Komunikaty używane w tym dialogu procedury startowej są następujące:

Tabela 5

Przygotowanie pociągu

Komunikat Objaśnienie Skład pociągu RU do IM, komunikat ten musi być wysłany zgodnie z powyższym opisem. W wypadku, gdy IM otrzymał komunikat o składzie pociągu wysłany obowiązkowo przez RU, IM może wysłać: Pociąg zaakceptowany IM do RU: Komunikat jest opcjonalny, jeśli nic innego nie zostało uzgodnione pomiędzy IM i RU. Przygotowywanie pociągu może być zakończone. Pociąg nie jest odpowiedni IM do RU: Komunikat ten może być wysłany przez IM, jeśli zostanie to przez niego wykryte. Możliwości dla RU: zmienić skład pociągu lub anulować trasę pociągu i zażądać nowej trasy. Pociąg gotowy RU do IM, komunikat ten musi być wysłany. Położenie pociągu IM do RU, określa dokładnie, gdzie i kiedy pociąg musi stawić się w sieci. Komunikat ten może być wysłany, w zależności od krajowych zasad. Pociąg na starcie RU do IM, komunikat ten może być wysłany, aby wskazać, że pociąg rozpoczął swoją podróż, jako odpowiedź na komunikat: „Położenie pociągu”. Komunikat ten może być wysłany, w zależności od krajowych zasad. Informacja o jeździe pociągu IM do RU, komunikat ten musi być wysłany, aby wskazać, że pociąg przybył na infrastrukturę.

Komunikaty te są opisane poprzez wymienienie głównych punktów w następujących rozdziałach. Szczegółowe formaty są określone w załączniku A indeks 1. Logiczną kolejność przedstawiono w załączniku A indeks 5 rozdział 3.

Uwaga: Podczas przygotowywania pociągu może również wystąpić komunikat „Trasa pociągu niedostępna”, gdyż komunikat ten może być wysłany w dowolnym czasie pomiędzy momentem zakontraktowania pociągu a odjazdem pociągu. Procedura służąca do tego celu jest opisana w rozdziale 4.2.2 („Żądanie trasy”).

4.2.3.2. Komunikat „Skład pociągu”

Komunikat ten musi być wysłany od RU do następnego RU z określeniem składu pociągu. Komunikat ten musi również być wysłany od RU do IM, gdy jest to żądane przez TSI „Ruch kolejowy” kolei konwencjonalnej lub przez umowę pomiędzy IM a RU. Za każdym razem gdy nastąpi zmiana składu podczas przejazdu pociągu, odpowiedzialny RU musi uaktualnić ten komunikat dla wszystkich uczestniczących stron.

Danymi, które muszą zostać przesłane i być dostępne są:

— numer pociągu i numer trasy w celu identyfikacji trasy,

— punkt początkowy trasy oraz data i czas, na które trasa była żądana,

— punkt docelowy trasy oraz data i czas, kiedy proponowany pociąg ma przybyć do swojego punktu docelowego,

— identyfikacja lokomotyw(y) i położenie lokomotyw(y) w pociągu,

— długość pociągu, ciężar pociągu, maksymalna prędkość pociągu,

— skład pociągu z ciągiem identyfikatorów pojazdów,

— system kontroli jazdy pociągu, w tym pokładowe urządzenia radiowe,

— informacje dotyczące wyjątkowego pomiaru,

— numery UN/RID niebezpiecznych towarów,

— wskazanie, czy będzie przewożony inwentarz żywy i ludzie (poza załogą pociągu),

— układ hamulcowy, który ma być używany,

— dane o wagonach.

Po otrzymaniu składu pociągu IM może zweryfikować zapisy na podstawie zakontraktowanej trasy, jeżeli umowa pomiędzy IM i RU wyraźnie pozwala na to. W takim wypadku IM musi mieć łatwy dostęp do informacji o możliwych ograniczeniach w odnośnej infrastrukturze, do technicznych danych o wagonach (rozdział 4.2.11.3: Źródłowe bazy danych taboru kolejowego), do pliku z informacjami o niebezpiecznych towarach oraz do bieżącego, uaktualnionego stanu informacji o wagonach (rozdział 4.2.12.2: Inne bazy danych, Baza danych wagonów i jednostek intermodalnych). Odnosi się to do wszystkich wagonów w pociągu. W takim wypadku również IM, który zarządza swoimi trasami pociągów i utrzymuje aktualny status informacji o trasach, musi dodać dane o składzie pociągu do danych o trasie i pociągu wymienionych w rozdziale 4.2.2.1 (Żądanie trasy, Uwagi wstępne).

4.2.3.3. Komunikat „Pociąg zaakceptowany”

W zależności od porozumienia umownego pomiędzy IM i RU oraz od wymagań przepisów IM może również powiadomić RU, czy skład pociągu jest akceptowalny dla zarezerwowanej trasy. Jest to dokonywane przy pomocy tego komunikatu.

Główna treść tego komunikatu zawiera:

— numer pociągu i trasy,

— punkt początkowy trasy wraz z datą i czasem, na kiedy trasa była żądana,

— punkt docelowy trasy wraz z datą i czasem, kiedy proponowany pociąg ma przybyć do swojego punktu docelowego,

— wskazanie, że IM zaakceptował skład pociągu jako odpowiedni do uzgodnionej trasy.

4.2.3.4. Komunikat „Pociąg nie jest odpowiedni”

Jeżeli pociąg nie jest odpowiedni do uprzednio uzgodnionej trasy, IM może powiadomić RU przy pomocy tego komunikatu. W tym wypadku RU musi ponownie sprawdzić skład pociągu. Główna treść tego komunikatu zawiera:

— numer pociągu i trasy,

— punkt początkowy trasy wraz z datą i czasem, na kiedy trasa była żądana,

— punkt docelowy trasy wraz z datą i czasem, kiedy proponowany pociąg ma przybyć do swojego punktu docelowego,

— wskazanie nieodpowiedniości, które oznacza, że dany pociąg nie odpowiada przydzielonej trasie i dlatego nie może jechać,

— podanie przyczyny.

4.2.3.5. Komunikat „Pociąg gotowy”

Komunikat ten musi być wysłany od RU do IM z podaniem, że dany pociąg jest gotowy do wejścia do sieci. Główna treść tego komunikatu zawiera:

— numer pociągu i trasy,

— punkt początkowy trasy wraz z datą i czasem, na kiedy trasa była żądana,

— punkt docelowy trasy wraz z datą i czasem, kiedy proponowany pociąg ma przybyć do swojego punktu docelowego,

— wskazanie gotowości pociągu, które oznacza, że dany pociąg został przygotowany i jest gotowy do jazdy,

— identyfikator kontaktu kontrolnego dla wszystkich komunikacji pomiędzy pokładem a stacją kontrolną,

— jeżeli porozumienie umowne pomiędzy RU i IM nie wymaga wymiany komunikatów „Lokalizacja pociągu/Pociąg na starcie”, w komunikacie tym muszą być określone data i czas rozpoczęcia jazdy pociągu, które informują IM o przewidywanym dniu/godzinie, kiedy pociąg stawi się w sieci. W wypadku wymaganej wymiany komunikatów „Lokalizacja pociągu/Pociąg na starcie” ten element danych nie musi być wysyłany.

4.2.3.6. Komunikat „Położenie pociągu”

Komunikat ten może być wysłany od IM do RU z dokładnym określeniem, kiedy i gdzie pociąg powinien stawić się w sieci, jako odpowiedź na komunikat gotowości pociągu. Przesłanie tego komunikatu zależy od ustalenia umownego pomiędzy RU a IM. W wypadku gdy potrzebne jest przesłanie, główna treść tego komunikatu zawiera:

— numer pociągu i trasy,

— punkt początkowy trasy wraz z datą i czasem, na kiedy trasa była żądana,

— punkt docelowy trasy wraz z datą i czasem, kiedy proponowany pociąg ma przybyć do swojego punktu docelowego,

— identyfikację toru, która podaje RU identyfikator toru, na którym pociąg powinien stawić się w sieci,

— datę/czas przejazdu, która informuje RU o dokładnym dniu/godzinie, kiedy pociąg powinien stawić się w sieci,

— identyfikator kontaktu kontrolnego.

4.2.3.7. Komunikat „Pociąg na starcie”

Komunikat ten może być wysłany od RU do IM po otrzymaniu od IM komunikatu „Położenie pociągu” w celu wskazania, że pociąg rozpoczął swoją podróż. Komunikat ten musi posiadać identyfikator, do którego się odnosi oraz wskazanie:

— startu pociągu: daty/czasu, kiedy pociąg faktycznie rozpoczął podróż.

4.2.3.8. Informacja o jeździe pociągu

Gdy tylko pociąg stawi się w infrastrukturze IM, co oznacza, że opuścił on stację odjazdową, IM wysyła ten komunikat do RU, który zarezerwował trasę. Komunikat ten jest opisany w rozdziale 4.2.4 (Prognoza jazdy pociągu).

4.2.4. Prognoza jazdy pociągu

4.2.4.1. Uwagi ogólne

W niniejszej sekcji określono komunikaty, które muszą być wymieniane podczas normalnej jazdy pociągu bez jakichkolwiek zakłóceń.

Stosownymi komunikatami są:

Prognoza jazdy pociągu,

Informacja o jeździe pociągu.

Ta wymiana informacji pomiędzy RU i IM odbywa się zawsze pomiędzy zarządzającym IM a RU, który zarezerwował trasę, po której pociąg faktycznie porusza się. W wypadku otwartego dostępu, który oznacza, że trasy dla pełnego przejazdu są zarezerwowane przez jednego RU (ten RU również prowadzi pociąg podczas całego przejazdu), wszystkie komunikaty są wysyłane do tego RU. Tak samo jest w wypadku, gdy trasy dla przejazdu są zarezerwowane przez jednego RU za pośrednictwem OSS.

Do dalszych rozważań rozróżnione zostaną następujące scenariusze przy uwzględnieniu różnych zależności komunikacyjnych pomiędzy RU i IM zgodnie ze scenariuszami rezerwacji trasy podanymi w rozdziale 4.2.2.1 (Żądanie trasy, Wstępne uwagi, scenariusz A, B):

— Pociąg zbliżający się do punktu przekazania pomiędzy IM n1 a jego sąsiadem IM n2

Zakłada się, że punkt przekazania pomiędzy IM nie jest także punktem wymiany (tylko scenariusz B) ani punktem obsługi. Zatem punkt przekazania jest punktem na zarezerwowanych trasach jednego RU i RU wysłał już informację o składzie pociągu do IM n2, przesyłając jednocześnie ten komunikat do IM n1.

IM n1, po odjeździe z punktu odjazdu (5), musi wysłać komunikat prognozy jazdy pociągu do IM n2 z szacowanym czasem przekazania (ETH). Komunikat tej zostaje jednocześnie wysłany do RU.

Gdy pociąg opuści infrastrukturę należącą do IM n1 w punkcie przekazania, wówczas tenże IM wysyła do RU, który zakontraktował jego trasę, informację o jeździe pociągu z faktycznym czasem przekazania w tym punkcie.

Gdy pociąg przybędzie do infrastruktury należącej do IM n2 w punkcie przekazania, wówczas tenże IM wysyła do RU, który zakontraktował jego trasę informację o jeździe pociągu z faktycznym czasem przekazania w tym punkcie.

— Pociąg zbliżający się do punktu wymiany pomiędzy RU 1 a następnym RU 2 (tylko scenariusz B)

W umowie o trasie punkt wymiany musi być zawsze określony jako punkt raportowania. (TETA w punktach raportowania będą generowane przez IM, tak jak określono w ich umowach z RU).

Dla tego punktu z chwilą opuszczenia przez pociąg poprzedniego punktu raportowania odpowiedzialny IM wysyła do RU, który zakontraktował u niego trasę (np. RU 1), komunikat prognozy jazdy pociągu wraz z TETA dla tego punktu wymiany. RU 1 przekazuje ten komunikat do następnego RU (np. RU 2), który ma przejąć pociąg. Ponadto, komunikat ten zostaje również przesłany do wiodącego RU (LRU) dla transportu, jeśli taki istnieje i jeśli jest to określone w umowie o współpracy pomiędzy obydwoma RU.

Jeżeli punkt wymiany jest również punktem przekazania pomiędzy np. IM n1 i IM n2, to IM n1 wysyła do IM n2 komunikat prognozy jazdy pociągu już po odjeździe z punktu odjazdu lub z poprzedniego punktu wymiany wraz z szacowanym czasem przekazania (ETH). Komunikat ten zostaje również wysłany do RU, który zakontraktował trasę, np. RU 1. Dla RU ETH jest równa TETA w punkcie wymiany. RU 1 przekazuje ten komunikat do swojego sąsiada RU 2 oraz do LRU dla transportu, jeśli taki istnieje i jeśli jest to określone w umowie o współpracy pomiędzy obydwoma RU.

Gdy pociąg przybędzie do punktu wymiany, IM musi wysłać do RU, który zakontraktował jego trasę, na przykład RU 1, informację o jeździe pociągu wraz z faktycznym czasem przybycia do tego punktu.

Zanim pociąg opuści punkt wymiany, RU 2 musi wysłać do IM, który przydzielił trasę, komunikat o nowym składzie pociągu i wykonać procedurę odjazdu opisaną w rozdziale 4.2.3 (Przygotowanie pociągu).

— Pociąg zbliżający się do punktu obsługi RU (scenariusz A)

Punkt obsługi musi zawsze być określony w umowie o trasie jako punkt raportowania.

Dla tego punktu odpowiedzialny IM musi wysłać komunikat prognozy jazdy pociągu wraz z TETA, tylko jeżeli jest to określone w umowie pomiędzy IM i RU.

Lecz jeżeli punkt obsługi jest również punktem przekazania pomiędzy, na przykład, IM n1 i IM n2, to IM n1 musi wysłać do IM n2 komunikat prognozy jazdy pociągu po odjeździe z punktu odjazdu z poprzedniej wymiany wraz z szacowanym czasem przekazania (ETH). Komunikat ten zostaje również wysłany do RU. Dla RU ETH jest równa TETA w punkcie obsługi.

Gdy pociąg przybędzie do punktu obsługi, IM musi wysłać do RU informację o jeździe pociągu wraz z faktycznym czasem przybycia do tego punktu point.

Zanim pociąg opuści punkt obsługi RU i IM muszą wykonać procedurę odjazdu określoną w rozdziale 4.2.3 (Przygotowanie pociągu).

— Przyjazd pociągu do punktu docelowego

Gdy pociąg przybędzie do swojego punktu docelowego, odpowiedzialny IM wysyła do RU, który zakontraktował trasę, komunikat „Informacja o jeździe pociągu” wraz z faktycznym czasem przyjazdu.

Uwaga: W umowie o trasę mogą być także określone inne miejsca, dla których żądana jest prognoza jazdy pociągu z TETA oraz komunikaty „Informacja o jeździe pociągu” wraz z faktycznym czasem. Dla tych punktów odpowiedzialny IM wysyła te komunikaty, jak określono w umowie. Dalszą ocenę i przetwarzanie dostarczonych ETH i TETA opisano w rozdziałach od 4.2.7 (ETI/ETA przesyłki) do 4.2.9 (Raportowanie o wymianie).

W następujących rozdziałach komunikaty „Prognoza jazdy pociągu” i „Informacja o jeździe pociągu” są opisane jedynie przez wymienienie głównej treści. Szczegółowe formaty określone są w załączniku A indeks 1. Logiczną kolejność tego komunikatu przedstawiono w załączniku A indeks 5 rozdział 4 z uwagą, że odnośnie relacji komunikacyjnej pomiędzy RU i IM dla jazdy pociągu dwa scenariusze żądania trasy A (przypadek A) i A (przypadek B) (rozdział 4.2.2.1: Żądanie trasy, Wstępne uwagi) są identyczne, ponieważ w obu przypadkach IM znają tylko jednego RU, np. RU 1, który obsługuje całą trasę i jest ponadto odpowiedzialny za nowy skład pociągu w punktach obsługi.

4.2.4.2. Komunikat „Prognoza jazdy pociągu”

Komunikat ten musi być wydany przez IM for dla punktów przekazania, punktów wymiany oraz dla punktu docelowego pociągu, jak opisano w rozdziale 4.2.4.1 (Uwagi ogólne).

Ponadto komunikat ten musi być wysłany przez IM do RU dla innych punktów raportowania zgodnie z umowami RU/IM (np. dla punktów obsługi).

Głównymi elementami danych są:

— numer trasy i numer pociągu,

— planowa data i czas odjazdu w miejscu IM (lub planowy czas przekazania następnemu IM),

— identyfikacja punktu raportowania,

— prognozowane data/czas w punkcie raportowania.

4.2.4.3. Komunikat „Informacja o jeździe pociągu”

Komunikat ten musi być wydany po:

— 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 uzgodnionych na podstawie umowy (np. punktów obsługi). Głównymi elementami danych są: — numer trasy i numer pociągu, — planowa data/czas odjazdu w miejscu IM, — identyfikacja ostatniego punktu raportowania, — faktyczny czas w punkcie raportowania, — status punktu raportowania pociągu (przyjazd, odjazd, przejazd, nieokreślony, odjazd z punktu początkowego, przyjazd do punktu docelowego), — tor przyjazdu do miejsca, — tor odjazdu z miejsca, — minuty odchylenia czasu delta od zarezerwowanego planowego czasu, — aktualny rozkład jazdy w wypadku jego wielokrotnej zmiany, — dla każdego odchylenia od zarezerwowanego planowego czasu w tymże miejscu raportowania: — kod powodu (może być wiele powodów), — czas odchylenia dla tego kodu powodu (może być wysłanych wiele powodów na punkt raportowania), — można dodać dowolny tekst dotyczący odchylenia.

4.2.5. Informacja o zakłóceniu służby

4.2.5.1. Uwagi ogólne

Gdy RU dowie się o zakłóceniu służby podczas operacji prowadzenia pociągu, za którą jest odpowiedzialny, musi niezwłocznie powiadomić zainteresowanego IM (brak komunikatu informatycznego, np. ustnie przez maszynistę). Jeśli to konieczne, RU uaktualnia „Operacyjną bazę danych wagonów i jednostek intermodalnych”. Jeśli to niezbędne, IM uaktualnia dane o infrastrukturze w „Bazie danych powiadomień o ograniczeniach w infrastrukturze” oraz/lub bazie danych tras bądź pociągów.

Jeżeli opóźnienie przekracza x minut (wartość ta musi być określona w umowie pomiędzy RU i IM), zainteresowany IM musi wysłać do RU komunikat o prognozie jazdy pociągu odnoszący się do następnego punktu raportowania.

Jeżeli pociąg jest anulowany, IM wysyła komunikat o zakłóceniu jazdy pociągu określony poniżej.

W przypadkach wyjątkowych, gdy RU lub IM nie jest zdolny uruchomienia pociągu o prognozowanym czasie, musi zostać wynegocjowana nowa trasa zgodnie z rozdziałem 4.2.2 (Żądanie trasy).

4.2.5.2. Komunikat „Zakłócona jazda pociągu”

Jeżeli pociąg jest anulowany, komunikat ten zostaje wysyłany przez IM do sąsiedniego IM oraz do RU, który zakontraktował trasę.

Głównymi elementami tego komunikatu są:

— numer trasy i pociągu,

— identyfikacja miejsca,

— planowa data i czas odjazdu w tym miejscu,

— powód zakłócenia,

— opis zakłócenia.

4.2.6. Położenie pociągu

4.2.6.1. Wstęp

W niniejszej sekcji określono możliwości śledzenia w celu uzyskania informacji o położeniu pociągu. RU może w dowolnym czasie wysłać do IM zapytanie o jego pociągi. RU może zapytać o:

— jazdę pociągu (ostatnio zarejestrowane położenie, opóźnienia, powody opóźnień),

— osiągi pociągu (opóźnienia, powody opóźnień, miejsca opóźnień),

— wszystkie identyfikatory określonego pociągu,

— prognozę pociągu w określonym miejscu,

— wszystkie prognozy jazdy pociągu w określonym miejscu.

Dostęp do tych informacji musi być niezależny od relacji komunikacyjnej RU/IM podczas jazdy pociągu, co oznacza, że RU musi mieć pojedynczy (6) adres dostępu do tych informacji. Informacje opierają się głównie na wspomnianej wyżej wymianie przechowywanych komunikatów.

4.2.6.2. Komunikaty „Zapytanie o jazdę pociągu”

Cel : RU zapytuje o ostatnio zarejestrowany status (położenie, opóźnienia oraz powody opóźnień) jednego określonego pociągu w infrastrukturze określonego IM. Zapytanie : Główne elementy danych: — bieżący numer pociągu, — identyfikator IM, — planowa data i czas odjazdu w miejscu IM. Odpowiedź : Dane informacyjne: — ostatnie miejsce raportowania, — faktyczny czas w punkcie raportowania, — status pociągu w punkcie raportowania (przyjazd, odjazd, przejazd, nieokreślony, odjazd z punktu początkowego, przyjazd do punktu docelowego), — tor przyjazdu do miejsca, — tor odjazdu z miejsca, — zarezerwowany planowy czas, — opóźnienie delta w stosunku do zarezerwowanego planowanego czasu, — czas zmienionego rozkładu jazdy (w stosunku do bieżącego rozkładu jazdy w wypadku licznych zmian rozkładu jazdy), — dla każdego opóźnienia w tymże miejscu raportowania: — kod powodu oraz czas opóźnienia dla tego kodu powodu.

4.2.6.3. Komunikaty „Zapytanie o opóźnienie/osiągi pociągu”

Cel : RU zapytuje o wszystkie opóźnienia określonego pociągu u określonego IM. Zapytanie : Główne elementy danych: — bieżący numer pociągu, — identyfikator IM, — planowa data i czas odjazdu w miejscu IM. Odpowiedź : Dane informacyjne (te same informacje, co w wypadku „Zapytania o jazdę pociągu”, nie tylko dla ostatniego punktu, lecz dla każdego punktu raportowania pociągu w infrastrukturze określonego IM): — dla każdego punktu raportowania: — ostatnie miejsce raportowania, — faktyczny czas w punkcie raportowania, — status pociągu w punkcie raportowania (przyjazd, odjazd, przejazd, nieokreślony, odjazd z punktu początkowego, przyjazd do punktu docelowego), — tor przyjazdu do miejsca, — tor odjazdu z miejsca, — zarezerwowany planowy czas, — opóźnienie delta w stosunku do zarezerwowanego planowanego czasu, — czas zmienionego rozkładu jazdy (w stosunku do bieżącego rozkładu jazdy w wypadku licznych zmian rozkładu jazdy), — dla każdego opóźnienia w tymże miejscu raportowania: — kod powodu i czas opóźnienia dla tego kodu powodu.

4.2.6.4. Komunikaty „Zapytanie o identyfikator pociągu”

Cel : RU zapytuje o aktualny identyfikator pociągu i swoje poprzednie identyfikatory pociągu. Do zapytania może być użyty dowolny z identyfikatorów określonego pociągu. Zapytanie : Główne elementy danych: — znany bieżący numer pociągu, — identyfikator IM, — planowana data i czas odjazdu pociągu w miejscu IM. Odpowiedź : Dane informacyjne: — Aktualny identyfikator pociągu: — numer jazdy pociągu, — planowana data i czas odjazdu w miejscu IM, — Dla każdego innego identyfikatora pociągu: — numer jazdy pociągu, — planowa data i czas odjazdu w miejscu IM.

4.2.6.5. Komunikaty „Zapytanie IM o prognozę pociągu”

Cel : RU zapytuje o przewidywany czas dla określonego pociągu w określonym miejscu raportowania lub, pomijając miejsce raportowania, zapytuje IM o przewidywany czas w punkcie przekazania. Zapytanie : Główne elementy danych: — nieżący numer pociągu, — planowana data i czas odjazdu w miejscu IM, — identyfikator miejsca raportowania (Miejsce raportowania, dla którego wymagana jest prognoza. Jest to opcjonalne i jeżeli nie jest podane, odpowiedź odnosi się do końcowego punktu raportowania dla tegoż IM dla tego pociągu). Odpowiedź : Dane informacyjne: — kod IM, — identyfikacja punktu raportowania, — przewidywane data/czas w punkcie raportowania.

4.2.6.6. Komunikaty „Zapytanie IM o pociągi w miejscu raportowania”

Cel : RU to zapytuje o wszystkie swoje pociągi w określonym miejscu raportowania w infrastrukturze określonego IM. Zapytanie : Główne elementy danych: — kod IM, — identyfikacja miejsca raportowania (Miejsce raportowania, dla którego wymagana jest prognoza. Jest to opcjonalne i jeżeli nie jest podane, odpowiedzią powinien być końcowy punkt raportowania dla tegoż IM dla tego pociągu). Odpowiedź : Dane informacyjne: — dla każdego spośród pociągów tego zapytującego: — numer jazdy pociągu, — planowe data i czas odjazdu w miejscu IM lub planowany czas przekazania, — kod IM, — identyfikacja punktu raportowania, — przewidywane data/czas w punkcie raportowania.

4.2.7. ETI/ETA przesyłki

4.2.7.1. Wstępna uwaga

W rozdziałach 4.2.2 od (Żądanie trasy) do 4.2.6 (Położenie pociągu) opisana jest głównie komunikacja pomiędzy RU i IM. Ponieważ zadaniem zarządcy infrastruktury jest monitorowanie i kontrola pociągów, zasadniczym elementem tej komunikacji jest numer pociągu. Informacja o wagonach, będąca częścią komunikatu o składzie pociągu, jest istotna dla sprawdzania składu pociągu w porównaniu do umowy IM/RU o trasę oraz w wyjątkowych przypadkach.

Indywidualne monitorowanie wagonów lub jednostek intermodalnych nie jest objęte tą wymianą informacji. Jest to dokonywane na poziomie RU/LRU w oparciu o związane komunikaty i jest opisane w następujących rozdziałach od 4.2.7 (ETI/ETA przesyłki ) do 4.2.9 (Raportowanie o wymianie).

Wymiana i aktualizacja informacji związanych z wagonami i jednostkami intermodalnymi są zasadniczo wspierane przechowywaniem „planów podróży” i „ruchów wagonów” (rozdział 4.2.12.2: Inne bazy danych).

Jak już wspomniano w rozdziale 2.3.2 (Rozpatrywane procesy), dla klienta najważniejszą informacją jest zawsze szacowany czas (ETA) przybycia jego przesyłki. ETA związana z wagonami, a także ETI są również podstawowymi informacjami w komunikacji pomiędzy LRU i RU. Informacje te są dla LRU głównym instrumentem do monitorowania fizycznego transportu przesyłki oraz sprawdzania jej w stosunku do zobowiązania wobec klienta.

Wszystkie prognozowane czasy zawarte w komunikatach związanych z pociągiem 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. Są to wszystko szacowane czasy przyjazdu pociągu (TETA). Dla różnych wagonów lub jednostek intermodalnych w pociągu taka TETA może mieć różne znaczenia. Na przykład TETA dla punktu wymiany może być dla pewnych wagonów lub jednostek intermodalnych szacowanym czasem wymiany (ETI). Dla innych wagonów pozostających w pociągu do dalszego transportu przez tego samego RU TETA może nie być istotna. Zadaniem RU otrzymującego informacje o TETA jest zidentyfikowanie i przetworzenie tych informacji, przechowanie ich w „Operacyjnej bazie danych wagonów i jednostek intermodalnych” jako ruchu wagonów i przekazanie ich do LRU, jeżeli pociąg nie jedzie w trybie otwartego dostępu. Jest to teraz rozważone w następujących rozdziałach.

4.2.7.2. Obliczanie ETI/ETA

Obliczanie ETI/ETA oparte jest o informacje otrzymane od odpowiedzialnego zarządcy infrastruktury, który w komunikacie „Prognoza jazdy pociągu” przesyła szacowany czas przyjazdu pociągu (TETA) dla określonych punktów raportowania (w każdym razie dla punktów przekazania, wymiany lub przyjazdu, w tym również terminali intermodalnych) na uzgodnionej trasie, np. dla punktu przekazania od jednego IM do następnego IM (w tym wypadku TETA jest równa ETH).

Dla punktów wymiany lub dla innych określonych punktów raportowania na uzgodnionej trasie RU musi obliczyć dla następnego RU w łańcuchu przesyłki transportowej szacowany czas wymiany (ETI) dla wagonów i/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 do obliczenia ETI dla wagonów może być różny. Jest to wyjaśnione w poniższych dwóch uproszczonych przykładach. (Obrazowe przedstawienie tych scenariuszy podano w załączniku A indeks 5 rozdział 1.4, zaś schemat proceduralny oparty o przykład 1 dla punktu wymiany C przedstawiono w załączniku A indeks 5 rozdział 5).

Przykład 1 : RU 1 ma w tym samym pociągu wagony nr 1 i 2 od LRU 1 oraz wagony nr 3 do 5 od LRU 2. W punkcie wymiany C dalszy transport wagonów 1 i 2 będzie wykonywany przez RU2, a wagonów 3 do 5 przez RU 3. W tym wypadku RU 1 musi obliczyć dla wagonów 1 i 2 ETI odnoszącą się do punktu wymiany C i musi wysłać te wartości do LRU 1. RU 1 musi także obliczyć dla wagonów 3 do 5 ETI odnoszącą się do tego samego punktu wymiany C i wysłać te wartości do LRU 2. Przykład 2 : RU 1 ma w tym samym pociągu wagony nr 1 i 2 od LRU 1 oraz wagony nr 3 do 5 od LRU 2. W punkcie wymiany C dalszy transport wagonów 3 to 5 będzie wykonywany przez RU3, natomiast wagony 1 i 2 pozostaną w pociągu RU 1 aż do punktu wymiany E, gdzie odpowiedzialność za te wagony zostanie zmieniona na RU 2. W tym wypadku RU 1 musi obliczyć ETI odnoszącą się do punktu wymiany C tylko dla wagonów 3 do 5 i musi wysłać te wartości do LRU 2. Dla wagonów 1 i 2 punkt wymiany C nie jest istotny. Następnym punktem wymiany istotnym dla tych wagonów jest E i w odniesieniu do tego punktu RU 1 musi obliczyć ETI i wysłać te wartości do LRU 1.

Następny RU, na podstawie danych ETI dostarczonych przez poprzedniego RU, oblicza dla swojej części ETI odnoszącą się wagonów dla następnego punktu wymiany. Kroki te są wykonywane przez każdego kolejnego RU. Gdy ostatni RU (np. RU n) w łańcuchu transportowym wagonu otrzyma ETI od swojego poprzedzającego RU (np. RU n-1) dla wymiany wagonu pomiędzy RU n-1 i RU n, ostatni RU (RU n) musi obliczyć szacowany czas przyjazdu wagonów do końcowego punktu docelowego. Ma to na celu zapewnienie ustawienia wagonów zgodnie z kolejnością wagonów oraz stosownie do zobowiązania LRU wobec swojego klienta. Jest to ETA dla wagonu i musi być wysłane do LRU. Musi zostać przechowane elektronicznie wraz z ruchem wagonów. LRU musi udzielić klientowi dostępu do istotnych dla niego danych zgodnie z warunkami umowy.

Uwaga: odnośnie do jednostek intermodalnych: Dla jednostek intermodalnych na wagonie ETI wagonu są również ETI dla jednostek intermodalnych. Co się tyczy ETA dla jednostek intermodalnych, to należy zauważyć, że RU nie jest w stanie obliczyć takiej ETA poza częścią transportu kolejowego. Dlatego RU może dostarczyć tylko ETI odnoszące się do terminalu intermodalnego.

Wiodący RU jest odpowiedzialny za porównanie ETA ze zobowiązaniem wobec klienta.

Z odchyleniami ETA w stosunku do zobowiązania wobec klienta należy postępować zgodnie z umową i może to prowadzić do rozpoczęcia przez LRU procesu zarządzania alertem. Do przekazywania informacji o wyniku tego procesu przewidziany jest komunikat „Alert”.

Jako podstawę dla procesu zarządzania alertem LRU musi mieć możliwość składania związanego z wagonami zapytania o odchylenia. To zapytanie LRU i odpowiedź od RU jest również określona poniżej.

4.2.7.3. Komunikat „ETI/ETA wagonów”

Cel : Wysłanie ETI lub uaktualnionej ETI od jednego RU do następnego w łańcuchu transportowym. Ostatni RU łańcuchu transportowym wagonów wysyła ETA lub uaktualnioną ETA do LRU. Główne elementy danych: : — identyfikacja RU, który wytworzył ETI lub ETA, — stacja odjazdowa lub poprzednia stacja wymiany (ETI lub czas odjazdu na stacji początkowej), — numer pociągu wyruszającego ze stacji odjazdowej lub poprzedniej stacji wymiany (z ETI lub czasu odjazdu na stacji początkowej), — faktyczna data i czas odjazdu pociągu, — stacja przyjazdowa lub następna stacja wymiany (końcowa ETI/ETA), — numer pociągu przyjeżdżającego do stacji końcowej ETI/ETA (Przyjazd do następnej stacji wymiany), — data i czas przyjazdu wagonu (ETI lub ETA).

4.2.7.4. Komunikat „Alert”

Cel : Po porównaniu ETA ze zobowiązaniem wobec klienta LRU może wysłać komunikat „Alert” do uczestniczącego RU. Główne elementy danych: : — numer wagonu, — zobowiązanie wobec klienta: data i czas przyjazdu, — faktyczna ETA: data i czas.

Uwaga: W wypadku otwartego dostępu obliczenie ETI i ETA jest wewnętrznym procesem RU. W tym przypadku RU jest sam wiodącym RU.

4.2.7.5. Komunikaty „Zapytanie o odchylenia dotyczące wagonu”

Cel : LRU zapytuje o odchylenia odnośnie do określonego wagonu. Zapytanie : Główne elementy danych: — numer wagonu, — identyfikator LRU. Odpowiedź : Dane informacyjne: — Dla każdego punktu raportowania: — miejsce raportowania, — status wagonu w punkcie raportowania (odjazd, przyjazd do stacji rozrządowej, odjazd ze stacji rozrządowej, przyjazd do punktu wymiany, przyjazd do docelowej stacji rozrządowej), — odpowiedzialny RU w miejscu raportowania i zgodnie ze statusem wagonu w punkcie raportowania, — czas zmienionego rozkładu jazdy (w porównaniu do aktualnego rozkładu jazdy w wypadku wielu zmian rozkładu jazdy), — ETI, jeżeli punkt raportowania jest punktem wymiany, — faktyczny czas w punkcie raportowania, — Dla każdego odchylenia w tymże punkcie raportowania: — kod powodu oraz czas opóźnienia dla tego powodu.

4.2.8. Ruch wagonów

4.2.8.1. Uwagi wstępne

Następujące dane muszą być przechowane i elektronicznie dostępne do celów raportowania o ruchu wagonu. Muszą one również być wymienione w ramach komunikatu z upoważnionymi stronami na podstawie umowy. Szczegółowe formaty są określone w załączniku A indeks 1.

— 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

— Potwierdzenie dostawy wagonu

— Raportowanie o wymianie wagonu zostanie opisane oddzielnie w rozdziale 4.2.9: Raportowanie o wymianie

4.2.8.2. Komunikat „Powiadomienie o zwolnieniu wagonu”

Cel : LRU do RU: wiodącym RU niekoniecznie jest pierwszy RU w łańcuchu transportowym. W tym wypadku LRU musi powiedzieć odpowiedzialnemu RU, że wagon jest gotowy do zabrania na bocznicy klienta (miejsce odjazdu zgodnie ze zobowiązaniem LRU) o danym czasie zwolnienia (data i czas odjazdu). Zdarzenie to musi zostać przechowane w „Operacyjnej bazie danych wagonów i jednostek intermodalnych”. Główne elementy danych : — numer wagonu, — miejsce, data i czas odjazdu (miejsce, z którego planowane jest wyruszenie transportu). Następujące dane przechowywane w bazach danych muszą być łatwo dostępne dla RU i LRU: — jednostka, identyfikacja, rozmiar i typ transportu, — wykorzystana pojemność jednostki, — całkowity ciężar (zarezerwowany/rzeczywisty całkowity ciężar (masa) towaru, w tym opakowania i urządzeń przewoźnika), — wskazanie niebezpiecznych towarów.

4.2.8.3. Komunikat „Powiadomienie o odjeździe wagonu”

Cel : RU do LRU: RU musi powiadomić LRU o rzeczywistej dacie i czasie, kiedy wagon został zabrany z miejsca odjazdu. Zdarzenia te muszą zostać przechowane w „Operacyjnej bazie danych wagonów i jednostek intermodalnych”. Poprzez wymianę tego komunikatu odpowiedzialność za wagon przenosi się z klienta na RU. Główne elementy danych : — numer wagonu, — miejsce, data i czas odjazdu (miejsce, z którego planowane jest wyruszenie transportu). Następujące dane przechowywane w bazach danych muszą być łatwo dostępne dla RU i LRU: — jednostka, identyfikacja, rozmiar i typ transportu, — wykorzystana pojemność jednostki, — całkowity ciężar (zarezerwowany/rzeczywisty całkowity ciężar (masa) towaru, w tym opakowania i urządzeń przewoźnika), — wskazanie niebezpiecznych towarów.

4.2.8.4. Komunikat „Przyjazd wagonu do stacji rozrządowej”

Cel : 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” z rozdziału 4.2.4 (Prognoza jazdy pociągu). Zdarzenie to musi zostać przechowane w „Operacyjnej bazie danych wagonów i jednostek intermodalnych”. Główne elementy danych: : — numer wagonu, — identyfikacja przyjazdu do stacji rozrządowej, — data i czas przyjazdu do stacji rozrządowej.

4.2.8.5. Komunikat „Wyjazd wagonu ze stacji rozrządowej”

Cel : 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” z rozdziału 4.2.4 (Prognoza jazdy pociągu). Zdarzenie to musi zostać przechowane w „Operacyjnej bazie danych wagonów i jednostek intermodalnych”. Główne elementy danych : — numer wagonu, — identyfikacja wyjazdu ze stacji rozrządowej, — data i czas wyjazdu ze stacji rozrządowej.

4.2.8.6. Komunikat „Wyjątkowa sytuacja wagonu”

Cel : RU musi powiadomić LRU, jeśli z wagonem zdarzyło się coś nieoczekiwaneg