Akty Prawne
Dziennik Urzędowy Unii Europejskiej - Seria L
Dz.U.UE.L.2006.13.1

Rozporządzenie 62/2006 dotyczące technicznej specyfikacji dla interoperacyjności odnoszącej się do podsystemu aplikacji telematycznych dla przewozów towarowych transeuropejskiego systemu kolei konwencjonalnych

ROZPORZĄDZENIE KOMISJI (WE) 62/2006

z dnia 23 grudnia 2005 r.

dotyczące technicznej specyfikacji dla interoperacyjności odnoszącej się do podsystemu aplikacji telematycznych dla przewozów towarowych transeuropejskiego systemu kolei konwencjonalnych

(Tekst mający znaczenie dla EOG)

KOMISJA WSPÓLNOT EUROPEJSKICH,

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

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

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

(1) Zgodnie z art. 2 lit. c) dyrektywy 2001/16/WE transeuropejski system kolei konwencjonalnych podzielony jest na podsystemy strukturalne i funkcjonalne. Każdy z tych podsystemów musi być objęty techniczną specyfikacją dla interoperacyjności (TSI).

(2) Pierwszym krokiem w ustanowieniu TSI jest opracowanie projektu TSI przez Europejskie Stowarzyszenie na rzecz Interoperacyjności Kolei (AEIF), wyznaczone jako wspólny organ przedstawicielski.

(3) AEIF otrzymało mandat na przygotowanie projektu TSI dla podsystemu aplikacji telematycznych dla przewozów towarowych, zgodnie z art. 6 ust. 1 dyrektywy 2001/16/WE. Podstawowe parametry dla projektu niniejszej TSI zostały przyjęte decyzją Komisji 2004/446/WE z dnia 29 kwietnia 2004 r. określającą podstawowe parametry dla TSI Hałas, Wagony towarowe i Aplikacje telematyczne, wymienionych w dyrektywie 2001/16/WE⁽²⁾.

(4) Projektowi TSI, opracowanemu na bazie podstawowych parametrów, towarzyszyło sprawozdanie wprowadzające, zawierające analizę kosztów i zysków, zgodnie z art. 6 ust. 5 dyrektywy.

(5) Projekt TSI został przeanalizowany przez Komitet ustanowiony na mocy art. 21 dyrektywy Rady 96/48//WE z dnia 23 lipca 1996 r. w sprawie interoperacyjności transeuropejskiego systemu kolei dużych prędkości⁽³⁾ oraz w świetle sprawozdania wprowadzającego.

(6) Zgodnie z art. 1 dyrektywy 2001/16/WE warunki osiągnięcia interoperacyjności transeuropejskiej systemu kolei konwencjonalnych obejmują działania związane z projektowaniem, konstrukcją, modernizacją, odnawianiem i obsługą infrastruktury i taboru kolejowego, mające na celu zapewnienie funkcjonowania systemu, który ma być wprowadzony do użytku po wejściu w życie tej dyrektywy. Ponadto istotne jest również skuteczne połączenie systemów informatycznych i komunikacyjnych różnych zarządców infrastruktury i przewoźników kolejowych.

(7) Większość istniejących aplikacji telematycznych dla przewozów towarowych została opracowana i wdrożona zgodnie z wymogami rynków krajowych, co utrudnia osiągniecie ciągłości ponadgranicznych usług informacyjnych, będących czynnikiem kluczowym dla zapewnienia jakości usług międzynarodowego transportu kolejowego, zwłaszcza w szybko rosnącym segmencie międzynarodowego transportu towarowego.

(8) TSI dla telematyki nie powinna wymagać wykorzystania szczególnych technologii lub rozwiązań technicznych, za wyjątkiem sytuacji, kiedy jest to absolutnie niezbędne dla zrealizowania funkcji interoperacyjności transeuropejskiej systemu kolei konwencjonalnych.

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

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

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

(12) Dla zapewnienia skutecznego wdrażania TSI należy opracować Strategiczny Europejski Plan Wdrożeniowy. Kolejne etapy, ustanawiane przez podmioty, muszą być koordynowane na poziomie europejskim i musza uwzględniać istniejące procesy i systemy IT przewoźników kolejowych i zarządców infrastruktury. W tym celu przewoźnicy kolejowi i zarządcy infrastruktury powinni wnieść swój udział poprzez zapewnienie wszelkich informacji funkcjonalnych i technicznych na temat poszczególnych istniejących aplikacji telematycznych dla przewozów towarowych.

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

(14) Celem uniknięcia nieporozumień konieczne jest stwierdzenie, że przepisy zawarte w decyzji Komisji 2004/446/WE, które dotyczą podstawowych parametrów transeuropejskiego systemu kolei konwencjonalnych, nie mają już zastosowania.

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

(16) Przepisy niniejszego rozporządzenia są zgodne z opinią Komitetu ustanowionego na mocy dyrektywy 96/48/WE,

PRZYJMUJE NINIEJSZE ROZPORZĄDZENIE:

Artykuł 3

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

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

Artykuł 4a 1

Artykuł 4b 2

Niniejsze rozporządzenie wiąże w całości i jest bezpośrednio stosowane we wszystkich Państwach Członkowskich.

Sporządzono w Brukseli, dnia 23 grudnia 2005 r.

	W imieniu Komisji
	Jacques BARROT
	Wiceprzewodniczący

______

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

⁽²⁾ Dz.U. L 155 z 30.4.2004, str. 1, sprostowanie w Dz.U. L 193 z 1.6.2004, str. 1.

⁽³⁾ Dz.U. L 235 z 17.9.1996, str. 6. Dyrektywa zmieniona dyrektywą 2004/50/WE.

⁽⁴⁾ Dz.U. L 164 z 30.4.2004, str. 1, sprostowanie w Dz.U. L 220 z 21.6.2004, str. 3).

ZAŁĄCZNIK 4

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

Transeuropejski system kolei konwencjonalnej

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

1. WSTĘP

1.1. Zakres techniczny

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

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

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

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

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

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

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

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

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

1.2. Zakres geograficzny

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

1.3. Zawartość niniejszej TSI

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

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

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

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

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

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

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

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

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

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

2. DEFINICJA PODSYSTEMU/ZAKRES

2.1. Funkcja w zakresie TSI

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

Obejmuje on w szczególności:

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

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

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

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

2.2. Funkcje poza zakresem TSI

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

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

2.3. Przegląd opisu podsystemu

2.3.1. Uczestniczące jednostki

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

- wagony,

- lokomotywy,

- maszyniści,

- manewrowanie i rozrządzanie,

- sprzedaż automatów biletowych,

- zarządzanie przesyłką,

- skład pociągu,

- prowadzenie pociągu,

- monitorowanie pociągu,

- sterowanie pociągiem,

- monitorowanie przesyłki,

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

- odprawa celna,

- obsługa terminali intermodalnych,

- zarządzanie przewozami.

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

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

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

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

"»Ubiegający się« oznacza licencjonowanego przewoźnika kolejowego i/lub międzynarodowe ugrupowanie przewoźników kolejowych oraz, w Państwach Członkowskich, które przewidują taką możliwość, inne osoby i/lub jednostki prawne mające wynikające ze służby publicznej lub komercyjne interesy w nabywaniu mocy przepustowych infrastruktury, takie jak organy publiczne zgodnie z rozporządzeniem (EWG) nr 1191/69 oraz załadowcy, spedytorzy oraz przewoźnicy transportu kombinowanego, w celu prowadzenia usług kolejowych na ich odnośnych terytoriach.

Natomiast »przewoźnik kolejowy« jest zdefiniowany jako dowolne publiczne lub prywatne przedsiębiorstwo licencjonowane zgodnie z obowiązującym prawodawstwem wspólnotowym, którego główna działalność polega na świadczeniu usług przewozu towarów i/lub osób koleją przy wymaganiu, że przedsiębiorstwo to musi zapewnić trakcję; obejmuje to również przedsiębiorstwa, które dostarczają wyłącznie trakcję."

W oparciu o tę definicję w rozumieniu niniejszej TSI uważa się RU za dostawcę usług w zakresie prowadzenia pociągów.

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

"Zdolność przepustowa infrastruktury jest alokowana przez zarządcę infrastruktury, a z chwilą przydzielenia wnioskodawcy nie może być przekazywana przez otrzymującego innemu przedsiębiorstwu lub innym rodzajom przewozów. Wszelki obrót zdolnością przepustową infrastruktury jest zakazany i prowadzi do wykluczenia z dalszej alokacji zdolności przepustowej. Wykorzystywanie zdolności przepustowej przez przedsiębiorstwo kolejowe przy wykonywaniu działalności gospodarczej wnioskodawcy, który nie jest przedsiębiorstwem kolejowym, nie jest uważane za przekazanie."

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

Jak już wspomniano, dla transportu towarowego muszą być zapewnione różne usługi. Jedną z nich jest na przykład dostarczanie wagonów. Usługę tę można powiązać z zarządcą floty pojazdów. Jeżeli ta usługa na potrzeby transportu jest jedną z usług oferowanych przez RU, to RU działa również jako zarządca floty pojazdów. Zarządca floty pojazdów może z kolei zarządzać swoimi własnymi wagonami i/lub wagonami innego dysponenta (innego dostawcy usług w zakresie wagonów towarowych). Potrzeby tego rodzaju dostawcy usług są brane pod uwagę niezależnie od tego, czy osoba prawna zarządcy floty pojazdów jest jednocześnie przewoźnikiem kolejowym (RU) czy nie.

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

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

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

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

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

2.3.2. Rozpatrywane procesy

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

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

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

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

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

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

- MIERZENIA jakości dostarczanej usługi w porównaniu do tego, co zostało określone, np. ścisłości wystawionych rachunków w stosunku do podanej ceny, rzeczywistych czasów przejazdu w stosunku do zobowiązań, wagonów zamówionych w stosunku do dostarczonych, ETA w stosunku do faktycznego czasu przyjazdu,

- DZIAŁANIA w sposób produktywny pod względem wykorzystania: zdolności przepustowej pociągów, infrastruktury i floty pojazdów poprzez stosowanie procesów gospodarczych, systemów i wymiany informacji wymaganych do wspomagania sporządzania harmonogramu wagonów/jednostek intermodalnych i pociągów.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.3.3. Uwagi ogólne

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

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

- identyfikacja taboru,

- dane techniczne/projektowe,

- ocena zgodności z infrastrukturą,

- ocena istotnych charakterystyk obciążenia,

- istotne charakterystyki hamulców,

- dane dotyczące konserwacji i utrzymania,

- charakterystyki środowiskowe.

W intermodalnej działalności transportowej w różnych punktach (zwanych terminalami przeładunkowymi) nie tylko wagon jest podłączany do innego pociągu, lecz także jednostka intermodalna może być przeniesiona z jednego wagonu do drugiego. W związku z tym nie wystarczy pracować tylko przy pomocy planu podróży dla wagonów i dlatego musi zostać opracowany również plan podróży dla jednostek intermodalnych.

W rozdziale 4.2.12 (Różnorodne pliki źródłowe) wymieniono niektóre źródłowe pliki i bazy danych, wśród nich operacyjną bazę danych wagonów i jednostek intermodalnych. Baza ta zawiera dane o statusie operacyjnym taboru, informacje o ciężarze i niebezpiecznych towarach, informacje dotyczące jednostek intermodalnych oraz informacje o lokalizacji. W rozdziale 4.2.13 (Elektroniczne przesyłanie dokumentów) podano wymagania dotyczące elektronicznego przesyłania dokumentów.

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

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

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

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

Nie ma bezpośredniej transmisji danych z podsystemu "Aplikacje telematyczne dla przewozów towarowych" do pociągu, maszynisty lub do części podsystemu "Sterowanie ruchem kolejowym", a fizyczna sieć transmisyjna jest zupełnie inna niż sieć wykorzystywana przez podsystem "Sterowanie ruchem kolejowym". System ERTMS/ETSC używa GSM-R. W tej otwartej sieci specyfikacje ETCS wyjaśniają, że bezpieczeństwo jest osiągane przy odpowiednim zarządzaniu zagrożeniami otwartych sieci w protokole EURORADIO.

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

3. WYMAGANIA ZASADNICZE

3.1. Spełnienie wymagań zasadniczych

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

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

3.2. Aspekty wymagań zasadniczych

Wymagania zasadnicze dotyczą:

- bezpieczeństwa,

- niezawodności i dostępności,

- zdrowia,

- ochrony środowiska,

- zgodności technicznej.

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

3.3. Aspekty związane z wymaganiami ogólnymi

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

3.3.1. Bezpieczeństwo

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

- Wymaganie zasadnicze 1.1.1 załącznika III do dyrektywy 2001/16/WE:

"Projektowanie, konstrukcja lub montaż, utrzymanie i monitorowanie składników mających krytyczne znaczenie dla bezpieczeństwa, a konkretnie składników występujących w ruchach pociągów musi być takie, aby gwarantowało bezpieczeństwo na poziomie odpowiadającym celom ustalonym dla sieci, w tym również dla szczególnych pogorszonych sytuacji."

To wymaganie zasadnicze nie odnosi się do podsystemu "Aplikacje telematyczne".

- Wymaganie zasadnicze 1.1.2 załącznika III do dyrektywy 2001/16/WE:

"Parametry występujące w kontakcie koło/szyna muszą spełniać wymagania stabilności niezbędne do zagwarantowania bezpiecznego ruchu przy maksymalnej dopuszczonej prędkości."

To wymaganie zasadnicze nie odnosi się do podsystemu "Aplikacje telematyczne".

- Wymaganie zasadnicze 1.1.3 załącznika III do dyrektywy 2001/16/WE:

"Zastosowane składniki muszą wytrzymywać wszelkie normalne i wyjątkowe naprężenia, które zostały określone podczas okresu ich eksploatacji. Konsekwencje wszelkich przypadkowych awarii dla bezpieczeństwa muszą być ograniczone za pomocą odpowiednich środków."

To wymaganie zasadnicze nie odnosi się do podsystemu "Aplikacje telematyczne".

- Wymaganie zasadnicze 1.1.4 załącznika III do dyrektywy 2001/16/WE:

"Projektowanie stałych instalacji i taboru kolejowego oraz wybór zastosowanych materiałów muszą mieć na uwadze ograniczenie wytwarzania, rozprzestrzeniania oraz skutków ognia i dymu w razie pożaru."

To wymaganie zasadnicze nie odnosi się do podsystemu "Aplikacje telematyczne".

- Wymaganie zasadnicze 1.1.5 załącznika III do dyrektywy 2001/16/WE:

"Wszelkie urządzenia, którymi mają posługiwać się użytkownicy, muszą być tak zaprojektowane, aby nie wpływały ujemnie na bezpieczną pracę urządzeń lub na zdrowie i bezpieczeństwo użytkowników, jeśli zostaną użyte w przewidywalny sposób niezgodny z wywieszonymi instrukcjami."

To wymaganie zasadnicze nie odnosi się do podsystemu "Aplikacje telematyczne".

3.3.2. Niezawodność i dostępność

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

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

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

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

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

3.3.3. Zdrowie

- Wymaganie zasadnicze 1.3.1 załącznika III do dyrektywy 2001/16/WE:

"Materiały, które z racji sposobu, w jaki są używane, mogą stanowić zagrożenie dla zdrowia tych, którzy mają do nich dostęp, nie mogą być stosowane w pociągach i infrastrukturze kolejowej."

To wymaganie zasadnicze nie odnosi się do podsystemu "Aplikacje telematyczne".

- Wymaganie zasadnicze 1.3.2 załącznika III do dyrektywy 2001/16/WE:

"Materiały te muszą zostać wybrane, rozmieszczone i użyte w taki sposób, aby ograniczyć emisję szkodliwych i niebezpiecznych dymów i gazów, szczególnie w razie pożaru."

To wymaganie zasadnicze nie odnosi się do podsystemu "Aplikacje telematyczne".

3.3.4. Ochrona środowiska

- Wymaganie zasadnicze 1.4.1 załącznika III do dyrektywy 2001/16/WE:

"Wpływ na środowisko spowodowany ustanowieniem i eksploatacją transeuropejskiego systemu kolei konwencjonalnej musi zostać oceniony i uwzględniony na etapie projektowania systemu zgodnie z obowiązującymi wspólnotowymi przepisami."

To wymaganie zasadnicze nie odnosi się do podsystemu "Aplikacje telematyczne".

- Wymaganie zasadnicze 1.4.2 załącznika III do dyrektywy 2001/16/WE:

"Materiały zastosowane w pociągach i infrastrukturze muszą uniemożliwiać emisję dymów lub gazów szkodliwych lub niebezpiecznych dla środowiska, zwłaszcza w razie pożaru."

To wymaganie zasadnicze nie odnosi się do podsystemu "Aplikacje telematyczne".

- Wymaganie zasadnicze 1.4.3 załącznika III do dyrektywy 2001/16/WE:

"Tabor kolejowy i systemy zasilania energią muszą być zaprojektowane i wykonane w taki sposób, aby były zgodne pod względem elektromagnetycznym z instalacjami, urządzeniami oraz publicznymi lub prywatnymi sieciami, z którymi mogłyby kolidować."

To wymaganie zasadnicze nie odnosi się do podsystemu "Aplikacje telematyczne".

- Wymaganie zasadnicze 1.4.4 załącznika III do dyrektywy 2001/16/WE:

"Eksploatacja transeuropejskiego systemu kolei konwencjonalnej musi respektować istniejące przepisy dotyczące zanieczyszczenia hałasem."

To wymaganie zasadnicze nie odnosi się do podsystemu "Aplikacje telematyczne".

- Wymaganie zasadnicze 1.4.5 załącznika III do dyrektywy 2001/16/WE:

"Eksploatacja transeuropejskiego systemu kolei konwencjonalnej nie może prowadzić do wytwarzania niedopuszczalnego poziomu drgań gruntu dla działalności i terenów będących w pobliżu infrastruktury i w normalnym stanie utrzymania."

To wymaganie zasadnicze nie odnosi się do podsystemu "Aplikacje telematyczne".

3.3.5. Zgodność techniczna

- Wymaganie zasadnicze 1.5 załącznika III do dyrektywy 2001/16/WE:

"Charakterystyki techniczne infrastruktury i stałych instalacji muszą być zgodne ze sobą oraz z charakterystykami pociągów, które będą używane w transeuropejskim systemie kolei konwencjonalnej. Jeżeli zgodność z tymi charakterystykami okaże się trudna na niektórych odcinkach sieci, można wprowadzić tymczasowe rozwiązania, które zapewnią zgodność w przyszłości."

To wymaganie zasadnicze nie odnosi się do podsystemu "Aplikacje telematyczne".

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

3.4.1. Zgodność techniczna

- Wymaganie zasadnicze 2.7.1 załącznika III do dyrektywy 2001/16/WE:

"Wymagania zasadnicze dla aplikacji telematycznych gwarantują minimalną jakość usługi dla pasażerów i przewoźników towarów, zwłaszcza pod względem zgodności technicznej.

Należy podjąć kroki w celu zapewnienia:

