ZAŁĄCZNIK

SPIS TREŚCI

1. WPROWADZENIE 23

1.1. Skróty 23

1.2. Dokumenty referencyjne 23

1.3. Zakres techniczny 24

1.4. Zakres geograficzny 24

2. DEFINICJA PODSYSTEMU I ZAKRES 24

2.1. Funkcja wchodząca w zakres TSI 24

2.2. Funkcje niewchodzące w zakres TSI 25

2.3. Przegląd opisu podsystemu 25

2.3.1. Rozpatrywane procesy 25

3. WYMAGANIA ZASADNICZE 26

3.1. Zgodność z wymaganiami zasadniczymi 26

3.2. Aspekty wymagań zasadniczych 26

3.3. Aspekty związane z wymaganiami ogólnymi 26

3.3.1. Bezpieczeństwo 26

3.3.2. Niezawodność i dostępność 26

3.3.3. Zdrowie 26

3.3.4. Ochrona środowiska 26

3.3.5. Zgodność techniczna 27

3.3.6. Dostępność 27

4. CHARAKTERYSTYKA PODSYSTEMU 27

4.1. Wstęp 27

4.2. Funkcjonalne i techniczne specyfikacje podsystemu 27

4.2.1. Dane listu przewozowego 28

4.2.2. Wniosek o przydzielenie trasy i przydział trasy 28

4.2.3. Przygotowanie pociągu 30

4.2.4. Informacja o jeździe pociągu i prognoza jazdy pociągu 31

4.2.5. Informacje o zakłóceniu usługi 32

4.2.6. ETI/ETA przesyłki 32

4.2.7. Ruch wagonów 34

4.2.8. Wymiana danych w celu poprawy jakości 35

4.2.9. Główne dane referencyjne 35

4.2.10. Lista plików referencyjnych i referencyjnych baz danych 36

4.2.11. Łączność sieciowa i komunikacja 37

4.3. Funkcjonalne i techniczne specyfikacje dotyczące interfejsów 39

4.3.1. Interfejsy z TSI „Infrastruktura” 39

4.3.2. Interfejsy z TSI „Sterowanie ruchem kolejowym” 39

4.3.3. Interfejsy z podsystemem „Tabor kolejowy” 40

4.3.4. Interfejsy z TSI „Ruch kolejowy” 40

4.3.5. Interfejsy z podsystemem „Aplikacje telematyczne dla przewozów pasażerskich” 40

4.4. Zasady eksploatacji 40

4.4.1. Jakość danych 41

4.4.2. Obsługa centralnego repozytorium 42

4.5. Zasady utrzymania 42

4.6. Kwalifikacje zawodowe 42

4.7. Warunki bezpieczeństwa i higieny pracy 42

5. SKŁADNIKI INTEROPERACYJNOŚCI 43

5.1. Definicja 43

5.2. Wykaz składników 43

5.3. Charakterystyki wydajnościowe i specyfikacje dotyczące składników 43

6. OCENA ZGODNOŚCI SKŁADNIKÓW LUB ICH PRZYDATNOŚCI DO STOSOWANIA ORAZ WERYFIKACJA PODSYSTEMU 43

6.1. Składniki interoperacyjności 43

6.1.1. Procedury oceny 43

6.1.2. Moduł 43

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

6.2.1. Ocena zgodności narzędzi informatycznych 43

7. WDROŻENIE 44

7.1. Wstęp 44

7.2. Zarządzanie zmianami 45

7.2.1. Proces zarządzania zmianami 45

7.2.2. Szczególny proces zarządzania zmianami dotyczący dokumentów wymienionych w dodatku I do niniejszego rozporządzenia 45

Dodatek I – Wykaz dokumentów technicznych 47

Dodatek II – Glosariusz 48

Dodatek III – Zadania krajowego punktu kontaktowego ds. TAF/TAP 56

1. WPROWADZENIE

1.1. Skróty

Tabela 1

Skróty

Skrót Definicja CI Wspólny interfejs KE Komisja Europejska ERA Agencja Kolejowa Unii Europejskiej (zwana dalej również „Agencją”) IM Zarządca infrastruktury (ang. Infrastructure Manager) ISO Międzynarodowa Organizacja Normalizacyjna LCL Przesyłki drobnicowe (ang. Less than Container Loads) LRU Wiodące przedsiębiorstwo kolejowe RISC Komitet ds. interoperacyjności i bezpieczeństwa kolei RU Przedsiębiorstwo kolejowe (ang. Railway Undertaking) TAF Aplikacje telematyczne dla przewozów towarowych (ang. Telematics Applications for Freight) TAP Aplikacje telematyczne dla przewozów pasażerskich (ang. Telematics Applications for Passengers) TCP/IP Protokół sterowania transmisją (ang. Transmission Control Protocol)/Protokół internetowy TSI Techniczna specyfikacja interoperacyjności WK Posiadacze wagonów (ang. Wagon Keepers)

1.2. Dokumenty referencyjne

Tabela 2

Dokumenty referencyjne

Nr ref. Tytuł skrócony/odniesienie Tytuł Data ostatniego wydania: [1] Dyrektywa (UE) 2016/797 Dyrektywa Parlamentu Europejskiego i Rady (UE) 2016/797 z dnia 11 maja 2016 r. w sprawie interoperacyjności systemu kolei w Unii Europejskiej (Dz.U. L 138 z 26.5.2016, s. 44). 27.5.2020 [2] Rozporządzenie Komisji (UE) nr 454/2011 dotyczące TSI TAP Rozporządzenie Komisji (UE) nr 454/2011 z dnia 5 maja 2011 r. w sprawie technicznej specyfikacji interoperacyjności odnoszącej się do podsystemu „Aplikacje telematyczne dla przewozów pasażerskich” transeuropejskiego systemu kolei (Dz.U. L 123 z 12.5.2011, s. 11) 27.5.2019 [3] Dyrektywa 2012/34/UE Dyrektywa Parlamentu Europejskiego i Rady 2012/34/UE z dnia 21 listopada 2012 r. w sprawie utworzenia jednolitego europejskiego obszaru kolejowego (Dz.U. L 343 z 14.12.2012, s. 32). 14.11.2017 [4] ERA-TD-105 TAF TSI – ANNEX D.2: APPENDIX F – TAF TSI DATA AND MESSAGE MODEL [Załącznik D.2: Dodatek F – Model danych i komunikatów TSI TAF] [5] Rozporządzenie Komisji (UE) nr 62/2006 dotyczące TSI TAF Rozporządzenie Komisji (WE) nr 62/2006 z dnia 23 grudnia 2005 r. dotyczące technicznej specyfikacji dla interoperacyjności odnoszącej się do podsystemu aplikacji telematycznych dla przewozów towarowych transeuropejskiego systemu kolei konwencjonalnych (Dz.U. L 13 z 18.1.2006, s. 1) 18.1.2006 [6] C(2010) 2576 final Decyzja Komisji z dnia 29 kwietnia 2010 r. dotycząca mandatu dla Europejskiej Agencji Kolejowej do opracowania i przeprowadzenia przeglądu technicznych specyfikacji interoperacyjności w celu rozszerzenia ich zakresu na cały system kolei w Unii Europejskiej 29.4.2010 [7] Dyrektywa (UE) 2016/798 Dyrektywa Parlamentu Europejskiego i Rady (UE) 2016/798 z dnia 11 maja 2016 r. w sprawie bezpieczeństwa kolei (Dz.U. L 138 z 26.5.2016, s. 102). 26.5.2016 [8] Decyzja delegowana Komisji (UE) 2017/1474 Decyzja delegowana Komisji (UE) 2017/1474 z dnia 8 czerwca 2017 r. uzupełniająca dyrektywę Parlamentu Europejskiego i Rady (UE) 2016/797 w odniesieniu do szczegółowych celów dotyczących opracowania, przyjęcia i przeglądu technicznych specyfikacji interoperacyjności (Dz.U. L 210 z 15.8.2017, s. 5). 15.8.2017

1.3. Zakres techniczny

Niniejsza techniczna specyfikacja interoperacyjności (dalej zwana „TSI TAF”) odnosi się do elementu „aplikacje telematyczne dla przewozów towarowych” podsystemu „aplikacje telematyczne” wymienionego w wykazie podsystemów eksploatacyjnych (funkcjonalnych) zamieszczonym w załączniku II do dyrektywy (UE) 2016/797 i opisanego w sekcji 2.6 lit. b) wspomnianego załącznika.

Niniejsza TSI TAF została opracowana w celu zapewnienia sprawnej wymiany informacji poprzez ustanowienie ram technicznych umożliwiających osiągnięcie możliwie jak najbardziej opłacalnego ekonomicznie procesu transportu. W zakres tej specyfikacji wchodzą aplikacje dla przewozów towarowych oraz zarządzania połączeniami z innymi rodzajami transportu, co oznacza, że skoncentrowano się w niej nie tylko na samej eksploatacji pociągów, ale i na usługach transportowych RU. Kwestie bezpieczeństwa zostały uwzględnione jedynie w odniesieniu do istniejących elementów danych; wartości nie będą miały wpływu na bezpieczną eksploatację pociągu, a zgodności z wymogami TSI TAF nie można uznawać za zgodność z wymogami bezpieczeństwa.

TAF TSI ma również wpływ na warunki wykorzystywania transportu kolejowego przez użytkowników. W tym kontekście termin „użytkownicy” oznacza nie tylko zarządców infrastruktury lub przedsiębiorstwa kolejowe, lecz także wszystkich innych dostawców usług, takich jak firmy wagonowe, operatorów intermodalnych, a nawet klientów.

1.4. Zakres geograficzny

Niniejsza TSI ma zastosowanie do sieci Unii zgodnie z definicją zawartą w sekcji 1 załącznika I do dyrektywy (UE) 2016/797.

2. DEFINICJA PODSYSTEMU I ZAKRES

2.1. Funkcja wchodząca w zakres TSI

Podsystem „Aplikacje telematyczne dla przewozów towarowych” został określony w załączniku II do dyrektywy (UE) 2016/797, sekcja 2.6 lit. b).

W jego skład wchodzą w szczególności:

— aplikacje dla przewozów towarowych, w tym systemy informatyczne (monitorowanie towarów i pociągów w czasie rzeczywistym),

— systemy zestawcze i przydziałowe, przy czym systemy przydziałowe są rozumiane jako skład pociągów,

— systemy rezerwacyjne, przy czym są one tu rozumiane jako rezerwacja tras pociągów,

— zarządzanie połączeniami z innymi rodzajami transportu i sporządzanie elektronicznych dokumentów towarzyszących.

2.2. Funkcje niewchodzące w zakres TSI

W zakres niniejszej TSI nie wchodzą systemy płatności i fakturowania dla klientów ani też podobne systemy obsługi płatności i fakturowania pomiędzy różnymi dostawcami usług, takimi jak przedsiębiorstwa kolejowe lub zarządcy infrastruktury. Jednakże informacje stanowiące podstawę do płatności za usługi transportowe dostarczane są za pomocą rozwiązania systemowego, na którym opiera się wymiana danych zgodnie z rozdziałem 4.2 („Specyfikacje funkcjonalne i techniczne podsystemu”).

Długoterminowe planowanie rozkładów jazdy nie wchodzi w zakres niniejszej TSI „Aplikacje telematyczne”. Niemniej jednak w niektórych punktach umieszczono odniesienie do wyniku długoterminowego planowania, o ile istnieje związek ze sprawną wymianą informacji koniecznych do eksploatacji pociągów.

2.3. Przegląd opisu podsystemu

2.3.1. Rozpatrywane procesy

Biorąc pod uwagę potrzeby klienta, jedną z usług jest organizowanie linii transportowej zgodnie z umową między wiodącym przedsiębiorstwem kolejowym (LRU) a klientem i zarządzanie nią.

LRU stanowi jeden centralny punkt kontaktowy dla klienta. Jeżeli w łańcuchu transportowym uczestniczy więcej niż jedno przedsiębiorstwo kolejowe, to LRU jest także odpowiedzialne za koordynację z innymi RU. Usługa ta może być również realizowana przez spedytora lub dowolny inny podmiot.

