Artykuł 1

Przedmiot

Niniejszym przyjmuje się przedstawioną w załączniku techniczną specyfikację interoperacyjności odnoszącą się do podsystemu aplikacji telematycznych dla przewozów towarowych wchodzącego w skład europejskiego systemu kolei.

Artykuł 2

Zakres

Artykuł 3

Aktualizacja dokumentów technicznych i sprawozdawczość w tym zakresie

Agencja udostępnia za pośrednictwem swej strony internetowej kody lokalizacji i kody przedsiębiorstw, o których mowa w pkt 4.2.11.1 (lit. b) i d)) oraz dokumenty techniczne, o których mowa w pkt 7.2 załącznika, a także składa Komisji sprawozdanie dotyczące ich aktualizacji.

Komisja informuje państwa członkowskie o aktualizacji wspomnianych dokumentów za pośrednictwem komitetu ustanowionego zgodnie z art. 29 ust. 1 dyrektywy 2008/57/WE.

Artykuł 4

Zgodność z sieciami w państwach nienależących do UE

W odniesieniu do kolejowych przewozów towarowych wykonywanych z lub do państw trzecich zgodność z wymaganiami zawartymi w TSI przedstawionej w załączniku jest uzależniona od dostępności informacji ze strony podmiotów spoza UE, chyba że wymiana informacji zgodna z TSI jest przewidziana w umowach dwustronnych.

Artykuł 5

Wdrożenie

Artykuł 6

Uchylenie

Rozporządzenie (WE) nr 62/2006 zostaje uchylone z dniem wejścia w życie niniejszego rozporządzenia.

Artykuł 7

Wejście w życie i stosowanie

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

Niniejsze rozporządzenie stosuje się od dnia 1 stycznia 2015 r.

ZAŁĄCZNIK

SPIS TREŚCI

1.

WPROWADZENIE

443

1.1.

Skróty

443

1.2.

Dokumenty referencyjne

444

1.3.

Zakres techniczny

445

1.4.

Zakres geograficzny

445

1.5.

Treść niniejszej TSI TAF

445

2.

DEFINICJA PODSYSTEMU I ZAKRES

446

2.1.

Funkcja wchodząca w zakres TSI

446

2.2.

Funkcje nie wchodzące w zakres TSI

446

2.3.

Przegląd opisu podsystemu

446

2.3.1.

Uczestniczące podmioty

446

2.3.2.

Rozpatrywane procesy

448

2.3.3.

Uwagi ogólne

449

3.

WYMAGANIA ZASADNICZE

450

3.1.

Zgodność z wymaganiami zasadniczymi

450

3.2.

Aspekty wymagań zasadniczych

450

3.3.

Aspekty związane z wymaganiami ogólnymi

451

3.3.1.

Bezpieczeństwo

451

3.3.2.

Niezawodność i dostępność

451

3.3.3.

Zdrowie

451

3.3.4.

Ochrona środowiska

451

3.3.5.

Zgodność techniczna

451

3.4.

Aspekty dotyczące w szczególności podsystemu „Aplikacje telematyczne dla przewozów towarowych”

451

3.4.1.

Zgodność techniczna

451

3.4.2.

Niezawodność i dostępność

451

3.4.3.

Zdrowie

452

3.4.4.

Bezpieczeństwo

452

4.

CHARAKTERYSTYKA PODSYSTEMU

452

4.1.

Wstęp

452

4.2.

Funkcjonalne i techniczne specyfikacje podsystemu

452

4.2.1.

Dane listu przewozowego

453

4.2.2.

Wniosek o przydzielenie trasy

454

4.2.3.

Przygotowanie pociągu

455

4.2.4.

Prognoza jazdy pociągu

456

4.2.5.

Informacje o zakłóceniu usługi

457

4.2.6.

ETI/ETA przesyłki

458

4.2.7.

Ruch wagonów

459

4.2.8.

Raportowanie o wymianie

460

4.2.9.

Wymiana danych w celu poprawy jakości

461

4.2.10.

Główne dane referencyjne

462

4.2.11.

Lista plików referencyjnych i referencyjnych baz danych

463

4.2.12.

Łączność sieciowa i komunikacja

466

4.3.

Funkcjonalne i techniczne specyfikacje dotyczące interfejsów

468

4.3.1.

Interfejsy z TSI „Infrastruktura”

468

4.3.2.

Interfejsy z TSI „Sterowanie ruchem kolejowym”

468

4.3.3.

Interfejsy z podsystemem „Tabor kolejowy”

468

4.3.4.

Interfejsy z TSI „Ruch kolejowy”

468

4.3.5.

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

469

4.4.

Zasady eksploatacji

469

4.4.1.

Jakość danych

469

4.4.2.

Obsługa centralnego repozytorium

471

4.5.

Zasady utrzymania

471

4.6.

Kwalifikacje zawodowe

471

4.7.

Warunki bezpieczeństwa i higieny pracy

471

5.

SKŁADNIKI INTEROPERACYJNOŚCI

471

5.1.

Definicja

471

5.2.

Wykaz składników

471

5.3.

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

472

6.

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

472

6.1.

Składniki interoperacyjności

472

6.1.1.

Procedury oceny

472

6.1.2.

Moduł

472

6.1.3.

Posystem „Aplikacje telematyczne dla przewozów towarowych”

472

7.

WDROŻENIE

473

7.1.

Tryb stosowania niniejszej TSI

473

7.1.1.

Wstęp

473

7.1.2.

Etap pierwszy — szczegółowe specyfikacje informatyczne i plan generalny

473

7.1.3.

Etap 2 i 3 — opracowanie i wdrożenie

473

7.1.4.

Zarządzanie, role i podział odpowiedzialności

473

7.2.

Zarządzanie zmianami

475

7.2.1.

Proces zarządzania zmianami

475

7.2.2.

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

475

Dodatek I:

Wykaz dokumentów technicznych

476

Dodatek II:

Glosariusz

477

Dodatek III:

Zadania krajowego punktu kontaktowego ds. TAF/TAP

488

1.   WPROWADZENIE

1.1.   Skróty

Tabela 1

Skróty

Skrót	Definicja
ANSI	Amerykański Narodowy Instytut Normalizacyjny (American National Standards Institute)
CI	Wspólny interfejs (ang. Common Interface)
CR	Wniosek o wprowadzenie zmian (ang. Change Request)
KE	Komisja Europejska
ERA	Europejska Agencja Kolejowa (zwana dalej również „agencją”)
ERTMS	Europejski system zarządzania ruchem kolejowym (ang. European Rail Traffic Management System)
ETCS	Europejski system sterowania pociągiem (ang. European Train Control System)
IM	Zarządca infrastruktury (ang. Infrastructure Manager)
ISO	Międzynarodowa Organizacja Normalizacyjna
LAN	Lokalna sieć komputerowa (ang. Local Area Network)
LCL	Przesyłki drobnicowe (ang. Less than Container Loads)
LRU	Wiodące przedsiębiorstwo kolejowe (ang. Lead Railway Undertaking)
ONC	Otwarta sieć obliczeniowa (ang. Open Network Computing)
OTIF	Międzyrządowa Organizacja Międzynarodowych Przewozów Kolejami (Intergovernmental Organization for International Carriage by Rail)
PVC	Stały obwód wirtualny (ang. Permanent Virtual Circuit)
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
TEN	Sieć transeuropejska
TSI	Techniczna specyfikacja interoperacyjności
WK	Posiadacze wagonów (ang. Wagon Keepers)
WP	Grupa robocza (ang. Working Party) powołana przez ERA

1.2.   Dokumenty referencyjne

Tabela 2

Dokumenty referencyjne

Nr ref.	Tytuł skrócony/odniesienie	Tytuł	Data ostatniego wydania:
[1]	Dyrektywa 2008/57/WE	Dyrektywa Parlamentu Europejskiego i Rady 2008/57/WE z dnia 17 czerwca 2008 r. w sprawie interoperacyjności systemu kolei we Wspólnocie (Dz.U. L 191 z 18.7.2008, s. 1)	17.6.2008
[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)	5.5.2011
[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).	21.11.2012
[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]	22.3.2013
[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]	Rozporządzenie Komisji (UE) nr 280/2013	Rozporządzenie Komisji (UE) nr 280/2013 z dnia 22 marca 2013 r. zmieniające rozporządzenie (WE) nr 62/2006 dotyczące technicznej specyfikacji dla interoperacyjności odnoszącej się do podsystemu aplikacji telematycznych dla przewozów towarowych transeuropejskiego systemu kolei konwencjonalnych (Dz.U. L 84 z 23.3.2013, s. 17)	22.3.2013
[7]	Rozporządzenie Komisji (UE) nr 328/2012	Rozporządzenie Komisji (UE) nr 328/2012 z dnia 3 maja 2012 r. zmieniające rozporządzenie (WE) nr 62/2006 dotyczące technicznej specyfikacji dla interoperacyjności odnoszącej się do podsystemu aplikacji telematycznych dla przewozów towarowych transeuropejskiego systemu kolei konwencjonalnych (Dz.U. L 106 z 18.4.2012, s. 14)	17.4.2012
[8]	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
[9]	Dyrektywa 2004/49/WE	Dyrektywa 2004/49/WE Parlamentu Europejskiego i Rady z dnia 29 kwietnia 2004 r. w sprawie bezpieczeństwa kolei wspólnotowych oraz zmieniająca dyrektywę Rady 95/18/WE w sprawie przyznawania licencji przedsiębiorstwom kolejowym, oraz dyrektywę 2001/14/WE w sprawie alokacji zdolności przepustowej infrastruktury kolejowej i pobierania opłat za użytkowanie infrastruktury kolejowej oraz certyfikację w zakresie bezpieczeństwa (Dyrektywa w sprawie bezpieczeństwa kolei) (Dz.U. L 164 z 30.4.2004, s. 44)	28.11.2009
[10]	Dyrektywa 2001/13/WE	Dyrektywa 2001/13/WE Parlamentu Europejskiego i Rady z dnia 26 lutego 2001 r. zmieniająca dyrektywę Rady 95/18/WE w sprawie przyznawania licencji przedsiębiorstwom kolejowym (Dz.U. L 75 z 15.3.2001, s. 26)	26.2.2001

1.3.   Zakres techniczny

Niniejsza techniczna specyfikacja interoperacyjności (dalej zwana „TSI TAF”) odnosi się do elementu „aplikacje telematyczne dla przewozów towarowych” podsystemu „aplikacje telematyczne” wymienionego w wykazie podsystemów eksploatacyjnych (funkcjonalnych) zamieszczonym w załączniku II do dyrektywy 2008/57/WE [1].

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

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

Zakres techniczny niniejszej TSI został również określony w art. 2 ust. 1 i 3 niniejszego rozporządzenia.

1.4.   Zakres geograficzny

Zakres geograficzny niniejszej TSI obejmuje sieć całego systemu kolei składającą się z:

—	sieci transeuropejskiego systemu kolei konwencjonalnej (TEN) opisanej w sekcji 1.1 „Sieć” załącznika I do dyrektywy 2008/57/WE [1],