- że bazy danych, oprogramowanie i protokoły komunikacji danych są opracowane w sposób pozwalający na maksymalną wymianę danych pomiędzy różnymi aplikacjami i operatorami, z wyłączeniem poufnych danych handlowych,

- łatwego dostępu użytkownikom do informacji."

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

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

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

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

3.4.2. Niezawodność i dostępność

- Wymaganie zasadnicze 2.7.2 załącznika III do dyrektywy 2001/16/WE:

"Metody użycia, zarządzanie, uaktualnianie i utrzymanie tych baz danych, oprogramowania i protokołów komunikacji danych muszą gwarantować sprawność tych systemów oraz jakość usługi."

To wymaganie jest szczególnie spełnione przez następujące rozdziały:

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

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

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

Lecz to wymaganie zasadnicze, zwłaszcza metoda użycia w celu zagwarantowania sprawności tych aplikacji telematycznych oraz jakości usługi jest podstawą dla całej TSI i nie ogranicza się tylko wymienionych wyżej rozdziałów.

3.4.3. Zdrowie

- Wymaganie zasadnicze 2.7.3 załącznika III do dyrektywy 2001/16/WE:

"Interfejsy pomiędzy tymi systemami a użytkownikami muszą odpowiadać minimalnym zasadom ergonomii i ochrony zdrowia."

Niniejsza TSI nie określa żadnych dodatkowych określeń ponad istniejące krajowe i europejskie reguły dotyczące minimalnych zasad ergonomii i ochrony zdrowia połączenia pomiędzy tymi aplikacjami telematycznymi i użytkownikami.

3.4.4. Bezpieczeństwo

- Wymaganie zasadnicze 2.7.4 załącznika III do dyrektywy 2001/16/WE:

"Należy zapewnić odpowiednie poziomy integralności i niezawodności przechowywania lub przesyłania informacji dotyczących bezpieczeństwa."

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

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

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

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

4. CHARAKTERYSTYKA PODSYSTEMU

4.1. Wstęp

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

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

4.2. Specyfikacje funkcjonalne i techniczne podsystemu

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

- dane listu przewozowego,

- żądanie trasy,

- przygotowanie pociągu,

- prognoza jazdy pociągu,

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

- lokalizacja pociągu,

- ETI/ETA wagonów/jednostek intermodalnych,

- ruch wagonów,

- raportowanie o wymianie,

- wymiana danych dla poprawy jakości,

- pierwotne dane źródłowe,

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

- elektroniczne przesyłanie dokumentów,

- łączność sieciowa i komunikacja.

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

Ogólne uwagi na temat struktury komunikatów

Komunikaty są podzielone na dwa zbiory danych:

- Dane kontrolne: wyjaśnienie - patrz: poniżej

- Dane informacyjne: informacje o aplikacji

Dane kontrolne pokazują następujące elementy:

- Status: Status komunikatu może być następujący:

"Nowy komunikat", jeśli jest to nowy komunikat

"Zmiana", jeśli jest to modyfikacja poprzednio wysłanego komunikatu

"Usunięcie", jeśli poprzednio wysłany komunikat powinien zostać usunięty.

- Oznaczenie komunikatu z podaniem:

Typu komunikatu: np. "żądanie trasy" lub "zapytanie o jazdę pociągu"

Daty i czasu: faktycznego dnia i czasu wysłania komunikatu

Numeru komunikatu: numeru wygenerowanego przez wysyłającego komunikat

- Związane oznaczenie, tylko jeśli komunikat jest odpowiedzią na otrzymany komunikat (identyczne z "Oznaczeniem komunikatu" otrzymanego komunikatu) z podaniem:

Związanego typu: typu otrzymanego komunikatu

Związanej daty i czasu: dnia i czasu otrzymanego komunikatu

Związanego numeru: numeru otrzymanego komunikatu

- Wysyłający komunikat

- Odbiorca komunikatu

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

4.2.1. Dane listu przewozowego

4.2.1.1. List przewozowy klienta

List przewozowy musi zostać wysłany przez klienta do wiodącego RU (LRU). Musi on wykazywać wszystkie dane potrzebne do przewiezienia przesyłki od nadawcy do odbiorcy. LRU musi uzupełnić te dane o dodatkowe informacje. Dane te wraz z dodatkowymi danymi (opis danych można znaleźć w załączniku A - dodatek A, B i F i załącznik 1 do dodatku B) są wymienione w tabeli w załączniku A - załącznik 1 do dodatku B, z podaniem w wierszu "Dane w liście przewozowym", czy są one obowiązkowe czy opcjonalne, i czy muszą być dostarczone przez nadawcę, czy uzupełnione przez LRU.

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

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

4.2.1.2. Zamówieni a wagonów

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

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

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

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

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

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

- dane dotyczące nadawcy i odbiorcy,

- dane dotyczące przebiegu trasy,

- identyfikacja przesyłki,

- dane o wagonach,

- dane o miejscu i czasie.

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

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

- numer CN/HS,

- informacja o niebezpiecznych towarach,

- jednostka transportu.

4.2.2. Żądanie trasy

4.2.2.1. Uwagi wstępne

Planowanie długoterminowe

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

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

Głównymi danymi trasy muszą być:

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

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

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

- Opis odcinka przejazdu, który określa dane dostarczone przez IM dla każdego przyjętego odcinka trasy przejazdu - od początku do pierwszego pośredniego przystanku, dalszych pośrednich przystanków oraz od końcowego pośredniego przystanku do końca przyjętej trasy przejazdu. Opis ten może zawierać:

- pośrednie przystanki lub inne wyznaczone punkty wzdłuż proponowanej trasy wraz z datą i czasem przyjazdu, odjazdu lub przejazdu w tych pośrednich punktach, jak również z kodem działania, który określa działanie, jakie ma być podjęte w tymże pośrednim punkcie drogi,

- identyfikację IM odpowiedzialnego za zarządzanie ruchem dla bieżącego odcinka przejazdu oraz identyfikację IM odpowiedzialnego za zarządzanie ruchem dla następnego odcinka przejazdu,

- opis urządzeń (systemu sterowania ruchem, systemu radiowego itp.) przenoszonych przez pociąg; muszą one być zgodne z infrastrukturą w celu umożliwienia trakcji i łączności pomiędzy pociągiem a systemem kontroli IM,

- dane dotyczące pociągu dla odcinka trasy przejazdu: maks. ciężar, maks. długość, maks. prędkość, maks. nacisk na oś, min. siła hamulca, maks. ciężar na metr, dane dotyczące wyjątkowych pomiarów, identyfikatory niedozwolonych niebezpiecznych towarów,

- numer trasy,

- dodatkowy czas przebiegu odcinka drogi uwzględniający powrót do sprawności, problemy związane z trasą itp.

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

Pilne żądanie trasy

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

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

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

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

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

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

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

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

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

Tabela 1

Żądanie trasy

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

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

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

Tabela 2

Anulowanie trasy przez RU

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

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

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

Tabela 3

Anulowanie trasy przez IM

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

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

Tabela 4

Potwierdzenie otrzymania

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

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

4.2.2.2. Komunikat "Żądanie trasy"

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

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

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

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

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

- odcinek żądanego przejazdu:

- pośrednie przystanki lub inne wyznaczone punkty na proponowanej trasie wraz z datą/czasem, kiedy proponowany pociąg ma przybyć do pośredniego punktu oraz datą/czasem, kiedy pociąg ma odjechać od pośredniego punktu. Pusty wpis oznacza, że pociąg nie zatrzyma się w tym punkcie,

- dostępne urządzenia w pociągu: typ trakcji, system kontroli jazdy pociągu, w tym pokładowe urządzenia radiowe,

- ciężar pociągu,

- długość pociągu,

- układ hamulcowy, który ma być używany, oraz charakterystyka hamowania,

- maksymalna prędkość pociągu,

- maksymalny nacisk na oś pociągu,

- maksymalny ciężar na metr,

- informacje dotyczące wyjątkowego pomiaru,

- numery UN/RID dotyczące ewentualnych niebezpiecznych towarów,

- określenia działania, które ma być podjęte w każdym pośrednim punkcie drogi,

- odpowiedzialny RU: identyfikacja RU odpowiedzialnego za pociąg dla bieżącego odcinka przejazdu,

- odpowiedzialny IM: identyfikacja IM odpowiedzialnego za pociąg dla bieżącego odcinka przejazdu,

- następny odpowiedzialny IM: identyfikacja IM odpowiedzialnego za pociąg dla (ewentualnego) następnego odcinka przejazdu.

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

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

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

4.2.2.3. Komunikat "Dane o trasie"

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

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

- nowy numer trasy,

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

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

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

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

- odcinek zmodyfikowanej trasy przejazdu:

- żądane urządzenia w pociągu: Typ trakcji, system kontroli jazdy pociągu, w tym pokładowe urządzenia radiowe,

- ciężar pociągu,

- długość pociągu,

- układ hamulcowy, który ma być używany oraz charakterystyka hamowania,

- maksymalna prędkość pociągu,

- maksymalny nacisk na oś pociągu,

- maksymalny ciężar na metr,

- informacje dotyczące wyjątkowego pomiaru,

- numery UN/RID dotyczące ewentualnych niebezpiecznych towarów,

- określenia działania, które ma być podjęte w każdym pośrednim punkcie drogi,

- odpowiedzialny RU: Identyfikacja RU odpowiedzialnego za pociąg dla bieżącego odcinka przejazdu,

- odpowiedzialny IM: Identyfikacja IM odpowiedzialnego za pociąg dla bieżącego odcinka przejazdu,

- następny odpowiedzialny IM: Identyfikacja IM odpowiedzialnego za pociąg dla (ewentualnego) następnego odcinka przejazdu.

4.2.2.4. Komunikat "Trasa potwierdzona"

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

- numer trasy w celu identyfikacji trasy,

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

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

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

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

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

4.2.2.5. Komunikat "Odmowa danych o trasie"

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

- numer trasy w celu identyfikacji trasy,

- oznaczają odmowę danych o trasie.

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

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

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

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

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

4.2.2.6. Komunikat "Trasa anulowana"

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

- numer trasy w celu identyfikacji trasy,

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

- oznacza anulowanie zarezerwowanej trasy pociągu.

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

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

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

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

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

4.2.2.7. Komunikat "Trasa niedostępna"

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

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

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

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

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

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

- podanie przyczyny.

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

4.2.2.8. Komunikat "Potwierdzenie odbioru"

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

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

4.2.3. Przygotowanie pociągu

4.2.3.1. Uwagi ogólne

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

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

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

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

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

Tabela 5

Przygotowanie pociągu

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

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

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

4.2.3.2. Komunikat "Skład pociągu"

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

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

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

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

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

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

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

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

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

- informacje dotyczące wyjątkowego pomiaru,

- numery UN/RID niebezpiecznych towarów,

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

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

- dane o wagonach.

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

4.2.3.3. Komunikat "Pociąg zaakceptowany"

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

Główna treść tego komunikatu zawiera:

- numer pociągu i trasy,

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

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

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

4.2.3.4. Komunikat "Pociąg nie jest odpowiedni"

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

- numer pociągu i trasy,

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

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

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

- podanie przyczyny.

4.2.3.5. Komunikat "Pociąg gotowy"

Komunikat ten musi być wysłany od RU do IM z podaniem, że dany pociąg jest gotowy do wejścia do sieci.

Główna treść tego komunikatu zawiera:

- numer pociągu i trasy,

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

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

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

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

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

4.2.3.6. Komunikat "Położenie pociągu"

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

- numer pociągu i trasy,

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

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

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

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

- identyfikator kontaktu kontrolnego.

4.2.3.7. Komunikat "Pociąg na starcie"

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

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

4.2.3.8. Informacja o jeździe pociągu

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

4.2.4. Prognoza jazdy pociągu

4.2.4.1. Uwagi ogólne

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

Stosownymi komunikatami są:

Prognoza jazdy pociągu,

Informacja o jeździe pociągu.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

- Przyjazd pociągu do punktu docelowego

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

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

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

4.2.4.2. Komunikat "Prognoza jazdy pociągu"

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

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

Głównymi elementami danych są:

- numer trasy i numer pociągu,

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

- identyfikacja punktu raportowania,

- prognozowane data/czas w punkcie raportowania.

4.2.4.3. Komunikat "Informacja o jeździe pociągu"

Komunikat ten musi być wydany po:

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

- przyjeździe i odjeździe z punktów przekazania, punktów wymiany oraz punktów raportowania uzgodnionych na podstawie umowy (np. punktów obsługi).

Głównymi elementami danych są:

- numer trasy i numer pociągu,

- planowa data/czas odjazdu w miejscu IM,

- identyfikacja ostatniego punktu raportowania,

- faktyczny czas w punkcie raportowania,

- status punktu raportowania pociągu (przyjazd, odjazd, przejazd, nieokreślony, odjazd z punktu początkowego, przyjazd do punktu docelowego),

- tor przyjazdu do miejsca,

- tor odjazdu z miejsca,

- minuty odchylenia czasu delta od zarezerwowanego planowego czasu,

- aktualny rozkład jazdy w wypadku jego wielokrotnej zmiany,

- dla każdego odchylenia od zarezerwowanego planowego czasu w tymże miejscu raportowania:

- kod powodu (może być wiele powodów),

- czas odchylenia dla tego kodu powodu (może być wysłanych wiele powodów na punkt raportowania),

- można dodać dowolny tekst dotyczący odchylenia.

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

4.2.5.1. Uwagi ogólne

Gdy RU dowie się o zakłóceniu służby podczas operacji prowadzenia pociągu, za którą jest odpowiedzialny, musi niezwłocznie powiadomić zainteresowanego IM (brak komunikatu informatycznego, np. ustnie przez maszynistę). Jeśli to konieczne, RU uaktualnia "Operacyjną bazę danych wagonów i jednostek intermodalnych".

Jeśli to niezbędne, IM uaktualnia dane o infrastrukturze w "Bazie danych powiadomień o ograniczeniach w infrastrukturze" oraz/lub bazie danych tras bądź pociągów.

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

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

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

4.2.5.2. Komunikat "Zakłócona jazda pociągu"

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

Głównymi elementami tego komunikatu są:

- numer trasy i pociągu,

- identyfikacja miejsca,

- planowa data i czas odjazdu w tym miejscu,

- powód zakłócenia,

- opis zakłócenia.

4.2.6. Położenie pociągu

4.2.6.1. Wstęp

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

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

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

- wszystkie identyfikatory określonego pociągu,

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

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

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

4.2.6.2. Komunikaty "Zapytanie o jazdę pociągu"

Cel: RU zapytuje o ostatnio zarejestrowany status (położenie, opóźnienia oraz powody opóźnień) jednego określonego pociągu w infrastrukturze określonego IM.

Zapytanie: Główne elementy danych:

- bieżący numer pociągu,

- identyfikator IM,

- planowa data i czas odjazdu w miejscu IM.

Odpowiedź: Dane informacyjne:

- ostatnie miejsce raportowania,

- faktyczny czas w punkcie raportowania,

- status pociągu w punkcie raportowania (przyjazd, odjazd, przejazd, nieokreślony, odjazd z punktu początkowego, przyjazd do punktu docelowego),

- tor przyjazdu do miejsca,

- tor odjazdu z miejsca,

- zarezerwowany planowy czas,

- opóźnienie delta w stosunku do zarezerwowanego planowanego czasu,

- czas zmienionego rozkładu jazdy (w stosunku do bieżącego rozkładu jazdy w wypadku licznych zmian rozkładu jazdy),

- dla każdego opóźnienia w tymże miejscu raportowania:

- kod powodu oraz czas opóźnienia dla tego kodu powodu.

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

Cel: RU zapytuje o wszystkie opóźnienia określonego pociągu u określonego IM.

Zapytanie: Główne elementy danych:

- bieżący numer pociągu,

- identyfikator IM,

- planowa data i czas odjazdu w miejscu IM.

Odpowiedź: Dane informacyjne (te same informacje, co w wypadku "Zapytania o jazdę pociągu", nie tylko dla ostatniego punktu, lecz dla każdego punktu raportowania pociągu w infrastrukturze określonego IM):

- dla każdego punktu raportowania:

- ostatnie miejsce raportowania,

- faktyczny czas w punkcie raportowania,

- status pociągu w punkcie raportowania (przyjazd, odjazd, przejazd, nieokreślony, odjazd z punktu początkowego, przyjazd do punktu docelowego),

- tor przyjazdu do miejsca,

- tor odjazdu z miejsca,

- zarezerwowany planowy czas,

- opóźnienie delta w stosunku do zarezerwowanego planowanego czasu,

- czas zmienionego rozkładu jazdy (w stosunku do bieżącego rozkładu jazdy w wypadku licznych zmian rozkładu jazdy),

- dla każdego opóźnienia w tymże miejscu raportowania:

- kod powodu i czas opóźnienia dla tego kodu powodu.

4.2.6.4. Komunikaty "Zapytanie o identyfikator pociągu"

Cel: RU zapytuje o aktualny identyfikator pociągu i swoje poprzednie identyfikatory pociągu. Do zapytania może być użyty dowolny z identyfikatorów określonego pociągu.

Zapytanie: Główne elementy danych:

- znany bieżący numer pociągu,

- identyfikator IM,

- planowana data i czas odjazdu pociągu w miejscu IM.

Odpowiedź: Dane informacyjne:

- Aktualny identyfikator pociągu:

- numer jazdy pociągu,

- planowana data i czas odjazdu w miejscu IM,

- Dla każdego innego identyfikatora pociągu:

- numer jazdy pociągu,

- planowa data i czas odjazdu w miejscu IM.

4.2.6.5. Komunikaty "Zapytanie IM o prognozę pociągu"

Cel: RU zapytuje o przewidywany czas dla określonego pociągu w określonym miejscu raportowania lub, pomijając miejsce raportowania, zapytuje IM o przewidywany czas w punkcie przekazania.

Zapytanie: Główne elementy danych:

- nieżący numer pociągu,

- planowana data i czas odjazdu w miejscu IM,

- identyfikator miejsca raportowania (Miejsce raportowania, dla którego wymagana jest prognoza. Jest to opcjonalne i jeżeli nie jest podane, odpowiedź odnosi się do końcowego punktu raportowania dla tegoż IM dla tego pociągu).

Odpowiedź: Dane informacyjne:

- kod IM,

- identyfikacja punktu raportowania,

- przewidywane data/czas w punkcie raportowania.

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

Cel: RU to zapytuje o wszystkie swoje pociągi w określonym miejscu raportowania w infrastrukturze określonego IM.

Zapytanie: Główne elementy danych:

- kod IM,

- identyfikacja miejsca raportowania (Miejsce raportowania, dla którego wymagana jest prognoza. Jest to opcjonalne i jeżeli nie jest podane, odpowiedzią powinien być końcowy punkt raportowania dla tegoż IM dla tego pociągu).

Odpowiedź: Dane informacyjne:

- dla każdego spośród pociągów tego zapytującego:

- numer jazdy pociągu,

- planowe data i czas odjazdu w miejscu IM lub planowany czas przekazania,

- kod IM,

- identyfikacja punktu raportowania,

- przewidywane data/czas w punkcie raportowania.

4.2.7. ETI/ETA przesyłki

4.2.7.1. Wstępna uwaga

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

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

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

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

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