Zakres niniejszej TSI dotyczącej sektora kolejowego transportu towarowego jest ograniczony zgodnie z dyrektywą (UE) 2016/797 do wymiany danych dokonywanej przez IM oraz RU/LRU. Niniejsza TSI pozwala LRU dostarczać klientowi informacje, w szczególności:

— informacje o trasie,

— informacje o kursowaniu pociągu w odniesieniu do uzgodnionych punktów raportowania, w tym przynajmniej punktu początkowego trasy, punktu wymiany/przekazania i punktu docelowego transportu będącego przedmiotem umowy,

— przewidywany czas przyjazdu (ang. Estimated Time of Arrival, ETA) do miejsca docelowego, w tym stacji rozrządowych i terminali intermodalnych,

— informacje o zakłóceniu usługi. Jeżeli wiodące RU uzyska informację o zakłóceniu usługi, przekazuje ją ono klientowi w należytym terminie.

Na użytek dostarczania powyższych informacji w rozdziale 4 określono odpowiednie komunikaty zgodne z wymaganiami w zakresie TAF.

RU/LRU musi zasadniczo posiadać przynajmniej zdolność:

— OKREŚLANIA usług pod względem ceny i czasów przejazdu, dostawy wagonów (w stosownych przypadkach), danych dotyczących wagonów/jednostek intermodalnych (lokalizacja, status oraz przewidywany czas przyjazdu (ETA) wagonów/jednostek intermodalnych), w przypadku gdy przesyłki mogą być załadowywane do pustych wagonów, kontenerów itp.,

— DOSTARCZANIA określonej usługi w sposób niezawodny i niezakłócony poprzez stosowanie powszechnych procesów gospodarczych i powiązanych systemów. RU, IM oraz inni dostawcy usług i zainteresowane strony, takie jak urzędy celne, muszą dysponować możliwością wymiany informacji drogą elektroniczną,

— MIERZENIA jakości dostarczanej usługi w porównaniu z określonymi wcześniej parametrami, to jest pokrywania się wystawionych rachunków z podaną wcześniej ceną, rzeczywistych czasów przejazdu z podjętymi zobowiązaniami, wagonów dostarczonych z zamówieniem, ETA z faktycznym czasem przyjazdu,

— DZIAŁANIA w sposób produktywny pod względem wykorzystania: zdolności przepustowej pociągów, infrastruktury i floty pojazdów poprzez stosowanie procesów gospodarczych, systemów i wymiany informacji koniecznych do właściwej eksploatacji wagonów/jednostek intermodalnych i sporządzania rozkładu jazdy pociągu.

Obsługiwanie pustych wagonów nabiera szczególnego znaczenia, jeśli weźmie się pod uwagę wagony eksploatowane w trybie interoperacyjności. Co do zasady nie ma różnicy w obsługiwaniu wagonów załadowanych i pustych. Transport pustych wagonów jest również dokonywany na podstawie zleceń przewozu, w związku z czym zarządca floty takich pustych wagonów musi być uważany za klienta.

3. WYMAGANIA ZASADNICZE

3.1. Zgodność z wymaganiami zasadniczymi

Zgodnie z dyrektywą (UE) 2016/797 system kolei Unii, podsystemy i ich składniki interoperacyjności muszą spełniać zasadnicze wymagania określone ogólnie w załączniku III do wspomnianej dyrektywy.

W zakresie TSI w niniejszej wersji spełnianie przez podsystem stosownych wymagań zasadniczych podanych w rozdziale 3 zostanie zapewnione dzięki zastosowaniu się do specyfikacji opisanych w rozdziale 4 („Charakterystyka podsystemu”).

3.2. Aspekty wymagań zasadniczych

Wymagania zasadnicze dotyczą:

— bezpieczeństwa,

— niezawodności i dostępności,

— zdrowia,

— ochrony środowiska,

— zgodności technicznej,

— dostępności.

Zgodnie z dyrektywą (UE) 2016/797 wymagania zasadnicze mogą mieć ogólne zastosowanie w odniesieniu do całego transeuropejskiego systemu kolei lub mogą dotyczyć jedynie poszczególnych podsystemów i ich składników.

3.3. Aspekty związane z wymaganiami ogólnymi

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

3.3.1. Bezpieczeństwo

Wymagania zasadnicze 1.1.1, 1.1.2, 1.1.3, 1.1.4 i 1.1.5 określone w załączniku III do dyrektywy (UE) 2016/797 nie odnoszą się do podsystemu „Aplikacje telematyczne”.

3.3.2. Niezawodność i dostępność

„Monitorowanie i konserwacja nieruchomych i ruchomych elementów uczestniczących w ruchu pociągów muszą być zorganizowane, przeprowadzane i określane ilościowo w taki sposób, aby utrzymać ich funkcjonowanie w zamierzonych warunkach”.

To wymaganie zasadnicze jest spełnione poprzez zgodność ze specyfikacjami w następujących rozdziałach:

— rozdział 4.2.9: „Główne dane referencyjne”,

— rozdział 4.2.10: „Lista plików referencyjnych i referencyjnych baz danych”,

— rozdział 4.2.11: „Łączność sieciowa i komunikacja”.

3.3.3. Zdrowie

Wymagania zasadnicze 1.3.1 i 1.3.2 określone w załączniku III do dyrektywy (UE) 2016/797 nie odnoszą się do podsystemu „Aplikacje telematyczne”.

3.3.4. Ochrona środowiska

Wymagania zasadnicze 1.4.1, 1.4.2, 1.4.3, 1.4.4 i 1.4.5 określone w załączniku III do dyrektywy (UE) 2016/797 nie odnoszą się do podsystemu „Aplikacje telematyczne”.

3.3.5. Zgodność techniczna

Wymaganie zasadnicze 1.5 określone w załączniku III do dyrektywy (UE) 2016/797 nie odnosi się do podsystemu „Aplikacje telematyczne”.

3.3.6. Dostępność

Wymaganie zasadnicze 1.6 określone w załączniku III do dyrektywy (UE) 2016/797 nie odnosi się do podsystemu „Aplikacje telematyczne”.

4. CHARAKTERYSTYKA PODSYSTEMU

4.1. Wstęp

System kolei, do którego zastosowanie ma dyrektywa (UE) 2016/797 i którego częścią jest podsystem „Aplikacje telematyczne”, jest systemem zintegrowanym, którego spójność musi być zweryfikowana. Należy sprawdzać w szczególności, czy zachowana jest spójność: w specyfikacjach podsystemu, między jego interfejsami a systemem, z którymi jest on zintegrowany, jak również w zasadach dotyczących jego eksploatacji i utrzymania.

Biorąc pod uwagę wszystkie mające zastosowanie wymagania zasadnicze, podsystem „Aplikacje telematyczne dla przewozów towarowych” charakteryzuje się podanymi poniższej cechami.

4.2. Funkcjonalne i techniczne specyfikacje podsystemu

W świetle wymagań zasadniczych przedstawionych w rozdziale 3 specyfikacje funkcjonalne i techniczne podsystemu obejmują informacje dotyczące następujących kwestii:

— dane listu przewozowego,

— wniosek o przydzielenie trasy i przydział trasy,

— przygotowanie pociągu,

— informacja o jeździe pociągu i prognoza jazdy pociągu,

— informacje o zakłóceniu usługi,

— ETI/ETA wagonów/jednostek intermodalnych,

— ruch wagonów,

— wymiana danych w celu poprawy jakości,

— główne dane referencyjne,

— lista plików referencyjnych i referencyjnych baz danych,

— łączność sieciowa i komunikacja.

Niezależnie od przepisów zawartych w rozdziale 4 i jego podrozdziałach każdy zainteresowany podmiot może wymieniać komunikaty, o których mowa w rozdziałach 4.2.2.3 (tylko podczas eksploatacji lub przygotowania do eksploatacji pociągu), 4.2.4.2, 4.2.4.3, 4.2.5.2, 4.2.6.3 i 4.2.6.4, z innymi zainteresowanymi podmiotami zaangażowanymi w tę samą usługę przewozu towarowego, pod warunkiem że możliwa jest identyfikacja zainteresowanych podmiotów. Nadawca może pobierać opłatę za wymianę tych komunikatów.

LRU odpowiada za informowanie klientów zgodnie z porozumieniem umownym.

Szczegółowe specyfikacje określone są w pełnym katalogu danych. Wymagane formaty komunikatów i danych we wspomnianym katalogu określono w wymienionym w dodatku I dokumencie „TAF TSI – Annex D.2: Appendix F – TAF TSI Data and Message Model”. W tym samym celu można ponadto wykorzystać inne obowiązujące normy, o ile istnieje szczególne porozumienie pomiędzy zaangażowanymi stronami, umożliwiające wykorzystywanie takich norm, w szczególności na potrzeby transportu kombinowanego/intermodalnego lub na terytoriach państw członkowskich UE graniczących z państwami trzecimi.

Ogólne uwagi na temat struktury komunikatów

Każdy komunikat składa się z dwóch zestawów danych:

— dane kontrolne: określone poprzez wskazany w katalogu komunikatów obowiązkowy tytuł komunikatu,

— dane informacyjne: określone poprzez obowiązkową/opcjonalną treść danego komunikatu oraz obowiązkowy/opcjonalny zestaw danych wskazany w katalogu.

Jeżeli komunikat lub element danych określony jest w niniejszym rozporządzeniu jako opcjonalny, zainteresowane strony podejmują decyzję dotyczącą stosowania go. Zasady stosowania takich komunikatów i elementów danych muszą zostać zawarte w porozumieniu umownym. Jeżeli zawarte w katalogu danych elementy opcjonalne w pewnych okolicznościach stają się obowiązkowe, informacja o tym musi zostać zawarta w katalogu danych.

4.2.1. Dane listu przewozowego

4.2.1.1. List przewozowy klienta

Klient wysyła list przewozowy do wiodącego RU. W liście tym muszą zostać wskazane wszystkie dane potrzebne do przewiezienia przesyłki od nadawcy do odbiorcy zgodnie z „Przepisami ujednoliconymi o umowie międzynarodowego przewozu towarów kolejami (CIM)” i „Przepisami ujednoliconymi o umowach użytkowania pojazdów w międzynarodowej komunikacji kolejowej (CUV)”. LRU musi uzupełnić te dane o dodatkowe informacje. Podzbiór danych listu przewozowego, w tym wspomniane dodatkowe informacje, opisano w dokumentach: „TAF TSI – Annex D.2: Appendix A (WAGON/ILU TRIP PLANNING)” oraz „TAF TSI – Annex D.2: Appendix F – TAF TSI Data and Message Model” [4]), wymienionych w tabeli w dodatku I do niniejszego rozporządzenia.

W przypadku otwartego dostępu wiodące RU zawierające umowę z klientem posiada wszystkie dane po uzupełnieniu ich o informacje dodatkowe. Nie jest wymagana wymiana komunikatów z innymi RU. Dane te są także podstawą do wystosowania wniosku o przydzielenie trasy ad hoc, jeśli jest to konieczne do wykonania listu przewozowego.

Poniższe komunikaty dotyczą przypadku, w którym przewóz nie jest wykonywany na zasadzie otwartego dostępu. Treść tych komunikatów może także być podstawą do wystosowania wniosku o przydzielenie trasy ad hoc, jeśli jest to konieczne do wykonania listu przewozowego.

4.2.1.2. Zlecenia przewozu

Zlecenie przewozu jest zasadniczo podzbiorem informacji zawartych w liście przewozowym. Musi ono zostać dostarczone przez LRU przedsiębiorstwom kolejowym uczestniczącym w łańcuchu transportowym. Treść zlecenia przewozu musi zawierać istotne informacje, które są potrzebne RU do wykonania transportu na etapie, za który to RU odpowiada, aż do przekazania przesyłki kolejnemu RU.