—	sieci transeuropejskiego systemu kolei dużych prędkości (TEN) opisanej w sekcji 2.1 „Sieć” załącznika I do dyrektywy 2008/57/WE [1],

—	pozostałych części sieci całego systemu kolei, w wyniku rozszerzenia zakresu zgodnie z opisem zawartym w sekcji 4 załącznika I do dyrektywy 2008/57/WE [1].

Zakres ten nie obejmuje natomiast przypadków, o których mowa w art. 1 ust. 3 dyrektywy 2008/57/WE [1].

1.5.   Treść niniejszej TSI TAF

Treść niniejszej TSI TAF jest zgodna z art. 5 dyrektywy 2008/57/WE [1].

W niniejszej TSI zawarto również w rozdziale 4 („Charakterystyka podsystemu”) wymagania dotyczące eksploatacji i utrzymania, których zakres odpowiada zakresowi określonemu w ustępach 1.1 („Zakres techniczny”) i 1.2 („Zakres geograficzny”).

2.   DEFINICJA PODSYSTEMU I ZAKRES

2.1.   Funkcja wchodząca w zakres TSI

Podsystem „Aplikacje telematyczne dla przewozów towarowych” został określony w załączniku II do dyrektywy 2008/57/WE [1], sekcja 2.5 lit. b).

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

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

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

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

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

2.2.   Funkcje niewchodzące w zakres TSI

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

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

2.3.   Przegląd opisu podsystemu

2.3.1.   Uczestniczące podmioty

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

—	wagony towarowe,

—	lokomotywy,

—	maszyniści,

—	manewrowanie i rozrządzanie,

—	sprzedaż przedziałów czasowych,

—	zarządzanie przesyłką,

—	skład pociągu,

—	eksploatacja pociągu,

—	monitorowanie pociągu,

—	sterowanie pociągiem,

—	monitorowanie przesyłki,

—	kontrole i naprawy wagonów lub lokomotyw,

—	odprawa celna,

—	obsługa terminali intermodalnych,

—	zarządzanie przewozami.

Pewni określeni dostawcy usług są zdefiniowani bezpośrednio w tekście dyrektyw 2012/34/UE [3], 2008/57/WE [1] i 2004/49/WE [9]. Ponieważ wspomniane dyrektywy muszą zostać uwzględnione, w TSI wzięto pod uwagę w szczególności poniższe definicje:

„Zarządca infrastruktury” (IM) (dyrektywa 2012/34/UE [3]) oznacza każdy podmiot lub przedsiębiorstwo, które są odpowiedzialne w szczególności za założenie infrastruktury kolejowej, zarządzanie nią i jej utrzymanie, w tym za prowadzenie ruchu pociągów, urządzenia bezpiecznej kontroli jazdy i urządzenia sterowania ruchem kolejowym (srk); funkcje zarządcy infrastruktury na sieci lub części sieci mogą być przydzielane różnym podmiotom lub przedsiębiorstwom. W przypadku gdy zarządca infrastruktury pod względem prawnym, organizacyjnym lub w zakresie podejmowania decyzji nie jest niezależny od któregokolwiek przedsiębiorstwa kolejowego, funkcje, o których mowa w sekcjach 2 i 3 rozdziału IV, są wykonywane odpowiednio przez organ pobierający opłaty i przez organ alokujący, które są niezależne w swojej formie prawnej, organizacyjnej i w zakresie podejmowania decyzji od któregokolwiek przedsiębiorstwa kolejowego. W oparciu o tę definicję w ramach niniejszej TSI za IM uważa się dostawcę usług w zakresie przydzielania tras, sterowania/monitorowania pociągów oraz sprawozdawczości związanej z pociągami/trasami.

„Wnioskodawca” (dyrektywa 2012/34/UE [3]) oznacza przedsiębiorstwo kolejowe lub międzynarodowe ugrupowanie przedsiębiorstw kolejowych lub inne osoby lub podmioty prawne, takie jak właściwe organy w rozumieniu rozporządzenia (WE) nr 1370/2007 oraz spedytorzy, nadawcy towarów i operatorzy transportu kombinowanego, którzy ze względu na świadczenie usługi publicznej lub ze względów handlowych są zainteresowani uzyskaniem zdolności przepustowej infrastruktury.

„Przedsiębiorstwo kolejowe” (dyrektywa 2004/49/WE [9]) oznacza przedsiębiorstwo zdefiniowane w dyrektywie 2001/14/WE oraz każde publiczne lub prywatne przedsiębiorstwo, którego działalność polega na dokonywaniu transportu towarów i/lub pasażerów koleją, z zastrzeżeniem, że przedsiębiorstwo to musi zapewnić trakcję; obejmuje to również przedsiębiorstwa, które dostarczają wyłącznie trakcję. W oparciu o tę definicję w ramach niniejszej TSI za RU uważa się dostawcę usług w zakresie eksploatacji pociągów.

W odniesieniu do przydziału trasy pociągu na potrzeby przewozu pociągiem należy również wziąć pod uwagę art. 38 dyrektywy 2012/34/UE [3]:

zdolność przepustowa infrastruktury jest alokowana przez zarządcę infrastruktury. Po dokonaniu alokacji na rzecz wnioskodawcy nie może być ona przekazywana przez otrzymującego innemu przedsiębiorstwu lub innym rodzajom przewozów.

Wszelki obrót zdolnością przepustową infrastruktury jest zakazany i prowadzi do wykluczenia z dalszej alokacji zdolności przepustowej.

Wykorzystywanie zdolności przepustowej przez przedsiębiorstwo kolejowe przy wykonywaniu działalności gospodarczej wnioskodawcy, który nie jest przedsiębiorstwem kolejowym, nie jest uważane za przekazanie.

W przypadku scenariuszy komunikacji pomiędzy zarządcami infrastruktury a wnioskodawcami w trybie wykonawczym transportu należy brać pod uwagę tylko IM i RU, a nie wszystkie rodzaje wnioskodawców, którzy mogą być stosowni dla trybu planowania. W trybie wykonawczym zawsze istnieje zdefiniowana zależność IM — RU, w odniesieniu do której specyfikacje dotyczące wymiany wiadomości i przechowywania informacji określono w niniejszej TSI. Nie ma to wpływu na definicję wnioskodawcy oraz wynikające z niej możliwości przydziału trasy.

Na potrzeby transportu towarowego zapewnione muszą zostać różnorodne usługi. Jedną z takich usług jest na przykład dostarczanie wagonów. Usługę tę można powiązać z zarządcą floty pojazdów. Jeżeli ta usługa na potrzeby transportu jest jedną z usług oferowanych przez RU, to RU działa również jako zarządca floty pojazdów. Zarządca floty pojazdów może z kolei zarządzać swoimi własnymi wagonami lub wagonami innego posiadacza (innego dostawcy usług w zakresie wagonów towarowych). Zapotrzebowanie na tego rodzaju dostawcę usług jest uwzględniane niezależnie od tego, czy osoba prawna zarządcy floty pojazdów jest jednocześnie RU, czy nie.

W niniejszej TSI nie wprowadza się nowych osób prawnych, ani nie wymaga się od RU angażowania zewnętrznych dostawców do świadczenia usług, które świadczy samo RU, jednakże w stosownych przypadkach usługę określono nazwą odpowiedniego dostawcy usług. Jeśli usługa jest świadczona przez RU, to RU działa jako dostawca usług w odniesieniu do danej usługi.

Biorąc pod uwagę potrzeby klienta, jedną z usług jest organizowanie linii transportowej i zarządzanie nią, zgodnie ze zobowiązaniem wobec klienta. Usługa ta jest dostarczana przez wiodące przedsiębiorstwo kolejowe (wiodące RU lub LRU). LRU stanowi jeden centralny punkt kontaktowy dla klienta. Jeżeli w łańcuchu transportowym uczestniczy więcej niż jedno przedsiębiorstwo kolejowe, to LRU jest także odpowiedzialne za koordynację z innymi przedsiębiorstwami kolejowymi.

Usługa ta może być również realizowana przez spedytora lub dowolny inny podmiot.

Zakres działalności RU jako LRU może różnić się w zależności od typu przepływu transportu. W działalności intermodalnej zarządzanie objętością załadowczą w pociągach odcinkowych bezpośrednich oraz przygotowywanie listów przewozowych jest wykonywane przez integratora usług intermodalnych, który może wówczas być klientem LRU.

Podstawową kwestią jest jednak to, że RU i IM oraz wszyscy pozostali dostawcy usług (w znaczeniu zdefiniowanym w niniejszym załączniku) muszą ze sobą współpracować, w drodze wspólnego działania lub otwartego dostępu oraz poprzez sprawną wymianę informacji, aby zapewnić klientowi ciągłość usług.

2.3.2.   Rozpatrywane procesy

Zakres niniejszej TSI dotyczącej sektora kolejowego transportu towarowego jest ograniczony zgodnie z dyrektywą 2008/57/WE [1] do IM i RU/LRU w odniesieniu do ich bezpośrednich klientów. Zgodnie z porozumieniem umownym LRU dostarcza klientowi informacje, w szczególności:

—	informacje o trasie,

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

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

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

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

Przy wykonywaniu transportu towarowego działalność LRU dotycząca przesyłki rozpoczyna się wraz z otrzymaniem listu przewozowego od klienta oraz, na przykład, w przypadku wagonów ładownych — wraz z czasem zwolnienia wagonów. LRU tworzy wstępny plan podróży (w oparciu o doświadczenie lub umowę) dla danego transportu. Jeżeli LRU zamierza wykonywać transport wagonów ładownych pociągiem w trybie otwartego dostępu (LRU wykonuje transport danym pociągiem na całej trasie), to wstępny plan podróży jest zarazem planem ostatecznym. Jeżeli LRU zamierza przemieszczać wagony ładowne w ramach transportu pociągiem wykonywanego przy współpracy z innymi RU, musi najpierw dowiedzieć się, do których RU powinien się zwrócić i w jakim czasie może nastąpić wymiana pomiędzy dwoma kolejnymi RU. LRU przygotowuje wówczas wstępne zamówienia przewozów indywidualnie dla każdego RU, jako poszczególne części listu przewozowego. Szczegóły dotyczące zamówień przewozów zawarto w rozdziale 4.2.1 („Dane listu przewozowego”).

RU, do którego zwrócono się, sprawdza dostępność zasobów potrzebnych do eksploatacji wagonów oraz dostępność trasy pociągu. Odpowiedzi otrzymane od poszczególnych RU pozwalają LRU na dopracowanie planu podróży lub prowadzą do wznowienia zapytania — być może nawet skierowania go do innych RU — aż plan podróży zostanie w pełni dostosowany do wymagań klienta.

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

—

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

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

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

—

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

RU/LRU jako wnioskodawcy muszą również zapewnić posiadanie (poprzez umowy z IM) wymaganej trasy pociągu i muszą wykonać transport pociągiem w obrębie swojego odcinka przejazdu. Jeżeli chodzi o trasę pociągu, mogą oni wykorzystać zarezerwowane już (w trybie planowania) trasy lub muszą zwrócić się z wnioskiem ad hoc o przydzielenie trasy pociągu do zarządców infrastruktury (IM) właściwych dla odcinków przejazdu, na których RU wykonuje transport pociągiem. W dodatku I podano przykład scenariusza dotyczącego wniosku o przydzielenie trasy.