4.2.7.2. Obliczanie ETI/ETA

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

Dla punktów wymiany lub dla innych określonych punktów raportowania na uzgodnionej trasie RU musi obliczyć dla następnego RU w łańcuchu przesyłki transportowej szacowany czas wymiany (ETI) dla wagonów i/lub jednostek intermodalnych.

Ponieważ RU może mieć w pociągu wagony o różnych trasach przejazdu i pochodzące od różnych LRU, punkt wymiany do obliczenia ETI dla wagonów może być różny. Jest to wyjaśnione w poniższych dwóch uproszczonych przykładach. (Obrazowe przedstawienie tych scenariuszy podano w załączniku A indeks 5 rozdział 1.4, zaś schemat proceduralny oparty o przykład 1 dla punktu wymiany C przedstawiono w załączniku A indeks 5 rozdział 5).

Przykład 1: RU 1 ma w tym samym pociągu wagony nr 1 i 2 od LRU 1 oraz wagony nr 3 do 5 od LRU 2. W punkcie wymiany C dalszy transport wagonów 1 i 2 będzie wykonywany przez RU2, a wagonów 3 do 5 przez RU 3. W tym wypadku RU 1 musi obliczyć dla wagonów 1 i 2 ETI odnoszącą się do punktu wymiany C i musi wysłać te wartości do LRU 1. RU 1 musi także obliczyć dla wagonów 3 do 5 ETI odnoszącą się do tego samego punktu wymiany C i wysłać te wartości do LRU 2.

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

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

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

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

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

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

4.2.7.3. Komunikat "ETI/ETA wagonów"

Cel: Wysłanie ETI lub uaktualnionej ETI od jednego RU do następnego w łańcuchu transportowym. Ostatni RU łańcuchu transportowym wagonów wysyła ETA lub uaktualnioną ETA do LRU.

Główne elementy danych:: - identyfikacja RU, który wytworzył ETI lub ETA,

- stacja odjazdowa lub poprzednia stacja wymiany (ETI lub czas odjazdu na stacji początkowej),

- numer pociągu wyruszającego ze stacji odjazdowej lub poprzedniej stacji wymiany (z ETI lub czasu odjazdu na stacji początkowej),

- faktyczna data i czas odjazdu pociągu,

- stacja przyjazdowa lub następna stacja wymiany (końcowa ETI/ETA),

- numer pociągu przyjeżdżającego do stacji końcowej ETI/ETA (Przyjazd do następnej stacji wymiany),

- data i czas przyjazdu wagonu (ETI lub ETA).

4.2.7.4. Komunikat "Alert"

Cel: Po porównaniu ETA ze zobowiązaniem wobec klienta LRU może wysłać komunikat "Alert" do uczestniczącego RU.

Główne elementy danych:: - numer wagonu,

- zobowiązanie wobec klienta: data i czas przyjazdu,

- faktyczna ETA: data i czas.

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

4.2.7.5. Komunikaty "Zapytani e o odchyleni a dotyczące wagonu"

Cel: LRU zapytuje o odchylenia odnośnie do określonego wagonu.

Zapytanie: Główne elementy danych:

- numer wagonu,

- identyfikator LRU.

Odpowiedź: Dane informacyjne:

- Dla każdego punktu raportowania:

- miejsce raportowania,

- status wagonu w punkcie raportowania (odjazd, przyjazd do stacji rozrządowej, odjazd ze stacji rozrządowej, przyjazd do punktu wymiany, przyjazd do docelowej stacji rozrządowej),

- odpowiedzialny RU w miejscu raportowania i zgodnie ze statusem wagonu w punkcie raportowania,

- czas zmienionego rozkładu jazdy (w porównaniu do aktualnego rozkładu jazdy w wypadku wielu zmian rozkładu jazdy),

- ETI, jeżeli punkt raportowania jest punktem wymiany,

- faktyczny czas w punkcie raportowania,

- Dla każdego odchylenia w tymże punkcie raportowania:

- kod powodu oraz czas opóźnienia dla tego powodu.

4.2.8. Ruch wagonów

4.2.8.1. Uwagi wstępne

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

- Powiadomienie o zwolnieniu wagonu

- Powiadomienie o odjeździe wagonu

- Przyjazd wagonu do stacji rozrządowej

- Wyjazd wagonu ze stacji rozrządowej

- Komunikat o wyjątkowej sytuacji wagonu

- Powiadomienie o przyjeździe wagonu

- Powiadomienie o dostawie wagonu

- Potwierdzenie dostawy wagonu

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

4.2.8.2. Komunikat "Powiadomienie o zwolnieniu wagonu"

Cel: LRU do RU: wiodącym RU niekoniecznie jest pierwszy RU w łańcuchu transportowym. W tym wypadku LRU musi powiedzieć odpowiedzialnemu RU, że wagon jest gotowy do zabrania na bocznicy klienta (miejsce odjazdu zgodnie ze zobowiązaniem LRU) o danym czasie zwolnienia (data i czas odjazdu).

Zdarzenie to musi zostać przechowane w "Operacyjnej bazie danych wagonów i jednostek intermodalnych".

Główne elementy danych: - numer wagonu,

- miejsce, data i czas odjazdu (miejsce, z którego planowane jest wyruszenie transportu).

Następujące dane przechowywane w bazach danych muszą być łatwo dostępne dla RU i LRU:

- jednostka, identyfikacja, rozmiar i typ transportu,

- wykorzystana pojemność jednostki,

- całkowity ciężar (zarezerwowany/rzeczywisty całkowity ciężar (masa) towaru, w tym opakowania i urządzeń przewoźnika),

- wskazanie niebezpiecznych towarów.

4.2.8.3. Komunikat "Powiadomienie o odjeździe wagonu"

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

Zdarzenia te muszą zostać przechowane w "Operacyjnej bazie danych wagonów i jednostek intermodalnych". Poprzez wymianę tego komunikatu odpowiedzialność za wagon przenosi się z klienta na RU.

Główne elementy danych: - numer wagonu,

- miejsce, data i czas odjazdu (miejsce, z którego planowane jest wyruszenie transportu).

Następujące dane przechowywane w bazach danych muszą być łatwo dostępne dla RU i LRU:

- jednostka, identyfikacja, rozmiar i typ transportu,

- wykorzystana pojemność jednostki,

- całkowity ciężar (zarezerwowany/rzeczywisty całkowity ciężar (masa) towaru, w tym opakowania i urządzeń przewoźnika),

- wskazanie niebezpiecznych towarów.

4.2.8.4. Komunikat "Przyjazd wagonu do stacji rozrządowej"

Cel: RU musi powiadomić LRU, że wagon przybył do jego stacji rozrządowej. Komunikat ten może być oparty o komunikat "Informacja o jeździe pociągu" z rozdziału 4.2.4 (Prognoza jazdy pociągu). Zdarzenie to musi zostać przechowane w "Operacyjnej bazie danych wagonów i jednostek intermodalnych".

Główne elementy danych:: - numer wagonu,

- identyfikacja przyjazdu do stacji rozrządowej,

- data i czas przyjazdu do stacji rozrządowej.

4.2.8.5. Komunikat "Wyjazd wagonu ze stacji rozrządowej "

Cel: RU musi powiadomić LRU, że wagon opuścił jego stację rozrządową. Komunikat ten może być oparty o komunikat "Informacja o jeździe pociągu" z rozdziału 4.2.4 (Prognoza jazdy pociągu). Zdarzenie to musi zostać przechowane w "Operacyjnej bazie danych wagonów i jednostek intermodalnych".

Główne elementy danych: - numer wagonu,

- identyfikacja wyjazdu ze stacji rozrządowej,

- data i czas wyjazdu ze stacji rozrządowej.

4.2.8.6. Komunikat "Wyjątkowa sytuacja wagonu"

Cel: RU musi powiadomić LRU, jeśli z wagonem zdarzyło się coś nieoczekiwanego, co mogłoby mieć wpływ na ETI/ETA lub co wymaga dodatkowego działania. W większości wypadków komunikat ten wymaga również obliczenia nowej ETI/ETA. Jeżeli LRU postanowi, aby mieć nową ETI/ETA, odsyła komunikat do RU, który wysłał ten komunikat, wraz ze wskazaniem "Żądana ETI/ETA" (wiadomość: "Wyjątkowa sytuacja wagonu", komunikat "Żądanie nowej ETI/ETA"). Obliczenie nowej ETI/ETA musi być wykonane zgodnie z procedurą podaną w rozdziale 4.2.7 (ETI/ETA przesyłki ).

Informacje te muszą zostać przechowane w "Operacyjnej bazie danych wagonów i jednostek intermodalnych".

Główne elementy danych: - numer wagonu,

- miejsce, data i czas zakłócenia (miejsce, w którym zdarzyło się coś niespodziewanego podczas transportu),

- kod powodu/zakłócenia.

Ponadto muszą być łatwo dostępne następujące dane przechowywane w bazach danych:

- identyfikacja jednostki transportowej,

- wskazanie niebezpiecznych towarów.

4.2.8.7. Komunikat "Wyjątkowa sytuacja wagonu", Żądanie nowej ETI/ETA

Cel: LRU może wysłać ten komunikat do faktycznego RU, który wysłał "Komunikat wyjątku", aby zażądać obliczenia nowej ETI/ETA. LRU wysyła ten komunikat również do wszystkich następnych RU, informując ich o odchyłkach. Potrzeba obliczenia nowej ETI/ETA zależy od uznania LRU i nie jest niezbędna we wszystkich przypadkach.

Główne elementy danych: - numer wagonu,

- miejsce, data i czas zakłócenia (miejsce, w którym zdarzyło się coś niespodziewanego podczas transportu),

- kod powodu/zakłócenia,

- żądanie nowej ETI/ETA.

Ponadto muszą być łatwo dostępne następujące dane przechowywane w bazach danych:

- identyfikacja jednostki transportowej,

- wskazanie niebezpiecznych towarów.

4.2.8.8. Komunikat "Powiadomienie o przyjeździe wagonu"

Cel: Ostatni RU w łańcuchu transportowym wagonów lub jednostek intermodalnych musi powiadomić LRU, że wagon przybył do jego stacji rozrządowej (miejsca RU).

Główne elementy danych: - numer wagonu,

- identyfikacja stacji rozrządowej RU,

- data i czas przyjazdu.

4.2.8.9. Komunikat "Powiadomienie o dostawie wagonu"

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

Główne elementy danych: - numer wagonu,

- identyfikacja umieszczenia na bocznicy odbiorcy (miejsce, strefa, tor, stanowisko),

- data i czas umieszczenia.

"Powiadomienie o dostawie wagonu" może zostać wysłane po raz drugi jako "Potwierdzenie dostawy wagonu" z dodatkowymi danymi:

- identyfikator klienta.