Struktura danych obowiązkowych w zleceniu przewozu oraz szczegóły dotyczące formatu odnośnego komunikatu wskazane zostały w pozycji zatytułowanej „Consignment Order Message” w wymienionym w dodatku I dokumencie „TAF TSI – Annex D.2: Appendix F – TAF TSI Data and Message Model”.

Główne elementy zlecenia przewozu to:

— dane dotyczące nadawcy i odbiorcy,

— dane dotyczące przebiegu trasy,

— identyfikacja przesyłki,

— dane o wagonach,

— dane o miejscu i czasie.

4.2.2. Wniosek o przydzielenie trasy i przydział trasy

4.2.2.1. Uwagi wstępne

Informacje dotyczące trasy oznaczają wnioskowane, przyjęte i faktyczne dane, które mają być przechowywane, dotyczące trasy i charakterystyki pociągu w odniesieniu do każdego odcinka trasy. W poniższym opisie przedstawiono dane, które muszą być dostępne dla zarządcy infrastruktury lub organu alokującego (AB). Dane te muszą być aktualizowane za każdym razem, gdy nastąpi zmiana. W danych dotyczących trasy ustalonej na rok musi być zatem możliwe wyszukanie danych na potrzeby wprowadzania krótkoterminowych zmian. W szczególności, jeżeli zmiany te są istotne dla klienta, musi on być o nich informowany przez LRU.

Wniosek o przydzielenie trasy ad hoc

Wskutek wyjątkowych okoliczności podczas jazdy pociągu lub z powodu pilnych zapotrzebowań transportowych przedsiębiorstwo kolejowe lub wnioskodawca musi mieć możliwość otrzymania ad hoc trasy w sieci.

Pełniąc rolę odpowiedzialnego wnioskodawcy, RU/wnioskodawca musi dostarczyć zarządcy infrastruktury wszystkie niezbędne dane o tym, kiedy i dokąd wymagana jest jazda pociągu, wraz ze wszystkimi parametrami fizycznymi, które mają znaczenie w odniesieniu do infrastruktury. Wymagania te obowiązują w odniesieniu do wszystkich wniosków o przydzielenie trasy ad-hoc i powiązanych komunikatów. Na poziomie europejskim nie określono dla nich minimalnych ram czasowych. Minimalne ramy czasowe mogą zostać określone w regulaminie sieci.

Wniosek o przydzielenie trasy ad hoc nie uwzględnia kwestii związanych z zarządzaniem ruchem. Rozgraniczenie czasowe pomiędzy przydzieleniem trasy ad hoc a zmianami trasy w związku z zarządzaniem ruchem jest przedmiotem porozumień miejscowych i może być określone w regulaminie sieci.

Wymagania dotyczące obowiązków RU/wnioskodawcy/IM w trakcie procesu wnioskowania o przydzielenie trasy oraz procesu przydziału trasy nie są częścią niniejszego rozporządzenia. Stosowne informacje podano w rozporządzeniu wykonawczym Komisji (UE) 2019/773 (1) (TSI „Ruch kolejowy”).

4.2.2.2. Komunikat „Wniosek o przydzielenie trasy”

Pełniąc rolę odpowiedzialnego wnioskodawcy, RU/wnioskodawca wysyła komunikat „Wniosek o przydzielenie trasy” do zarządcy infrastruktury (IM)/organu alokującego (AB) w celu zwrócenia się z wnioskiem o przydzielenie trasy.

Definicję obowiązkowej struktury komunikatu „Wniosek o przydzielenie trasy” oraz wymagane elementy podano w wymienionym w dodatku I dokumencie „TAF TSI – Annex D.2: Appendix F – TAF TSI Data and Message Model”.

4.2.2.3. Komunikat „Szczegółowe dane o trasie”

Pełniąc rolę IM odpowiedzialnego za planowanie, IM/AB wysyła komunikat „Szczegółowe dane o trasie” do RU/wnioskodawcy jako odpowiedź na złożony przez to RU/tego wnioskodawcę wniosek o przydzielenie trasy.

Definicję obowiązkowej struktury komunikatu „Szczegółowe dane o trasie” oraz wymagane elementy podano w wymienionym w dodatku I dokumencie „TAF TSI – Annex D.2: Appendix F – TAF TSI Data and Message Model”.

4.2.2.4. Komunikat „Trasa potwierdzona”

Pełniąc rolę odpowiedzialnego wnioskodawcy, wnioskujące RU/wnioskodawca wysyła komunikat „Trasa potwierdzona” w celu potwierdzenia trasy zaproponowanej przez IM/AB.

Definicję obowiązkowej struktury komunikatu „Trasa potwierdzona” oraz wymagane elementy podano w wymienionym w dodatku I dokumencie „TAF TSI – Annex D.2: Appendix F – TAF TSI Data and Message Model”.

4.2.2.5. Komunikat „Odmowa szczegółowych danych o trasie”

Pełniąc rolę odpowiedzialnego wnioskodawcy, wnioskujące RU/wnioskodawca wysyła komunikat „Odmowa szczegółowych danych o trasie” do właściwego IM/AB w celu odrzucenia zaproponowanych przez niego danych o trasie.

Definicję obowiązkowej struktury komunikatu „Odmowa szczegółowych danych o trasie” oraz wymagane elementy podano w wymienionym w dodatku I dokumencie „TAF TSI – Annex D.2: Appendix F – TAF TSI Data and Message Model”.

4.2.2.6. Komunikat „Trasa odwołana”

Pełniąc rolę odpowiedzialnego wnioskodawcy (w fazie planowania) lub rolę odpowiedzialnego RU (w fazie eksploatacji), RU/wnioskodawca wysyła komunikat „Trasa odwołana” do właściwego IM/AB w celu odwołania całości albo części potwierdzonej trasy.

Definicję obowiązkowej struktury komunikatu „Trasa odwołana” oraz wymagane elementy podano w wymienionym w dodatku I dokumencie „TAF TSI – Annex D.2: Appendix F – TAF TSI Data and Message Model”.

4.2.2.7. Komunikat „Trasa niedostępna”

Pełniąc rolę IM odpowiedzialnego za planowanie (w fazie planowania) lub rolę odpowiedzialnego IM (w fazie eksploatacji), IM/AB wysyła komunikat „Trasa niedostępna” do zamawiającego trasę RU/wnioskodawcy w przypadku, gdy trasa potwierdzona przez RU/wnioskodawcę nie jest już dostępna.

IM musi powiadomić RU, jak tylko dowie się, że trasa pociągu nie jest dostępna. Komunikat „Trasa 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.

Komunikat „Trasa niedostępna” oznacza, że trasa lub jej część nie może być wykorzystana i już nie istnieje.

Jeżeli dostępna jest trasa alternatywna, IM musi bez kolejnego wniosku ze strony RU wysłać alternatywną propozycję wraz z tym komunikatem lub gdy tylko trasa ta będzie znana. Dokonuje się tego za pomocą komunikatu „Szczegółowe dane o trasie” związanego z tym komunikatem „Trasa niedostępna”. Jeżeli alternatywna propozycja nie jest możliwa, IM musi niezwłocznie poinformować o tym RU.

Definicję obowiązkowej struktury komunikatu „Trasa niedostępna” oraz wymagane elementy podano w wymienionym w dodatku I dokumencie „TAF TSI – Annex D.2: Appendix F – TAF TSI Data and Message Model”.

4.2.2.8. Komunikat „Potwierdzenie odbioru”

Odbiorca każdego komunikatu wysyła komunikat „Potwierdzenie odbioru” do nadawcy pierwotnego komunikatu w celu potwierdzenia, że pierwotny komunikat dotarł do systemu, z którego korzysta odbiorca.

Definicję obowiązkowej struktury komunikatu „Potwierdzenie odbioru” oraz wymagane elementy podano w wymienionym w dodatku I dokumencie „TAF TSI – Annex D.2: Appendix F – TAF TSI Data and Message Model”.

4.2.3. Przygotowanie pociągu

4.2.3.1. Uwagi ogólne

Niniejszy parametr podstawowy określa komunikaty, które muszą być wymieniane na etapie przygotowania pociągu do czasu rozpoczęcia jazdy pociągu.

Przygotowanie pociągu obejmuje sprawdzenie zgodności między pociągiem a drogą. Zgodność tę sprawdza RU, na podstawie dostarczonych przez odpowiednich IM informacji zawierających opis infrastruktury i jej ograniczeń.

Jeżeli pociąg zostaje w całości przejęty przez kolejne RU, odpowiedzialne RU przesyła dane o składzie pociągu do kolejnego odpowiedzialnego RU. Zgodnie z porozumieniem umownym odpowiedzialne RU musi wysłać ten komunikat również do IM. Ma to również zastosowanie, jeżeli trasa została zamówiona przez innego odpowiedzialnego wnioskodawcę, który upoważnił odpowiedzialne RU do wykonania przejazdu pociągu. Ponadto odpowiedzialne RU pozostaje partnerem w wymianie komunikatów z IM, jeżeli zleca podwykonawstwo w zakresie przejazdu pociągu innemu RU.

Jeżeli skład pociągu ulegnie zmianie w pewnym miejscu trasy, komunikat ten musi zostać wysłany jeszcze raz, z informacjami zaktualizowanymi przez odpowiadające za to RU.

4.2.3.2. Komunikat „Skład pociągu”

Odpowiedzialne RU wysyła komunikat „Skład pociągu”, określając w nim skład pociągu, do następnego odpowiedzialnego RU zaangażowanego w usługę przewozu towarowego oraz do wiodącego RU. Zgodnie z regulaminem sieci odpowiedzialne RU musi wysłać komunikat „Skład pociągu” również do IM.

Definicję obowiązkowej struktury komunikatu „Skład pociągu” oraz wymagane elementy podano w wymienionym w dodatku I dokumencie „TAF TSI – Annex D.2: Appendix F – TAF TSI Data and Message Model”.

Minimalny zakres informacji, jakie muszą zostać dostarczone na potrzeby wymiany komunikatu „Skład pociągu” pomiędzy RU a IM został określony w rozdziale 4.2.2.7.2 rozporządzenia wykonawczego (UE) 2019/773 (TSI „Ruch kolejowy”).

4.2.3.3. Komunikat „Pociąg gotowy”

Odpowiedzialne RU wysyła do zarządcy infrastruktury komunikat „Pociąg gotowy” za każdym razem, gdy pociąg jest gotowy do jazdy po zakończeniu jego przygotowania, chyba że zgodnie z przepisami krajowymi zarządca infrastruktury uznaje rozkład jazdy za komunikat „Pociąg gotowy”.

W przypadku transportu kombinowanego operator terminalu wysyła do RU komunikat „Pociąg gotowy” za każdym razem, gdy skład wagonów jest gotowy do rozpoczęcia jazdy. RU dostarczające trakcję do punktu wejścia IM wysyła komunikat „Pociąg gotowy” do RU wykonującego usługę kolejową w sieci IM.

Definicję obowiązkowej struktury komunikatu „Pociąg gotowy” oraz wymagane elementy podano w wymienionym w dodatku I dokumencie „TAF TSI – Annex D.2: Appendix F – TAF TSI Data and Message Model”.

4.2.4. Informacja o jeździe pociągu i prognoza jazdy pociągu

4.2.4.1. Uwagi ogólne

Niniejszy parametr podstawowy określa informacje o jeździe pociągu i prognozę jazdy pociągu. Wskazuje się w nim, w jaki sposób ma być prowadzony dialog pomiędzy zarządcą infrastruktury a przedsiębiorstwem kolejowym, aby zapewnić wymianę informacji o jeździe pociągu i prognoz jazdy pociągu.

Niniejszy parametr podstawowy określa, w jaki sposób zarządca infrastruktury musi w odpowiednim momencie wysłać informację o jeździe pociągu do przedsiębiorstwa kolejowego oraz do kolejnego sąsiedniego zarządcy infrastruktury zaangażowanego w przejazd pociągu.

Celem informacji o jeździe pociągu jest przekazywanie szczegółowych danych dotyczących bieżącego statusu pociągu w wynikających z umowy punktach raportowania.