Ważna dla komunikacji pomiędzy IM a RU podczas ruchu pociągu jest także własność trasy. Komunikacja musi być zawsze oparta o numer pociągu oraz numer trasy, przy użyciu których IM komunikuje się z RU, które zarezerwowało trasę pociągu należącą do infrastruktury danego IM (zob. także dodatek I).

Jeżeli RU zapewnia transport na całej trasie przejazdu A–F (RU działa w trybie otwartego dostępu, nie uczestniczą inne RU), każdy uczestniczący IM komunikuje się bezpośrednio tylko z tym RU. Taka działalność RU w trybie „otwartego dostępu” może być realizowana przez zarezerwowanie całości trasy pociągu w centralnym punkcie obsługi (ang. One Stop Shop) lub dokonywanie osobnych rezerwacji poszczególnych odcinków bezpośrednio u każdego IM. TSI uwzględnia obydwa przypadki, jak przedstawiono w rozdziale 4.2.2.1: „Wniosek o przydzielenie trasy. Uwagi wstępne”.

Przebieg dialogu pomiędzy RU i IM w celu ustalenia trasy pociągu towarowego określono w rozdziale 4.2.2 („Wniosek o przydzielenie trasy”). Funkcja ta odnosi się do art. 48 ust. 1 dyrektywy 2012/34/UE [3]. W zakres takiego dialogu nie wchodzi uzyskiwanie licencji przez RU świadczące usługi zgodnie z dyrektywą 2001/13/WE [10], certyfikacji zgodnie z dyrektywą 2012/34/UE [3] ani praw dostępu zgodnie z dyrektywą 2012/34/UE [3].

W rozdziale 4.2.3 („Przygotowanie pociągu”) określono wymianę informacji dotyczącą składu pociągu oraz procedury odjazdu pociągu. Wymianę danych podczas jazdy pociągu w przypadku zwykłego przejazdu przedstawiono w rozdziale 4.2.4 („Prognoza jazdy pociągu”), a komunikaty na wypadek sytuacji wyjątkowych określono w rozdziale 4.2.5 („Informacja o zakłóceniu usługi”). Wszystkie te komunikaty są wymieniane pomiędzy RU i IM i odnoszą się do konkretnych pociągów.

Dla klienta najważniejszą informacją jest zawsze przewidywany czas przyjazdu (ETA) jego przesyłki. ETA może zostać ustalony na podstawie wymiany informacji pomiędzy LRU a IM (w przypadku otwartego dostępu). W przypadku trybu współpracy z różnymi RU, ETA oraz przewidywany czas wymiany (ang. estimated time of interchange, ETI) mogą zostać ustalone na podstawie wymiany komunikatów pomiędzy RU i IM, a wynik ustaleń dostarczony LRU przez poszczególne RU (rozdział 4.2.6 „ETI/ETA przesyłki”).

Wymiana informacji pomiędzy IM a RU stanowi dla LRU również źródło następujących informacji:

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

—	kiedy odpowiedzialność za wagony została przeniesiona z jednego RU na kolejne RU w łańcuchu transportowym (rozdział 4.2.8 „Raportowanie o wymianie”).

Na podstawie nie tylko wymiany danych pomiędzy IM i RU, lecz także wymiany danych pomiędzy poszczególnymi RU i LRU, można opracować różnorodne statystyki:

—	na potrzeby — w perspektywie średnioterminowej — bardziej szczegółowego planowania procesu produkcji, oraz

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

—	w celu poprawy jakości usług transportowych i wydajności (rozdział 4.2.9 „Wymiana danych służąca poprawie jakości”).

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

2.3.3.   Uwagi ogólne

O jakości systemu informacyjnego decyduje wiarygodność zawartych w nim danych. Dlatego dane, które odgrywają decydującą rolę w ekspediowaniu przesyłki, wagonu lub kontenera, muszą być precyzyjne i uzyskane w ekonomiczny sposób, co znaczy, że określone dane powinny być wprowadzane do systemu tylko raz.

Z tych względów aplikacje i komunikaty, o których mowa w niniejszej TSI, umożliwiają uniknięcie wielokrotnego ręcznego wprowadzania danych dzięki dostępowi do wpisanych już do systemu danych, np. danych referencyjnych o taborze. Wymagania dotyczące danych referencyjnych o taborze określono w rozdziale 4.2.10 („Główne dane referencyjne”). Określone referencyjne bazy danych taboru muszą umożliwiać łatwy dostęp do danych technicznych. Zawartość baz danych musi być dostępna, na podstawie usystematyzowanych praw dostępu zależnych od uprawnień, dla wszystkich IM, RU i zarządców floty pojazdów, w szczególności do celów zarządzania flotą i utrzymania taboru. Bazy te muszą zawierać wszystkie dane techniczne niezbędne do celów transportu, takie jak:

—	identyfikacja taboru kolejowego,

—	dane techniczne/projektowe,

—	ocena zgodności z infrastrukturą,

—	ocena stosownej charakterystyki załadunku,

—	charakterystyka dotycząca hamowania,

—	dane dotyczące utrzymania,

—	charakterystyka pod kątem kwestii związanych ze środowiskiem.

W intermodalnej działalności transportowej w różnych punktach (zwanych terminalami przeładunkowymi) nie tylko wagon jest podłączany do innego pociągu, lecz także jednostka intermodalna może być przeniesiona z jednego wagonu do drugiego. W związku z tym w działalności tej nie można opierać się jedynie na planie podróży sporządzonym w odniesieniu do wagonów, należy również opracować plan podróży w odniesieniu do jednostek intermodalnych.

W rozdziale 4.2.11 („Lista plików referencyjnych”) wymieniono kilka plików referencyjnych i różne bazy danych, wśród nich operacyjną bazę danych wagonów i jednostek intermodalnych. Baza ta zawiera dane o statusie operacyjnym taboru, informacje o ciężarze i niebezpiecznych towarach, informacje dotyczące jednostek intermodalnych oraz informacje o lokalizacji.

W TSI dotyczącej podsystemu „Aplikacje telematyczne dla przewozów towarowych” określono wymagane informacje, które muszą być wymieniane pomiędzy różnymi partnerami biorącymi udział w łańcuchu transportowym, co umożliwia wdrożenie standardowego procesu wymiany obowiązkowych danych. W TSI przedstawiono również strategię dotyczącą architektury takiej platformy komunikacyjnej. Została ona opisana w rozdziale 4.2.12 („Łączność sieciowa i komunikacja”), z uwzględnieniem:

—	interfejsu podsystemu „Ruch kolejowy”, o którym mowa w art. 5 ust. 3 dyrektywy 2008/57/WE [1],

—	wymagań dotyczących treści regulaminu sieci, określonych w art. 27 dyrektywy 2012/34/WE [3] i w załączniku IV do tej dyrektywy,

—	dostępnych informacji o taborze wagonów towarowych oraz wymagań dotyczących konserwacji, pochodzących z TSI dotyczącej taboru kolejowego.

Nie ma bezpośredniej transmisji danych z podsystemu „Aplikacje telematyczne dla przewozów towarowych” do pociągu, maszynisty lub do części podsystemu „Sterowanie ruchem kolejowym”, a fizyczna sieć transmisyjna jest zupełnie inna niż sieć wykorzystywana przez podsystem „Sterowanie ruchem kolejowym”. System ERTMS/ETCS wykorzystuje GSM-R. W przypadku tej otwartej sieci w specyfikacjach ETCS wyjaśniono, że bezpieczeństwo jest osiągane poprzez odpowiednie zarządzanie zagrożeniami otwartych sieci w protokole EURORADIO.

Interfejsy podsystemów strukturalnych: „Tabor kolejowy” i „Bezpieczna kontrola jazdy pociągu” określone są jedynie za pośrednictwem referencyjnych baz danych taboru kolejowego (rozdział 4.2.10.2: „Referencyjne bazy danych taboru kolejowego”), które znajdują się pod kontrolą posiadaczy taborów. Interfejsy podsystemów: „Infrastruktura”, „Bezpieczna kontrola jazdy pociągu” i „Energia” określone są w ramach definicji trasy (rozdział 4.2.2.3: „Komunikat »Szczegółowe dane o trasie«”) podawanej przez IM, która zawiera odnoszące się do pociągu parametry związane z infrastrukturą, oraz w treści informacji o ograniczeniach w infrastrukturze, dostarczanej przez IM (rozdział 4.2.2 „Wniosek o przydzielenie trasy” oraz rozdział 4.2.3 „Przygotowanie pociągu”).

3.   WYMAGANIA ZASADNICZE

3.1.   Zgodność z wymaganiami zasadniczymi

Zgodnie z art. 4 ust. 1 dyrektywy 2008/57/WE [1] transeuropejski system kolei, podsystemy i ich składniki interoperacyjności muszą spełniać wymagania zasadnicze zawarte w ogólnych warunkach określonych w załączniku III do dyrektywy.

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

3.2.   Aspekty wymagań zasadniczych

Wymagania zasadnicze dotyczą:

—	bezpieczeństwa,

—	niezawodności i dostępności,

—

zdrowia,

—	ochrony środowiska,

—	zgodności technicznej.

Zgodnie z dyrektywą 2008/57/WE [1] wymagania zasadnicze mogą mieć ogólne zastosowanie w odniesieniu do całego transeuropejskiego systemu kolei lub mogą dotyczyć jedynie poszczególnych podsystemów i ich składników.

3.3.   Aspekty związane z wymaganiami ogólnymi

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

3.3.1.   Bezpieczeństwo

Wymagania zasadnicze 1.1.1, 1.1.2, 1.1.3, 1.1.4 i 1.1.5 określone w załączniku III do dyrektywy 2008/57/WE [1] nie odnoszą się do podsystemu „Aplikacje telematyczne”.

3.3.2.   Niezawodność i dostępność

.

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

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

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

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

3.3.3.   Zdrowie

Wymagania zasadnicze 1.3.1 i 1.3.2 określone w załączniku III do dyrektywy 2008/57/WE [1] nie odnoszą się do podsystemu „Aplikacje telematyczne”.

3.3.4.   Ochrona środowiska

Wymagania zasadnicze 1.4.1, 1.4.2, 1.4.3, 1.4.4 i 1.4.5 określone w załączniku III do dyrektywy 2008/57/WE [1] nie odnoszą się do podsystemu „Aplikacje telematyczne”.

3.3.5.   Zgodność techniczna

Wymaganie zasadnicze 1.5 określone w załączniku III do dyrektywy 2008/57/WE [1] nie odnosi się do podsystemu „Aplikacje telematyczne”.

3.4.   Aspekty dotyczące w szczególności podsystemu „Aplikacje telematyczne dla przewozów towarowych”

3.4.1.   Zgodność techniczna

Wymaganie zasadnicze 2.7.1 określone w załączniku III do dyrektywy 2008/57/WE [1]:

„Zasadnicze wymogi dla aplikacji telematycznych gwarantują minimalny poziom jakości usług dla pasażerów i przewoźników towarów, w szczególności w zakresie zgodności technicznej.

Należy podjąć działania zapewniające:

—	rozwój baz danych, oprogramowania i protokołów transmisji danych w sposób pozwalający na maksymalną wzajemną wymianę danych między różnymi aplikacjami i operatorami, z wyłączeniem poufnych danych handlowych,

—	łatwy dostęp użytkownika do informacji”

.

Powyższe wymaganie zasadnicze jest spełnione w szczególności poprzez zgodność ze specyfikacjami w następujących rozdziałach:

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

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

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

3.4.2.   Niezawodność i dostępność

Wymaganie zasadnicze 2.7.2 określone w załączniku III do dyrektywy 2008/57/WE [1]:

.

Powyższe wymaganie jest spełnione w szczególności poprzez zgodność ze specyfikacjami w następujących rozdziałach:

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

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

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

To wymaganie zasadnicze, zwłaszcza w odniesieniu do sposobu użytkowania zapewniającego wydajność tych aplikacji telematycznych oraz jakość usług, jest podstawą całej TSI, tak więc zakres jego zastosowania nie ogranicza się do rozdziałów 4.2.10, 4.2.11 oraz 4.2.12.

3.4.3.   Zdrowie

Wymaganie zasadnicze 2.7.3 określone w załączniku III do dyrektywy 2008/57/WE [1]:

.

W niniejszej TSI nie określono żadnych dodatkowych wymagań wykraczających poza istniejące krajowe i europejskie uregulowania dotyczące minimalnych zasad ergonomii i ochrony zdrowia w odniesieniu do płaszczyzny współpracy (interfejsu) między aplikacjami telematycznymi a użytkownikami.

3.4.4.   Bezpieczeństwo

Wymaganie zasadnicze 2.7.4 określone w załączniku III do dyrektywy 2008/57/WE [1]:

.

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

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

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

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

4.   CHARAKTERYSTYKA PODSYSTEMU

4.1.   Wstęp

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

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

4.2.   Funkcjonalne i techniczne specyfikacje podsystemu

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

—	dane listu przewozowego,

—	wniosek o przydzielenie trasy,

—	przygotowanie pociągu,

—	prognoza jazdy pociągu,

—	informacje o zakłóceniu usługi,

—	ETI/ETA wagonów/jednostek intermodalnych,

—	ruch wagonów,

—	raportowanie o wymianie,

—	wymiana danych w celu poprawy jakości,

—	główne dane referencyjne,

—	lista plików referencyjnych i referencyjnych baz danych,

—	łączność sieciowa i komunikacja.

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

Ogólne uwagi na temat struktury komunikatów

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

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

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

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

4.2.1.   Dane listu przewozowego

4.2.1.1.   List przewozowy klienta

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

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

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

4.2.1.2.   Zlecenia przewozu

Zlecenie przewozu jest zasadniczo podzbiorem informacji zawartych w liście przewozowym. Musi ono zostać dostarczone przez LRU przedsiębiorstwom kolejowym uczestniczącym w łańcuchu transportowym. Treść zlecenia przewozu musi zawierać istotne informacje, które są potrzebne RU do wykonania transportu na etapie, za który to RU odpowiada, aż do przekazania przesyłki kolejnemu RU. Dlatego treść ta zależy od pełnionej przez przedsiębiorstwo kolejowe roli: początkowego RU, tranzytowego RU lub odbiorczego RU.

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

Główne elementy zlecenia przewozu to:

—	dane dotyczące nadawcy i odbiorcy,

—	dane dotyczące przebiegu trasy,

—	identyfikacja przesyłki,

—	dane o wagonach,

—	dane o miejscu i czasie.

Niektóre dane zawarte w liście przewozowym muszą być również dostępne dla wszystkich partnerów (np. dla IM, posiadacza itd.) w łańcuchu transportowym, w tym dla klientów. Są to w szczególności następujące dane w odniesieniu do poszczególnych wagonów:

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

—	numer CN/HS,

—	informacja o niebezpiecznych towarach,

—	jednostka transportu.

Wersję papierową stosować można tylko w wyjątkowych przypadkach, wyłącznie wówczas, gdy danych tych nie można przesłać za pomocą komunikatów określonych powyżej.

4.2.2.   Wniosek o przydzielenie trasy

4.2.2.1.   Uwagi wstępne

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

Wniosek o przydzielenie trasy ad hoc

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

W pierwszym przypadku muszą zostać podjęte natychmiastowe działania, przy czym znany jest rzeczywisty skład pociągu w oparciu o wykaz pojazdów kolejowych w składzie pociągu.

W drugim przypadku przedsiębiorstwo kolejowe musi dostarczyć zarządcy infrastruktury wszystkie niezbędne dane o tym, kiedy i dokąd wymagana jest jazda pociągu, wraz z wszystkimi parametrami fizycznymi, które mają znaczenie w odniesieniu do infrastruktury.

Parametr podstawowy „wnioski o przydzielenie trasy ad hoc” powinien być spełniany w drodze współpracy między RU a zarządcą infrastruktury (IM). W zakresie tego parametru podstawowego termin IM może odnosić się do zarządcy infrastruktury oraz, w stosownych przypadkach, do organów alokujących (zob. dyrektywa 2012/34/UE [3]).

Wymagania te obowiązują w odniesieniu do wszystkich wniosków o przydzielenie trasy ad-hoc.

Niniejszy parametr podstawowy nie uwzględnia kwestii związanych z zarządzaniem ruchem. Rozgraniczenie czasowe pomiędzy przydzieleniem trasy ad-hoc a zmianami trasy w związku z zarządzaniem ruchem jest przedmiotem porozumień miejscowych.

Przedsiębiorstwo kolejowe (RU) musi dostarczyć zarządcy infrastruktury (IM) wszystkie niezbędne dane o tym, kiedy i dokąd wymagana jest jazda pociągu, wraz z wszystkimi parametrami fizycznymi, które maja znaczenie dla infrastruktury.

Każdy zarządca infrastruktury jest odpowiedzialny za odpowiedniość trasy w ramach swojej infrastruktury, natomiast przedsiębiorstwo kolejowe ma obowiązek porównać parametry techniczne pociągu z wartościami podanymi w szczegółowych danych dotyczących zamówionej trasy.

Bez uszczerbku dla warunków użytkowania trasy zawartych w regulaminie sieci lub dla zasad odpowiedzialności w razie jakichkolwiek ograniczeń w infrastrukturze wyjaśnionych w TSI „Ruch kolejowy”, przed przygotowaniem pociągu RU musi wiedzieć, czy istnieją jakieś ograniczenia na odcinkach linii lub stacjach (węzłach) wpływające na skład jego pociągu opisany w umowie o trasę.

Porozumienie o przydzieleniu trasy ad hoc na przejazd pociągu zawierane jest w oparciu o dialog między RU a IM. Wnioskodawcy mogą składać wnioski o przyznanie zdolności przepustowej infrastruktury. Aby wykorzystać tę zdolność przepustową infrastruktury, wnioskodawcy wyznaczają przedsiębiorstwo kolejowe, które zawrze umowę z zarządcą infrastruktury zgodnie z dyrektywą 2012/34/UE [3]. W odnośnym dialogu biorą udział wszystkie RU i wszyscy IM uczestniczące(-y) w przemieszczaniu pociągu po wnioskowanej trasie, jednakże ich wkład w proces znajdowania trasy może być różny.

4.2.2.2.   Komunikat „Wniosek o przydzielenie trasy”

Komunikat ten wysłany jest przez RU do zarządcy infrastruktury (IM) w celu zwrócenia się z wnioskiem o przydzielenie trasy.

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

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

IM wysyła taki komunikat do RU jako odpowiedź na złożony przez to RU wniosek o przydzielenie trasy.

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

4.2.2.4.   Komunikat „Trasa potwierdzona”

RU wnioskujące o przydzielenie trasy wykorzystuje ten komunikat do zamówienia lub potwierdzenia trasy proponowanej przez IM.

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

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

RU wnioskujące o przydzielenie trasy wykorzystuje ten komunikat do odrzucenia szczegółowych danych o trasie proponowanej przez odpowiedniego zarządcę infrastruktury.

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

4.2.2.6.   Komunikat „Trasa odwołana”

Komunikat ten jest wykorzystywany przez RU wnioskujące o przydzielenie trasy do rezygnacji z całości lub części zamówionej trasy.

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

4.2.2.7.   Komunikat „Trasa niedostępna”

IM wysyła ten komunikat do RU, które zamówiło trasę, w przypadku gdy trasa ta nie jest już dostępna.

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

4.2.2.8.   Komunikat „Potwierdzenie odbioru”

Komunikat ten jest wysyłany przez odbiorcę komunikatu do nadawcy pierwotnego komunikatu w celu potwierdzenia, że do systemu, z którego korzysta odbiorca, pierwotny komunikat dotarł w określonym przedziale czasu.

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

4.2.3.   Przygotowanie pociągu

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ń.

W ramach przygotowania pociągu RU musi wysłać dane o składzie pociągu do kolejnych RU. Zgodnie z porozumieniem umownym RU musi wysłać ten komunikat również do IM, u którego (u których) zamówił poszczególne odcinki danej trasy.

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

W celu przygotowania pociągu RU musi mieć dostęp do powiadomień o ograniczeniach w infrastrukturze, do technicznych danych o wagonach (referencyjne bazy danych taboru kolejowego, rozdział 4.2.10.2 „Referencyjne bazy danych taboru kolejowego”), do informacji o niebezpiecznych towarach oraz do bieżących, aktualizowanych informacji o wagonach (rozdział 4.2.11.2: „Inne bazy danych: Operacyjna baza danych wagonów i jednostek intermodalnych”). Dotyczy to wszystkich wagonów pociągu. Na koniec RU musi wysłać dane o składzie pociągu do kolejnych RU. Komunikat ten RU musi wysłać również do każdego IM, u którego zamówił odcinek trasy, jeśli taki wymóg zawarto w odnoszącej się do kolei konwencjonalnych TSI „Ruch kolejowy” lub w umowie (umowach) między RU a IM.

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

W każdym punkcie, np. w punkcie początkowym i w punkcie wymiany, w którym następuje zmiana RU, na którym spoczywa odpowiedzialność, obowiązkowe jest przeprowadzenie między IM a RU dialogu przewidzianego na początku procedury: „Pociąg gotowy — Informacja o jeździe pociągu”.

4.2.3.2.   Komunikat „Skład pociągu”

Komunikat ten RU musi wysłać do kolejnego RU, określając w nim skład pociągu. Zgodnie z regulaminem sieci RU musi wysłać ten komunikat również do IM. Za każdym razem, gdy następuje zmiana składu podczas przejazdu pociągu, RU dokonujące tej zmiany musi zaktualizować informacje w tym komunikacie i przekazać je LRU, które przekazuje odnośne informacje wszystkim uczestniczącym stronom.

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

Minimalny zakres informacji, jakie muszą zostać dostarczone na potrzeby wymiany komunikatu „Skład pociągu” pomiędzy RU a IM został określony w rozdziale 4.2.2.7.2 decyzji 2012/757/UE w sprawie TSI „Ruch kolejowy”.

4.2.3.3.   Komunikat „Pociąg gotowy”

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