Uwaga: W wypadku 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 dla tych komunikatów, oparty o przykład 1 obliczenia ETI dla wagonów 1 i 2 (patrz: rozdział 4.2.7.2 jest zintegrowany ze schematem raportowania wymiany przedstawionym w załączniku A indeks 5 rozdział 6.

4.2.9. Raportowanie o wymianie

4.2.9.1. Wstępna uwaga

Raportowanie o wymianie opisuje komunikaty dołączane do przekazania odpowiedzialności za wagon pomiędzy dwoma przewoźnikami kolejowymi, które występuje w punktach wymiany. Nakazuje również nowemu RU wykonanie obliczenia ETI i przeprowadzenie procesu opisanego w rozdziale 4.2.7 (ETI/ETA przesyłki ).

Muszą zostać wymienione następujące komunikaty:

- Powiadomienie o wymianie wagonu,

- Powiadomienie o wymianie wagonu/Zastępstwo,

- Odebranie wagonu przy wymianie,

- Odmówienie wagonu przy wymianie.

Dane informacyjne tych komunikatów należy przechować w "Operacyjnej bazie danych wagonów i jednostek intermodalnych". W razie jakiegokolwiek odchylenia musi zostać wygenerowana nowa ETI/ETA i przekazana zgodnie z procesem opisanym w rozdziale 4.2.7: ETI/ETA przesyłki. Schemat proceduralny tych komunikatów jest przedstawiony w związku z komunikatami ruchu wagonów w załączniku A indeks 5 rozdział 6.

Powiadomienia o wymianie wagonów oraz Powiadomienia o wymianie wagonów/Zastępstwa, 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 tym wypadku wszystkie wagony mogą być wymienione w jednym przekazie komunikatów.

W wypadku otwartego dostępu nie ma punktów wymiany. W punkcie obsługi odpowiedzialność za wagony nie zmienia się. Dlatego nie ma potrzeby wymiany specjalnych komunikatów. Lecz uzyskane z "Informacji 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ą zostać przetworzone i przechowane w "Operacyjnej bazie danych wagonów i jednostek intermodalnych".

Zawartość tych komunikatów jest podana poniżej:

4.2.9.2. Komunikat "Powiadomienie o wymianie wagonu"

Cel: Za pomocą komunikatu "Powiadomienie o wymianie wagonu" przewoźnik kolejowy (RU1) pyta następnego przewoźnika kolejowego (RU2) w łańcuchu transportowym, czy przyjmuje odpowiedzialność za wagon. Za pomocą komunikatu "Powiadomienie o wymianie wagonu/Zastępstwo" RU 2 informuje swojego IM, że przyjął odpowiedzialność.

Główne elementy danych: - numer wagonu,

- numer pociągu (tylko wówczas, jeśli wagon jest w pociągu),

- miejsce, dzień i czas wymiany.

Ponadto muszą być łatwo dostępne następujące dane przechowywane w bazach danych:

- identyfikacja jednostki transportowej (numer, rozmiar, typ),

- całkowity ciężar (zarezerwowany/rzeczywisty całkowity ciężar (masa) towaru, w tym opakowania i urządzeń przewoźnika),

- zastosowana jednostka objętości,

- dane i identyfikacja niebezpiecznych towarów.

4.2.9.3. Komunikat "Powiadomienie o wymianie wagonu/Zastępstwo"

Cel: Za pomocą komunikatu "Powiadomienie o wymianie wagonu/Zastępstwo" RU 2 informuje IM, że przejął odpowiedzialność za określony wagon.

Główne elementy danych: - numer wagonu,

- numer pociągu (tylko wówczas, jeżeli wagon jest w pociągu),

- miejsce, dzień i czas wymiany.

Ponadto muszą być łatwo dostępne następujące dane przechowywane w bazach danych:

- dane i identyfikacja niebezpiecznych towarów.

4.2.9.4. Komunikat "Odebranie wagonu przy wymianie"

Cel: Za pomocą komunikatu "Odebranie wagonu przy wymianie" RU 2 informuje RU 1, że przyjmuje odpowiedzialność za wagon.

Główne elementy danych: - numer wagonu,

- miejsce, dzień i czas wymiany.

4.2.9.5. Komunikat "Odmowa wagonu przy wymianie "

Cel: Za pomocą komunikatu "Odmowa wagonu przy wymianie" RU 2 informuje RU 1, że nie ma chęci przejęcia odpowiedzialności za wagon.

Główne elementy danych: - numer wagonu,

- miejsce, dzień i czas wymiany,

- kod powodu odmowy,

- dalszy opis (opcjonalny).

4.2.10. Wymiana danych dla poprawy jakości

Aby być konkurencyjnym, europejskie kolejnictwo musi dostarczać swoim klientom usługi o wyższej jakości (patrz również: załącznik III, art. 2.7.1 do dyrektywy 2001/16/WE).

Procesem pomiarowym jest zasadniczy proces odbywający się po podróży, mający na celu wspieranie poprawy jakości.

Oprócz mierzenia jakości usługi dostarczanej klientowi LRU, RU i IM muszą mierzyć jakość składników usługi, które w sumie składają się na produkt dostarczany klientowi.

W procesie tym uczestniczą IM i RU (zwłaszcza jeśli są oni wiodącymi RU), którzy wybierają indywidualny parametr jakości, drogę przebiegu lub miejsce oraz okres pomiaru, w którym mają być mierzone rzeczywiste wyniki na podstawie z góry określonych kryteriów, które zwykle zostały określone w umowie.

Wyniki procesu pomiarowego muszą wyraźnie pokazywać poziom osiągnięć względem celu, który został uzgodniony pomiędzy stronami umowy.

Raporty z pomiarów muszą pozwalać na dostęp do wystarczająco szczegółowych danych dla umożliwienia analizy, która wskaże miejsce oraz widoczną przyczynę obniżeń jakości, np. opóźnień. Następnie musi być przeprowadzona analiza pierwotnych przyczyn dotycząca powtarzających się niepowodzeń jakościowych, tak aby strony umowy mogły określić działanie korygujące.

Obowiązkiem IM i RU jest dostarczenie danych, uczestniczenie w analizie pierwotnych przyczyn, także ze stronami trzecimi, oraz wdrożenie ewentualnego uzgodnionego działania korygującego.

Proces pomiarowy jest procesem powtarzalnym.

Aby zmierzyć jakość, można posłużyć się zdefiniowanymi już komunikatami przedstawionymi w 6 nagłówkach wymienionych poniżej:

1. LRU/Klient: Czas tranzytu, ETA, rozwiązanie alertów

W umowach pomiędzy RU działającymi jako integratorzy usług (LRU) a klientami mogą być dokonywane zobowiązania (w zależności od indywidualnego uzgodnienia) dotyczące czasu tranzytu, ETA oraz rozwiązania alertów. Najbardziej odpowiednimi komunikatami dla tego pomiaru jakości są:

- Powiadomienie o zwolnieniu,

- Powiadomienie o odjeździe,

- Powiadomienie o dostawie.

2. LRU/Dostawcy usług: Czasy tranzytu i obsługi, ETA, ETI, kody powodów

W umowach pomiędzy wiodącym RU a innymi dostawcami usług transportowych mogą być dokonywane następujące zobowiązania dotyczące czasów tranzytu z indywidualnymi dostawcami usług:

- czas od odcięcia zwalniacza/odciągnięcia do dostawy przy wymianie,

- od zabrania do wprowadzenia do terminala przeładunkowego,

- od terminala przeładunkowego do załadowania,

- od odbioru przy wymianie do dostawy przy wymianie,

- od odbioru przy wymianie do umieszczenia/konstruktywnego umieszczenia,

- od uziemienia do dostawy.

Najbardziej odpowiednimi komunikatami dla tego pomiaru jakości są:

- Powiadomienie o zwolnieniu,

- Powiadomienie odjeździe,

- Przyjazd do stacji rozrządowej,

- Odjazd ze stacji rozrządowej,

- Powiadomienie o przyjeździe,

- Dostawa wagonu przy wymianie,

- Odbiór wagonu przy wymianie,

- Odmowa wagonu przy wymianie.

3. RU/IM: Osiągi pociągu, ETA (TETA), ETH pociągu

W umowach pomiędzy RU i IM poziom punktualności dla rozkładów jazdy pociągów w określonych punktach raportowania może być określony jako dokładność ETA i ETH pociągów. Najbardziej odpowiednimi komunikatami dla tego pomiaru jakości są:

- Prognoza jazdy pociągu,

- Informacja o jeździe pociągu,

- Zapytanie/odpowiedź odnośnie do opóźnienia/osiągów pociągu.

4. RU/IM: Dostępność trasy/planowana trasa

W umowach pomiędzy RU i IM dostępność trasy dla jazdy pociągów będzie wyraźnie opisana za pomocą przedziału czasu w określonych punktach. W umowach tych będą również ujęte specyfikacje pojazdu wyrażone poprzez maksymalną długość i ciężar brutto, skrajnię ładunku itp. Aspekt ten będzie omówiony w pozycji numer 6 (IM/RU: Jakość składu pociągu).

W umowach tych będą również określone procedury i ramy czasowe dla potwierdzania wykorzystania trasy, anulowania używania planowanej trasy oraz zakres, w jakim trasa może być używana poza (przed lub po) określonym przedziałem czasu. Najbardziej odpowiednimi komunikatami dla tego pomiaru jakości są:

- Trasa anulowana,

- Trasa niedostępna.

5. RU/IM: Dostępność trasy w trybie natychmiastowym

Gdy RU zechce poprowadzić pociąg poza granicami czasowymi ustalonymi dla planowanej trasy, to do uczestniczących IM musi zostać wysłane żądanie w trybie natychmiastowym (jak przewidziano w dyrektywie 2001/14/WE).

Okresowo RU będzie porównywał dane żądania trasy i odpowiedzi w celu sporządzenia następujących raportów:

- czas odpowiedzi na żądanie trasy w stosunku do ramowego porozumienia,

- ilość tras będących w granicach żądanego czasu, dostarczonych w ciągu pewnych okresów czasu,

- ilość odrzuconych żądań trasy.

Najbardziej odpowiednimi komunikatami dla tego pomiaru jakości są:

- Żądanie trasy,

- Dane o trasie,

- Odmowa danych o trasie,

- Trasa anulowana,

- Trasa niedostępna.

6. IM/RU: Jakość składu pociągu

Gdy komunikaty gotowości pociągu i/lub wykazy składu pociągu są wysyłane przez RU do IM lub innego RU, to muszą one być zgodne ze specyfikacjami zawartymi w stosownej umowie. Dla sprawdzenia tej zgodności, a tym samym dla pomiaru jakości składu pociągu najbardziej odpowiednimi komunikatami są:

- Skład pociągu,

- Pociąg nie jest odpowiedni.

4.2.11. Pierwotne dane źródłowe

4.2.11.1. Wstęp

Dane o infrastrukturze ("Oświadczenie w sprawie sieci" oraz dane przechowywane w "Bazie danych powiadomień o ograniczeniach w infrastrukturze") oraz dane o taborze kolejowym (w "Źródłowych bazach danych taboru kolejowego" oraz w "Operacyjnej bazie danych wagonów i jednostek intermodalnych") są najważniejszymi danymi dla 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ą wyraźny obraz wszystkich dostępnych instalacji i urządzeń w dowolnym czasie, umożliwiając w ten sposób szybkie decyzje podczas prowadzenia.

4.2.11.2. Bazy danych powiadomień o ograniczeniach w infrastrukturze

Każdy IM jest odpowiedzialny za odpowiedniość trasy w jego infrastrukturze, a RU jest zobowiązany sprawdzić charakterystyki pociągu w porównaniu z wartościami podanymi w danych o trasie dotyczących jego zakontraktowanej trasy.

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

W tym celu IM musi zainstalować i wypełnić "Bazy danych powiadomień o ograniczeniach w infrastrukturze". Struktura takiej bazy danych jest opisana w załączniku A dodatek D i F. Wpisy w tych bazach danych oparte są o odcinki zgodnie ze stosownymi "Oświadczeniami w sprawie sieci" z dodaniem informacji o ograniczeniach. Te bazy danych muszą być dostępne za pośrednictwem powszechnego interfejsu (4.2.14.1: Ogólna architektura oraz 4.2.14.7: Uniwersalny interfejs).

RU jest zobowiązany uwzględnić wszystkie ograniczenia przedstawione w "Bazie danych powiadomień o ograniczeniach w infrastrukturze", które wpływają na jazdę jego pociągu aż do okresu przedodjazdowego. Jeżeli nic innego nie jest określone w umowie pomiędzy IM i RU, okres przedodjazdowy rozpoczyna się jedną godzinę przed planowanym czasem odjazdu.

W okresie przedodjazdowym IM musi powiadomić bezpośrednio RU o wszelkich zmianach powstałych w "Bazie danych powiadomień o ograniczeniach w infrastrukturze".

4.2.11.3. Źródłowe bazy danych taboru kolejowego

Dysponent taboru kolejowego jest odpowiedzialny za przechowywanie danych o taborze kolejowym w "Źródłowej bazie danych taboru kolejowego".

Informacje, które muszą być włączane do "Źródłowych bazy danych taboru kolejowego", opisane są szczegółowo w załączniku A dodatek A, B, F i załącznik 1 do dodatku B. Muszą zawierać wszystkie dane dotyczące:

- identyfikacji taboru kolejowego,

- oceny zgodności z infrastrukturą,

- oceny odnośnych charakterystyk obciążenia,

- odnośnych charakterystyk hamulców,

- danych dotyczących utrzymania,

- charakterystyk środowiskowych.

Źródłowe bazy danych taboru kolejowego muszą pozwalać na łatwy dostęp (pojedynczy powszechny dostęp jest zapewniony za pośrednictwem powszechnego interfejsu) do technicznych danych w celu ograniczenia do minimum objętości danych przesyłanych dla każdej operacji. Zawartość baz danych musi być dostępna na podstawie zhierarchizowanych praw dostępu zależnych od przywileju dla wszystkich dostawców usług (IM, RU, dostawców logistyki oraz zarządców parku pojazdowego), w szczególności do celów zarządzania parkiem i utrzymania taboru kolejowego.

Wpisy w "Źródłowej bazie danych taboru kolejowego" mogą być pogrupowane w następujący sposób:

- Dane administracyjne,

związane z pozycjami certyfikacji i rejestracji, takimi jak odniesienie do pliku wspólnotowej rejestracji, identyfikator notyfikowanego organu itp.; może to obejmować historyczne dane dotyczące własności, wynajmu itp. Należy wziąć pod uwagę następujące kroki:

- wspólnotowa certyfikacja,

- 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 TSI "Tabor kolejowy".

Dysponent jest zobowiązany zapewnić, że dane te są dostępne i że kryjące się za nimi procesy zostały przeprowadzone.

- Dane projektowe,

które winny objąć wszystkie składowe (fizyczne) elementy taboru kolejowego, w tym charakterystyki dotyczące środowiska, oraz wszelkie informacje, które są spodziewane, że pozostaną ważne przez cały okres żywotności taboru kolejowego - ta część może zawierać historię ważniejszych modyfikacji, kapitalnej konserwacji, remontu itp.

4.2.11.4. Dane operacyjne o taborze kolejowym

Oprócz danych źródłowych dotyczących taboru kolejowego, dane przedstawiające faktyczny stan taboru kolejowego są najważniejszymi danymi do celów operacyjnych.

Dane te winny zawierać dane tymczasowe, takie jak ograniczenia, bieżące i przewidywane działania konserwacyjne, liczniki kilometrów i usterek itp.; oraz wszelkie dane, które można by uznać za "status" (tymczasowe ograniczenia prędkości, odłączenie hamulców, potrzeby napraw oraz opis usterek itp.).

Do używania danych operacyjnych o taborze kolejowym należy rozważyć trzy różne jednostki, biorąc pod uwagę różne strony odpowiedzialne za tabor kolejowy podczas prowadzenia transportu:

- przewoźnika kolejowego jako odpowiedzialnego podczas kontroli jego transportu,

- dysponenta taboru kolejowego, oraz

- użytkownika (najemcę) taboru kolejowego.

W wypadku wszystkich trzech różnych stron dane operacyjne o taborze kolejowym muszą być dostępne przez upoważnionego użytkownika i poniżej do z góry określonego przez niego upoważnionego poziomu przy użyciu pojedynczego klucza danego przez identyfikator wagonu (numer wagonu).

Dane operacyjne o taborze kolejowym są częścią ogólnoeuropejskiej "Operacyjnej bazy danych wagonów i jednostek intermodalnych" opisanej w rozdziale 4.2.12.2: Inne bazy danych.

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

4.2.12.1. Źródłowe pliki

Dla prowadzenia pociągów towarowych w sieci europejskiej następujące pliki źródłowe muszą być oddane do dyspozycji dostawców usług (IM, RU, dostawców logistyki i zarządców parku pojazdowego), którzy muszą mieć do nich dostęp. Dane te muszą stale przedstawiać rzeczywisty stan rzeczy.

Lokalnie przechowywane i administrowane:

- źródłowy plik służb awaryjnych skorelowanych z rodzajem niebezpiecznego towaru.

Centralnie przechowywane i administrowane:

- źródłowy plik kodowania dla wszystkich IM, RU, firm będących dostawcami usług,

- źródłowy plik kodowania dla klientów transportu,

- źródłowy plik kodowania położeń (podstawowych, drugorzędnych i strefowych punktów toru),

- źródłowy plik kodowania dla lokalizacji klientów,

- źródłowy plik kodowania wszystkich istniejących systemów sterowania pociągami,

- źródłowy plik numerów niebezpiecznych towarów, UN i RID,

- źródłowy plik wszystkich różnych typów lokomotyw,

- źródłowy plik wszystkich kodów towarów CN i HS,

- źródłowy plik wszystkich europejskich warsztatów remontowych,

- źródłowy plik wszystkich europejskich organów audytujących,

- źródłowy plik wszystkich europejskich licencjonowanych operatorów wraz ze stosownym wykazem udzielonych krajowych świadectw bezpieczeństwa.

Kodowanie IM, RU, organizacji i firm transportowych oraz klientów transportu, jak również lokalizacji (podstawowe, drugorzędne, ...), w tym lokalizacji klientów, jest w toku.

4.2.12.2. Inne bazy danych

Aby umożliwić odtworzenie ruchów pociągów i wagonów, muszą zostać zainstalowane następujące bazy danych, które muszą być uaktualnianie w czasie rzeczywistym przy każdym stosownym zdarzeniu. Upoważnione jednostki, takie jak dysponenci i zarządcy parku pojazdowego muszą mieć dostęp do danych istotnych dla wypełniania ich funkcji zgodnie z warunkami umów.

- Operacyjna baza danych wagonów i jednostek intermodalnych.

- Plan podróży dla wagonu/jednostki intermodalnej.

Te bazy danych muszą być dostępne za pośrednictwem powszechnego interfejsu (4.2.14.1: Ogólna architektura oraz 4.2.14.7: Uniwersalny interfejs).

Operacyjna baza danych wagonów i jednostek intermodalnych

Komunikacja pomiędzy LRU a RU w trybie współpracy opiera się na numerach wagonów i/lub jednostek intermodalnych. Dlatego RU, który komunikuje się z IM na poziomie pociągu, musi rozbić ten 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". Informacja o ruchu pociągu prowadzi do nowych wpisów/uaktualnień w "Operacyjnej bazie danych wagonów i jednostek intermodalnych" dla informacji klienta. Część ruchowa wagonu lub jednostki intermodalnej w bazie danych zostaje utworzona najpóźniej w czasie otrzymania od klienta czasu zwolnienia wagonu lub jednostki intermodalnej. Czas zwolnienia jest pierwszym wpisem dotyczących ruchu wagonu do "Operacyjnej bazy danych wagonów i jednostek intermodalnych" związanym z rzeczywistą trasą przejazdu. Komunikaty dotyczące ruchu wagonów są 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 poprzez uniwersalny interfejs (4.2.14.1: Ogólna architektura oraz 4.2.14.7: Uniwersalny interfejs).

"Operacyjna baza danych wagonów i jednostek intermodalnych" jest najważniejszą bazą danych dla śledzenia wagonów, a przez to również dla komunikacji pomiędzy uczestniczącym RU a LRU. Ta baza danych pokazuje ruch wagonu lub jednostki intermodalnej, począwszy od odjazdu do końcowej dostawy na bocznicę klienta wraz z ETI i rzeczywistymi czasami w różnych miejscach aż do czasu ostatecznej dostawy ETA. Baza danych pokazuje również różny status taboru kolejowego, taki jak:

- Status: załadowywanie taboru kolejowego

Status ten jest wymagany do wymiany informacji pomiędzy RU i IM oraz przekazywania ich do innych przewoźników kolejowych uczestniczących w przejeździe transportowym.

- Status: załadowany wagon w trasie

Status ten jest wymagany do wymiany informacji pomiędzy IM i RU, z innymi zarządcami infrastruktury oraz z innymi przewoźnikami kolejowymi uczestniczącymi w przejeździe transportowym.

- Status: pusty wagon w trasie

Status ten jest wymagany do wymiany informacji pomiędzy IM i RU, z innymi zarządcami infrastruktury oraz przewoźnikami kolejowymi uczestniczącymi w przejeździe transportowym.

- Status: rozładowywanie taboru kolejowego

Status ten jest wymagany do wymiany informacji pomiędzy RU w punkcie docelowym a LRU dla transportu.

- Status: pusty wagon pod kontrolą kierownictwa parku pojazdowego

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 zwykle ciągną wagony pochodzące od różnych klientów. Dla każdego wagonu LRU (RU pełniący rolę integratora usług) musi sporządzić i uaktualnić plan podróży, który odpowiada trasie pociągu na poziomie pociągu. Nowe trasy dla pociągu - np. w razie zakłóceń służby - prowadzą do zrewidowanych planów podróży dla danych wagonów. 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żdego LRU. Te bazy danych muszą być dostępne poprzez uniwersalny interfejs (4.2.14.1: Ogólna architektura oraz 4.2.14.7: Uniwersalny interfejs).

Uwaga:

Oprócz obowiązkowych baz danych wymienionych powyżej, po stronie każdego IM może być zainstalowana baza danych pociągów.

Ta należąca do zarządy infrastruktury baza danych pociągów odpowiada ruchowej części "Operacyjnej bazy danych wagonów i jednostek intermodalnych". Głównymi wpisami danych są dane o pociągu pochodzące z komunikatu o składzie pociągu otrzymanego od RU. Wszelkie zdarzenia dotyczące pociągu prowadzą do uaktualnienia bazy danych odnoszącej się do tego pociągu. Alternatywną możliwością przechowywania tych danych jest baza danych tras (rozdział 4.2.2: Żądanie trasy). Te bazy danych muszą być dostępne poprzez uniwersalny interfejs (4.2.14.1: Ogólna architektura oraz 4.2.14.7: Uniwersalny interfejs).

4.2.12.3. Dodatkowe wymagani a dotyczące baz danych

W poniższych punktach wymieniono dodatkowe wymagania, jakie muszą być spełniane przez różnorodne bazy danych.

Są to:

1. Uwierzytelnienie

Baza danych musi obsługiwać funkcję uwierzytelnienia użytkowników systemów, zanim będą oni mogli uzyskać dostęp do bazy danych.

2. Zabezpieczenie

Baza danych musi spełniać warunki zabezpieczenia w sensie kontrolowania dostępu do bazy danych. Ewentualne szyfrowanie samej treści bazy danych nie jest wymagane.

3. Zgodność

Wybrana baza danych winna spełniać tzw. zasadę ACID (cząsteczkowość, zgodność, oddzielenie, trwałość).

4. Kontrola dostępu

Baza danych musi pozwalać na dostęp do danych użytkownikom lub systemom, którym udzielone zostało zezwolenie. Kontrola dostępu winna być obsługiwana aż do pojedynczego atrybutu rekordu danych. Baza danych winna obsługiwać konfigurowalną, opartą o rolę kontrolę dostępu w zakresie wstawiania, uaktualniania lub usuwania rekordów danych.

5. Odtwarzanie przemieszczania

Baza danych musi obsługiwać logowanie wszystkich działań dokonywanych w bazie danych, tak aby pozwolić na odtworzenie szczegółów dotyczących wpisu danych (kto, co i kiedy dokonał zmiany w zawartości).

6. Strategia blokady

Baza danych musi implementować strategię blokowania, która pozwala na dostęp do danych nawet wtedy, gdy inni użytkownicy dokonują w tym czasie edycji rekordów.

7. Wielokrotny dostęp

Baza danych musi zapewniać możliwość równoczesnego dostępu do danych przez kilku użytkowników i kilka systemów.

8. Niezawodność

Niezawodność bazy danych musi pozwalać na utrzymanie wymaganej dostępności.

9. Dostępność

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

10. Konserwacyjność

Konserwacyjność bazy danych musi pozwalać na utrzymanie wymaganej dostępności.

11. Bezpieczeństwo

Same bazy danych nie są związane z bezpieczeństwem. Stąd aspekty bezpieczeństwa są tu istotne. Nie należy mylić tego z faktem, iż dane - np. niepoprawne lub nieaktualne dane - mogą mieć wpływ na bezpieczeństwo prowadzenia pociągu.

12. Kompatybilność

Baza danych musi obsługiwać szeroko przyjęty język manipulacji danymi, taki jak SQL lub XQL.

13. Funkcja importu

Baza danych winna udostępniać funkcję, która pozwala na import sformatowanych danych, które mogą być użyte do wypełnienia bazy danych zamiast ręcznego wprowadzenia.

14. Funkcja eksportu

Baza danych winna udostępniać funkcję, która pozwala na eksport zawartości kompletnej bazy danych lub jej części w postaci sformatowanych danych.

15. Obowiązkowe pola

Baza danych musi obsługiwać obowiązkowe pola, które muszą zostać wypełnione zanim odnośny rekord zostanie zaakceptowany jako dane wejściowe do bazy danych.

16. Sprawdzenia wiarygodności

Baza danych musi obsługiwać konfigurowalne sprawdzenia wiarygodności przed zaakceptowaniem wstawienia, uaktualnienia lub usunięcia rekordów danych.

17. Czasy odpowiedzi

Baza danych musi mieć takie czasy odpowiedzi, które pozwalają użytkownikom na wstawianie, uaktualnianie lub usuwanie rekordów danych w odpowiednim czasie.

18. Aspekty wydajnościowe

Baza danych musi obsługiwać zapytania niezbędne do umożliwienia sprawnego zarządzania około 60.000 przebiegów pociągów na dobę. Przyjmuje się, że około 50 % tych przebiegów pociągów może odbyć się w ciągu dwu godzin.

Liczba i rodzaj zapytań lub uaktualnień przypadająca na pociąg zależy od ogólnego procesu planowania i zarządzania pociągiem.

19. Aspekty pojemnościowe

Baza danych musi umożliwiać przechowanie stosownych danych dla wszystkich wagonów towarowych bądź sieci. Powinno być możliwe rozszerzenie pojemności za pomocą prostych sposobów (np. przez dodanie pojemności pamięci i komputerów). Rozszerzenie pamięci nie powinno wymagać wymiany podsystemu.

20. Dane historyczne

Baza danych winna obsługiwać dane historyczne w sensie udostępnienia danych, które zostały już przesłane do archiwum.

21. Strategia tworzenia kopii zapasowych

Powinna być wdrożona strategia tworzenia kopii zapasowych zapewniająca odtworzenie zawartości bazy danych za okres do 24 godzin.

22. Aspekty handlowe

Używany system bazy danych powinien być dostępny w handlu jako produkt gotowy (produkt COTS - dostępny od ręki) lub powinien być dostępny w publicznej domenie (źródło otwarte).

Uwagi:

Powyższe wymagania muszą być spełnione poprzez standardowy System Zarządzania Bazami Danych (DBMS).

Używanie różnorodnych baz danych jest wpisane w różne opisane tu wcześniej przepływy robocze. Ogólnym przepływem roboczym jest mechanizm żądanie/odpowiedź, w którym zainteresowana strona żąda informacji z bazy danych poprzez uniwersalny interfejs (4.2.14.1: Ogólna architektura oraz 4.2.14.7: Uniwersalny interfejs). DBMS odpowiada na to żądanie poprzez dostarczenie żądanych danych lub za pomocą odpowiedzi, że dane nie mogą być udostępnione (dane takie nie istnieją lub istnieje odmowa dostępu spowodowana kontrolą dostępu).

4.2.13. Elektroniczne przesyłanie dokumentów

Opis zamieszczony w rozdziale 4.2.14 (Łączność sieciowa i komunikacja) przedstawia sieć komunikacyjną służącą do wymiany danych. Sieć ta oraz opisana obsługa zabezpieczenia pozwalają na dowolny typ transmisji sieciowej, takiej jak poczta elektroniczna, transfer plików (ftp, http) itp. Strony uczestniczące w wymianie informacji mogą następnie postanowić o tym, jaki typ należy wybrać, co oznacza, że dane jest elektroniczne przesyłanie dokumentów, na przykład poprzez ftp.

4.2.14. Łączność sieciowa i komunikacja

4.2.14.1. Architektura ogólna

Ten podsystem wraz z upływem czasu doświadczy wzrostu i interakcji dużej i złożonej społeczności telematycznej interoperacyjności kolei z setkami uczestniczących aktorów (RU, IM, ...), którzy będą konkurować i/lub współpracować przy zaspokajaniu potrzeb rynku.

Infrastruktura sieci i komunikacji, wspierająca taką społeczność interoperacyjności kolei, oparta będzie o architekturę wymiany informacji znaną i przyjętą przez wszystkich uczestniczących graczy.

Proponowana architektura wymiany informacji:

- jest przeznaczona do uzgodnienia ze sobą heterogenicznych modeli informacji poprzez semantyczne przekształcanie danych wymienianych pomiędzy systemami oraz uzgadnianie różnic procesu gospodarczego i protokołu poziomu aplikacji,

- ma minimalny wpływ na istniejące architektury informatyczne wdrożone przez poszczególnych uczestników,

- chroni dokonane już inwestycje informatyczne.

Architektura wymiany informacji sprzyja przeważnie wymianie informacji pomiędzy wszystkimi uczestnikami typu peer-to-peer (równy z równym), przy czym gwarantuje ona ogólną integralność i spójność społeczności interoperacyjności, dostarczając zestaw scentralizowanych usług.

Model interakcji peer-to-peer pozwala na najlepsze rozdzielenie kosztów pomiędzy różnych uczestników w oparciu o faktyczne użytkowanie i będzie na ogół stwarzać mniejsze problemy związane ze skalowalnością. Obrazowe przedstawienie ogólnej architektury podano w załączniku A indeks 5 rozdział 1.5.

4.2.14.2. Sieć

Łączność sieciowa w tym wypadku oznacza metodę i filozofię komunikacji i nie oznacza fizycznej sieci.

Interoperacyjność kolei oparta jest o architekturę wymiany informacji znaną i przyjętą przez wszystkich uczestników, przez co zachęca i obniża bariery dla nowych uczestników, zwłaszcza klientów.

Kwestia bezpieczeństwa będzie zatem rozwiązywana nie przez sieć (VPN, tunelowanie, ...), lecz wymienianie i zarządzanie wewnętrznie bezpiecznymi wiadomościami. Sieć VPN nie jest więc wymagana (administracja dużej sieci VPN bywa złożona i kosztowna w prowadzeniu), dzięki czemu unika się 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.

W każdym razie, jeżeli niektórzy uczestnicy mają lub chcą wprowadzić różnorodne stopnie zabezpieczenia na wybranych partycjach sieci, to mogą to zrobić.

Poprzez publiczną sieć internetową możliwe jest zaimplementowanie hybrydowego modelu peer-to-peer z "centralnym repozytorium" i "uniwersalnym interfejsem" w węźle każdego uczestnika.

Zwrócenie się do centralnego repozytorium następuje najpierw w celu uzyskania metainformacji, takich jak tożsamość partnera (uczestnika), którego niektóre dane są przechowywane, bądź w celu zweryfikowania uwierzytelnień zabezpieczenia. Następnie realizowana jest komunikacja peer-to-peer pomiędzy zaangażowanymi uczestnikami.

4.2.14.3. Protokoły

Należy używać tylko protokołów należących do pełnego pakietu protokołów internetowych.

.................................................

Notka Wydawnictwa Prawniczego "Lex"

Grafiki zostały zamieszczone wyłącznie w Internecie. Obejrzenie grafik podczas pracy z programem Lex wymaga dostępu do Internetu.

.................................................

grafika

4.2.14.4. Bezpieczeństwo

Aby osiągnąć wysoki poziom bezpieczeństwa, wszystkie wiadomości muszą być zamknięte w sobie, co oznacza, że informacje zawarte w wiadomości są zabezpieczone i odbiorca może zweryfikować autentyczność wiadomości. Można to rozwiązać przy użyciu schematu szyfrowania i podpisywania podobnego do szyfrowania poczty elektronicznej. Pozwala to na zastosowanie dowolnego typu transmisji sieciowej, jak poczta elektroniczna, transfer plików (ftp, http) itp. Strony uczestniczące w wymianie informacji mogą następnie postanowić o tym, jaki faktyczny typ należy wybrać.

4.2.14.5. Szyfrowanie

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

4.2.14.6. Centralne repozytorium

Centralne repozytorium musi być w stanie obsługiwać:

- metadane - zorganizowane dane opisujące treść wiadomości,

- infrastrukturę kluczy publicznych (PKI),

- zezwolenie certyfikacyjne (CA),

- katalog (książkę telefoniczną) - zawiera on wszystkie informacje o uczestnikach potrzebne do wymiany wiadomości.

Zarządzanie centralnym repozytorium powinno być powierzone niekomercyjnej organizacji ogólnoeuropejskiej.

4.2.14.7. Uniwersalny interfejs

Uniwersalny interfejs jest nieodzowny dla każdego uczestnika, aby mógł on przystąpić do wspólnoty interoperacyjności kolei.

Uniwersalny interfejs musi być w stanie obsługiwać:

- formatowanie wychodzących wiadomości według metadanych,

- podpisywanie i szyfrowanie wychodzących wiadomości,

- adresowanie wychodzących wiadomości,

- weryfikację autentyczności przychodzących wiadomości,

- deszyfrowanie przychodzących wiadomości,

- sprawdzenie zgodności przychodzących wiadomości według metadanych,

- pojedynczy powszechny dostęp do różnorodnych baz danych.

Każdy przypadek uniwersalnego interfejsu będzie miał dostęp do wszystkich danych wymaganych zgodnie z TSI w obrębie każdego RU, IM itp., bez względu na to, czy odnośne bazy danych są centralne czy indywidualne (patrz również: załącznik A indeks 5 rozdział 1.6).

W oparciu o wyniki weryfikacji autentyczności przychodzących wiadomości może być zaimplementowany minimalny poziom potwierdzenia wiadomości:

i) pozytywne przesłanie ACK;