Prognoza jazdy pociągu jest wykorzystywana do udzielania informacji na temat przewidywanego czasu w wynikających z umowy punktach prognozy. Komunikat ten musi zostać wysłany przez zarządcę infrastruktury do przedsiębiorstwa kolejowego oraz sąsiedniego zarządcy infrastruktury zaangażowanego w przejazd.

W porozumieniach umownych określa się punkty raportowania w odniesieniu do jazdy pociągu.

Ta wymiana informacji pomiędzy RU a IM odbywa się zawsze pomiędzy IM zarządzającym odnośną infrastrukturą a odpowiedzialnym RU, na którym spoczywa odpowiedzialność za przejazd pociągu. Ma to również zastosowanie, jeżeli trasa została zamówiona przez innego odpowiedzialnego wnioskodawcę, który upoważnił odpowiedzialne RU do wykonania przejazdu pociągu. Ponadto odpowiedzialne RU pozostaje partnerem w wymianie komunikatów z IM, jeżeli zleca podwykonawstwo w zakresie przejazdu pociągu innemu RU.

Na podstawie porozumienia umownego LRU zapewnia klientowi prognozę jazdy pociągu i informację o jeździe pociągu. Punkty raportowania są uzgadniane przez obie strony w ramach umowy.

4.2.4.2. Komunikat „Prognoza jazdy pociągu”

Komunikat ten musi zostać wysłany przez IM do RU, które wykonuje przejazd pociągiem, w odniesieniu do punktów przekazania, punktów wymiany oraz do punktu docelowego pociągu, zgodnie z opisem w rozdziale 4.2.4.1.

W przypadku transportu kombinowanego na mocy porozumienia umownego LRU/odpowiedzialne RU zapewnia przekazanie komunikatu „Prognoza jazdy pociągu” operatorowi terminalu.

Ponadto komunikat ten musi być wysłany przez IM do RU w odniesieniu do innych punktów raportowania zgodnie z umowami między RU a IM.

Prognozę jazdy pociągu można także wysłać zanim pociąg rozpocznie jazdę. W odniesieniu do dodatkowych opóźnień mających miejsce pomiędzy dwoma punktami raportowania w umowie pomiędzy przedsiębiorstwem kolejowym a zarządcą infrastruktury należy określić wartość progową, na podstawie której podejmowana jest decyzja o wysłaniu pierwotnej lub nowej prognozy. Jeżeli stopień opóźnienia nie jest znany, zarządca infrastruktury musi wysłać „Komunikat o zakłóceniu usługi” (zob. rozdział 4.2.5. „Informacje o zakłóceniu usługi”).

W komunikacie „Prognoza jazdy pociągu” podaje się prognozowany czas w odniesieniu do uzgodnionych punktów prognozy.

Zarządca infrastruktury wysyła ten komunikat do następnego sąsiedniego zarządcy infrastruktury zaangażowanego w przejazd pociągu.

Definicję obowiązkowej struktury komunikatu „Prognoza jazdy pociągu” oraz wymagane elementy podano w wymienionym w dodatku I dokumencie „TAF TSI – Annex D.2: Appendix F – TAF TSI Data and Message Model”.

4.2.4.3. Komunikaty „Informacja o jeździe pociągu” i „Przyczyna opóźnienia pociągu”.

Komunikat „Informacja o jeździe pociągu” musi zostać wysłany przez IM do odpowiedzialnego RU przy:

— odjeździe z punktu odjazdu, przyjeździe do punktu docelowego,

— przyjeździe i odjeździe z punktów przekazania, punktów wymiany oraz punktów raportowania wynikających umowy (np. punktów obsługi).

Gdy tylko znana jest przyczyna opóźnienia (pierwsze założenie), oraz w przypadku aktualizacji informacji na jej temat, IM powinien przekazać te informacje odpowiedzialnemu RU w osobnym komunikacie „Przyczyna opóźnienia pociągu”.

Definicję obowiązkowej struktury komunikatów „Informacja o jeździe pociągu” i „Przyczyna opóźnienia pociągu” oraz wymagane elementy podano w wymienionym w dodatku I dokumencie „TAF TSI – Annex D.2: Appendix F – TAF TSI Data and Message Model”.

4.2.5. Informacje o zakłóceniu usługi

4.2.5.1. Uwagi ogólne

Niniejszy parametr podstawowy określa, w jaki sposób informacje o zakłóceniu usługi są wymieniane pomiędzy przedsiębiorstwem kolejowym a zarządcą infrastruktury.

Jeśli RU uzyska informację o zakłóceniu usługi podczas wykonywania przejazdu pociągiem, za który jest odpowiedzialny, musi niezwłocznie powiadomić stosownego IM (informacja może zostać przekazana przez RU ustnie). Jeżeli dochodzi do wstrzymania jazdy pociągu, zarządca infrastruktury wysyła komunikat „Wstrzymana jazda pociągu” do RU, z którym zawarł umowę, oraz do kolejnego sąsiedniego zarządcy infrastruktury zaangażowanego w jazdę pociągu.

Jeżeli wielkość opóźnienia jest znana, zarządca infrastruktury musi zamiast komunikatu „Wstrzymana jazda pociągu” wysłać komunikat „Prognoza jazdy pociągu”.

4.2.5.2. Komunikat „Wstrzymana jazda pociągu”

Jeżeli jazda pociągu zostaje wstrzymana IM wysyła ten komunikat do kolejnego sąsiedniego IM zaangażowanego w przejazd pociągu i do odpowiedzialnego RU.

W przypadku transportu kombinowanego na mocy porozumienia umownego LRU/RU zapewnia przekazanie komunikatu „Wstrzymana jazda pociągu” operatorowi terminalu.

Definicję obowiązkowej struktury komunikatu „Wstrzymana jazda pociągu” oraz wymagane elementy podano w wymienionym w dodatku I dokumencie „TAF TSI – Annex D.2: Appendix F – TAF TSI Data and Message Model”.

4.2.6. ETI/ETA przesyłki

4.2.6.1. Uwagi wstępne

W rozdziale 4.2.2 („Wniosek o przydzielenie trasy”) opisano głównie komunikację między RU i IM. Indywidualne monitorowanie wagonów lub jednostek intermodalnych nie wchodzi w zakres takiej wymiany informacji. Monitorowanie to odbywa się na poziomie RU/LRU na podstawie komunikatów dotyczących pociągu, co zostało opisane w poniższych rozdziałach, od 4.2.6 („ETI/ETA przesyłki”) do 4.2.7 („Ruch wagonów”).

Podstawę wymiany i aktualizacji informacji dotyczących wagonów i jednostek intermodalnych stanowią zasadniczo przechowywane w bazach „plany podróży” i „dane o ruchach wagonów” (rozdział 4.2.10.2: „Inne bazy danych”).

Dla klienta najważniejszą informacją jest zawsze przewidywany czas przyjazdu (ETA) jego przesyłki i przewidywany czas przyjazdu pociągu (TETA). ETA dotyczący wagonów, a także ETI są również podstawowymi informacjami w komunikacji pomiędzy LRU i RU. Informacje te są dla LRU głównym instrumentem monitorowania fizycznego transportu przesyłki oraz sprawdzania zgodności przebiegu tego transportu z zobowiązaniami wobec klienta.

Wszystkie prognozowane czasy zawarte w komunikatach dotyczących pociągu odnoszą się do przyjazdu pociągu do pewnego punktu, którym może być punkt przekazania, punkt wymiany, punkt docelowy pociągu lub inny punkt raportowania. Wszystkie te pozycje są przewidywanymi czasami przyjazdu pociągu (ang. Train Estimated Times of Arrivals, TETA).

Zgodnie z porozumieniem umownym LRU podaje klientowi w odniesieniu do danej przesyłki przewidywany czas przyjazdu (ETA) oraz przewidywany czas wymiany (ETI), a w odniesieniu do pociągu podaje TETA. Stopień szczegółowości uzgadniany jest przez obie strony w ramach umowy.

W przypadku transportu kombinowanego w komunikatach zawierających identyfikatory jednostek ładunkowych (np. kontenerów, nadwozi wymiennych i naczep) stosuje się kody BIC lub kody ILU zgodnie z, odpowiednio, normą ISO 6346 i normą EN 13044.

4.2.6.2. Obliczanie ETI/ETA

Obliczanie ETI/ETA oparte jest o informacje otrzymane od zarządcy odnośnej infrastruktury, który w komunikacie „Prognoza jazdy pociągu” podaje przewidywany czas przyjazdu pociągu do określonych punktów raportowania (w każdym przypadku w odniesieniu do punktów przekazania, wymiany lub przyjazdu, w tym również terminali intermodalnych) na uzgodnionej trasie, np. czas przyjazdu do punktu przekazania między danym IM a kolejnym IM (w takim przypadku TETA odpowiada ETH).

W odniesieniu do punktów wymiany lub innych określonych punktów raportowania na uzgodnionej trasie RU musi obliczyć na użytek kolejnego RU w łańcuchu przesyłki transportowej przewidywany czas wymiany (ETI) dla wagonów lub jednostek intermodalnych.

Uwaga dotycząca transportu kombinowanego: W przypadku jednostek intermodalnych w wagonie ETI wagonu stanowi również ETI jednostek intermodalnych. W odniesieniu do ETA jednostek intermodalnych należy zauważyć, że RU nie jest w stanie obliczyć takiego ETA ani TETA poza publiczną siecią IM. W związku z tym RU może dostarczyć jedynie ETI odnoszące się do RU działającego w terminalu, które zapewni ETA lub TETA operatorowi terminalu przyjazdowego. W oparciu o te ETA i TETA operator terminalu dostarczy ETP operatorowi transportu kombinowanego, który przekaże ten ETP odbiorcy końcowemu (np. nadawcy towarów, dostawcy usług logistycznych itp.).

Wiodące RU jest odpowiedzialne za porównywanie ETA i TETA ze zobowiązaniem wobec klienta.

W przypadku odchyleń ETA i TETA od czasu określonego w zobowiązaniu wobec klienta należy postępować zgodnie z umową; odchylenia takie mogą prowadzić do wszczęcia przez LRU procesu zarządzania alertem. Do przekazywania informacji o wyniku tego procesu stosuje się komunikat „Alert”.

LRU musi posiadać możliwość wystosowania zapytania o odchylenia dotyczącego pociągów lub wagonów, przy czym możliwość ta stanowi podstawę procesu zarządzania alertem. To zapytanie LRU i odpowiedź RU zostały również określone poniżej.

4.2.6.3. Komunikat „ETI/ETA wagonów”

Odpowiedzialne RU wysyła ten komunikat w celu poinformowania kolejnego odpowiedzialnego RU w łańcuchu transportowym o ETI lub zaktualizowanym ETI.

Wszystkie odpowiedzialne RU w łańcuchu transportowym wagonów wysyłają ETI/ETA lub zaktualizowany ETI/ETA do LRU. Zgodnie z porozumieniem umownym na podstawie zgromadzonych ETI wiodące RU oblicza i przekazuje swojemu klientowi oraz operatorowi terminalu dokładne ETA lub TETA.

Definicję obowiązkowej struktury komunikatu „ETI/ETA wagonów” oraz wymagane elementy podano w wymienionym w dodatku I dokumencie „TAF TSI – Annex D.2: Appendix F – TAF TSI Data and Message Model”.

4.2.6.4. Komunikat „Alert”

W wyniku porównania ETA z zobowiązaniem wobec klienta LRU może wysłać komunikat „Alert” do uczestniczących RU. Definicję obowiązkowej struktury komunikatu „Alert” oraz wymagane elementy podano w wymienionym w dodatku I dokumencie „TAF TSI – Annex D.2: Appendix F – TAF TSI Data and Message Model”.

Uwaga: W przypadku otwartego dostępu obliczenie ETI i ETA jest wewnętrznym procesem RU. W takim przypadku RU jest równocześnie wiodącym RU.

4.2.7. Ruch wagonów

4.2.7.1. Uwagi wstępne