Definicję obowiązkowej struktury komunikatu „Pociąg gotowy” oraz wymagane elementy podano w wymienionym w dodatku I dokumencie „TAF TSI — Annex D.2: Appendix F — TAF TSI Data and Message Model”. W tym samym celu można ponadto wykorzystać inne obowiązujące normy, o ile uczestniczące podmioty zawarły szczególne porozumienie umożliwiające wykorzystywanie takich norm.

4.2.4.   Prognoza jazdy pociągu

4.2.4.1.   Uwagi ogólne

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

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

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 RU, które zamówiło trasę, po której pociąg faktycznie się porusza.

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

4.2.4.2.   Komunikat „Prognoza jazdy pociągu”

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

Ponadto komunikat ten musi być wysłany przez IM do RU w odniesieniu do innych punktów raportowania zgodnie z umowami między RU a IM (np. w odniesieniu do punktów obsługi lub stacji).

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

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

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

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

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

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

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

Jeżeli znana jest przyczyna opóźnienia (pierwsze założenie) informację o niej należy przesłać w osobnym komunikacie „Przyczyna opóźnienia pociągu”.

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

4.2.5.   Informacje o zakłóceniu usługi

4.2.5.1.   Uwagi ogólne

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

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

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

4.2.5.2.   Komunikat „Wstrzymana jazda pociągu”

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

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

4.2.6.   ETI/ETA przesyłki

4.2.6.1.   Uwaga wstępna

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

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

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

Wszystkie prognozowane czasy zawarte w komunikatach dotyczących pociągu odnoszą się do przyjazdu pociągu do pewnego punktu, którym może być punkt przekazania, punkt wymiany, punkt docelowy pociągu lub inny punkt raportowania. Wszystkie te pozycje są przewidywanymi czasami przyjazdu pociągu (ang. Train Estimated Times of Arrivals, TETA). Znaczenie TETA może zmieniać się w zależności od poszczególnych wagonów lub jednostek intermodalnych w pociągu. Na przykład TETA w odniesieniu do punktu wymiany może oznaczać w przypadku pewnych wagonów lub jednostek intermodalnych przewidywany czas wymiany (ETI). W przypadku innych wagonów pozostających w składzie pociągu do dalszego transportu przez to samo RU TETA może nie być istotny. Zadaniem RU otrzymującego informacje o TETA jest zidentyfikowanie i przetworzenie tych informacji, zachowanie ich w operacyjnej bazie danych wagonów i jednostek intermodalnych jako danych o ruchu wagonów i przekazanie ich LRU, jeżeli jazda pociągu nie odbywa się w trybie otwartego dostępu. Odnośny opis zawarto w poniższych rozdziałach.

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

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

4.2.6.2.   Obliczanie ETI/ETA

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

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

Ponieważ RU może mieć w pociągu wagony o różnych trasach przejazdu i pochodzące od różnych LRU, punkt wymiany przyjmowany w obliczeniach ETI może różnić się w zależności od wagonu. (Prezentację graficzną odnośnych scenariuszy oraz przykłady zamieszczono w wymienionym w dodatku I dokumencie „TAF TSI — Annex A.5: Figures and Sequence Diagrams of the TAF TSI messages” w rozdziale 1.4, natomiast schemat proceduralny odnoszący się do przykładu 1 dla punktu wymiany C przedstawiono w wymienionym w dodatku I dokumencie „TAF TSI — Annex A.5: Figures and Sequence Diagrams of the TAF TSI messages” w rozdziale 5).

Kolejne RU, na podstawie danych dotyczących ETI dostarczonych przez poprzednie RU, oblicza z kolei ETI wagonów w następnym punkcie wymiany. Kroki te są wykonywane przez każde kolejne RU. Gdy ostatnie RU (np. RU n) w łańcuchu transportowym wagonu otrzyma od poprzedzającego je RU (np. RU n-1) ETI wagonu pomiędzy RU n-1 a RU n, ostatnie RU (RU n) musi obliczyć przewidywany czas przyjazdu wagonów do punktu docelowego. Ma to na celu zapewnienie zestawienia wagonów w kolejności zgodnej ze zleceniem przewozu oraz stosownie do zobowiązania LRU wobec klienta. Jest to ETA wagonu i musi on zostać wysłany do LRU. Dane dotyczące ETA muszą być przechowywane w formacie elektronicznym wraz z danymi o ruchu wagonów. LRU musi udzielać klientowi stosownych informacji zgodnie z warunkami porozumienia umownego.

Uwaga dotycząca jednostek intermodalnych: W przypadku jednostek intermodalnych w wagonie ETI wagonu stanowi również ETI jednostek intermodalnych. W odniesieniu do ETA jednostek intermodalnych należy zauważyć, że RU nie jest w stanie obliczyć takiego ETA poza ramami transportu kolejowego. Dlatego RU może dostarczyć tylko ETI odnoszące się do terminalu intermodalnego.

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

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

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

4.2.6.3.   Komunikat „ETI/ETA wagonów”

Komunikat ten RU wysyła w celu poinformowania kolejnego RU w łańcuchu transportowym o ETI lub zaktualizowanym ETI. Ostatni RU w łańcuchu transportowym wagonów wysyła ETA lub zaktualizowany ETA do LRU. Definicję obowiązkowej struktury komunikatu „ETI/ETA wagonów” oraz wymagane elementy podano w wymienionym w dodatku I dokumencie „TAF TSI — Annex D.2: Appendix F — TAF TSI Data and Message Model”.

4.2.6.4.   Komunikat „Alert”

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

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

4.2.7.   Ruch wagonów

4.2.7.1.   Uwagi wstępne

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

—	Powiadomienie o zwolnieniu wagonu

—	Powiadomienie o odjeździe wagonu

—	Przyjazd wagonu do stacji rozrządowej

—	Wyjazd wagonu ze stacji rozrządowej

—	Komunikat o wyjątkowej sytuacji wagonu

—	Powiadomienie o przyjeździe wagonu

—	Powiadomienie o dostawie wagonu

—	Raportowanie o wymianie wagonu zostało opisane oddzielnie w rozdziale 4.2.8 „Raportowanie o wymianie”.

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

4.2.7.2.   Komunikat „Powiadomienie o zwolnieniu wagonu”

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

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

4.2.7.3.   Komunikat „Powiadomienie o odjeździe wagonu”

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

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

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

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

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

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

4.2.7.6.   Komunikat „Wyjątkowa sytuacja wagonu”

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

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

4.2.7.7.   Komunikat „Powiadomienie o przyjeździe wagonu”

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

4.2.7.8.   Komunikat „Powiadomienie o dostawie wagonu”

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

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

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

4.2.8.   Raportowanie o wymianie

4.2.8.1.   Uwaga wstępna

Raportowanie o wymianie obejmuje komunikaty wysyłane w związku z następującym w punktach wymiany przeniesieniem odpowiedzialności za wagon z jednego przedsiębiorstwa kolejowego na kolejne. Nakazuje również nowemu RU wykonanie obliczenia ETI i przeprowadzenie procesu opisanego w rozdziale 4.2.6 („ETI/ETA przesyłki”).

Wymienione muszą zostać następujące komunikaty:

—	powiadomienie o wymianie wagonu,

—	powiadomienie o wymianie wagonu oraz zastępstwie,

—	odebranie wagonu przy wymianie,

—	odmówienie wagonu przy wymianie.

Dane informacyjne tych komunikatów muszą być przechowywane w operacyjnej bazie danych wagonów i jednostek intermodalnych. W przypadku jakiegokolwiek odchylenia nowy ETI/ETA musi zostać wygenerowany i przekazany zgodnie z procesem opisanym w rozdziale 4.2.6 „ETI/ETA przesyłki”. Schemat proceduralny w odniesieniu do tych komunikatów został przedstawiony w wymienionym w dodatku I dokumencie „TAF TSI — Annex A.5: Figures and Sequence Diagrams of the TAF TSI messages”, w związku z komunikatami dotyczącymi ruchu wagonów.

Powiadomienia o wymianie wagonów oraz powiadomienia o wymianie wagonów/zastępstwie, jak również komunikaty o odebraniu wagonów mogą być przekazywane w formie wykazu różnych wagonów, zwłaszcza jeśli wszystkie wagony znajdują się w jednym pociągu. W takim przypadku wszystkie wagony mogą być wymienione w pojedynczym przekazie komunikatu.

W przypadku otwartego dostępu nie ma punktów wymiany. W punkcie obsługi podmiot, na którym spoczywa odpowiedzialność za wagony, nie zmienia się. Dlatego też nie ma potrzeby wymiany odnośnych komunikatów. Zawarte w komunikacie „Informacja o jeździe pociągu” w tym punkcie raportowania informacje odnoszące się do wagonów lub jednostek intermodalnych — dotyczące daty/czasu przyjazdu i odjazdu — muszą jednak zostać przetworzone i zachowane w operacyjnej bazie danych wagonów i jednostek intermodalnych.

Na podstawie porozumienia umownego LRU musi udzielać klientowi informacji wchodzących w zakres raportowania o wymianie za pomocą komunikatów opisanych poniżej.

Definicję obowiązkowej struktury tych komunikatów podano w wymienionym w dodatku I dokumencie „TAF TSI — Annex D.2: Appendix F — TAF TSI Data and Message Model”.

4.2.8.2.   Komunikat „Powiadomienie o wymianie wagonu”

Za pomocą komunikatu „Powiadomienie o wymianie wagonu” przedsiębiorstwo kolejowe (RU 1) pyta kolejne przedsiębiorstwo kolejowe (RU 2) w łańcuchu transportowym, czy przyjmuje ono odpowiedzialność za wagon. Za pomocą komunikatu „Powiadomienie o wymianie wagonu/Zastępstwo” RU 2 informuje swojego IM, że przyjęło odpowiedzialność. Definicję obowiązkowej struktury komunikatu „Powiadomienie o o wymianie wagonu” oraz wymagane elementy podano w wymienionym w dodatku I dokumencie „TAF TSI — Annex D.2: Appendix F — TAF TSI Data and Message Model”.

4.2.8.3.   Komunikat „Powiadomienie o wymianie wagonu/Zastępstwo”

Za pomocą komunikatu „Powiadomienie o wymianie wagonu/Zastępstwo” RU 2 informuje IM, że przejęło odpowiedzialność za określony wagon. Definicję obowiązkowej struktury komunikatu „Powiadomienie o o wymianie wagonu/Zastępstwo” oraz wymagane elementy podano w wymienionym w dodatku I dokumencie „TAF TSI — Annex D.2: Appendix F — TAF TSI Data and Message Model”.

4.2.8.4.   Komunikat „Odebranie wagonu przy wymianie”

Za pomocą komunikatu „Odebranie wagonu przy wymianie” RU 2 informuje RU 1, że przyjmuje odpowiedzialność za wagon. Definicję obowiązkowej struktury komunikatu „Odebranie wagonu przy wymianie” oraz wymagane elementy podano w wymienionym w dodatku I dokumencie „TAF TSI — Annex D.2: Appendix F — TAF TSI Data and Message Model”.

4.2.8.5.   Komunikat „Odmowa wagonu przy wymianie”