ii) negatywne przesłanie NACK.

Do zarządzania powyższymi zadaniami uniwersalny interfejs korzysta z informacji zawartych w centralnym depozycie.

Uczestnik może zaimplementować lokalne "lustro" centralnego repozytorium, aby skrócić czasy odpowiedzi.

4.3. Specyfikacje funkcjonalne i techniczne interfejsów

W świetle wymagań zasadniczych przedstawionych w rozdziale 3 specyfikacje funkcjonalne i techniczne 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 do długodystansowych usług 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" używa danych wymaganych do celów operacyjnych podanych w umowie o trasę, ostatecznie uaktualnianych w bazie danych powiadomień o ograniczeniach dostarczonej przez IM. Zatem nie ma bezpośredniego interfejsu pomiędzy tą TSI a TSI dotyczącą infrastruktury.

4.3.2. Interfejsy z TSI "Sterowanie ruchem kolejowym"

Jedyne połączenie ze sterowaniem ruchem kolejowym istnieje poprzez:

- umowę o trasę, gdy w ramach opisu odcinka linii podane są stosowne informacje o używalnych urządzeniach do sterowania ruchem kolejowym, oraz

- różnorodne źródłowe bazy danych taboru kolejowego, w których muszą być przechowane urządzenia taboru kolejowego do sterowania ruchem kolejowym.

4.3.3. Interfejsy z podsystemem "Tabor kolejowy"

Podsystem "Aplikacje telematyczne dla przewozów towarowych" identyfikuje techniczne i operacyjne dane, które muszą być dostępne dla taboru kolejowego.

TSI "Tabor kolejowy" określa charakterystykę wagonu. Jeżeli charakterystyka wagonu zmieni się, musi to zostać uaktualnione w "Źródłowych bazach danych taboru kolejowego" w ramach normalnego procesu utrzymania bazy danych. Zatem nie istnieje bezpośredni interfejs pomiędzy tą 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 podczas normalnej, jak i pogorszonej służby, w tym szczególnie planowanie i zarządzanie ruchem.

Podsystem "Aplikacje telematyczne dla przewozów towarowych" określa głównie aplikacje dla usług przewozu towarowego, w tym monitorowanie w czasie rzeczywistym przewozu i pociągów oraz zarządzanie połączeniami z innymi sposobami transportu.

W celu zapewnienia spójności pomiędzy obydwiema TSI obowiązuje następująca procedura.

Gdy specyfikacje TSI "Ruch kolejowy" związane z wymaganiami niniejszej TSI będą zapisywane i/lub będą poddawane zmianom, wówczas należy skonsultować się z organem odpowiedzialnym za niniejszą TSI.

W razie gdyby specyfikacje niniejszej TSI związane z wymaganiami operacyjnymi określonymi w TSI "Ruch kolejowy" były poddawane jakiejś zmianie, wówczas należy skonsultować się z organem odpowiedzialnym za TSI "Ruch kolejowy".

4.4. Zasady operacyjne

W świetle wymagań zasadniczych przedstawionych w rozdziale 3 zasady operacyjne specyficzne dla podsystemu, którego dotyczy niniejsza TSI, są następujące:

4.4.1. Jakość danych

Do celów zapewnienia jakości danych twórca każdej wiadomości TSI będzie odpowiedzialny za poprawność danych zawartych w wiadomości w czasie wysyłania wiadomości. Gdy dane źródłowe do celów zapewnienia jakości danych są dostępne z baz danych dostarczonych w ramach TSI, do zapewnienia jakości danych muszą być użyte dane zawarte w tychże bazach danych.

Gdy dane źródłowe do celów zapewnienia jakości danych nie są udostępnione z baz danych dostarczonych w ramach niniejszej TSI, twórca wiadomości musi dokonać sprawdzenia zapewnienia jakości danych ze swoich własnych zasobów.

Zapewnienie jakości danych obejmie porównanie danych z baz danych dostarczonych w ramach niniejszej TSI, jak opisano powyżej, plus, w stosownym wypadku, logiczne sprawdzenia w celu zapewnienia punktualności i ciągłości danych i wiadomości.

Dane są wysokiej jakości, jeżeli są odpowiednie do zamierzonych zastosowań, co oznacza, że

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

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

Jakość danych charakteryzuje głównie:

- ścisłość,

- kompletność,

- zgodność,

- punktualność.

Ścisłość:

Wymagane informacje (dane) muszą być pobierane możliwie jak najbardziej ekonomicznie. Jest to wykonalne tylko wówczas jeśli pierwotne dane, które ogrywają decydującą rolę w ekspediowaniu przesyłki, wagonu lub kontenera, są rejestrowane, jeśli to możliwe, tylko przy jednej okazji dla całego transportu. Dlatego pierwotne dane powinny być wprowadzane do systemu możliwie jak najbliżej ich źródła, np. na podstawie listu przewozowego sporządzonego, gdy wagon lub przesyłka jest przekazywana do przewozu, tak aby zostały w pełni zintegrowane z każdą późniejszą operacją przetwarzania.

Kompletność:

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

Ponadto wszystkie przychodzące wiadomości muszą być sprawdzone pod względem kompletności przy użyciu metadanych.

Zgodność:

W celu zagwarantowania zgodności muszą zostać zaimplementowane reguły handlowe. Należy unikać zdublowanych wpisów, a właściciel danych powinien być wyraźnie zidentyfikowany.

Rodzaj implementacji tych reguł handlowych zależy od złożoności reguły. Dla prostych reguł wystarczą więzy i zwalniacze baz danych. W wypadku bardziej złożonych reguł, które wymagają danych z różnych tabel, muszą zostać zaimplementowane procedury walidacji, które sprawdzają zgodność wersji danych, zanim zostaną wygenerowane dane interfejsowe i zaczną działać nowe wersje danych. Należy zagwarantować, że transferowane dane są walidowane w oparciu o zdefiniowane zasady handlowe.

Punktualność:

Dostarczenie informacji w samą porę jest istotną sprawą. O ile zwolnienie do przechowania danych lub wysłania wiadomości jest kierowane przez zdarzenie bezpośrednio z systemu informatycznego, punktualność nie stanowi problemu, jeżeli system jest zaprojektowany w dobry sposób zgodnie z potrzebami procesów gospodarczych. Lecz w większości wypadków inicjowanie wysłania wiadomości jest dokonywane przez operatora lub przynajmniej oparte jest na dodatkowych danych wejściowych od operatora (na przykład wysłanie danych o składzie pociągu lub aktualizacja danych dotyczących pociągu lub wagonu). Aby spełnić wymagania punktualności, należy możliwie jak najwcześniej dokonywać uaktualniania danych, również w celu zagwarantowania, aby wiadomości miały zawsze aktualne zawarte w nich dane, gdy są wysyłane automatycznie przez system.

Ogólnie, muszą być spełnione następujące wymagania:

Czas odpowiedzi na zapytania musi krótszy niż 5 minut. Wszystkie uaktualnienia i wymiany danych muszą być dokonywane możliwie jak najwcześniej. Czas reakcji systemu i transmisji dla uaktualnienia musi być krótszy niż 1 minuta.

Metryki jakości danych:

Dla kompletności (procent pól danych mających wpisane do nich wartości) danych obowiązkowych oraz dla zgodności danych (procent odpowiadających sobie wartości pomiędzy tabelami/plikami/rekordami) musi być osiągnięte 100 %.

Dla punktualności danych (procent danych dostępnych w określonych progowych ramach czasowych) musi być osiągnięte 98 %. O ile wartości progowe nie są określone w niniejszej TSI, wartości te muszą zostać określone w umowach pomiędzy uczestniczącymi stronami.

Wymagana ścisłość (procent przechowywanych wartości, które są poprawne w porównaniu do faktycznej wartości) musi być wyższa niż 90 %. Dokładna wartość i kryteria muszą być określone w umowach pomiędzy uczestniczącymi stronami.

4.4.2. Obsługa centralnego repozytorium

Funkcje centralnego repozytorium są określone w rozdziale 4.2.14.6 (Centralne repozytorium). Do celów zapewnienia jakości danych jednostka obsługująca centralne repozytorium powinna być odpowiedzialna za uaktualnianie oraz jakość metadanych i katalogu, a także za administrację kontroli dostępu (publicznych kluczy). Jeśli chodzi o jakość metadanych, musi zostać osiągnięte 100 % dla kompletności, zgodności, punktualności i ścisłości.

4.5. Zasady utrzymania

W świetle wymagań zasadniczych przedstawionych w rozdziale 3 zasady utrzymania specyficzne dla 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. Dlatego celowym jest zainstalowanie podwójnych systemów lub komputerów o szczególnie wysokim stopniu niezawodności, dla których zapewnione jest nieprzerwane działanie podczas utrzymania.

Aspekty utrzymania dotyczące różnorodnych baz danych są wymienione w rozdziale 4.2.12.3 (Dodatkowe wymagania dotyczące baz danych), punkty 10 i 21.

4.6. Kwalifikacje zawodowe

Kwalifikacje zawodowe personelu wymaganego do obsługi i utrzymania podsystemu i do zaimplementowania TSI są następujące:

Implementacja niniejszej TSI nie wymaga zupełnie nowego systemu sprzętu i oprogramowania z nowym personelem. Realizacja wymagań TSI prowadzi tylko do zmian, unowocześnień lub rozszerzeń funkcjonalnych obsługi, która jest dotychczas wykonywana przez istniejący personel. Dlatego nie ma dodatkowych wymagań odnośnie do istniejących krajowych lub europejskich zasad dotyczących kwalifikacji zawodowych.

W razie konieczności szkolenie personelu w zakresie dodatkowych urządzeń nie powinno polegać jedynie na pokazaniu, jak należy obsługiwać sprzęt. Członek personelu musi znać i rozumieć swoją konkretną rolę, jaką ma odgrywać w ogólnym procesie transportu. Personel musi w szczególności być świadomy wymogu utrzymania wysokiego poziomu sprawności roboczej, gdyż jest to decydującym czynnikiem dla rzetelności informacji, które będą przetwarzane na następnym etapie.

Kwalifikacje zawodowe potrzebne do składania i prowadzenia pociągów są określone w TSI "Ruch kolejowy".

4.7. Warunki BHP

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

Nie ma dodatkowych wymagań w stosunku do istniejących krajowych i europejskich zasad BHP.

4.8. Rejestry infrastruktury i taboru kolejowego

Zgodnie z art. 24 ust. 1 dyrektywy 2001/16/WE "Państwa Członkowskie zapewniają, że rejestry infrastruktury i taboru kolejowego są corocznie publikowane i uaktualniane. Rejestry te podają główną cechę każdego uczestniczącego podsystemu lub części podsystemu oraz ich korelację z cechami określonymi przez stosowne TSI. W tym celu każda TSI podaje dokładnie, które informacje muszą być ujmowane w rejestrach infrastruktury i taboru kolejowego."

Z uwagi na ich coroczne uaktualnianie i publikowanie rejestry te nie nadają się do wykorzystania przez "Aplikacje telematyczne dla przewozów towarowych". Dlatego niniejsza TSI nie ma nic do podania w tych rejestrach.

5. SKŁADNIKI INTEROPERACYJNOŚCI

5.1. Definicja

Zgodnie z art. 2 lit. d) dyrektywy 2001/16/WE:

Składnikiem interoperacyjności jest "dowolna elementarna część, grupa części, podzespół lub kompletny zespół urządzenia włączonego lub mającego w zamierzeniu być włączonym do podsystemu, od którego bezpośrednio lub pośrednio zależy interoperacyjność transeuropejskiego systemu kolei konwencjonalnej. Pojęcie składnika obejmuje przedmioty zarówno materialne, jak i niematerialne, takie jak oprogramowanie".