Dane zawarte w wymienionych poniżej komunikatach muszą być przechowane i elektronicznie dostępne do celów raportowania o ruchu wagonu. Muszą one również być wymieniane między upoważnionymi stronami w ramach komunikatu na podstawie umowy.

— Powiadomienie o zwolnieniu wagonu

— Powiadomienie o odjeździe wagonu

— Przyjazd wagonu do stacji rozrządowej

— Wyjazd wagonu ze stacji rozrządowej

— Komunikat o wyjątkowej sytuacji wagonu

— Powiadomienie o przyjeździe wagonu

— Powiadomienie o dostawie wagonu

Na podstawie porozumienia umownego LRU musi udzielać klientowi informacji o ruchu wagonów za pomocą komunikatów opisanych poniżej.

4.2.7.2. Komunikat „Powiadomienie o zwolnieniu wagonu”

Wiodące RU niekoniecznie jest pierwszym RU w łańcuchu transportowym. W takim przypadku LRU musi powiadomić RU odpowiadające za dany przejazd, że wagon jest gotowy do zabrania z bocznicy klienta (miejsce odjazdu zgodnie ze zobowiązaniem LRU) o danym czasie zwolnienia (data i czas odjazdu).

Dane o takich zdarzeniach mogą być przechowywane w operacyjnej bazie danych wagonów i jednostek intermodalnych. Definicję obowiązkowej struktury komunikatu „Powiadomienie o zwolnieniu wagonu” oraz wymagane elementy podano w wymienionym w dodatku I dokumencie „TAF TSI – Annex D.2: Appendix F – TAF TSI Data and Message Model”.

4.2.7.3. Komunikat „Powiadomienie o odjeździe wagonu”

RU musi powiadomić LRU o rzeczywistej dacie i czasie, kiedy wagon został zabrany z miejsca odjazdu.

Dane o takich zdarzeniach mogą być przechowywane w operacyjnej bazie danych wagonów i jednostek intermodalnych. Poprzez wymianę tego komunikatu odpowiedzialność za wagon przechodzi z klienta na RU. Definicję obowiązkowej struktury komunikatu „Powiadomienie o odjeździe wagonu” oraz wymagane elementy podano w wymienionym w dodatku I dokumencie „TAF TSI – Annex D.2: Appendix F – TAF TSI Data and Message Model”.

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

RU musi powiadomić LRU, że wagon przybył do jego stacji rozrządowej. Komunikat ten może być oparty o komunikat „Informacja o jeździe pociągu” opisany w rozdziale 4.2.4 („Prognoza jazdy pociągu”). Dane o tym zdarzeniu mogą być przechowywane w operacyjnej bazie danych wagonów i jednostek intermodalnych. Definicję obowiązkowej struktury komunikatu „Przyjazd wagonu do stacji rozrządowej” oraz wymagane elementy podano w wymienionym w dodatku I dokumencie „TAF TSI – Annex D.2: Appendix F – TAF TSI Data and Message Model”.

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

RU musi powiadomić LRU, że wagon opuścił jego stację rozrządową. Komunikat ten może być oparty o komunikat „Informacja o jeździe pociągu” opisany w rozdziale 4.2.4 („Prognoza jazdy pociągu”). Dane o tym zdarzeniu mogą być przechowywane w operacyjnej bazie danych wagonów i jednostek intermodalnych. Definicję obowiązkowej struktury komunikatu „Wyjazd wagonu ze stacji rozrządowej” oraz wymagane elementy podano w wymienionym w dodatku I dokumencie „TAF TSI – Annex D.2: Appendix F – TAF TSI Data and Message Model”.

4.2.7.6. Komunikat „Wyjątkowa sytuacja wagonu”

RU musi powiadomić LRU, jeśli z wagonem zdarzyło się coś nieoczekiwanego, co mogłoby mieć wpływ na ETI/ETA lub co wymaga dodatkowego działania. W większości przypadków komunikat ten wymaga również obliczenia nowego ETI/ETA. Jeżeli LRU zdecyduje, że konieczne jest określenie nowego ETI/ETA, odsyła komunikat do RU, które wysłało komunikat o wyjątkowej sytuacji, i zawiera w nim wskazanie „Wnioskuje się o ETI/ETA” (komunikaty: „Wyjątkowa sytuacja wagonu”, „Wnioskuje się o ETI/ETA”). Obliczenie nowego ETI/ETA musi być wykonane zgodnie z procedurą podaną w rozdziale 4.2.6 (ETI/ETA przesyłki).

Informacja ta może zostać zachowana w operacyjnej bazie danych wagonów i jednostek intermodalnych. Definicję obowiązkowej struktury komunikatu „Wyjątkowa sytuacja wagonu” oraz wymagane elementy podano w wymienionym w dodatku I dokumencie „TAF TSI – Annex D.2: Appendix F – TAF TSI Data and Message Model”.

4.2.7.7. Komunikat „Powiadomienie o przyjeździe wagonu”

Ostatnie RU w łańcuchu transportowym wagonów lub jednostek intermodalnych musi powiadomić LRU, że wagon przybył do jego stacji rozrządowej (lokalizacja RU). Definicję obowiązkowej struktury komunikatu „Powiadomienie o przyjeździe wagonu” oraz wymagane elementy podano w wymienionym w dodatku I dokumencie „TAF TSI – Annex D.2: Appendix F – TAF TSI Data and Message Model”.

4.2.7.8. Komunikat „Powiadomienie o dostawie wagonu”

Ostatni RU w łańcuchu transportowym wagonów musi powiadomić LRU, że wagon został umieszczony na bocznicy odbiorcy.

Uwaga: W przypadku otwartego dostępu opisany ruch wagonu jest wewnętrznym procesem RU (LRU). Niemniej jednak wszystkie obliczenia i przechowanie danych muszą być wykonane przez niego jako LRU posiadającego umowę i zobowiązanie wobec klienta.

Schemat proceduralny w odniesieniu do tych komunikatów, oparty na przykładzie 1 obliczenia ETI dla wagonów 1 i 2 (zob. rozdział 4.2.6.2: „Obliczanie ETI/ETA”) został zintegrowany ze schematem raportowania wymiany przedstawionym w wymienionym w dodatku I dokumencie „TAF TSI – Annex A.5: Figures and Sequence Diagrams of the TAF TSI messages”, w rozdziale 6.

4.2.8. Wymiana danych w celu poprawy jakości

Aby zachować konkurencyjność, europejskie kolejnictwo musi poprawić jakość usług świadczonych swym klientom (zob. również pkt 2.7.1 w załączniku III do dyrektywy (UE) 2016/797). Proces pomiarowy stanowi zasadniczy proces odbywający się po podróży, mający na celu wspieranie działań na rzecz poprawy jakości. Oprócz mierzenia jakości usługi świadczonej na rzecz klienta LRU, RU i IM muszą mierzyć jakość wszystkich składników usługi, które składają się na produkt dostarczany klientowi. W procesie tym uczestniczą IM i RU (zwłaszcza jeśli są one wiodącymi RU), którzy/które wybierają indywidualny parametr jakości, drogę lub lokalizację oraz okres pomiaru, w odniesieniu do których mają być mierzone rzeczywiste wyniki w stosunku do z góry ustalonych kryteriów, które zazwyczaj są określane w umowie. Wyniki procesu pomiarowego muszą wyraźnie pokazywać poziom osiągnięć względem wartości docelowych, które zostały uzgodnione między stronami umowy.

4.2.9. Główne dane referencyjne

4.2.9.1. Wstęp

By usprawnić proces przygotowania pociągu i eksploatacji wagonów, posiadacz wagonów powinien udostępniać dane dotyczące taboru w referencyjnej bazie danych taboru kolejowego.

4.2.9.2. Referencyjne bazy danych taboru kolejowego

Posiadacz taboru kolejowego jest odpowiedzialny za przechowywanie danych o taborze kolejowym w referencyjnej bazie danych taboru kolejowego.

Informacje, które muszą być zachowywane w indywidualnych referencyjnych bazach danych taboru kolejowego, opisane są szczegółowo w wymienionym w dodatku I dodatku C.

Referencyjne bazy danych taboru kolejowego muszą umożliwiać łatwy dostęp do danych referencyjnych o taborze w celu ograniczenia do minimum objętości danych przesyłanych w ramach każdej operacji. Zawartość baz danych musi być dostępna, na podstawie usystematyzowanych praw dostępu zależnych od uprawnień, dla wszystkich dostawców usług (w szczególności dla IM i RU).

Wpisy w referencyjnej bazie danych taboru kolejowego mogą być pogrupowane w następujących kategoriach:

— dane administracyjne związane z elementami certyfikacji i rejestracji. Dodatkowo, zgodnie z art. 5 rozporządzenia Komisji (UE) nr 445/2011 (2), posiadacze wagonów przechowują numer identyfikacyjny certyfikacji podmiotu odpowiedzialnego za utrzymanie,

— dane projektowe, które muszą obejmować wszystkie składowe (fizyczne) elementy taboru kolejowego, w szczególności informacje potrzebne RU w fazach planowania i eksploatacji pociągu.

Posiadacz jest zobowiązany zapewnić, że dane te są dostępne i że odpowiadające im procesy zostały przeprowadzone;

Definicję obowiązkowej struktury referencyjnej bazy danych taboru oraz wymagane elementy podano w wymienionym w dodatku I dokumencie „TAF TSI – Annex D.2: Appendix F – TAF TSI Data and Message Model”.

4.2.10. Lista plików referencyjnych i referencyjnych baz danych

4.2.10.1. Pliki referencyjne

Na potrzeby eksploatacji pociągów towarowych w sieci europejskiej dostawcy usług (IM, RU, dostawcy usług logistycznych i zarządcy floty pojazdów) muszą mieć dostęp do wskazanych poniżej plików referencyjnych. Dane te muszą w każdym momencie odzwierciedlać rzeczywisty stan rzeczy. W przypadku gdy plik referencyjny jest użytkowany wspólnie z TSI TAP, rozwijanie jego zawartości i wprowadzane w nim zmiany muszą być zgodne z TSI TAP w celu osiągnięcia jak najwyższego stopnia synergii.

Agencja Kolejowa Unii Europejskiej będzie centralnie przechowywać i utrzymywać niepowtarzalne kody w odniesieniu do następujących danych referencyjnych:

— referencyjny plik kodowania dla wszystkich IM, RU, firm będących dostawcami usług,

— referencyjny plik kodowania lokalizacji (podstawowych i drugorzędnych).

Agencja zachowuje kopię referencyjnego pliku podstawowych kodów lokalizacji i kodów przedsiębiorstw. Na indywidualne żądanie i bez uszczerbku dla praw własności intelektualnej, dane te powinny być dostępne dla ogółu społeczeństwa.

Pozostałe listy kodów zostały określone w wymienionym w dodatku I dokumencie „TAF TSI – Annex D.2: Appendix F – TAF TSI Data and Message Model”.

4.2.10.2. Operacyjna baza danych wagonów i jednostek intermodalnych (opcjonalna)

Aby umożliwić śledzenie ruchu pociągów i wagonów, można zainstalować operacyjną bazę danych wagonów i jednostek intermodalnych, aktualizowaną w czasie rzeczywistym przy każdym stosownym zdarzeniu. Upoważnione podmioty, takie jak posiadacze i zarządcy floty pojazdów mogą mieć dostęp do danych istotnych dla pełnienia przez nich ich funkcji zgodnie z warunkami umów.