Za pomocą komunikatu „Odmowa wagonu przy wymianie” RU 2 informuje RU 1, że odmawia przejęcia odpowiedzialności za wagon. Definicję obowiązkowej struktury komunikatu „Odmowa wagonu przy wymianie” oraz wymagane elementy podano w wymienionym w dodatku I dokumencie „TAF TSI — Annex D.2: Appendix F — TAF TSI Data and Message Model”.

4.2.9.   Wymiana danych w celu poprawy jakości

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

4.2.10.   Główne dane referencyjne

4.2.10.1.   Wstęp

Dane o infrastrukturze (regulamin sieci oraz powiadomienia o ograniczeniach w infrastrukturze) oraz dane o taborze kolejowym (w referencyjnych bazach danych taboru kolejowego i w operacyjnej bazie danych wagonów i jednostek intermodalnych) są najważniejszymi danymi na potrzeby eksploatacji pociągów towarowych w sieci europejskiej. Obydwa rodzaje danych wspólnie pozwalają na ocenę zgodności taboru kolejowego z infrastrukturą, pomagają uniknąć wielokrotnego wprowadzania danych, co podnosi zwłaszcza jakość danych, a ponadto dają jasny obraz wszystkich dostępnych instalacji i urządzeń w dowolnym momencie, umożliwiając w ten sposób szybkie podejmowanie decyzji podczas eksploatacji.

4.2.10.2.   Referencyjne bazy danych taboru kolejowego

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

Informacje, które muszą być zachowywane w indywidualnych referencyjnych bazach danych taboru kolejowego, opisane są szczegółowo w wymienionym w dodatku I dodatku C. W ich skład muszą wchodzić wszystkie dane konieczne do:

—	identyfikacji taboru kolejowego,

—	oceny zgodności z infrastrukturą,

—	oceny charakterystyki stosownego załadunku,

—	scharakteryzowania hamowania,

—	podania danych dotyczących utrzymania,

—	podania charakterystyki pod kątem kwestii związanych ze środowiskiem.

Referencyjne bazy danych taboru kolejowego muszą umożliwiać łatwy dostęp (jednorodny wspólny sposób dostępu jest zapewniony za pomocą wspólnego interfejsu) do technicznych danych w celu ograniczenia do minimum objętości danych przesyłanych w ramach każdej operacji. Zawartość baz danych musi być dostępna, na podstawie usystematyzowanych praw dostępu zależnych od uprawnień, dla wszystkich dostawców usług (IM, RU, dostawców usług logistycznych i zarządców floty pojazdów), w szczególności do celów zarządzania flotą i utrzymania taboru.

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

—

dane administracyjne związane z elementami certyfikacji i rejestracji, takimi jak odniesienie do pliku rejestracji WE, identyfikator jednostki notyfikowanej itd.; w ich zakres mogą wchodzić historyczne dane dotyczące własności, wynajmu itp. Dodatkowo, zgodnie z art. 5 rozporządzenia (UE) nr 445/2011, posiadacze wagonów mogą przechowywać w indywidualnych referencyjnych bazach danych taboru kolejowego numer identyfikacyjny certyfikacji podmiotu odpowiedzialnego za utrzymanie. Należy uwzględnić informacje dotyczące następujących kwestii: — certyfikacja WE, — rejestracja w „rodzimym” państwie, — data oddania do eksploatacji w państwie rejestracji, — rejestracja w innych krajach do użytku w ich krajowych sieciach, — certyfikacja bezpieczeństwa całego taboru kolejowego, który nie odpowiada wymogom TSI „Tabor kolejowy”. Posiadacz jest zobowiązany zapewnić, że dane te są dostępne i że odpowiadające im procesy zostały przeprowadzone;

—

dane projektowe, które muszą obejmować wszystkie składowe (fizyczne) elementy taboru kolejowego, w tym charakterystykę dotyczącą kwestii związanych ze środowiskiem, oraz wszelkie informacje, wobec których można oczekiwać, że pozostaną ważne przez cały okres eksploatacji taboru kolejowego — ta część może zawierać historię ważniejszych modyfikacji, kapitalnej konserwacji, remontu itp.

4.2.10.3.   Dane operacyjne o taborze kolejowym

Oprócz danych referencyjnych dotyczących taboru kolejowego, dane odzwierciedlające faktyczny stan taboru kolejowego są najważniejszymi danymi do celów operacyjnych.

Dane te muszą zawierać dane o ograniczonym okresie ważności, takie jak ograniczenia, bieżące i przewidywane działania w zakresie utrzymania, stan liczników kilometrów i usterek itp. oraz wszelkie dane, które można uznać za dane dotyczące „stanu” (tymczasowe ograniczenia prędkości, odłączenie hamulca, opis potrzebnych napraw, opis usterek itp.).

Przy wykorzystywaniu danych operacyjnych o taborze kolejowym należy uwzględnić trzy różne podmioty, biorąc pod uwagę różne strony odpowiedzialne za tabor kolejowy podczas wykonywania transportu:

—	przedsiębiorstwo kolejowe jako odpowiedzialne na odcinkach, na których wykonuje ono transport,

—	posiadacz taboru kolejowego, oraz

—	użytkownik (najemca) taboru kolejowego.

W przypadku wszystkich trzech podmiotów dane operacyjne o taborze kolejowym muszą być dostępne dla upoważnionego użytkownika, zgodnie z zakresem posiadanych przez niego z góry określonych praw dostępu, przy użyciu pojedynczego klucza w postaci identyfikatora wagonu (numeru wagonu).

Dane operacyjne o taborze kolejowym są częścią operacyjnej bazy danych wagonów i jednostek intermodalnych opisanej w rozdziale 4.2.11.2 „Inne bazy danych”.

4.2.11.   Lista plików referencyjnych i referencyjnych baz danych

4.2.11.1.   Pliki referencyjne

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

Przechowywane i administrowane lokalnie:

a)	referencyjny plik służb ratunkowych, skorelowany z rodzajem niebezpiecznego towaru.

Przechowywane i administrowane centralnie:

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

c)	referencyjny plik kodowania dla klientów korzystających z usług transportu towarowego;

d)	referencyjny plik kodowania lokalizacji (podstawowych i drugorzędnych);

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

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

4.2.11.2.   Inne bazy danych

Aby umożliwić śledzenie ruchu pociągów i wagonów, podane poniżej bazy danych muszą być zainstalowane i aktualizowane w czasie rzeczywistym przy każdym stosownym zdarzeniu. Upoważnione podmioty, takie jak posiadacze i zarządcy floty pojazdów muszą mieć dostęp do danych istotnych dla pełnienia przez nich ich funkcji zgodnie z warunkami umów.

—	Operacyjna baza danych wagonów i jednostek intermodalnych,

—	Plan podróży wagonu/jednostki intermodalnej.

Te bazy danych muszą być dostępne za pośrednictwem wspólnego interfejsu (rozdziały: 4.2.12.1 „Ogólna architektura” oraz 4.2.12.6 „Wspólny interfejs”).

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

Operacyjna baza danych wagonów i jednostek intermodalnych

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

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

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

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

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

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

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

Bazy danych planów podróży wagonów

Pociągi mogą składać się z wagonów transportujących ładunki różnych klientów. Dla każdego wagonu LRU (RU pełniące rolę integratora usług) musi sporządzić, a następnie uaktualniać plan podróży, który odpowiada trasie pociągu na poziomie pociągu. Wprowadzenie nowej trasy pociągu — np. w razie zakłóceń usługi — prowadzi do rewidowania planów podróży wagonów w danym pociągu. Plan podróży zostaje utworzony z chwilą otrzymania listu przewozowego od klienta.

Plany podróży wagonów muszą być przechowywane w bazie danych przez każde LRU. Te bazy danych muszą być dostępne za pośrednictwem wspólnego interfejsu (rozdziały: 4.2.14.1 „Ogólna architektura” oraz 4.2.12.6 „Wspólny interfejs”).

Uwaga:

Oprócz obowiązkowych baz danych wymienionych powyżej, każdy IM może mieć zainstalowaną bazę danych pociągów.

Taka należąca do zarządy infrastruktury baza danych pociągów odpowiada części odnoszącej się do ruchu zawartej w operacyjnej bazie danych wagonów i jednostek intermodalnych. Podstawowymi wpisami w tej bazie są dane o pociągu pochodzące z otrzymanego od RU komunikatu o składzie pociągu. Wszelkie zdarzenia dotyczące pociągu prowadzą do aktualizacji danych w tej odnoszącej się pociągów bazie. Alternatywnym miejscem przechowywania takich danych jest baza danych tras (rozdział 4.2.2 „Wniosek o przydzielenie trasy”). Te bazy danych muszą być dostępne za pośrednictwem wspólnego interfejsu (rozdziały: 4.2.12.1 „Ogólna architektura” oraz 4.2.12.6 „Wspólny interfejs”).

4.2.11.3.   Dodatkowe wymagania dotyczące baz danych

W poniższych punktach wymieniono dodatkowe wymagania, jakie muszą spełniać poszczególne bazy danych.

Przedstawiają się one następująco:

1.	Uwierzytelnienie Baza danych musi obsługiwać funkcję uwierzytelnienia użytkowników systemów poprzedzającego ewentualne udzielenie im dostępu do danej bazy.

2.	Bezpieczeństwo Baza danych musi spełniać wymogi bezpieczeństwa pod względem kontrolowania dostępu do danej bazy danych. Ewentualne szyfrowanie samej zawartości bazy danych nie jest wymagane.

3.	Spójność Wybrana baza danych musi być zgodna z zasadą ACID (niepodzielność, spójność, izolacja, trwałość).

4.

Kontrola dostępu Baza danych musi zapewniać dostęp do danych użytkownikom lub systemom, którym udzielone zostało odnośne pozwolenie. Kontrola dostępu powinna być stosowana aż do poziomu pojedynczego atrybutu rekordu danych. Baza danych musi obsługiwać konfigurowalną, opartą na kryterium roli użytkownika kontrolę dostępu w odniesieniu do wprowadzania do bazy, aktualizacji lub usuwania rekordów danych.

5.	Rejestrowanie czynności Baza danych musi posiadać funkcję rejestrowania wszystkich czynności dokonywanych w tej bazie, tak by możliwe było odtworzenie szczegółów dotyczących przetwarzania danych (kto i kiedy dokonał jakiej zmiany w zawartości).

6.	Strategia blokady W bazie danych musi być wdrożona strategia blokady, dzięki której możliwy jest dostęp do danych nawet wtedy, gdy inni użytkownicy dokonują w tym samym czasie edycji rekordów.

7.	Równoczesny dostęp Baza danych musi zapewniać możliwość dostępu do danych kilku użytkownikom i systemom równocześnie.

8.	Niezawodność Niezawodność bazy danych musi umożliwiać utrzymanie wymaganej dostępności.

9.	Dostępność Baza danych musi wykazywać dostępność na żądanie wynoszącą co najmniej 99,9 %.

10.	Naprawialność Naprawialność bazy danych musi pozwalać na zachowanie wymaganej dostępności.