5.2. Wykaz składników

Składniki interoperacyjności są objęte stosownymi przepisami dyrektywy 2001/16/WE.

Jeśli chodzi o podsystem "Aplikacje telematyczne dla przewozów towarowych", nie ma określonych składników interoperacyjności.

Dla spełnienia wymagań niniejszej TSI potrzebny jest jedynie standardowy sprzęt informatyczny, bez szczególnych aspektów dla interoperacyjności w środowisku kolejowym. Dotyczy to składników sprzętu oraz używanego standardowego oprogramowania, takiego jak system operacyjny i bazy danych. Oprogramowanie użytkowe po stronie każdego użytkownika może być dostosowywane i udoskonalane stosownie do indywidualnej rzeczywistej funkcjonalności i potrzeb. Proponowana "architektura integracji aplikacji" zakłada, że aplikacje mogą nie mieć takiego samego wewnętrznego modelu informatycznego. Integracja aplikacji jest zdefiniowana jako proces powodujący, że systemy niezależnie zaprojektowanych aplikacji współpracują ze sobą.

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

Patrz: rozdział 5.2, nieistotne dla TSI "Aplikacje telematyczne dla przewozów towarowych".

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

6.1. Składniki interoperacyjności

6.1.1. Procedury oceny

Procedura oceny zgodności lub przydatności do użycia składników interoperacyjności musi być oparta o europejskie specyfikacje lub specyfikacje zatwierdzone zgodnie z dyrektywą 2001/16/WE.

W wypadku przydatności do użycia specyfikacje te będą podawać wszystkie parametry, które mają być mierzone, monitorowane lub obserwowane i będą opisywać 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 i/lub przydatności do użycia:

Wykaz specyfikacji, opis metod badawczych:

Nieistotne dla TSI "Aplikacje telematyczne dla przewozów towarowych".

6.1.2. Moduł

Na żądanie producenta lub jego przedstawiciela mającego siedzibę we Wspólnocie notyfikowany organ wykonuje procedurę zgodnie z przepisami stosownych modułów decyzji Rady 93/465/EWG przedstawionymi, poprawionymi i uzupełnionymi w załączniku do niniejszej TSI.

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

Nieistotne dla TSI "Aplikacje telematyczne dla przewozów towarowych".

6.2. Podsystem "Aplikacje telematyczne dla przewozów towarowych"

Na żądanie organu przyznającego lub jego przedstawiciela mającego siedzibę we Wspólnocie notyfikowany organ wykonuje procedurę wspólnotowej weryfikacji zgodnie z załącznikiem VI do dyrektywy 2001/16/WE.

Zgodnie z załącznikiem II dyrektywy 2001/16/WE podsystemy są rozbite na dziedziny strukturalne i operacyjne.

Ocena zgodności jest obligatoryjna dla TSI w dziedzinie strukturalnej. Podsystem "Aplikacje telematyczne dla przewozów towarowych" należą do dziedziny operacyjnej i w związku z tym niniejsza TSI nie określa żadnych modułów dla oceny zgodności.

Jednakże centralne repozytorium i uniwersalny interfejs w węźle każdego uczestnika stanowią trzon integracji aplikacji. Model wymiany informacji jest przechowywany w scentralizowanym repozytorium integracji aplikacji, w którym interfejsowe metadane są utrzymywane w jednym fizycznym miejscu. Te metadane zawierają informacje o treści komunikacji (co znajduje się w przesyłanych danych), punkt kontaktu identyfikuje nadawców i odbiorców, a mechanika procesu interakcji protokoły gospodarcze poziomu aplikacji.

Podkreślone są następujące punkty:

- Centralne repozytorium zawiera katalog (książkę telefoniczną) wszystkich uczestniczących graczy dotyczący wymiany wiadomości. Katalog ten musi zawsze przedstawiać rzeczywisty stan rzeczy. Nieprawidłowe wpisy stają się natychmiast zauważalne. Nie jest potrzebna procedura oceny.

- Centralne repozytorium zawiera również zezwolenie certyfikacyjne (otwarte CA PKI). Jest to akt administracyjny, który jest fizycznie zaimplementowany. Nieprawidłowe wpisy stają się natychmiast zauważalne. Nie jest potrzebna procedura oceny.

- Centralne repozytorium zawiera metadane wiadomości (zgodnie z załącznikiem A dodatek E i F) jako podstawę dla wymiany wiadomości w heterogenicznym środowisku informatycznym. Metadane muszą być administrowane i uaktualniane w centralnym depozycie. Wszelka niezgodność w strukturze lub zawartości wiadomości przy wysyłaniu i odbieraniu danych zostanie natychmiast rozpoznana i nastąpi odmowa przekazu. Nie jest potrzebna procedura oceny.

- Uniwersalny interfejs w węźle każdego uczestnika zawiera głównie lokalne "lustro" centralnego repozytorium dla skrócenia czasu odpowiedzi i zmniejszenia obciążenia repozytorium. Należy zagwarantować, że wersje danych w centralnym depozycie i w uniwersalnym interfejsie są zawsze takie same. Dlatego uaktualnianie danych musi być dokonywane na poziomie centralnym i stamtąd muszą być pobierane nowe wersje. Nie jest potrzebna procedura oceny.

7. WDROŻENIE

7.1. Modalności stosowania niniejszej TSI

7.1.1. Wstęp

Niniejsza TSI dotyczy podsystemu aplikacji telematycznych dla przewozów towarowych. Jest to podsystem funkcjonalny zgodnie z załącznikiem II do dyrektywy 2008/57/WE. Dlatego stosowanie tej TSI nie zależy od koncepcji nowego, odnowionego ani zmodernizowanego podsystemu, jak ma to zwyczajowo miejsce w przypadku technicznych specyfikacji interoperacyjności dotyczących podsystemów strukturalnych, chyba że jest to określone w TSI.

TSI jest wdrażana etapowo:

- etap pierwszy: szczegółowe specyfikacje informatyczne i plan ogólny,

- etap drugi: opracowywanie,

- etap trzeci: wdrażanie.

7.1.2. Etap pierwszy - szczegółowe specyfikacje informatyczne i plan ogólny

Specyfikacje wymagań funkcjonalnych, które mają być stosowane jako podstawa ww. architektury technicznej w czasie opracowywania i wdrażania systemu skomputeryzowanego, znajdują się w dodatkach A-F wymienionych w załączniku A.

Obowiązkowy plan ogólny od etapu koncepcji do gotowego systemu skomputeryzowanego, oparty na strategicznym europejskim planie wdrożeniowym (SEDP) przygotowanym przez branżę kolejową, obejmuje kluczowe elementy architektury systemu oraz wskazanie najważniejszych działań do wykonania.

7.1.3. Etap 2 i 3 - opracowanie i wdrażanie

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

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

Etapy opracowywania i wdrażania podlegają strukturze zarządzania obejmującej następujące podmioty.

Komitet sterujący

Komitet sterujący spełnia następujące role i obowiązki:

1. 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 uczestników i przedsiębiorstw kolejowych wykonujących usługi specjalne.

2. 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 ogólnym. Komitet sterujący podejmuje niezbędne działania w celu dostosowania etapu opracowywania w przypadku odstępstw od planu ogólnego.

3. W skład komitetu sterującego wchodzą:

- organy przedstawicielskie sektora kolejowego działające na poziomie europejskim, określone w art. 3 ust. 2 rozporządzenia (WE) nr 881/2004 ("reprezentatywne organy sektora kolejowego"),

- Europejska Agencja Kolejowa, oraz

- Komisja.

4. Komitetowi sterującemu przewodniczą wspólnie: a) Komisja; oraz b) osoba wyznaczona przez organy przedstawicielskie sektora kolejowego. Komisja, przy wsparciu członków komitetu sterującego, opracowuje regulamin wewnętrzny komitetu sterującego, który jest zatwierdzany przez ten komitet.

5. 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ą niezbędne działania i zasoby do wdrażania 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,

- dopilnowują, 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 ww. zainteresowanych podmiotów, jak i dla nowych uczestnikó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 razie potrzeby odstępstwa od planu ogólnego.

Organy przedstawicielskie

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

- reprezentują swoje 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 ww. 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 poinformowane 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 zagwarantowania, by koszty i korzyści każdej zmiany były właściwe analizowane, 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 zmian,

- wskazanie podmiotu odpowiedzialnego za procedury wdrażania zmian,

- procedurę potwierdzania (walidacji) zmian, które mają zostać wdrożone,

- politykę zarządzania zmianami, ich wprowadzenia, migracji i masowego wdrożenia,

- 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 (CCB) wchodzą Europejska Agencja Kolejowa, organy przedstawicielskie sektora kolejowego i krajowe organy ds. bezpieczeństwa. Taki skład zapewni odpowiednie spojrzenie na zmiany, które mają być wprowadzone, oraz globalną 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 załączniku A do niniejszego rozporządzenia

Europejska Agencja Kolejowa ustanawia zarządzanie zmianami w odniesieniu do dokumentów wymienionych w załączniku A 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 kolejowego działających na poziomie 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 załącznika A wraz z projektem nowej wersji dokumentu, 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 załącznika A w Dzienniku Urzędowym Unii Europejskiej Europejska Agencja Kolejowa udostępnia nową wersję dokumentu 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, zmian dokonuje się w taki sposób, aby pozostać jak najbliżej już wdrożonej TSI TAP, w celu osiągnięcia optymalnej synergii.

7.4. Szczególne przypadki

7.4.1. Wstęp

Następujące szczególne przepisy są dopuszczalne w szczególnych przypadkach wymienionych poniżej.

Te szczególne przypadki należą do dwu kategorii: przepisy obowiązują na stałe (przypadek "P") lub tymczasowo (przypadek "T"). W tymczasowych przypadkach zaleca się, aby zainteresowane Państwa Członkowskie dostosowały się do odpowiedniego podsystemu do 2010 r. (przypadek "T1"), cel przedstawiony w decyzji nr 1692/96/WE Parlamentu Europejskiego i Rady z dnia 23 lipca 1996 r. w sprawie wspólnotowych wytycznych dla rozwoju transeuropejskiej sieci transportowej⁽¹¹⁾, lub do 2020 r. (przypadek "T2"). "Otwarty T" jest zdefiniowany jako okres nieokreślony, który zostanie ustalony w przyszłej rewizji niniejszej TSI.

7.4.2. Wykaz szczególnych przypadków

7.4.2.1. Szczególny przypadek Państw Członkowskich UE graniczących z krajami trzecimi

Na terytoriach Państw Członkowskich UE posiadających granicę z krajami trzecimi wymagania niniejszej TSI nie są obligatoryjne w stosunku do transportu bezpośrednio przybywającego lub udającego się do tych krajów trzecich (przypadek "otwarty T").

Jeśli jednak trasa transportu będzie przedłużona do innego Państwa Członkowskiego UE, wymagania niniejszej TSI muszą być zastosowane w całości, pod warunkiem że nie ma dwustronnego lub wielostronnego porozumienia pomiędzy zainteresowanymi państwami lub pomiędzy RU lub IM działającymi na terytorium tychże Państw Członkowskich.

7.4.2.2. Szczególny przypadek Grecji

Dla przejazdu transportowanego prowadzonego na liniach o szerokości toru 1.000 mm obowiązują krajowe zasady.

______

⁽¹⁾ Dz.U. L 75 z 15.3.2001, str. 29. Dyrektywa ostatnio zmieniona dyrektywą 2004/49/WE (Dz.U. L 164 z 30.4.2004, str. 44, sprostowanie w Dz.U. L 220 z 21.6.2004, str. 16).

⁽²⁾ Dz.U. L 220 z 30.8.1993, str. 23.

⁽³⁾ Dz.U. L 75 z 15.3.2001, str. 26.

⁽⁴⁾ Dz.U. L 237 z 24.8.1991, str. 25. Dyrektywa ostatnio zmieniona dyrektywą 2004/51/WE Parlamentu Europejskiego i Rady (Dz.U. L 164 z 30.4.2004, str. 164, sprostowanie w Dz.U. L 220 z 21.6.2004, str. 58).

⁽⁵⁾ Pod pojęciem punktu odjazdu rozumiany jest punkt startowy trasy, który może być punktem odjazdu pociągu dla przejazdu lub punktem wymiany. Punkt przekazania jest końcowym punktem trasy.

⁽⁶⁾ Oznacza to, że dostęp do tych informacji musi być niezależny od tego, pod którym IM przechował informacje lub ich część.

⁽⁷⁾ Np. normy zapewnienia jakości, metoda opracowania systemu, metodologia badań, planowanie dokumentacji.

⁽⁸⁾ Istniejące aplikacje telematyczne dla przewozu towarowego są to aplikacje telematyczne dla przewozu towarowego, które są już w użyciu przed wejściem w życie niniejszej TSI.

⁽⁹⁾ Poziom bazowy pełni rolę początkowego punktu odniesienia dla kontrolowanego zarządzania ewolucją systemu.

⁽¹⁰⁾ Wydanie wersji jest to wersja systemu, która jest rozprowadzana do klientów kolejowych. Wersje systemu mogą mieć różną funkcjonalność, wydajność lub mogą naprawiać usterki systemu bądź wady dotyczące bezpieczeństwa lub zabezpieczenia.

⁽¹¹⁾ Dz.U. L 228 z 9.9.1996, str. 1. Decyzja ostatnio zmieniona decyzją nr 884/2004/WE (Dz.U. L 167 z 30.4.2004, str. 1, sprostowanie w Dz.U. L 201 z 7.6.2004, str. 1).

Załącznik A

5 WYKAZ ZAŁĄCZONYCH DOKUMENTÓW

Wykaz obowiązkowych specyfikacji

Indeks	Oznaczenie	Tytuł dokumentu	Wersja
5	ERA_FRS_TAF_A_Index_ 5.doc	TAF TSI - ANNEX A.5: Figures and Sequence Diagrams of the TAF TSI Messages [Załącznik A.5: Dane liczbowe i schematy sekwencyjne komunikatów TSI TAF]	1.0

Dodatek	Oznaczenie	Tytuł dokumentu	Wersja
A	ERA_FRS_TAF_D_2_ Appendix_A.doc	TAF TSI - ANNEX D.2: APPENDIX A (WAGON/ILU TRIP PLANNING) [Załącznik D.2: Dodatek A (Planowanie podróży wagony/ILU)]	1.0
B	ERA_FRS_TAF_D_2_ Appendix_B.doc	TAF TSI - ANNEX D.2: APPENDIX B - WAGON AND INTERMODAL UNIT OPERATING DATABASE (WIMO) [Załącznik D.2: Dodatek B - Operacyjna baza danych transportu kolejowego towarowego i intermodalnego (WIMO)]	1.1
C	ERA_FRS_TAF_D_2_ Appendix_C.doc	TAF TSI - ANNEX D.2: APPENDIX C - REFERENCE FILES [Załącznik D.2: Dodatek C - Pliki referencyjne]	1.1
D	ERA_FRS_TAF_D_2_ Appendix_D.doc	TAF TSI - ANNEX D.2: APPENDIX D - INFRASTRUCTURE RESTRICTION NOTICE DATA [Załącznik D.2: Dodatek D - Dane na temat powiadomień o ograniczeniach infrastruktury]	1.1
E	ERA_FRS_TAF_D_2_ Appendix_E.doc	TAF TSI - ANNEX D.2: APPENDIX E - COMMON INTERFACE [Załącznik D.2: Dodatek E - Interfejs wspólny]	1.0
F	ERA_FRS_TAF_D_2_ Appendix_F.doc	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]	1.1

Załącznik B

GLOSARIUSZ