Komunikacja pomiędzy LRU a RU w trybie współpracy opiera się na numerach wagonów lub jednostek intermodalnych. Dlatego RU, który komunikuje się z IM w odniesieniu do pociągu, musi rozbić podawane informacje na informacje dotyczące wagonów i jednostek intermodalnych. Informacje dotyczące wagonów i jednostek intermodalnych mogą być przechowywane w operacyjnej bazie danych wagonów i jednostek intermodalnych. Napływające informacje o ruchu pociągu powodują konieczność nowych wpisów/aktualizacji danych w operacyjnej bazie danych wagonów i jednostek intermodalnych, podawanych do wiadomości klientowi. Część odnosząca się do danych dotyczących ruchu wagonu lub jednostki intermodalnej jest tworzona w bazie danych najpóźniej w momencie otrzymania od klienta czasu zwolnienia wagonu lub jednostki intermodalnej. Czas zwolnienia jest pierwszym wpisem dotyczącym ruchu wagonu dokonywanym w operacyjnej bazie danych wagonów i jednostek intermodalnych i związanym z rzeczywistą trasą przejazdu. Komunikaty dotyczące ruchu wagonów zostały określone w rozdziale 4.2.7 („Ruch wagonów”). Ta baza danych jest dostępna za pośrednictwem wspólnego interfejsu (rozdziały: 4.2.11.1 „Ogólna architektura” oraz 4.2.11.6 „Wspólny interfejs”).

Operacyjna baza danych wagonów i jednostek intermodalnych służy śledzeniu ruchu wagonów, a przez to również komunikacji pomiędzy uczestniczącymi RU a LRU. Baza ta zawiera dane odzwierciedlające ruch wagonu lub jednostki intermodalnej począwszy od odjazdu po końcową dostawę na bocznicę klienta, wraz z ETI i rzeczywistymi czasami w różnych miejscach, aż po ETA ostatecznej dostawy. Baza zawiera również informację o określonym statusie taboru kolejowego, na przykład:

— Status: załadowywanie taboru kolejowego Status ten jest wymagany do wymiany informacji pomiędzy RU a IM oraz przekazywania ich do innych przedsiębiorstw kolejowych zaangażowanych w wykonywanie transportu pociągiem.

— Status: załadowany wagon w trasie Status ten jest wymagany do wymiany informacji pomiędzy IM a RU, z innymi zarządcami infrastruktury oraz z innymi przedsiębiorstwami kolejowymi zaangażowanymi w wykonywanie transportu pociągiem.

— Status: pusty wagon w trasie Status ten jest wymagany do wymiany informacji pomiędzy IM a RU, z innymi zarządcami infrastruktury oraz innymi przedsiębiorstwami kolejowymi zaangażowanymi w wykonywanie transportu pociągiem.

— Status: rozładowywanie taboru kolejowego Status ten jest wymagany do wymiany informacji pomiędzy RU w punkcie docelowym a LRU zaangażowanym w dany transport.

— Status: pusty wagon pod kontrolą zarządcy floty pojazdów Status ten jest wymagany do uzyskania informacji o dostępności pojazdu o określonej charakterystyce.

4.2.10.3. Dodatkowe wymagania dotyczące baz danych

Każdy system (baza danych) musi być jasno zdefiniowany, a spójność jego danych muszą zapewniać odpowiednie zasady dotyczące dostępności danych i uzyskiwania dostępu do danych.

4.2.11. Łączność sieciowa i komunikacja

4.2.11.1. Architektura ogólna

Celem architektury informatycznej jest wymiana informacji w bezpiecznym, zaufanym środowisku między wszystkimi podmiotami kolejowymi w jednolitym europejskim obszarze kolejowym (SERA).

W ramach omawianego podsystemu rozwinie się z czasem duża i złożona społeczność użytkowników aplikacji telematycznych w sektorze interoperacyjności kolei, w której będzie miała miejsce interakcja pomiędzy setkami uczestniczących podmiotów (RU, IM itd.), które będą konkurować lub współpracować przy zaspokajaniu potrzeb rynku.

Infrastruktura sieci i komunikacji, wspierająca taką społeczność w sektorze interoperacyjności kolei, oparta będzie na wspólnej architekturze wymiany informacji, znanej wszystkim uczestniczącym podmiotom i przez nie przyjętej.

Proponowana architektura wymiany informacji:

— jest przeznaczona do godzenia heterogenicznych modeli informacyjnych poprzez semantyczne przekształcanie danych wymienianych pomiędzy systemami oraz poprzez godzenie różnic w zakresie procesów biznesowych i protokołów na poziomie aplikacji,

— ma minimalny wpływ na istniejące architektury informatyczne wdrożone przez każdy podmiot,

— chroni dokonane już inwestycje informatyczne.

Architektura wymiany informacji jest oparta na stale aktualizowanych powszechnie przyjętych standardach stosowanych w przemyśle informatycznym, które zapewniają odpowiedni poziom cyberbezpieczeństwa względem stwierdzonych zagrożeń. Interakcje między wszystkimi podmiotami muszą gwarantować ogólną integralność i spójność interoperacyjności kolei, zapewniając zestaw scentralizowanych usług.

Wdrożenie koncepcji architektury, np. komunikacji typu „peer-to-peer”, oparte jest na normach technicznych dotyczących wspólnego interfejsu opisanych w zawartym w dodatku I dokumencie technicznym ERA-TD-104 „Annex D.2: Appendix E – Common Interface [Załącznik D.2: Dodatek E – Wspólny interfejs].

Prezentację graficzną architektury ogólnej zawarto w wymienionym w dodatku I dokumencie „TAF TSI – Annex A.5: Figures and Sequence Diagrams of the TAF TSI messages”, w rozdziale 1.5.

4.2.11.2. Sieć i bezpieczeństwo

„Sieć” w tym przypadku oznacza metodę i filozofię komunikacji, a nie fizyczną sieć połączeń.

Sieć zapewnia niezbędny poziom cyberbezpieczeństwa.

Interoperacyjność kolei oparta jest na wspólnej architekturze wymiany informacji, znanej wszystkim uczestnikom i przez nich przyjętej, co stanowi zachętę dla nowych podmiotów na rynku, zwłaszcza klientów, i zmniejsza stojące przed nimi przeszkody.

Koncepcja bezpieczeństwa może być wdrażana na różnych poziomach stosu komunikacyjnego między dwoma podmiotami.

Aby osiągnąć wysoki poziom bezpieczeństwa, wszystkie komunikaty muszą być autonomiczne, co oznacza, że informacje zawarte w komunikatach są zabezpieczone i odbiorca może zweryfikować autentyczność komunikatu. Można to zapewnić przy użyciu systemu szyfrowania i podpisywania podobnego do szyfrowania poczty elektronicznej.

4.2.11.3. Szyfrowanie

Do celów transmisji i przechowywania danych można zastosować szyfrowanie asymetryczne lub symetryczne, w zależności od wymagań biznesowych. W tym celu należy wdrożyć infrastrukturę klucza publicznego (PKI).

Szyfrowanie oparte jest na normach technicznych dotyczących wspólnego interfejsu opisanych w zawartym w dodatku I dokumencie technicznym ERA-TD-104 „Annex D.2: Appendix E – Common Interface [Załącznik D.2: Dodatek E – Wspólny interfejs].

4.2.11.4. Centralne repozytorium

Centralne repozytorium musi być zdolne do obsługiwania:

— metadanych – uporządkowanych danych opisujących zawartość komunikatów,

— infrastruktury klucza publicznego (ang. Public Key Infrastructure, PKI),

— centrum certyfikacji (ang. Certification Authority, CA).

Zarządzanie centralnym repozytorium powinno zostać powierzone niekomercyjnej organizacji ogólnoeuropejskiej. W przypadku gdy centralne repozytorium jest użytkowane w połączeniu z TSI TAP, jego rozwój i zmiany przeprowadza się w sposób możliwie jak najbardziej zbliżony do wdrożonej TSI TAP, tak by osiągnąć optymalny poziom współdziałania.

4.2.11.5. Wspólny interfejs

Zgodność z TSI, w odniesieniu do wymiany danych, oznacza wymianę obowiązkowych elementów katalogu danych TAF (XSD) zgodnie z przepisami rozdziału 4.2 TSI TAF.

W tym celu można korzystać ze specyfikacji wspólnego interfejsu, w tym z zastosowania XSD bez żadnego konkretnego porozumienia między uczestniczącymi podmiotami. Specyfikacje CI powinny być regularnie dostosowywane w celu uwzględnienia nowych technologii komunikacyjnych.

Ponadto możliwe jest połączenie dowolnych technologii komunikacyjnych, jeżeli jest ono zgodne ze specyfikacjami CI i jeżeli między uczestniczącymi podmiotami istnieje szczególne porozumienie.

Wspólny interfejs musi być w stanie obsługiwać:

— formatowanie wychodzących komunikatów zgodnie z metadanymi,

— podpisywanie i szyfrowanie komunikatów wychodzących,

— adresowanie komunikatów wychodzących,

— weryfikację autentyczności komunikatów przychodzących,

— rozszyfrowywanie komunikatów przychodzących,

— kontrole zgodności przychodzących komunikatów przeprowadzane na podstawie metadanych,

— jednorodny wspólny sposób dostępu do różnych baz danych.

Każda instalacja wspólnego interfejsu u każdego posiadacza wagonów, LRU, RU, IM itp. będzie zapewniać dostęp do wszystkich danych wymaganych zgodnie z TSI, bez względu na to, czy odnośne bazy danych są centralne czy indywidualne (zob. również wymieniony w dodatku I dokument „TAF TSI – Annex A.5: Figures and Sequence Diagrams of the TAF TSI messages” rozdział 1.6).

W przypadku gdy wspólny interfejs jest użytkowany wspólnie z TSI TAP, rozwój i zmiany przeprowadza się w sposób możliwie jak najbardziej zbliżony do wdrożonej TSI TAP, tak by osiągnąć optymalny poziom współdziałania. Na podstawie wyników weryfikacji autentyczności komunikatów przychodzących można wdrożyć minimalny poziom potwierdzenia komunikatu:

(i) pozytywny, wyślij ACK;

(ii) negatywny, wyślij NACK.

Do zarządzania powyższymi zadaniami wspólny interfejs wykorzystuje informacje zawarte w centralnym repozytorium.

Jeżeli podmiot wdraża lokalną kopię „lustrzaną” centralnego repozytorium, musi on przy użyciu swoich własnych środków dopilnować, aby stanowiła ona dokładną i aktualną kopię centralnego repozytorium.

4.2.11.6. Protokoły

Na potrzeby opracowywanych systemów stosować można jedynie protokoły należące do zestawu protokołów internetowych (powszechnie znanych jako TCP/IP, UDP/IP itp.).

4.3. Funkcjonalne i techniczne specyfikacje dotyczące interfejsów

W świetle wymagań zasadniczych przedstawionych w rozdziale 3 funkcjonalne i techniczne specyfikacje dotyczące interfejsów są następujące:

4.3.1. Interfejsy z TSI „Infrastruktura”

Podsystem „Infrastruktura” obejmuje systemy zarządzania ruchem, śledzenia i nawigacji: techniczne instalacje do przetwarzania danych i telekomunikacji przeznaczone na potrzeby dalekobieżnych przewozów pasażerskich oraz przewozów towarowych w sieci w celu zagwarantowania bezpiecznej i harmonijnej eksploatacji sieci oraz sprawnego zarządzania ruchem.

Podsystem „Aplikacje telematyczne dla przewozów towarowych” wykorzystuje podane w umowie o trasę dane konieczne do celów operacyjnych, w miarę możliwości uzupełnione danymi dotyczącymi ograniczeń w infrastrukturze, dostarczonymi przez IM. Zatem nie istnieje bezpośredni interfejs pomiędzy niniejszą TSI a TSI dotyczącą infrastruktury.

4.3.2. Interfejsy z TSI „Sterowanie ruchem kolejowym”

Jedyne połączenie ze sterowaniem ruchem kolejowym stanowią:

— umowa o trasę, w której w ramach opisu odcinka trasy podane są stosowne informacje o dostępnych urządzeniach do sterowania ruchem kolejowym, oraz

— różnorodne referencyjne bazy danych taboru kolejowego, w których muszą być przechowane dane urządzeń taboru kolejowego do sterowania ruchem kolejowym.

4.3.3. Interfejsy z podsystemem „Tabor kolejowy”

Podsystem „Aplikacje telematyczne dla przewozów towarowych” określa techniczne i operacyjne dane, które muszą być dostępne w odniesieniu do taboru kolejowego.