11.	Bezpieczeństwo Bazy danych jako takie nie mają związku z bezpieczeństwem. Dlatego też kwestie bezpieczeństwa nie są w odniesieniu do nich istotne. Nie należy mylić tego z faktem, iż dane — np. niepoprawne lub nieaktualne dane — mogą mieć wpływ na bezpieczeństwo eksploatacji pociągu.

12.	Kompatybilność Baza danych musi obsługiwać powszechnie przyjęty język przetwarzania danych, na przykład SQL lub XQL.

13.	Funkcja importu Baza danych musi posiadać funkcję, która umożliwia wprowadzenie danych do bazy poprzez import sformatowanych danych zamiast wprowadzania ręcznego.

14.	Funkcja eksportu Baza danych musi posiadać funkcję, która umożliwia eksport zawartości całej bazy danych lub jej części w postaci sformatowanych danych.

15.	Pola obowiązkowe W bazie danych istnieć muszą obowiązkowe pola, które muszą zostać wypełnione zanim odnośny rekord zostanie zaakceptowany jako wpis w bazie danych.

16.	Kontrole wiarygodności Baza danych musi posiadać funkcję konfigurowalnych kontroli wiarygodności przed zaakceptowaniem wprowadzenia, aktualizacji lub usunięcia rekordów danych.

17.	Czasy reakcji Czasy reakcji bazy danych muszą umożliwiać użytkownikom wprowadzanie, aktualizowanie lub usuwanie rekordów danych bez nadmiernych opóźnień.

18.

Aspekty związane z wydajnością Referencyjne pliki i bazy danych muszą w odpowiedzi na zapytania dostarczać w sposób ekonomicznie efektywny informacji niezbędnych do umożliwienia efektywnego dokonywania wszystkich stosownych przejazdów pociągów i wagonów, które wchodzą w zakres przepisów niniejszej TSI.

19.

Aspekty związane z pojemnością Baza danych musi umożliwiać przechowywanie stosownych danych w odniesieniu do wszystkich wagonów towarowych bądź do sieci. Należy zapewnić możliwość rozszerzenia pojemności w prosty sposób (np. przez dodanie pojemności pamięci i zwiększenie ilości komputerów). Rozszerzenie pojemności nie może wymagać wymiany podsystemu.

20.	Dane historyczne Baza danych musi umożliwiać zarządzanie danymi historycznymi w sensie udostępniania danych, które zostały już umieszczone w archiwum.

21.	Strategia sporządzania kopii zapasowych Wdrożona musi być strategia sporządzania kopii zapasowych zapewniająca odtworzenie pełnej zawartości bazy danych za okres do 24 godzin.

22.	Aspekty handlowe Wykorzystany w bazie danych system musi być dostępny w handlu jako produkt gotowy (produkt COTS — dostępny od ręki) lub być dostępny w domenie publicznej (oprogramowanie otwarte).

Uwagi:

Powyższe wymagania muszą być spełnione w ramach standardowego Systemu Zarządzania Bazami Danych (DBMS).

Używanie różnorodnych baz danych jest integralną częścią poszczególnych opisanych powyżej procesów. Zasadniczym procesem jest mechanizm zapytanie/odpowiedź, w którym zainteresowana strona wystosowuje zapytanie o informacje z bazy danych wykorzystując wspólny interfejs (rozdziały: 4.2.12.1 „Ogólna architektura” oraz 4.2.12.6 „Wspólny interfejs”). DBMS odpowiada na to zapytanie poprzez dostarczenie żądanych danych lub poprzez udzielenie odpowiedzi, że dane nie mogą zostać udostępnione (dane takie nie istnieją lub zgodnie z ustawieniami kontroli dostępu odmawia się dostępu do nich).

4.2.12.   Łączność sieciowa i komunikacja

4.2.12.1.   Architektura ogólna

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

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

Proponowana architektura wymiany informacji:

—	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 z podmiotów,

—	chroni dokonane już inwestycje informatyczne.

Architektura wymiany informacji sprzyja interakcji, zazwyczaj typu peer-to-peer („równy z równym”), między wszystkimi podmiotami, gwarantując przy tym integralność i spójność ogółu społeczności w sektorze interoperacyjności kolei poprzez dostarczanie zestawu scentralizowanych usług.

Model interakcji peer-to-peer umożliwia najlepszy podział kosztów między różne podmioty w oparciu o faktyczne użytkowanie i na ogół stwarza mniej problemów związanych ze skalowalnością. Prezentację graficzną architektury ogólnej zawarto w wymienionym w dodatku I dokumencie „TAF TSI — Annex A.5:Figures and Sequence Diagrams of the TAF TSI messages”, w rozdziale 1.5.

4.2.12.2.   Sieć

Łączność sieciowa w tym przypadku oznacza metodę i filozofię komunikacji, a nie fizyczną sieć połączeń.

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

Kwestie bezpieczeństwa będą zatem rozwiązywane nie w ramach samej sieci (VPN, tunelowanie itd.), lecz poprzez wymienianie bezpiecznych komunikatów i zarządzanie nimi. Sieć VPN nie jest więc wymagana (administrowanie dużą siecią VPN jest zadaniem złożonym i kosztownym), co pozwala uniknąć problemów związanych z przydzielaniem odpowiedzialności i własności. Tunelowanie nie jest uważane za niezbędny środek do osiągnięcia odpowiedniego poziomu bezpieczeństwa.

Jeżeli jednak niektóre podmioty muszą lub chcą wprowadzić różnorodne stopnie zabezpieczenia na wybranych partycjach sieci, to mogą to zrobić.

W ramach ogólnodostępnej sieci internetowej możliwe jest wdrożenie hybrydowego modelu peer-to-peer ze wspólnym interfejsem w węźle każdego uczestnika i centralnym centrum certyfikacji.

Następnie realizowana jest komunikacja peer-to-peer pomiędzy uczestniczącymi podmiotami.

Komunikacja typu „peer-to-peer” oparta jest na normach technicznych dotyczących wspólnego interfejsu opisanych w zawartym w dodatku I dokumencie „TAF TSI — Annex D.2: Appendix F — TAF TSI Data and Message Model”.

4.2.12.3.   Bezpieczeństwo

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

4.2.12.4.   Szyfrowanie

Należy stosować szyfrowanie asymetryczne lub rozwiązanie hybrydowe oparte na szyfrowaniu symetrycznym z zabezpieczeniem w formie klucza publicznego, ze względu na fakt, że stosowanie wspólnego tajnego klucza przez różnych uczestników w pewnym momencie zawodzi. Wyższy poziom zabezpieczenia jest łatwiejszy do osiągnięcia, jeśli każdy podmiot bierze na siebie odpowiedzialność za swoją własną parę kluczy, mimo że wymagany jest wysoki poziom integralności centralnego repozytorium (serwera kluczy).

4.2.12.5.   Centralne repozytorium

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 plik referencyjny jest użytkowany wspólnie z TSI TAP [2], rozwijanie jego zawartości i wprowadzane w nim zmiany muszą być zgodne z TSI TAP [2] w celu osiągnięcia jak najwyższego stopnia synergii.

4.2.12.6.   Wspólny interfejs

Wspólny interfejs jest obowiązkowy dla każdego podmiotu, aby mógł on przystąpić do społeczności interoperacyjności kolei.

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 użytkowany jest wspólnie z TSI TAP [2], rozwijanie zawartości i wprowadzane zmiany muszą być zgodne z TSI TAP [2] w celu osiągnięcia jak najwyższego stopnia synergii. Na podstawie wyników weryfikacji autentyczności komunikatów przychodzących można wdrożyć minimalny poziom potwierdzenia komunikatu:

(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.

Podmiot może sporządzić lokalną kopię „lustrzaną” centralnego repozytorium, aby skrócić czas reakcji.

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

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

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.12.6 Wspólny interfejs	4.2.21.7 Wspólny interfejs w odniesieniu do komunikacji RU/IM
Centralne repozytorium	4.2.12.5 Centralne repozytorium	4.2.21.6 Centralne repozytorium
Pliki referencyjne	4.2.11.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 (na przykład wysłanie danych o składzie pociągu lub aktualizacja danych dotyczących pociągu lub wagonu). Aby spełnić wymagania dotyczące terminowości należy możliwie jak najwcześniej dokonywać aktualizacji danych — także w celu zagwarantowania, by dane zawarte w komunikatach były zawsze aktualne w momencie, gdy są rozsyłane automatycznie przez system.

Wskaźniki jakości danych

W odniesieniu do kompletności (odsetek pól danych do których wpisano wartości) danych obowiązkowych oraz spójności danych (odsetek odpowiadających sobie wartości w obrębie tabel/plików/rekordów) należy osiągnąć poziom 100 %.

W odniesieniu do terminowości danych (odsetek danych dostępnych w określonych progowych ramach czasowych) należy osiągnąć poziom 98 %. W przypadku gdy wartości progowe nie zostały określone w niniejszej TSI, wartości te muszą zostać określone w umowach pomiędzy uczestniczącymi podmiotami.

Wymagana ścisłość (odsetek zachowanych w bazie wartości, które są zgodne z wartościami faktycznymi) musi osiągnąć poziom ponad 90 %. Dokładne wartości i kryteria należy określić w umowach pomiędzy uczestniczącymi podmiotami.

4.4.2.   Obsługa centralnego repozytorium

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

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.11.3 („Dodatkowe wymagania dotyczące baz danych”) w pkt 10 i 21.

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 lit. f) dyrektywy 2008/57/WE [1]:

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

5.2.   Wykaz składników

Składniki interoperacyjności są objęte stosownymi przepisami dyrektywy 2008/57/WE [1].

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

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

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

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

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

Procedura oceny zgodności składników interoperacyjności lub ich przydatności do stosowania musi być przeprowadzana w oparciu o europejskie specyfikacje lub specyfikacje zatwierdzone zgodnie z dyrektywą 2008/57/WE [1].

W przypadku przydatności do stosowania w odnośnych specyfikacjach określa się wszystkie parametry, które mają być mierzone, monitorowane lub obserwowane, i opisuje związane z nimi metody badań i procedury pomiarów przewidziane do stosowania w symulacji laboratoryjnej bądź w próbach w rzeczywistym środowisku kolejowym.

Procedury oceny zgodności lub przydatności do stosowania:

Wykaz specyfikacji, opis metod badawczych:

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

6.1.2.   Moduł

Na wniosek producenta lub jego przedstawiciela mającego siedzibę we Wspólnocie jednostka notyfikowana przeprowadza procedurę zgodnie z przepisami decyzji Komisji 2010/713/UE dotyczącymi stosownych modułów przedstawionymi, poprawionymi i uzupełnionymi w dodatku do niniejszej TSI.

Moduły należy łączyć i używać wybiórczo stosownie do konkretnego składnika.

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

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

Na wniosek organu przyznającego lub jego przedstawiciela mającego siedzibę we Wspólnocie jednostka notyfikowana przeprowadza procedurę weryfikacji WE zgodnie z załącznikiem VI do dyrektywy 2008/57/WE [1].

Zgodnie z załącznikiem II do dyrektywy 2008/57/WE [1] podsystemy można podzielić na podsystemy strukturalne i eksploatacyjne (funkcjonalne).

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