Pojęcie	Definicja
ACID	Cząsteczkowość, zgodność, oddzielenie, trwałość Są to cztery podstawowe atrybuty zapewnione dla każdej transakcji: Cząsteczkowość. W transakcji, w której występują dwie lub więcej oddzielnych informacji, zostają użyte wszystkie informacje lub żadna. Zgodność. Wynikiem transakcji jest nowy, poprawny stan danych lub w razie błędu przywrócenie wszystkich danych do stanu sprzed rozpoczęcia transakcji. Oddzielenie. Transakcja będąca w toku i jeszcze niezakończona musi pozostać oddzielona od każdej innej transakcji. Trwałość. Użyte dane zostają przechowane przez system w taki sposób, aby w razie awarii i ponownego uruchomienia systemu były dostępne w ich prawidłowym stanie. Pojęcie ACID opisane jest w normie ISO/IEC 10026-1:1992, sekcja 4. Każdy z tych atrybutów może być mierzony według pewnego wzorca porównawczego. Ogólnie jednak za realizację koncepcji ACID odpowiedzialny jest menedżer lub nadzorca transakcji. W systemie rozproszonym jednym ze sposobów na osiągnięcie ACID jest stosowanie zobowiązania dwufazowego (2PC), w którym do wykonania transakcji muszą zobowiązać się wszystkie uczestniczące lokalizacje lub żadna, a wówczas transakcja zostaje wycofana.
AEIF	Association Européenne pour l'Interopérabilité Ferroviaire. Zgodnie z dyrektywą 2001/16/WE AEIF jest "połączonym organem przedstawicielskim, wspólnym stowarzyszeniem UIC, UNIFE i UITP".
Ubiegający się	Oznacza licencjonowanego przewoźnika kolejowego i/lub międzynarodowe ugrupowanie przewoźników kolejowych oraz w Państwach Członkowskich, które przewidują taką możliwość, inne osoby i/lub jednostki prawne mające wynikające ze służby publicznej lub komercyjne interesy w nabywaniu mocy przepustowych infrastruktury, takie jak organy publiczne zgodnie z rozporządzeniem Rady (EWG) nr 1191/69⁽¹⁾ oraz załadowcy, spedytorzy oraz przewoźnicy transportu kombinowanego, w celu prowadzenia usług kolejowych na ich odnośnych terytoriach.
Pociąg marszrutowy bezpośredni	Szczególna postać pociągu bezpośredniego zawierającego tylko tyle wagonów, ile jest potrzebne, jadącego pomiędzy dwoma punktami przeładunku bez pośredniego zestawiania.
Rezerwowanie	Proces dokonywania rezerwacji miejsca na środku transportu w celu przewozu towaru.
CA	Zezwolenie certyfikacyjne (ang. Certification Authority)
Kod CN	Lista 8-cyfrowych kodów produktów używanych przez urzędy celne.
Kombinowany transport kolejowy	Transport intermodalny, w którym większa część europejskiej podróży odbywa się koleją, a ewentualny początkowy i/lub końcowy odcinek odbywający się drogą jest możliwie jak najkrótszy.
Odbiorca	Strona, która ma odebrać towar. Synonim: odbiorca towaru
Przesyłka	Możliwa do wyodrębnienia ilość towaru, który ma być przetransportowany od jednego nadawcy do jednego odbiorcy za pomocą jednego lub więcej rodzajów transportu, jak określono w pojedynczym dokumencie transportowym.
List przewozowy	Dokument, który jest świadectwem umowy o transport przez przewoźnika jednej przesyłki z podanego miejsca przyjęcia do podanego miejsca dostawy. Zawiera on szczegóły dotyczące przesyłki, która ma być przewieziona.
Nadawca	Strona, która poprzez umowę z integratorem usług nadaje lub wysyła towar przez przewoźnika, lub zleciła mu przewiezienie tego towaru. Synonimy: wysyłający, nadawca towaru.
Tryb współpracy	Sposób prowadzenia pociągu, w którym różni RU współpracują z sobą pod przewodnictwem jednego RU (LRU). Każdy uczestniczący RU kontraktuje we własnym zakresie trasę potrzebną dla przejazdu transportowego.
Produkt COTS	Gotowe produkty dostępne handlowo (ang. Commercial Off-The-Shelf).
Data/czas odjazdu, rzeczywiste	Data (i czas) odjazdu środka transportu.
Pociąg bezpośredni	Pociąg wraz z odnośnymi wagonami jadący pomiędzy dwoma punktami przeładunku (początkowym źródłowym - końcowym przeznaczenia) bez pośredniego zestawiania.
Odpowiedzialny	Każda osoba fizyczna lub prawna odpowiedzialna za ryzyko, które wprowadza do sieci, tj. RU.
Szyfrowanie	Kodowanie wiadomości Rozszyfrowanie: przekształcanie zaszyfrowanych danych z powrotem w pierwotną postać
Wymagania zasadnicze	Wymagania zasadnicze oznaczają wszystkie warunki przedstawione w załączniku III dyrektywy 2001/16/WE, które muszą być spełnione przez transeuropejski system kolei konwencjonalnej, podsystemy, składniki interoperacyjności, w tym również interfejsy.
ETA	Szacowany czas przyjazdu wagonów po stronie klienta.
ETH	Szacowany czas przekazania pociągu od jednego IM do drugiego.
ETI	Szacowany czas wymiany wagonów od jednego RU do drugiego.
Czas przewidywany	Najlepsze oszacowanie czasu przyjazdu, odjazdu lub przejazdu pociągu.
FTP	Protokół przesyłania plików (ang. File Transfer Protocol) Protokół służący do przekazywania plików pomiędzy systemami komputerowymi w sieci TCP/IP.
Terminal przeładunkowy	Stacja w granicach trasy przejazdu pociągu z jednostkami intermodalnymi, gdzie ładunek zmienia wagony.
GGP	Protokół międzybramowy (ang. Gateway to Gateway Protocol) Patrz również: IP
Ciężar ładunku brutto	Zarezerwowany/rzeczywisty całkowity ciężar (masa) towaru wraz z opakowaniem, lecz wyłączając sprzęt przewoźnika.
Punkt obsługi	Stacja, gdzie RU może zmienić skład pociągu, lecz gdzie pozostaje on odpowiedzialny za wagony, bez zmiany odpowiedzialności.
Punkt przekazania pomiędzy IM	Punkt, w którym odpowiedzialność przechodzi z jednego IM na drugiego.
Przewóz transportem drogowym	Transport drogowy
Najemca	Dowolna osoba fizyczna lub prawna wskazana jako taka przez dysponenta/ właściciela wagonu.
Kod HS	Lista 6-cyfrowych kodów produktów używanych przez urzędy celne, identycznych z pierwszymi 6 cyframi kodu CN.
HTTP	Protokół przesyłania hipertekstu (ang. Hypertext Transfer Protocol) Protokół klient/serwer służący do łączenia się z serwerami w sieci.
ICMP	Internetowy protokół komunikatów kontrolnych (ang. Internet Control Message Protocol) Od czasu do czasu komputer główny bramy (patrz: GGP) lub punktu docelowego (patrz: IP) komunikuje się z komputerem głównym źródła, aby na przykład donieść o błędach w przetwarzaniu datagramów. Do takich celów służy internetowy protokół komunikatów kontrolnych (ICMP). ICMP korzysta z podstawowej obsługi ze strony IP, tak jak gdyby był protokołem wyższego poziomu, jednak w rzeczywistości stanowi integralną część IP i musi być zaimplementowany przez każdy moduł IP. Komunikaty ICMP są wysyłane w kilku sytuacjach: na przykład wtedy, gdy datagram nie może dotrzeć do adresata, gdy brama nie ma możliwości buforowania datagramu przed jego przekazaniem oraz gdy brama może polecić głównemu komputerowi wysłanie ruchu na krótszą trasę. Protokół IP nie jest zaprojektowany jako bezwzględnie niezawodny. Celem komunikatów kontrolnych jest dostarczenie informacji zwrotnych o problemach w środowisku komunikacyjnym, nie zaś uczynienie IP niezawodnym. Nadal nie ma gwarancji, że datagram zostanie dostarczony lub że komunikaty kontrolne zostaną odesłane. Niektóre datagramy mogą pozostać niedostarczone bez jakiejkolwiek informacji o ich utracie. Protokoły wyższego poziomu, które wykorzystują IP, muszą zaimplementować swoje własne procedury niezawodności, jeśli wymagana jest niezawodna komunikacja. Komunikaty ICMP zwykle donoszą o błędach w przetwarzaniu datagramów. Aby uniknąć nieskończonego regresu komunikatów o komunikatach itp., nie są wysyłane komunikaty ICMP o komunikatach ICMP. Ponadto wysyłane są tylko komunikaty ICMP o błędach obsługi fragmentu zerowego fragmentowanych datagramów. (Fragment zerowy posiada przesunięcie równe zeru).
IM	Zarządca infrastruktury (ang. Infrastructure Manager): Każdy organ lub przedsiębiorstwo, które jest odpowiedzialne w szczególności za ustanowienie i utrzymywanie infrastruktury. Może to również obejmować zarządzanie systemami kontroli i bezpieczeństwa infrastruktury. Funkcje zarządcy infrastruktury w sieci lub części sieci mogą być przydzielone innym organom lub przedsiębiorstwom. (dyrektywa 2001/14/WE).
Zarządca infrastruktury	Patrz: IM
Przekazanie (między RU)	Przekazanie kontroli z jednej firmy kolejowej na inną ze względów praktycznych, operacyjnych i bezpieczeństwa. Przykładami są: - usługi mieszane, - usługi z podzieloną odpowiedzialnością za przewóz, - przekazywanie informacji pomiędzy różnymi zarządami kolejowymi, - przekazywanie informacji pomiędzy właścicielami/dysponentami wagonów i przewoźnikami kolejowymi.
Punkt przekazania (między RU)	Miejsce, w którym następuje przeniesienie odpowiedzialności za wagony z jednego RU na drugiego RU. Jeśli chodzi o jazdę pociągu, pociąg zostaje przejęty od jednego RU przez drugi RU, który posiada teraz trasę dla następnego odcinka przejazdu.
Punkt pośredni	Miejsce, które określa punkt początkowy lub końcowy odcinka przejazdu. Może to być np. punkt wymiany, przekazania lub obsługi.
Operator intermodalny	Operator terminalu intermodalnego, np. terminalu przeładunkowego.
Integrator Usług Intermodalnych	Dowolny organ lub przedsiębiorstwo, które ma umowę z klientami na transport jednostek intermodalnych. Przygotowuje on listy przewozowe, zarządza objętością załadowczą w pociągach marszrutowych bezpośrednich itp.
Terminal intermodalny	Miejsce, które zapewnia przestrzeń, sprzęt i środowisko robocze, w którym odbywa się przekazywanie jednostek załadowczych (kontenerów, nadwozi wymiennych, naczep lub przyczep).
Transport intermodalny	Przewóz towaru w jednej i tej samej jednostce załadowczej lub pojeździe, z wykorzystaniem kolejno kilku rodzajów transportu bez przeładunku samego towaru przy zmianie rodzaju transportu.
Jednostka intermodalna	Jednostka załadowcza przystosowana do przewozu różnymi rodzajami transportu, np. kontener, nadwozie wymienne, naczepa, przyczepa.
Internet	- dowolna duża sieć składająca się z szeregu mniejszych sieci, - grupa sieci, które są wzajemnie połączone, tak że wydają się jedną dużą, ciągłą siecią i mogą być adresowane w sposób płynny na poziomie warstwy sieciowej modelu OSI przy wykorzystaniu routerów, - nazwa własna sieci wykorzystywanej jako źródło informacji, do poczty elektronicznej oraz pogawędek online, przeznaczonej dla użytkowników na całym świecie.
Składnik interoperacyjności	Oznacza dowolną elementarną część, grupę części, podzespół lub kompletny zespół urządzenia włączony lub przeznaczony do włączenia do podsystemu, od którego bezpośrednio lub pośrednio zależy interoperacyjność transeuropejskiego systemu kolei konwencjonalnej. Pojęcie składnika obejmuje zarówno przedmioty materialne, jak i obiekty niematerialne, takie jak oprogramowanie.
IP	Protokół internetowy (ang. Internet Protocol) Protokół IP służy do obsługi datagramów przesyłanych pomiędzy komputerami głównymi w systemie wzajemnie połączonych sieci. Urządzenia łączące sieci zwane są bramami. Bramy te komunikują się ze sobą nawzajem do celów kontrolnych za pośrednictwem protokołu "brama do bramy" (Gateway to Gateway Protocol - GGP).
Podróż	"Podróż" oznacza przesłanie w przestrzeni załadowanego lub pustego wagonu ze stacji spedycyjnej do stacji docelowej.
Odcinek podróży	Jest to część podróży mająca miejsce w jednym sektorze infrastruktury jednego zarządcy infrastruktury lub Część podróży od wejściowego punktu przekazania do wyjściowego punktu przekazania w infrastrukturze jednego zarządcy.
Dysponent	Osoba, która będąc właścicielem lub posiadając prawo do dysponowania pojazdem, wykorzystuje ten pojazd gospodarczo i w sposób stały jako środek transportu, i jest zarejestrowana jako taka w Rejestrze Taboru Kolejowego.
Lead Railway Undertaking	Wiodący przewoźnik kolejowy: odpowiedzialny RU, który organizuje linię transportową i zarządza nią zgodnie ze zobowiązaniem klienta. Jest on jedynym punktem kontaktu dla klienta. Jeżeli w łańcuchu transportowym uczestniczy więcej niż jeden przewoźnik kolejowy, to LRU jest odpowiedzialny za koordynację różnych przewoźników. Klientem może być, zwłaszcza dla transportu intermodalnego, integrator usług intermodalnych.
Loco ID	Niepowtarzalny numer identyfikacyjny jednostki trakcyjnej
LRU	Patrz: Lead Railway Undertaking
MOŻE	Słowo to lub przymiotnik "OPCJONALNY" oznacza, że element jest naprawdę nieobowiązkowy. Jeden sprzedający może postanowić, aby ująć ten element, gdyż wymaga tego dany rynek lub ponieważ sprzedający uważa, iż poprawia on produkt, podczas gdy inny sprzedający może ten sam element pominąć. Implementacja, która nie zawiera określonej opcji, MUSI być przygotowana do współdziałania z inną implementacją, która zawiera tę opcję, choć być może z ograniczonym zbiorem funkcji. Analogicznie implementacja, która zawiera określoną opcję. MUSI być przygotowana do współdziałania z inną implementacją, która tej opcji nie zawiera (oczywiście z wyjątkiem funkcji, którą zapewnia ta opcja).
Metadane	W uproszczeniu są to dane o danych. Opisują one dane, usługi programowe oraz inne składniki zawarte w systemach informatycznych przedsiębiorstwa. Przykładami typów metadanych są m.in. definicje danych standardowych, informacje o lokalizacji i wyznaczeniu trasy oraz zarządzanie synchronizacją dla dystrybucji danych rozproszonych.
MUSI	Słowo to lub określenia "WYMAGANY" bądź "WINIEN" oznaczają, że definicja jest bezwzględnym wymogiem specyfikacji.
ZABRANIA SIĘ	Zwrot ten lub określenie "NIE POWINIEN" oznaczają, że definicja jest bezwzględnym zakazem specyfikacji.
NFS	Sieciowy system plików (ang. Network File System) jest protokołem rozproszonego systemu plików. Protokół NFS zapewnia przejrzysty, zdalny dostęp do rozproszonego systemu plików we wszystkich sieciach. Protokół NFS jest zaprojektowany tak, aby był niezależny od komputera, systemu operacyjnego, architektury sieci, mechanizmu zabezpieczeń oraz protokołu transportu. Niezależność ta osiągnięta jest dzięki zastosowaniu prymitywów RPC zbudowanych na bazie XDR.
Jednostki notyfikowane	Organy, które są odpowiedzialne za ocenianie zgodności lub odpowiedniości do użycia składników interoperacyjności lub za ocenianie wspólnotowej procedury weryfikacji podsystemów (dyrektywa 91/440/WE).
One Stop Shop (OSS)	Międzynarodowe partnerstwo pomiędzy zarządcami infrastruktury kolejowej, dające do dyspozycji klientom kolejowym jeden punkt kontaktu do celów: - zamawiania określonych tras pociągów w międzynarodowym ruchu przewozowym, - monitorowania całego ruchu pociągów, - ogólnie również fakturowania opłat za dostęp do torów w imieniu IM.
Tryb otwartego dostępu	Tryb użytkowania pociągu, w którym uczestniczy tylko jeden RU, który prowadzi pociąg w różnych infrastrukturach. Ten RU kontraktuje potrzebne trasy u wszystkich uczestniczących IM.
OSI	Połączenie systemów otwartych (ang. Open Systems Interconnection) Opisuje protokół komunikacyjny systemów otwartych w oparciu o model odniesienia OSI. Systemy otwarte są zdolne do komunikowania się niezależnie od rozwiązań dedykowanych.
Model odniesienia OSI	Standardowy opis sposobu przekazywania komunikatów pomiędzy dowolnymi dwoma punktami sieci. Model OSI model określa 7 warstw funkcji, które występują po obu stronach komunikacji. Warstwy te stanowią jedyne międzynarodowo przyjęte ramy standardów komunikacji.
OSS	One Stop Shop
Trasa	Trasa oznacza zdolność przepustową infrastruktury potrzebną do jazdy pociągu pomiędzy dwoma miejscami w danym okresie czasu (drogę określoną w czasie i przestrzeni).
Zespół tras	Połączenie indywidualnych tras pociągów w celu przedłużenia trasy w czasie i przestrzeni.
Numer trasy	Numer określonej trasy pociągu
Peer-to-Peer	Określenie peer-to-peer ("równy z równym") odnosi się do klasy podsystemów i aplikacji, które wykorzystują zasoby rozproszone do wykonywania pewnej krytycznej funkcji w sposób zdecentralizowany. Zasoby te obejmują moc obliczeniową, dane (pamięć i zawartość), szerokość pasma sieci oraz obecność (komputerów, ludzi oraz innych zasobów). Krytyczną funkcją może być rozproszone obliczanie, współużytkowanie danych lub zawartości, komunikacja i współpraca oraz usługi platformy. Decentralizacja może stosować się do algorytmów, danych i metadanych bądź do nich wszystkich. Nie wyklucza to zachowania centralizacji w pewnych częściach systemów i aplikacji, jeśli spełnia ona ich wymagania.
PKI	Infrastruktura kluczy publicznych (ang. Public Key Infrastructure)
Miejsce dostawy	Miejsce, w którym następuje dostawa (podaje się odjazdową stację kolejową). Miejsce, w którym zmienia się odpowiedzialność za wagon.
Miejsce odjazdu	Miejsce, z którego środek transportu ma według planu odjechać lub odjechał.
Miejsce docelowe	Miejsce, do którego środek transportu ma przyjechać lub przyjechał. Synonim: Miejsce przyjazdu
Okres przedodjazdowy	Jest to czas delta przed planowanym czasem odjazdu. Okres przedodjazdowy zaczyna się o planowym czasie odjazdu minus czas delta, a kończy się o planowanym czasie odjazdu.
Dane pierwotne	Dane podstawowe jako wejściowe dane odniesienia dla komunikatów lub jako podstawa dla realizacji funkcji i obliczania danych pochodnych.
Przekazanie do eksploatacji	Procedura zależna od technicznego zatwierdzenia wagonu oraz umowy z RU na użytkowanie, pozwalająca na zawodową eksploatację wagonu.
Przewoźnik kolejowy (RU)	Przewoźnik kolejowy (ang. Railway Undertaking) oznacza dowolne publiczne lub prywatne przedsiębiorstwo, którego główna działalność polega na świadczeniu usług przewozu towarów i/lub osób koleją przy wymaganiu, że przedsiębiorstwo to musi zapewnić trakcję; obejmuje to również przedsiębiorstwa, które dostarczają wyłącznie trakcję.
RAMS	Patrz: Niezawodność, dostępność, naprawialność, bezpieczeństwo.
RARP	Odwrotny protokół rozróżniania adresów (ang. Reverse Address Resolution Protocol)
Data/czas zwolnienia	Data/czas, kiedy spodziewane jest zwolnienie towaru lub kiedy towar został zwolniony przez klienta.
Czas zwolnienia wagonów	Data/czas, kiedy wagony są gotowe do zabrania z podanego miejsca na bocznicy klienta.
Niezawodność, dostępność, naprawialność, bezpieczeństwo (RAMS)	Niezawodność - wyrażona matematycznie zdolność do rozpoczęcia i kontynuowania działania w wyznaczonych warunkach przez wyznaczony okres czasu. Dostępność - wyrażony matematycznie czas działania w stosunku do czasu wyłączenia z eksploatacji. Naprawialność - wyrażona matematycznie zdolność systemu do przywrócenia do eksploatacji po awarii. Bezpieczeństwo - wyrażone matematycznie prawdopodobieństwo zainicjowania przez system niebezpiecznego zdarzenia.
Punkt raportowania	Miejsce na trasie przejazdu pociągu, w którym odpowiedzialny IM musi przekazać do RU, który ma zakontraktowaną trasę, "komunikat prognozy jazdy pociągu" wraz z TETA.
Repozytorium	Repozytorium jest podobne do bazy danych i słownika danych, jednakże zwykle obejmuje ono obszerne środowisko systemów zarządzania informacjami. Musi zawierać nie tylko opisy struktur danych (tj. jednostek i elementów), lecz również interesujące dla przedsiębiorstwa metadane, ekrany danych, raporty, programy i systemy. Zazwyczaj zawiera wewnętrzny zestaw oprogramowania narzędziowego, system zarządzania bazą danych (DBMS), metamodel, wypełnione metadane oraz oprogramowanie umożliwiające dostęp do danych w repozytorium oraz ich wprowadzanie.
RID	Przepisy dotyczące międzynarodowego przewozu koleją niebezpiecznych towarów.
Numer RID	Numer OTIF dla niebezpiecznego towaru.
RIV	Przepisy dotyczące wzajemnego użytkowania wagonów w ruchu międzynarodowym. Przepisy dotyczące wzajemnego użytkowania urządzenia załadowczego, kontenera i palet w ruchu międzynarodowym.
Droga	Geograficzna droga, która ma być przebyta od punktu początkowego do punktu docelowego.
Odcinek drogi	Część drogi.
RPC	Zdalne wywołanie procedur (ang. Remote Procedure Call) Protokół RPC jest określony w specyfikacji protokołu RPC, wersja 2 [RFC1831].
RU	Patrz: Przewoźnik kolejowy
Planowy czas odjazdu	Data i czas odjazdu, na które żądana jest trasa.
Planowy rozkład jazdy	Chronologicznie określone zajęcie infrastruktury kolejowej dla ruchu pociągu na otwartej linii lub na stacjach. Zmiany rozkładów jazdy będą dostarczane przez IM co najmniej 2 dni przed początkiem dnia, w którym pociąg odjeżdża ze swojego punktu początkowego. Rozkład jazdy stosuje się do określonego dnia. W niektórych krajach znany jest pod nazwą "Operacyjnego rozkładu jazdy".
Dostawca usług	Przewoźnik odpowiedzialny za określony etap transportu. Strona, która odbiera lub obsługuję rezerwację.
Przesyłka	Pakiet towaru od jednego nadawcy do jednego odbiorcy, który jest załadowany na jedną lub więcej kompletnych jednostek IM bądź na jeden lub więcej kompletnych wagonów. Np.: *