W TSI „Tabor kolejowy” określono charakterystykę wagonu. Jeżeli charakterystyka wagonu zmieni się, odpowiednie dane muszą zostać zaktualizowane w referencyjnych bazach danych taboru kolejowego w ramach normalnego procesu utrzymania bazy danych. Zatem nie istnieje bezpośredni interfejs pomiędzy niniejszą TSI a TSI dotyczącą taboru kolejowego.

4.3.4. Interfejsy z TSI „Ruch kolejowy”

Podsystem „Ruch kolejowy” określa procedury i związane z nimi urządzenia umożliwiające spójną obsługę różnych podsystemów strukturalnych, zarówno w normalnych, jak i pogorszonych warunkach eksploatacji, w tym w szczególności prowadzenie pociągu oraz planowanie i zarządzanie ruchem.

Podsystem „Aplikacje telematyczne dla przewozów towarowych” określa głównie aplikacje na potrzeby usług przewozu towarowego, służące między innymi monitorowaniu w czasie rzeczywistym transportu i pociągów oraz zarządzaniu połączeniami z innymi rodzajami transportu. W celu zapewnienia spójności pomiędzy obydwiema TSI obowiązuje podana poniżej procedura.

W przypadku uzupełniania TSI „Ruch kolejowy” o wymagania związane z wymaganiami zawartymi w niniejszej TSI lub wprowadzania w nich zmian należy skonsultować się z organem odpowiedzialnym za niniejszą TSI.

W przypadku wprowadzania zmian w specyfikacjach niniejszej TSI związanych z wymaganiami operacyjnymi określonymi w TSI „Ruch kolejowy” należy skonsultować się z organem odpowiedzialnym za TSI „Ruch kolejowy”.

4.3.5. Interfejsy z podsystemem „Aplikacje telematyczne dla przewozów pasażerskich”

Interfejs Referencyjna TSI dotycząca aplikacji telematycznych dla przewozów towarowych Referencyjna TSI dotycząca aplikacji telematyczne dla przewozów pasażerskich Pociąg gotowy 4.2.3.3. Komunikat „Pociąg gotowy” 4.2.14.1. Komunikat „Pociąg gotowy” w odniesieniu do wszystkich pociągów Prognoza jazdy pociągu 4.2.4.2. Komunikat „Prognoza jazdy pociągu” 4.2.15.2. Komunikat „Prognoza jazdy pociągu” w odniesieniu do wszystkich pociągów Informacja o jeździe pociągu 4.2.4.3. Informacja o jeździe pociągu 4.2.15.1. Komunikat „Informacje o jeździe pociągu” w odniesieniu do wszystkich pociągów Wstrzymana jazda pociągu (komunikat do RU) 4.2.5.2. Wstrzymana jazda pociągu 4.2.16.2. Komunikat „Wstrzymana jazda pociągu” w odniesieniu do wszystkich pociągów Obsługa danych dotyczących rozkładu jazdy pociągów ad-hoc 4.2.2. Wniosek o przydzielenie trasy 4.2.17. Obsługa danych dotyczących rozkładu jazdy pociągów ad-hoc Wspólny interfejs 4.2.11.6. Wspólny interfejs 4.2.21.7. Wspólny interfejs w odniesieniu do komunikacji RU/IM Centralne repozytorium 4.2.11.5. Centralne repozytorium 4.2.21.6. Centralne repozytorium Pliki referencyjne 4.2.10.1. Pliki referencyjne 4.2.19.1. Pliki referencyjne

4.4. Zasady eksploatacji

W świetle wymagań zasadniczych przedstawionych w rozdziale 3 zasady eksploatacji odnoszące się do podsystemu, którego dotyczy niniejsza TSI, są następujące:

4.4.1. Jakość danych

Do celów zapewnienia jakości danych nadawca każdego komunikatu TSI odpowiada za poprawność danych zawartych w komunikacie w momencie jego wysyłania. Jeśli dane źródłowe do celów zapewnienia jakości danych są dostępne w bazach danych wskazanych w niniejszej TSI, dane zawarte w tych bazach danych muszą zostać wykorzystane do zapewnienia jakości danych.

Jeśli dane źródłowe do celów zapewnienia jakości danych nie są dostępne w bazach danych wskazanych w niniejszej TSI, nadawca komunikatu musi we własnym zakresie dokonać weryfikacji w celu zapewnienia jakości danych.

Zapewnienie jakości danych obejmuje porównanie danych z baz danych wskazanych w niniejszej TSI, jak opisano powyżej, a ponadto, w stosownych przypadkach, weryfikację logiczną w celu zapewnienia terminowości i ciągłości danych i komunikatów.

Dane odznaczają się wysoką jakością, jeżeli są odpowiednie do ich przewidzianych zastosowań, to znaczy:

— są wolne od błędów: dostępne, ścisłe, terminowe, kompletne, zgodne z innymi źródłami itp., oraz

— posiadają pożądane cechy: są istotne, wyczerpujące, o odpowiednim poziomie szczegółowości, łatwe do odczytania, łatwe do interpretacji itp.

Jakość danych charakteryzuje przede wszystkim ich:

— ścisłość,

— kompletność,

— spójność,

— terminowość.

Ścisłość:

Wymagane informacje (dane) należy pozyskiwać w sposób możliwie jak najbardziej ekonomiczny. Jest to wykonalne tylko wówczas, gdy zapisywane są jedynie dane pierwotne, w miarę możliwości tylko jednokrotnie w odniesieniu do całego transportu. Z tego względu dane pierwotne powinny być wprowadzane do systemu możliwie jak najbliżej ich źródła, tak by mogły zostać w pełni zintegrowane z każdą późniejszą operacją przetwarzania.

Kompletność:

Przed wysłaniem komunikatów należy przy użyciu metadanych sprawdzić kompletność i składnię. Pozwala to również uniknąć niepotrzebnego ruchu informacji w sieci.

Przy użyciu metadanych należy także sprawdzić wszystkie komunikaty przychodzące pod względem kompletności.

Spójność:

W celu zagwarantowania spójności należy wdrożyć reguły biznesowe. Należy unikać dublowania wpisów, a właściciel danych powinien być wyraźnie zidentyfikowany.

Sposób wdrażania tych reguł biznesowych zależy od złożoności danej reguły. W przypadku prostych reguł wystarczają ograniczenia i wyzwalacze w bazach danych. W przypadku bardziej złożonych reguł, które wymagają danych z różnych tabel, należy wdrożyć procedury walidacji służące sprawdzeniu spójności wersji danych, zanim zostaną wygenerowane dane na potrzeby interfejsu i nowa wersja danych zostanie udostępniona. Należy zagwarantować, że przesyłane dane są poddawane walidacji w oparciu o zdefiniowane reguły biznesowe.

Terminowość:

Istotne jest, aby informacje były udzielane we właściwym czasie. Jeśli uruchomienie rejestracji danych lub wysłanie komunikatu następuje w wyniku zdarzenia bezpośrednio w systemie informatycznym, terminowość nie stanowi problemu, pod warunkiem że system jest zaprojektowany w sposób prawidłowy i zgodnie z potrzebami procesów biznesowych. Jednak w większości przypadków wysłanie komunikatu inicjowane jest przez operatora lub przynajmniej wymaga wykonania przez niego dodatkowej czynności. Aby spełnić wymagania dotyczące terminowości należy możliwie jak najwcześniej dokonywać aktualizacji danych – także w celu zagwarantowania, by dane zawarte w komunikatach były zawsze aktualne w momencie, gdy są rozsyłane automatycznie przez system.

Czas odpowiedzi na zapytania musi być uwzględniony w ramach szczegółowych specyfikacji informatycznych w odniesieniu do różnych aplikacji i typów użytkowników. Wszystkie aktualizacje i wymiany danych muszą być dokonywane możliwie jak najwcześniej.

Wskaźniki jakości danych:

W szczegółowych specyfikacjach informatycznych należy określić odpowiednie wartości procentowe w odniesieniu do:

— kompletności danych (odsetek pól danych, do których wpisano wartości) oraz ich spójności (odsetek odpowiadających sobie wartości w obrębie tabel/plików/rekordów),

— terminowości danych (odsetek danych dostępnych w określonych progowych ramach czasowych),

— wymaganej ścisłości (odsetek przechowywanych wartości, które są zgodne z wartościami faktycznymi).

4.4.2. Obsługa centralnego repozytorium

Funkcje centralnego repozytorium zostały określone w rozdziale 4.2.11.5 („Centralne repozytorium”). Na potrzeby zapewnienia jakości danych podmiot obsługujący centralne repozytorium jest odpowiedzialny za aktualizację oraz jakość metadanych i katalogu, a także za administrowanie kontrolą dostępu. Jakość metadanych pod względem kompletności, spójności, terminowości i ścisłości powinna umożliwić odpowiednie funkcjonowanie do celów niniejszej TSI.

4.5. Zasady utrzymania

W świetle wymagań zasadniczych przedstawionych w rozdziale 3 zasady utrzymania odnoszące się do podsystemu, którego dotyczy niniejsza TSI, są następujące:

Jakość usługi transportowej musi być zagwarantowana, nawet gdyby sprzęt do przetwarzania danych uległ całkowitej lub częściowej awarii. W związku z tym zalecane jest zainstalowanie systemów dupleksowych lub komputerów o szczególnie wysokim stopniu niezawodności, w przypadku których zapewnione jest ich nieprzerwane działanie podczas utrzymania.

Aspekty utrzymania dotyczące poszczególnych baz danych wymienione zostały w rozdziale 4.2.10.3 („Dodatkowe wymagania dotyczące baz danych”).

4.6. Kwalifikacje zawodowe

Kwalifikacje zawodowe personelu wymagane do eksploatacji i utrzymania podsystemu i do wdrożenia TSI są następujące:

Wdrożenie niniejszej TSI nie wymaga ani zupełnie nowego systemu w zakresie sprzętu i oprogramowania, ani nowego personelu. Działania mające na celu spełnienie wymagań określonych w TSI związane są jedynie z wprowadzaniem zmian, unowocześnień lub rozszerzeń funkcjonalnych w eksploatacji, dokonywanym – tak jak dotychczas – przez istniejący personel. W związku z tym nie określono dodatkowych wymagań do istniejących krajowych lub europejskich przepisów dotyczących kwalifikacji zawodowych.

Gdyby wystąpiła konieczność przeprowadzenia dodatkowych szkoleń dla personelu, nie powinny one polegać jedynie na zademonstrowaniu, jak należy obsługiwać sprzęt. Członek personelu musi znać i rozumieć swoją konkretną rolę, jaką ma do odegrania w całym procesie transportu. Personel musi w szczególności być świadomy wymogu utrzymania wysokiej jakości wykonywanej przez niego pracy, gdyż jest to czynnikiem decydującym o rzetelności informacji, które będą przetwarzane na kolejnym etapie.

Kwalifikacje zawodowe potrzebne do zestawiania i eksploatacji pociągów zostały określone w TSI „Ruch kolejowy”.

4.7. Warunki bezpieczeństwa i higieny pracy

Warunki BHP personelu wymagane w odniesieniu do obsługi i utrzymania przedmiotowego podsystemu (lub zakresu technicznego określonego w ust. 1.1) oraz do wdrożenia niniejszej TSI są następujące:

Nie określono dodatkowych wymagań do istniejących krajowych i europejskich przepisów w zakresie BHP.

5. SKŁADNIKI INTEROPERACYJNOŚCI

5.1. Definicja

Zgodnie z art. 2 ust. 7 dyrektywy (UE) 2016/797:

„»składniki interoperacyjności« oznaczają wszelkie elementarne składniki, grupy części składowych, podzespoły lub pełne zespoły sprzętowe, włączone lub mające być włączone do podsystemu, od których bezpośrednio lub pośrednio zależy system kolei. Pojęcie »składnik« obejmuje zarówno przedmioty materialne, jak i niematerialne, takie jak oprogramowanie”.

5.2. Wykaz składników