Niemniej jednak centralne repozytorium i wspólny interfejs w węźle każdego uczestnika stanowią podstawę integracji aplikacji. Model wymiany informacji jest przechowywany w scentralizowanym repozytorium integracji aplikacji, w którym metadane na potrzeby interfejsu są przechowywane w jednym fizycznym miejscu. Te metadane zawierają informacje o treści komunikacji (co znajduje się w przesyłanych danych), dane identyfikacyjne punktów kontaktowych nadawców i odbiorców oraz protokoły biznesowe mechanizmu interakcji na poziomie aplikacji.

Należy podkreślić następujące kwestie:

—	Centralne repozytorium zawiera również centrum certyfikacji (otwarte CA PKI). Jest to zasadniczo akt administracyjny, który został wdrożony fizycznie. Nieprawidłowe wpisy wykrywane są natychmiast. Procedura oceny jest zbędna.

—

Centralne repozytorium zawiera metadane komunikatów (zgodnie z dokumentem „TAF TSI — Annex D.2: Appendix F — TAF TSI Data and Message Model”, wymienionym w dodatku I) stanowiące podstawę do wymiany komunikatów w heterogenicznym środowisku informatycznym. Metadane muszą być administrowane i aktualizowane w centralnym repozytorium. Wszelka niezgodność w strukturze lub treści komunikatu przy wysyłaniu i odbieraniu danych zostanie natychmiast rozpoznana i nastąpi odmowa przekazu. Procedura oceny jest zbędna.

—

Wspólny interfejs w węźle każdego uczestnika zawiera przede wszystkim lokalną kopię „lustrzaną” centralnego repozytorium, sporządzoną w celu skrócenia czasu reakcji i zmniejszenia obciążenia repozytorium. Należy zapewnić, by centralne repozytorium i wspólny interfejs zawierały zawsze tę samą wersję danych. Z tego względu aktualizacji danych należy dokonywać na poziomie centralnym i z niego też muszą być pobierane nowe wersje. Procedura oceny jest zbędna.

7.   WDROŻENIE

7.1.   Tryb stosowania niniejszej TSI

7.1.1.   Wstęp

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

TSI wdrażana jest etapowo:

—	etap pierwszy: szczegółowe specyfikacje informatyczne i plan generalny,

—	etap drugi: opracowanie,

—	etap trzeci: wdrożenie.

7.1.2.   Etap pierwszy — szczegółowe specyfikacje informatyczne i plan generalny

Specyfikacje zawierające wymagania funkcjonalne, które należy wykorzystać jako podstawę wspomnianej powyżej architektury technicznej na etapie opracowywania i wdrażania systemu skomputeryzowanego, zawarto w dodatkach A–F wymienionych w dodatku I do niniejszego rozporządzenia.

Obowiązkowy plan generalny, który obejmuje wszystkie etapy od koncepcji po gotowy system skomputeryzowany i jest oparty na strategicznym europejskim planie wdrożeniowym (SEDP) przygotowanym przez sektor kolei, zawiera kluczowe elementy architektury systemu oraz wskazanie najważniejszych działań do wykonania.

7.1.3.   Etap 2 i 3 — opracowanie i wdrożenie

Przedsiębiorstwa kolejowe, zarządcy infrastruktury i posiadacze wagonów opracowują i wdrażają skomputeryzowany system TAF zgodnie z przepisami niniejszego rozdziału.

7.1.4.   Zarządzanie, role i podział odpowiedzialności

Etap opracowywania i etap wdrożenia podlegają strukturze zarządzania obejmującej wymienione poniżej podmioty.

Komitet sterujący

Komitet sterujący ma następujące zadania i obowiązki:

Komitet sterujący zapewnia strukturę zarządzania strategicznego w celu skutecznego zarządzania pracami zmierzającymi do wdrożenia TSI TAF oraz koordynacji takich prac. Obejmuje to ustalanie polityki, kierunku strategicznego i priorytetów. W ramach tych zadań komitet sterujący uwzględnia również interesy małych przedsiębiorstw, nowych podmiotów i przedsiębiorstw kolejowych wykonujących usługi specjalne.

Komitet sterujący monitoruje postępy wdrażania. Co najmniej cztery razy do roku przedkłada Komisji Europejskiej regularne sprawozdania na temat osiągniętych postępów w porównaniu z planem generalnym. Komitet sterujący podejmuje niezbędne działania w celu dostosowania przebiegu prac w przypadku odstępstw od planu generalnego.

1.	W skład komitetu sterującego wchodzą: — organy przedstawicielskie sektora kolejowego działające na szczeblu europejskim, określone w art. 3 ust. 2 rozporządzenia (WE) nr 881/2004 („organy przedstawicielskie sektora kolei”), — Europejska Agencja Kolejowa, oraz — Komisja.

2.	Komitetowi sterującemu przewodniczą wspólnie: a) Komisja; oraz b) osoba wyznaczona przez organy przedstawicielskie sektora kolei. Komisja, przy wsparciu członków komitetu sterującego, opracowuje regulamin wewnętrzny przedmiotowego komitetu sterującego, na który komitet sterujący musi wyrazić zgodę.

3.	Członkowie komitetu sterującego mogą wnioskować o to, aby komitet sterujący uwzględnił inne organizacje w charakterze obserwatorów, jeżeli jest to uzasadnione ze względów technicznych i organizacyjnych.

Zainteresowane podmioty

Przedsiębiorstwa kolejowe, zarządcy infrastruktury i posiadacze wagonów ustanawiają skuteczną strukturę zarządzania projektem, umożliwiającą skuteczne opracowanie i wdrożenie systemu TAF.

Wyżej wymienione zainteresowane podmioty:

—	zapewniają działania i zasoby niezbędne do wdrożenia niniejszego rozporządzenia,

—	przestrzegają zasad dostępu do wspólnych elementów TSI TAF, które mają być dostępne dla wszystkich uczestników rynku w sposób ujednolicony, przejrzysty i możliwie najtańszy pod względem kosztów usługi,

—	zapewniają, aby wszyscy uczestnicy rynku mieli dostęp do wszystkich wymienianych danych niezbędnych do spełnienia ich obowiązków prawnych oraz do wykonywania ich funkcji zgodnie z wymaganiami funkcjonalnymi TSI TAF,

—	chronią poufność kontaktów z klientami,

—

ustanawiają mechanizm umożliwiający „spóźnionym” podmiotom dołączenie do opracowywania TAF i skorzystanie z dotychczasowych osiągnięć TAF w zakresie elementów wspólnych w sposób zadowalający zarówno dla wspomnianych zainteresowanych podmiotów, jak i dla nowych podmiotów, w szczególności pod względem sprawiedliwego podziału kosztów,

—	składają komitetowi sterującemu TAF sprawozdania dotyczące postępów w zakresie realizacji planów wdrażania. W sprawozdaniach tych uwzględnia się, w stosownych przypadkach, informacje o odstępstwach od planu generalnego.

Organy przedstawicielskie

Organy przedstawicielskie sektora kolei działające na szczeblu europejskim, określone w art. 3 ust. 2 rozporządzenia (WE) nr 881/2004 Parlamentu Europejskiego i Rady (1), mają następujące zadania i obowiązki:

—	reprezentują poszczególne zainteresowane podmioty członkowskie w komitecie sterującym TSI TAF,

—	informują swoich członków o ich obowiązkach wynikających z wdrażania niniejszego rozporządzenia,

—	zapewniają wszystkim wspomnianym zainteresowanym podmiotom terminowy, bieżący i pełny dostęp do informacji na temat stanu prac komitetu sterującego i wszelkich innych grup w celu zabezpieczenia interesów każdego przedstawiciela w ramach wdrażania TSI TAF,

—	zapewniają skuteczny przepływ informacji od poszczególnych zainteresowanych podmiotów członkowskich do komitetu sterującego TAF, tak aby interesy zainteresowanych podmiotów były właściwie uwzględniane przy podejmowaniu decyzji mających wpływ na opracowywanie i wdrażanie TAF,

—	zapewniają skuteczny przepływ informacji od komitetu sterującego TAF do poszczególnych zainteresowanych podmiotów członkowskich, tak aby zainteresowane podmioty były odpowiednio informowane o decyzjach mających wpływ na opracowywanie i wdrażanie TAF.

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 Europejską Agencję Kolejową i obejmują:

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

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

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

—	politykę zarządzania, zwolnienia, migracji i wprowadzenia zmiany,

—	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ą Europejska Agencja Kolejowa, organy przedstawicielskie sektora kolei i krajowe organy ds. bezpieczeństwa. Taki skład zapewni odpowiednie podejście do zmian, które mają być wprowadzone, oraz wszechstronną ocenę ich konsekwencji. Komisja może dokooptować kolejne strony do CCB, jeżeli uzna ich uczestnictwo za konieczne. CCB przejdzie ostatecznie pod egidę Europejskiej Agencji Kolejowej.

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

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

1.

Wnioski o wprowadzenie zmian mających wpływ na dokumenty są składane za pośrednictwem krajowych organów ds. bezpieczeństwa, organów przedstawicielskich sektora kolei działających na szczeblu europejskim, określonych w art. 3 ust. 2 rozporządzenia (WE) nr 881/2004, lub za pośrednictwem komitetu sterującego TSI TAF. Komisja może dodać kolejne strony uprawnione do składania wniosków, jeżeli uzna ich wkład za konieczny.

2.	Europejska Agencja Kolejowa gromadzi i przechowuje wnioski o wprowadzenie zmian.

3.	Europejska Agencja Kolejowa 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 Europejska Agencja Kolejowa kieruje 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, to Europejska Agencja Kolejowa przekazuje wnioskodawcy uzasadnienie odrzucenia wniosku lub prośbę o przedłożenie dodatkowych informacji dotyczących projektu wniosku o wprowadzenie zmian.

6.	Do dokumentu wprowadza się zmiany na podstawie potwierdzonych wniosków o wprowadzenie zmian.

7.	Europejska Agencja Kolejowa przedkłada Komisji zalecenie dotyczące aktualizacji dokumentów wymienionych w dodatku I, wraz z projektem nowej wersji dokumentów, wnioskami o wprowadzenie zmian i ich oceną ekonomiczną.

8.	Europejska Agencja Kolejowa udostępnia na swojej stronie internetowej projekt nowej wersji dokumentu i potwierdzone wnioski o wprowadzenie zmian.

9.

Po opublikowaniu aktualizacji dokumentów wymienionych w dodatku I w Dzienniku Urzędowym Unii Europejskiej Europejska Agencja Kolejowa udostępnia nową wersję dokumentów na swojej stronie internetowej. W przypadkach gdy zarządzanie zmianami ma wpływ na elementy pozostające we wspólnym użytkowaniu w ramach TSI TAP [2], zmian dokonuje się w taki sposób, aby pozostać jak najbliżej już wdrożonej TSI TAP [2], w celu osiągnięcia jak największego stopnia synergii.

---

(1)  Rozporządzenie (WE) nr 881/2004 Parlamentu Europejskiego i Rady z dnia 29 kwietnia 2004 r. ustanawiające Europejską Agencję Kolejową (Rozporządzenie w sprawie Agencji) (Dz.U. L 164 z 30.4.2004, s. 1).