grafika

Pilne zamówienie trasy	Indywidualne żądanie trasy zgodnie z art. 23 dyrektywy 2001/14/WE, z powodu dodatkowych potrzeb transportowych lub operacyjnych.
ZALECA SIĘ	Słowo to lub przymiotnik "ZALECANE" oznacza, że w określonych okolicznościach mogą istnieć zasadne powody do pominięcia danego elementu, lecz przed wybraniem innego kierunku działania należy poznać i dokładnie rozważyć pełne konsekwencje.
NIE ZALECA SIĘ	Zwrot ten lub określenie "NIEZALECANE" oznacza, że w określonych okolicznościach mogą istnieć zasadne powody, kiedy określone postępowanie jest dopuszczalne lub nawet pożyteczne, lecz przed realizacją tak opisanego postępowania należy poznać pełne konsekwencje i dokładnie rozważyć przypadek.
SMTP	Prosty protokół przesyłania poczty (ang. Simple Mail Transfer Protocol)
SNMP	Prosty protokół zarządzania siecią (ang. Simple Network Management Protocol)
SQL	Strukturalny język zapytań (ang. Structured Query Language) Stworzony przez IBM, a następnie znormalizowany przez ANSI i ISO język, który służy do tworzenia, zarządzania i wyszukiwania danych w relacyjnych bazach danych.
Zaangażowany podmiot	Każda osoba lub organizacja o uzasadnionym zainteresowaniu dostawą usług kolejowych, np.: przewoźnik kolejowy (RU), dostawca usług monitorowania przesyłek, dostawca lokomotyw, dostawca wagonów, dostawca maszynistów/załóg pociągu, dostawca górek rozrządowych, dostawca mechanizmów zwrotnicowych, integrator usług, dostawca automatów biletowych (IM), kontroler pociągów (IM), zarządca ruchu, zarządca floty pojazdów dostawca usług promowych, inspektor wagonów i lokomotyw, dostawca usług naprawczych wagonów i lokomotyw, zarządca przesyłek, dostawca usług manewrowych i rozrządowych, dostawca usług logistycznych, odbiorca, nadawca, Dodatkowo dla jednostek intermodalnych: dostawca kontenerów, operator terminalu intermodalnego, dostawca platform/firma przewozowa, parowiec, linie barkowe.
TCP	Protokół sterowania transmisją (ang. Transmission Control Protocol)
Specyfikacja techniczna dla interoperacyjności	Oznacza specyfikacje, które obejmują podsystem lub jego część w celu spełnienia wymagań zasadniczych oraz zapewnienia interoperacyjności transeuropejskiego systemu kolei konwencjonalnej.
TETA	Patrz: Szacowany czas przyjazdu pociągu (ang. Train Estimated Time of Arrival)
Odtwarzanie przemieszczania	Działanie podjęte na żądanie znalezienia i zrekonstruowania historii transportu danej przesyłki, pojazdu, sprzętu, paczki lub ładunku.
Śledzenie	Działanie polegające na systematycznym monitorowaniu i rejestrowaniu aktualnego położenia i statusu danej przesyłki, pojazdu, sprzętu, paczki lub ładunku.
Szacowany czas przyjazdu pociągu	Szacowany czas przyjazdu pociągu do określonego punktu, np. punktu przekazania, punktu wymiany lub punktu docelowego pociągu.
Trasa pociągu	Droga przejazdu pociągu określona w czasie i przestrzeni.
Trasa pociągu/znaczniki czasowe	Określenie drogi przejazdu pociągu za pomocą czasu i miejsc (punktów znacznikowych), w których będzie się ona zaczynać i kończyć, wraz ze szczegółowymi danymi o tych miejscach na drodze, które pociąg minie lub w których zatrzyma się. Dane te mogą również zawierać wszelkie działania, które pociąg wykona po drodze, takie jak zmiana załogi pociągu, lokomotywy lub inne zmiany składu.
Transeuropejska sieć kolejowa	Sieć kolejowa opisana w załączniku 1 do dyrektywy 2001/16/WE.
Przeładunek	Operacja przenoszenia elementów ładunku towarowego lub jednostkowych ładunków z jednego pojazdu na drugi lub do i z magazynu.
Plan przemieszczania	Przedstawia planowaną podróż wzorcową wagonu lub jednostki intermodalnej.
TSI	Patrz: Specyfikacja techniczna dla interoperacyjności
Tunelowanie	Proces, za pomocą którego prywatne pakiety IP zostają zawarte w publicznym pakiecie IP.
UDP	Protokół datagramów użytkownika (ang. User Datagram Protocol) STUN (proste przeglądanie protokołu datagramów użytkownika (UDP) poprzez translatory adresów sieciowych (NAT)) jest lekkim protokołem, który pozwala na wykrywanie przez aplikacje obecności i typów NAT-ów i zapór ogniowych (firewalls) pomiędzy nimi a publicznym Internetem. Daje także możliwość określania przez aplikacje publicznych adresów protokołu internetowego (IP) przydzielonych im przez NAT. STUN współpracuje z wieloma istniejącymi NAT-ami i nie wymaga od nich żadnego szczególnego zachowania. W efekcie pozwala on na współpracę całego szeregu aplikacji z istniejącą infrastrukturą NAT.
UIC	UIC jest to międzynarodowy związek kolejowy.
UITP	UITP jest to międzynarodowy organ współpracy operatorów ruchu.
Numer UN	Numer ONZ dla niebezpiecznego towaru.
UNIFE	UNIFE jest to organizacja, która dba o interesy dostawców dla sektora kolejowego. Aktualnie około 100 dostawców i poddostawców jest reprezentowanych bezpośrednio, a około 1 000 pośrednio poprzez organizacje krajowe.
Wykorzystana pojemność jednostki	Kod używany do podawania, w jakim stopniu sprzęt jest załadowany lub pusty (np. pełny, pusty, LCL).
Ładunek jednostkowy	Pewna ilość indywidualnych paczek połączonych, spaletyzowanych lub powiązanych ze sobą z utworzeniem pojedynczej jednostki w celu sprawniejszego przenoszenia przez urządzenia mechaniczne.
Pociąg marszrutowy	Pociąg towarowy odprawiony tylko z jednym kwitem konsygnacyjnym i tylko jednym rodzajem towaru oraz złożony z jednakowych wagonów jadących od nadawcy do odbiorcy bez pośredniego zestawiania.
VPN	Wirtualna sieć prywatna (ang. Virtual Private Network) Określenie "wirtualna sieć prywatna" służy do opisu niemal dowolnego systemu zdalnej łączności, takiego jak publiczna sieć telefoniczna oraz stałe kanały wirtualne typu Frame Relay (Frame Relay PVC). Wraz z wprowadzeniem Internetu wirtualna sieć prywatna stała się równoznaczna z sieciową łącznością danych opartą na protokole IP. W uproszczeniu VPN składa się z dwu lub więcej sieci prywatnych, które komunikują się w bezpieczny sposób poprzez sieć publiczną. VPN może istnieć pomiędzy indywidualną maszyną i siecią prywatną (klientserwer) lub pomiędzy odległą siecią lokalną i siecią prywatną (serwer-serwer). Sieci prywatne mogą łączyć się przez tunelowanie. VPN powszechnie wykorzystuje Internet jako podstawową sieć transportową, lecz szyfruje dane przesyłane pomiędzy klientem VPN a bramą VPN, aby uniemożliwić ich odczytanie nawet w przypadku ich przechwycenia podczas przesyłania.
Przesyłka wagonowa	Ładunek jednostkowy, gdy jednostką jest wagon.
Zamówienie wagonu	Podzbiór listu przewozowego, który podaje dla RU istotne informacje potrzebne mu do prowadzenia transportu w okresie jego odpowiedzialności, aż do przekazania jej następnemu RU. Polecenie transportu przesyłki wagonowej.
Ceduła przewozowa	Dokument wystawiony przez przewoźnika lub w imieniu przewoźnika, stanowiący dowód zawarcia umowy o przewóz ładunku.
Web	Sieć ogólnoświatowa (WWW) Usługa internetowa, która łączy dokumenty poprzez udostępnienie hipertekstowych łączy (linków) pomiędzy serwerami, tak aby użytkownik mógł przechodzić z jednego dokumentu do innego związanego z nim dokumentu bez względu na to, gdzie jest on przechowany w Internecie.
XDR	Zewnętrzna reprezentacja danych (ang. External Data Representation) Protokół XDR jest wyspecyfikowany w standardzie XDR [RFC1832]. XDR jest standardem opisu i kodowania danych, przydatnym przy przesyłaniu danych pomiędzy różnymi architekturami komputerowymi. XDR wpisuje się w warstwę prezentacji danych modelu ISO i jest w przybliżeniu analogiczny pod względem celu z notacją dla składni abstrakcyjnej ISO - X.409. Główna różnica pomiędzy nimi polega na tym, że XDR używa zapisywania niejawnego, natomiast X.409 - jawnego. XDR używa języka do opisu formatów danych. Język ten może być używany tylko do opisywania danych; nie jest on językiem programowania. Język ten pozwala na opisywanie złożonych formatów danych w zwięzły sposób. Alternatywa polegająca na używaniu przedstawień graficznych (sama będąc nieformalnym językiem) szybko staje się niezrozumiała, gdy napotka złożoność. Sam język XDR jest podobny do języka C. Protokoły takie jak ONC RPC (zdalne wywołanie procedur) oraz NFS (sieciowy system plików) używają XDR do opisywania formatu swoich danych. Standard XDR opiera się na założeniu, że bajty (lub oktety) są przenośne, przy czym bajt jest zdefiniowany jako 8 bitów danych. Dane urządzenie sprzętowe powinno kodować bajty na różne nośniki w taki sposób, aby inne urządzenia sprzętowe mogły dekodować te bajty bez utraty znaczenia.
XML-RPC	XML-RPC jest to protokół zdanego wywołania procedur oparty o język XML (Extensible Mark-up Language), który działa poprzez Internet. Określa on format XML dla komunikatów przesyłanych pomiędzy klientami i serwerami przy użyciu HTTP. Komunikat XML-RPC koduje albo procedurę, która ma być wywołana przez serwer, wraz z parametrami używanymi przy wywołaniu, albo wynik wywołania. Parametrami i wynikami procedury mogą być skalary, liczby, ciągi, daty itp.; mogą to również być złożone struktury rekordów i list. Niniejszy dokument określa, w jaki sposób używać protokołu BEEP (Blocks Extensible Exchange Protocol) do przesyłania pomiędzy klientami i serwerami komunikatów zakodowanych w formacie XML-RPC.
XQL	Rozszerzony strukturalny język zapytań (ang. Extended Structured Query Language)
⁽¹⁾ Dz.U. L 156 z 28.6.1969, str. 1. Rozporządzenie ostatnio zmienione rozporządzeniem (EWG) nr 1893/91 (Dz.U. L 169 z 29.6.1991, str. 1).

1 Art. 4a dodany przez art. 1 rozporządzenia nr 328/2012 z dnia 17 kwietnia 2012 r. (Dz.U.UE.L.12.106.14) zmieniającego nin. rozporządzenie z dniem 8 maja 2012 r.

2 Art. 4b dodany przez art. 1 rozporządzenia nr 328/2012 z dnia 17 kwietnia 2012 r. (Dz.U.UE.L.12.106.14) zmieniającego nin. rozporządzenie z dniem 8 maja 2012 r.

3 Art. 4c dodany przez art. 1 rozporządzenia nr 328/2012 z dnia 17 kwietnia 2012 r. (Dz.U.UE.L.12.106.14) zmieniającego nin. rozporządzenie z dniem 8 maja 2012 r.

4 Załącznik zmieniony przez art. 2 pkt 1 oraz pkt 3-10 rozporządzenia nr 328/2012 z dnia 17 kwietnia 2012 r. (Dz.U.UE.L.12.106.14) zmieniającego nin. rozporządzenie z dniem 8 maja 2012 r.

5 Załącznik A:

-zmieniony przez art. 2 pkt 2 rozporządzenia nr 328/2012 z dnia 17 kwietnia 2012 r. (Dz.U.UE.L.12.106.14) zmieniającego nin. rozporządzenie z dniem 8 maja 2012 r.

- zmieniony przez art. 1 rozporządzenia nr 280/2013 z dnia 22 marca 2013 r. (Dz.U.UE.L.13.84.17) zmieniającego nin. rozporządzenie z dniem 24 marca 2013 r.

Zmiany w prawie

Stosunek prezydenta Dudy do wolnej Wigilii "uległ zawieszeniu"

Prezydent Andrzej Duda powiedział w czwartek, że ubolewa, że w sprawie ustawy o Wigilii wolnej od pracy nie przeprowadzono wcześniej konsultacji z prawdziwego zdarzenia. Jak dodał, jego stosunek do ustawy "uległ niejakiemu zawieszeniu". Wyraził ubolewanie nad tym, że pomimo wprowadzenia wolnej Wigilii, trzy niedziele poprzedzające święto mają być dniami pracującymi. Ustawa czeka na podpis prezydenta.

kk/pap 12.12.2024

ZUS: Renta wdowia - wnioski od stycznia 2025 r.

Od Nowego Roku będzie można składać wnioski o tzw. rentę wdowią, która dotyczy ustalenia zbiegu świadczeń z rentą rodzinną. Renta wdowia jest przeznaczona dla wdów i wdowców, którzy mają prawo do co najmniej dwóch świadczeń emerytalno-rentowych, z których jedno stanowi renta rodzinna po zmarłym małżonku. Aby móc ją pobierać, należy jednak spełnić określone warunki.

Grażyna J. Leśniak 20.11.2024

Zmiany w składce zdrowotnej od 1 stycznia 2026 r. Rząd przedstawił założenia

Przedsiębiorcy rozliczający się według zasad ogólnych i skali podatkowej oraz liniowcy będą od 1 stycznia 2026 r. płacić składkę zdrowotną w wysokości 9 proc. od 75 proc. minimalnego wynagrodzenia, jeśli będą osiągali w danym miesiącu dochód do wysokości 1,5-krotności przeciętnego wynagrodzenia w sektorze przedsiębiorstw w czwartym kwartale roku poprzedniego, włącznie z wypłatami z zysku, ogłaszanego przez prezesa GUS. Będzie też dodatkowa składka w wysokości 4,9 proc. od nadwyżki ponad 1,5-krotność przeciętnego wynagrodzenia, a liniowcy stracą możliwość rozliczenia zapłaconych składek w podatku dochodowym.

Grażyna J. Leśniak 18.11.2024

Prezydent podpisał nowelę ustawy o rozwoju lokalnym z udziałem lokalnej społeczności

Usprawnienie i zwiększenie efektywności systemu wdrażania Rozwoju Lokalnego Kierowanego przez Społeczność (RLKS) przewiduje ustawa z dnia 11 października 2024 r. o zmianie ustawy o rozwoju lokalnym z udziałem lokalnej społeczności. Jak poinformowała w czwartek Kancelaria Prezydenta, Andrzej Duda podpisał ją w środę, 13 listopada. Ustawa wejdzie w życie z dniem następującym po dniu ogłoszenia.

Grażyna J. Leśniak 14.11.2024

Do poprawki nie tylko emerytury czerwcowe, ale i wcześniejsze

Problem osób, które w latach 2009-2019 przeszły na emeryturę w czerwcu, przez co - na skutek niekorzystnych zasad waloryzacji - ich świadczenia były nawet o kilkaset złotych niższe od tych, jakie otrzymywały te, które przeszły na emeryturę w kwietniu lub w maju, w końcu zostanie rozwiązany. Emerytura lub renta rodzinna ma - na ich wniosek złożony do ZUS - podlegać ponownemu ustaleniu wysokości. Zdaniem prawników to dobra regulacja, ale równie ważna i paląca jest sprawa wcześniejszych emerytur. Obie powinny zostać załatwione.

Grażyna J. Leśniak 06.11.2024

Bez konsultacji społecznych nie będzie nowego prawa

Już od jutra rządowi trudniej będzie, przy tworzeniu nowego prawa, omijać proces konsultacji publicznych, wykorzystując w tym celu projekty poselskie. W czwartek, 31 października, wchodzą w życie zmienione przepisy regulaminu Sejmu, które nakazują marszałkowi Sejmu kierowanie projektów poselskich do konsultacji publicznych i wymagają sporządzenia do nich oceny skutków regulacji. Każdy obywatel będzie mógł odtąd zgłosić własne uwagi do projektów poselskich, korzystając z Systemu Informacyjnego Sejmu.

Grażyna J. Leśniak 30.10.2024

Identyfikator:	Dz.U.UE.L.2006.13.1
Rodzaj:	Rozporządzenie
Tytuł:	Rozporządzenie 62/2006 dotyczące technicznej specyfikacji dla interoperacyjności odnoszącej się do podsystemu aplikacji telematycznych dla przewozów towarowych transeuropejskiego systemu kolei konwencjonalnych
Data aktu:	23/12/2005
Data ogłoszenia:	18/01/2006
Data wejścia w życie:	19/01/2006

Rozporządzenie 62/2006 dotyczące technicznej specyfikacji dla interoperacyjności odnoszącej się do podsystemu aplikacji telematycznych dla przewozów towarowych transeuropejskiego systemu kolei konwencjonalnych

ROZPORZĄDZENIE KOMISJI (WE) 62/2006 z dnia 23 grudnia 2005 r. dotyczące technicznej specyfikacji dla interoperacyjności odnoszącej się do podsystemu aplikacji telematycznych dla przewozów towarowych transeuropejskiego systemu kolei konwencjonalnych (Tekst mający znaczenie dla EOG)

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

Załącznik A 5 WYKAZ ZAŁĄCZONYCH DOKUMENTÓW

Załącznik B GLOSARIUSZ

Zmiany w prawie

Dz.U.UE.L.2006.13.1

ROZPORZĄDZENIE KOMISJI (WE) 62/2006

z dnia 23 grudnia 2005 r.

dotyczące technicznej specyfikacji dla interoperacyjności odnoszącej się do podsystemu aplikacji telematycznych dla przewozów towarowych transeuropejskiego systemu kolei konwencjonalnych

(Tekst mający znaczenie dla EOG)

ZAŁĄCZNIK 4

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

Załącznik A

5 WYKAZ ZAŁĄCZONYCH DOKUMENTÓW

Załącznik B

GLOSARIUSZ