Składniki interoperacyjności są objęte stosownymi przepisami dyrektywy (UE) 2016/797.

W odniesieniu do podsystemu „Aplikacje telematyczne dla przewozów towarowych” składniki interoperacyjności nie zostały określone.

Do spełnienia wymagań określonych w niniejszej TSI potrzebny jest jedynie standardowy sprzęt informatyczny, wobec którego nie stawia się żadnych szczególnych wymogów związanych z interoperacyjnością w środowisku kolejowym. Dotyczy to zarówno części składowych sprzętu, jak i stosowanego standardowego oprogramowania, takiego jak system operacyjny i bazy danych. Oprogramowanie użytkowe stanowi indywidualny wybór każdego użytkownika i może być dostosowywane i udoskonalane stosownie do jego faktycznych funkcji i potrzeb. Proponowana „architektura integracji aplikacji” zakłada, że aplikacje mogą nie być oparte na tym samym wewnętrznym modelu informacyjnym. Integrację aplikacji zdefiniowano jako proces umożliwiający współpracowanie ze sobą niezależnie zaprojektowanych systemów aplikacji.

5.3. Charakterystyki wydajnościowe i specyfikacje dotyczące składników

Zob. rozdział 5.2, nie dotyczy TSI „Aplikacje telematyczne dla przewozów towarowych”.

6. OCENA ZGODNOŚCI SKŁADNIKÓW LUB ICH PRZYDATNOŚCI DO STOSOWANIA ORAZ WERYFIKACJA PODSYSTEMU

6.1. Składniki interoperacyjności

6.1.1. Procedury oceny

Nie dotyczy TSI „Aplikacje telematyczne dla przewozów towarowych”.

6.1.2. Moduł

Nie dotyczy TSI „Aplikacje telematyczne dla przewozów towarowych”.

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

Zgodnie z załącznikiem II do dyrektywy (UE) 2016/797 podsystemy można podzielić na podsystemy strukturalne i eksploatacyjne (funkcjonalne).

Ocena zgodności jest obowiązkowa w przypadku TSI dotyczącej podsystemu strukturalnego. Podsystem „Aplikacje telematyczne dla przewozów towarowych” stanowi podsystem funkcjonalny, w związku z tym w niniejszej TSI nie określono żadnych modułów służących ocenie zgodności.

6.2.1. Ocena zgodności narzędzi informatycznych

Projekty odpowiedzialne za narzędzia informatyczne stosowane przez europejski sektor kolejowy mogą zwrócić się do Agencji z wnioskiem o przeprowadzenie oceny zgodności tych narzędzi z wymogami TSI.

Do wniosku o przeprowadzenie oceny dołącza się:

— Dokument opisujący przypadek użycia, zawierający:

— informację o funkcji TSI TAF, której dotyczy,

— odniesienie do rozdziału TAF TSI,

— wykaz i dokumentację komunikatów (w tym informacje o ich sekwencji) na potrzeby badania zgodności,

— opis systemu informatycznego wykorzystującego komunikaty TAF,

— opis interfejsu komunikacyjnego systemu informatycznego (CI, inny itp.),

— informację, czy wniosek dotyczy celu pośredniego projektu finansowanego przez UE,

— informację o wersji dokumentów technicznych TSI TAF mających znaczenie dla oceny zgodności,

— plik(-i) XML systemu informatycznego i odpowiadający(-e) im plik(-i) XSD.

Agencja przeprowadza badanie zgodności TSI TAF i w terminie 3 miesięcy od potwierdzenia kompletności wydaje wnioskodawcy oficjalne sprawozdanie dotyczące oceny zgodności. Sprawozdanie to obejmuje następujące aspekty:

— czy komunikaty zawierają wszystkie obowiązkowe elementy TSI TAF,

— czy komunikaty są zgodne z dokumentami technicznymi TSI TAF,

— czy sekwencja komunikatów jest zgodna z TSI TAF.

Do badania zgodności, w celu sprawdzenia, czy zawierają elementy obowiązkowe uwzględnione w TSI TAF, mogą być również przekazane komunikaty inne niż XML. W takim przypadku zamiast pliku(-ów) XSD systemu informatycznego przekazuje się opis struktury komunikatu wraz z opisem elementów/pól danych, podając w stosownych przypadkach informacje o zastosowanych standardach i ich wersji.

7. WDROŻENIE

7.1. Wstęp

Niniejsza TSI dotyczy podsystemu „Aplikacje telematyczne dla przewozów towarowych”. Zgodnie z załącznikiem II do dyrektywy (UE) 2016/797 jest to podsystem funkcjonalny. Dlatego stosowanie niniejszej TSI nie opiera się na koncepcji nowego, odnowionego czy zmodernizowanego podsystemu, jak dzieje się zazwyczaj w przypadku TSI dotyczących podsystemów strukturalnych, z wyjątkiem przypadków określonych w TSI.

a) Zarządzanie projektem Etapem opracowywania i etapem wdrożenia zarządza komitet sterujący. Komitet sterujący zapewnia strukturę zarządzania strategicznego w celu skutecznego zarządzania pracami zmierzającymi do wdrożenia TSI TAF oraz koordynacji takich prac. Obejmuje to ustalanie polityki, kierunku strategicznego i priorytetów. W skład komitetu sterującego, któremu przewodniczą wspólnie Komisja oraz osoba wyznaczona przez organy przedstawicielskie sektora kolei, wchodzą: — organy przedstawicielskie sektora kolei działające na szczeblu europejskim, określone w art. 5 ust. 3 rozporządzenia (UE) 2016/796 („organy przedstawicielskie sektora kolei”), — Agencja, — Komisja oraz — inne organizacje, co do których złożono wniosek o to, aby komitet sterujący uwzględnił je w charakterze obserwatorów, jeżeli jest to uzasadnione ze względów technicznych i organizacyjnych.

b) Rozwój systemu Wszystkie zaangażowane podmioty wdrażają system zgodnie ze swoimi indywidualnymi planami generalnymi. W przypadku podmiotów, które nie przedłożyły indywidualnego planu generalnego, wiążący jest ich indywidualny plan, który zakomunikowały.

c) Proces monitorowania wdrażania i funkcjonowania Monitorowaniem zharmonizowanego w całej Europie wdrażania i funkcjonowania zarządza Grupa Współpracy ds. Wdrażania TAF (ang. TAF Implementation Cooperation Group, ICG). W skład ICG, utworzonej i zarządzanej przez Agencję, wchodzą: — Agencja, — krajowe punkty kontaktowe (zob. dodatek III), — organy przedstawicielskie oraz — inne organizacje wyznaczone przez Agencję i posiadające odpowiednie doświadczenie techniczne i organizacyjne. ICG jest odpowiedzialna za: — ocenę postępów we wdrażaniu i funkcjonowaniu, analizę odstępstw od planu generalnego oraz proponowanie działań usprawniających, — wspieranie krajowych punktów kontaktowych w monitorowaniu wdrażania i funkcjonowania TSI TAF na szczeblu krajowym, — zatwierdzanie sprawozdań dotyczących wdrażania i funkcjonowania TSI TAF, — składanie sprawozdań Komisji Europejskiej za pośrednictwem Agencji.

7.2. Zarządzanie zmianami

7.2.1. Proces zarządzania zmianami

Należy opracować procedury zarządzania zmianami w celu zapewnienia, by koszty i korzyści każdej zmiany zostały odpowiednio przeanalizowane, a zmiany były wprowadzane w kontrolowany sposób. Procedury te są określane, wdrażane, wspierane i zarządzane przez Agencję i obejmują:

— określenie ograniczeń technicznych leżących u podstaw zmiany,

— oświadczenie podmiotu przyjmującego odpowiedzialność za procedury wdrażania zmian,

— procedurę potwierdzenia zmian, które mają być wdrażane,

— politykę zarządzania zmianami i wersjami oraz migracji i wprowadzania zmian,

— określenie podziału odpowiedzialności w zakresie zarządzania szczegółowymi specyfikacjami oraz zapewnienia jakości i zarządzania konfiguracją.

W skład Komisji Kontroli Zmian (ang. Change Control Board, CCB) wchodzą Agencja, organy przedstawicielskie sektora kolei i państwa członkowskie. Taki skład zapewni odpowiednie podejście do zmian, które mają być wprowadzone, oraz wszechstronną ocenę ich konsekwencji. Docelowo CCB ma działać pod egidą Agencji.

7.2.2. Szczególny proces zarządzania zmianami dotyczący dokumentów wymienionych w dodatku I do niniejszego rozporządzenia

Agencja ustanawia zarządzanie zmianami w odniesieniu do dokumentów wymienionych w dodatku I do niniejszego rozporządzenia zgodnie z następującymi kryteriami:

1) Wnioski o wprowadzenie zmian mających wpływ na dokumenty są składane za pośrednictwem państw członkowskich lub organów przedstawicielskich sektora kolei działających na szczeblu europejskim, określonych w art. 38 ust. 4 rozporządzenia (UE) 2016/796, lub też za pośrednictwem komitetu sterującego TSI TAF.

2) Agencja gromadzi i przechowuje wnioski o wprowadzenie zmian.

3) Agencja kieruje wnioski o wprowadzenie zmian do odpowiedniej grupy roboczej Agencji, która je ocenia i sporządza propozycję, w razie potrzeby wraz z oceną ekonomiczną.

4) Następnie Agencja kieruje każdy wniosek o wprowadzenie zmiany i powiązaną propozycję do Komisji Kontroli Zmian, która dokonuje lub odmawia potwierdzenia zmiany lub też odkłada ją w czasie.

5) Jeżeli wniosek o wprowadzenie zmiany nie zostaje potwierdzony, Agencja przekazuje wnioskodawcy uzasadnienie odrzucenia wniosku lub prośbę o przedłożenie dodatkowych informacji dotyczących projektu wniosku o wprowadzenie zmian.

6) Jeżeli wniosek o wprowadzenie zmiany zostaje potwierdzony, w dokumencie technicznym wprowadza się zmiany.

7) Jeżeli nie można osiągnąć konsensusu w kwestii potwierdzenia wniosku o wprowadzenie zmiany, Agencja przedkłada Komisji zalecenie aktualizacji dokumentów wymienionych w dodatku I, wraz z projektem nowej wersji dokumentu, wnioskami o wprowadzenie zmian i ich oceną ekonomiczną, oraz udostępnia te dokumenty na swojej stronie internetowej.

8) Agencja udostępnia na swojej stronie internetowej nową wersję dokumentu technicznego wraz z potwierdzonymi wnioskami o wprowadzenie zmian. Agencja będzie na bieżąco informować państwa członkowskie za pośrednictwem komitetu ustanowionego zgodnie z art. 51 ust. 1 dyrektywy (UE) 2016/797.

9) Jeżeli wniosek o wprowadzenie zmiany wymagałby zmiany tekstu przepisów TSI TAF, Agencja przesyła Komisji Europejskiej wniosek dotyczący wniesienia o dokonanie przeglądu TSI TAF lub o opinię techniczną Agencji.

10) W przypadkach gdy zarządzanie zmianami ma wpływ na elementy pozostające we wspólnym użytkowaniu w ramach TSI TAP, zmian dokonuje się w taki sposób, aby zachować zgodność z już wdrożoną TSI TAP w celu osiągnięcia jak największego stopnia synergii.

(1) Rozporządzenie wykonawcze Komisji (UE) 2019/773 z dnia 16 maja 2019 r. w sprawie technicznej specyfikacji interoperacyjności w zakresie podsystemu „Ruch kolejowy” systemu kolei w Unii Europejskiej i uchylające decyzję 2012/757/UE (Dz.U. L 139 I z 27.5.2019, s. 5).

(2) Rozporządzenie Komisji (UE) nr 445/2011 z dnia 10 maja 2011 r. w sprawie systemu certyfikacji podmiotów odpowiedzialnych za utrzymanie w zakresie obejmującym wagony towarowe oraz zmieniające rozporządzenie (WE) nr 653/2007 (Dz.U. L 122 z 11.5.2011, s. 22).