ZAŁĄCZNIK

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

SPIS TREŚCI:

1.

WSTĘP

1.1.	Zakres techniczny

1.2.	Zakres geograficzny

1.3.	Zawartość niniejszej TSI

2.	DEFINICJA PODSYSTEMU/ZAKRES

2.1.	Funkcja w zakresie TSI

2.2.	Funkcje poza zakresem TSI

2.3.	Przegląd opisu podsystemu

2.3.1.

Uczestniczące jednostki

2.3.2.

Rozpatrywane procesy

2.3.3.

Uwagi ogólne

3.	WYMAGANIA ZASADNICZE

3.1.	Spełnienie wymagań zasadniczych

3.2.	Aspekty wymagań zasadniczych

3.3.	Aspekty związane z wymaganiami ogólnymi

3.3.1.

Bezpieczeństwo

3.3.2.

Niezawodność i dostępność

3.3.3.

Zdrowie

3.3.4.

Ochrona środowiska

3.3.5.

Zgodność techniczna

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

3.4.1.

Zgodność techniczna

3.4.2.

Niezawodność i dostępność

3.4.3.

Zdrowie

3.4.4.

Bezpieczeństwo

4.	CHARAKTERYSTYKA PODSYSTEMU

4.1.

Wstęp

4.2.	Specyfikacje funkcjonalne i techniczne podsystemu

4.2.1.

Dane listu przewozowego

4.2.2.

Żądanie trasy

4.2.3.

Przygotowanie pociągu

4.2.4.

Prognoza jazdy pociągu

4.2.5.

Informacja o zakłóceniu służby

4.2.6.

Położenie pociągu

4.2.7.

ETI/ETA przesyłki

4.2.8.

Ruch wagonów

4.2.9.

Raportowanie o wymianie

4.2.10.

Wymiana danych dla poprawy jakości

4.2.11.

Pierwotne dane źródłowe

4.2.12.

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

4.2.13.

Elektroniczne przesyłanie dokumentów

4.2.14.

Łączność sieciowa i komunikacja

4.3.	Specyfikacje funkcjonalne i techniczne interfejsów

4.3.1.

Interfejsy z TSI „Infrastruktura”

4.3.2.

Interfejsy z TSI „Sterowanie ruchem kolejowym”

4.3.3.

Interfejsy z podsystemem „Tabor kolejowy”

4.3.4.

Interfejsy z TSI „Ruch kolejowy”

4.4.	Zasady operacyjne

4.4.1.

Jakość danych

4.4.2.

Obsługa centralnego repozytorium

4.5.	Zasady utrzymania

4.6.	Kwalifikacje zawodowe

4.7.	Warunki BHP

4.8.	Rejestry infrastruktury i taboru kolejowego

5.	SKŁADNIKI INTEROPERACYJNOŚCI

5.1.

Definicja

5.2.	Wykaz składników

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

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

6.1.	Składniki interoperacyjności

6.1.1.

Procedury oceny

6.1.2.

Moduł

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

7.

WDROŻENIE

7.1.	Modalności stosowania niniejszej TSI

7.1.1.

Wstęp

7.1.2.

Strategiczny Europejski Plan Rozwoju (SEDP)

7.1.3.

Modalności wdrażania

7.2.	Strategia migracji

7.3.	Zarządzanie zmianą

7.3.1.

Wstęp

7.3.2.

Ustalanie poziomu bazowego

7.3.3.

Wydanie poziomu bazowego

7.3.4.

Rozwój nowych poziomów bazowych

7.3.5.

Proces zarządzania zmianą – wymagania

7.3.6.

Plan zarządzania konfiguracją – wymagania

7.4.	Szczególne przypadki

7.4.1.

Wstęp

7.4.2.

Wykaz szczególnych przypadków

ZAŁĄCZNIK A:

WYKAZ DOŁĄCZONYCH DOKUMENTÓW

ZAŁĄCZNIK B:

GLOSARIUSZ

TABELE:

Tabela 1:

Żądanie trasy

Tabela 2:

Anulowanie trasy przez RU

Tabela 3:

Anulowanie trasy przez IM

Tabela 4:

Potwierdzenie otrzymania

Tabela 5:

Przygotowanie pociągu

Transeuropejski system kolei konwencjonalnej

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

1.   WSTĘP

1.1.   Zakres techniczny

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

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

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

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

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

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

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

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

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

1.2.   Zakres geograficzny

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

1.3.   Zawartość niniejszej TSI

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

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

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

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

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

e)

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

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

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

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

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

2.   DEFINICJA PODSYSTEMU/ZAKRES

2.1.   Funkcja w zakresie TSI

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

Obejmuje on w szczególności:

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

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

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

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

2.2.   Funkcje poza zakresem TSI

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

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

2.3.   Przegląd opisu podsystemu

2.3.1.   Uczestniczące jednostki

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

—

wagony,

—	lokomotywy,

—	maszyniści,

—	manewrowanie i rozrządzanie,

—	sprzedaż automatów biletowych,

—	zarządzanie przesyłką,

—	skład pociągu,

—	prowadzenie pociągu,

—	monitorowanie pociągu,

—	sterowanie pociągiem,

—	monitorowanie przesyłki,

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

—	odprawa celna,

—	obsługa terminali intermodalnych,

—	zarządzanie przewozami.

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

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

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:

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

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

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

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

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

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

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

2.3.2.   Rozpatrywane procesy

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

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

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

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

—

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.3.3.   Uwagi ogólne

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

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

—	identyfikacja taboru,

—	dane techniczne/projektowe,

—	ocena zgodności z infrastrukturą,

—	ocena istotnych charakterystyk obciążenia,

—	istotne charakterystyki hamulców,

—	dane dotyczące konserwacji i utrzymania,

—	charakterystyki środowiskowe.

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

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

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

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

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

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

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

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

3.   WYMAGANIA ZASADNICZE

3.1.   Spełnienie wymagań zasadniczych

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

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

3.2.   Aspekty wymagań zasadniczych

Wymagania zasadnicze dotyczą:

—	bezpieczeństwa,

—	niezawodności i dostępności,

—

zdrowia,

—	ochrony środowiska,

—	zgodności technicznej.

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

3.3.   Aspekty związane z wymaganiami ogólnymi

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

3.3.1.   Bezpieczeństwo

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

—

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

—

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

—

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

—

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

—

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

3.3.2.   Niezawodność i dostępność

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

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

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

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

3.3.3.   Zdrowie

—

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

—

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

3.3.4.   Ochrona środowiska

—

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

—

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

—

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

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

—

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

3.3.5.   Zgodność techniczna

—

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

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

3.4.1.   Zgodność techniczna

—

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

3.4.2.   Niezawodność i dostępność

—

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

3.4.3.   Zdrowie

—

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

3.4.4.   Bezpieczeństwo

—

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

4.   CHARAKTERYSTYKA PODSYSTEMU

4.1.   Wstęp

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

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

4.2.   Specyfikacje funkcjonalne i techniczne podsystemu

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

—	dane listu przewozowego,

—	żądanie trasy,

—	przygotowanie pociągu,

—	prognoza jazdy pociągu,

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

—	lokalizacja pociągu,

—	ETI/ETA wagonów/jednostek intermodalnych,

—	ruch wagonów,

—	raportowanie o wymianie,

—	wymiana danych dla poprawy jakości,

—	pierwotne dane źródłowe,

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

—	elektroniczne przesyłanie dokumentów,

—	łączność sieciowa i komunikacja.

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

Ogólne uwagi na temat struktury komunikatów

Komunikaty są podzielone na dwa zbiory danych:

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

—	Dane informacyjne: informacje o aplikacji

Dane kontrolne pokazują następujące elementy:

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

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

—

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

—	Wysyłający komunikat

—	Odbiorca komunikatu

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

4.2.1.   Dane listu przewozowego

4.2.1.1.   List przewozowy klienta

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

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

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

4.2.1.2.   Zamówienia wagonów

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

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

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

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

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

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

—	dane dotyczące nadawcy i odbiorcy,

—	dane dotyczące przebiegu trasy,

—	identyfikacja przesyłki,

—	dane o wagonach,

—	dane o miejscu i czasie.

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

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

—	numer CN/HS,

—	informacja o niebezpiecznych towarach,

—	jednostka transportu.

4.2.2.   Żądanie trasy

4.2.2.1.   Uwagi wstępne

Planowanie długoterminowe

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

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

Głównymi danymi trasy muszą być:

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

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

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

—

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

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

Pilne żądanie trasy

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

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

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

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

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

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

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

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

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

Tabela 1

Żądanie trasy

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

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

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

Tabela 2

Anulowanie trasy przez RU

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

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

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

Tabela 3

Anulowanie trasy przez IM

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

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

Tabela 4

Potwierdzenie otrzymania

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

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

4.2.2.2.   Komunikat „Żądanie trasy”

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

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

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

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

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

—

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

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

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

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

4.2.2.3.   Komunikat „Dane o trasie”

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

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

—	nowy numer trasy,

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

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

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

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

—

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

4.2.2.4.   Komunikat „Trasa potwierdzona”

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

—	numer trasy w celu identyfikacji trasy,

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

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

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

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

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

4.2.2.5.   Komunikat „Odmowa danych o trasie”

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

—	numer trasy w celu identyfikacji trasy,

—	oznaczają odmowę danych o trasie.

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

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

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

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

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

4.2.2.6.   Komunikat „Trasa anulowana”

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

—	numer trasy w celu identyfikacji trasy,

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

—	oznacza anulowanie zarezerwowanej trasy pociągu.

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

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

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

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

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

4.2.2.7.   Komunikat „Trasa niedostępna”

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

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

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

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

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

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

—	podanie przyczyny.

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

4.2.2.8.   Komunikat „Potwierdzenie odbioru”

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

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

4.2.3.   Przygotowanie pociągu

4.2.3.1.   Uwagi ogólne

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

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

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

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

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

Tabela 5

Przygotowanie pociągu

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

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

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

4.2.3.2.   Komunikat „Skład pociągu”

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

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

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

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

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

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

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

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

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

—	informacje dotyczące wyjątkowego pomiaru,

—	numery UN/RID niebezpiecznych towarów,

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

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

—	dane o wagonach.

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

4.2.3.3.   Komunikat „Pociąg zaakceptowany”

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

Główna treść tego komunikatu zawiera:

—	numer pociągu i trasy,

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

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

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

4.2.3.4.   Komunikat „Pociąg nie jest odpowiedni”

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

—	numer pociągu i trasy,

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

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

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

—	podanie przyczyny.

4.2.3.5.   Komunikat „Pociąg gotowy”

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

—	numer pociągu i trasy,

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

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

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

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

—

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

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

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

—	numer pociągu i trasy,

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

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

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

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

—	identyfikator kontaktu kontrolnego.

4.2.3.7.   Komunikat „Pociąg na starcie”

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

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

4.2.3.8.   Informacja o jeździe pociągu

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

4.2.4.   Prognoza jazdy pociągu

4.2.4.1.   Uwagi ogólne

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

Stosownymi komunikatami są:

Prognoza jazdy pociągu,

Informacja o jeździe pociągu.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

—	Przyjazd pociągu do punktu docelowego

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

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

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

4.2.4.2.   Komunikat „Prognoza jazdy pociągu”

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

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

Głównymi elementami danych są:

—	numer trasy i numer pociągu,

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

—	identyfikacja punktu raportowania,

—	prognozowane data/czas w punkcie raportowania.

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

Komunikat ten musi być wydany po:

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

—

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

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

4.2.5.1.   Uwagi ogólne

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

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

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

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

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

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

Głównymi elementami tego komunikatu są:

—	numer trasy i pociągu,

—	identyfikacja miejsca,

—	planowa data i czas odjazdu w tym miejscu,

—	powód zakłócenia,

—	opis zakłócenia.

4.2.6.   Położenie pociągu

4.2.6.1.   Wstęp

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

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

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

—	wszystkie identyfikatory określonego pociągu,

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

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

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

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

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

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

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

4.2.6.4.   Komunikaty „Zapytanie o identyfikator pociągu”

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

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

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

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

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

4.2.7.   ETI/ETA przesyłki

4.2.7.1.   Wstępna uwaga

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

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

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

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

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

4.2.7.2.   Obliczanie ETI/ETA

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

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

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

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

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

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

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

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

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

4.2.7.3.   Komunikat „ETI/ETA wagonów”

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

4.2.7.4.   Komunikat „Alert”

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

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

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

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

4.2.8.   Ruch wagonów

4.2.8.1.   Uwagi wstępne

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

—	Powiadomienie o zwolnieniu wagonu

—	Powiadomienie o odjeździe wagonu

—	Przyjazd wagonu do stacji rozrządowej

—	Wyjazd wagonu ze stacji rozrządowej

—	Komunikat o wyjątkowej sytuacji wagonu

—	Powiadomienie o przyjeździe wagonu

—	Powiadomienie o dostawie wagonu

—	Potwierdzenie dostawy wagonu

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

4.2.8.2.   Komunikat „Powiadomienie o zwolnieniu wagonu”

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

4.2.8.3.   Komunikat „Powiadomienie o odjeździe wagonu”

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

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

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

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

Cel	:	RU musi powiadomić LRU, że wagon opuścił jego stację rozrządową. Komunikat ten może być oparty o komunikat „Informacja o jeździe pociągu” z rozdziału 4.2.4 (Prognoza jazdy pociągu). Zdarzenie to musi zostać przechowane w „Operacyjnej bazie danych wagonów i jednostek intermodalnych”.
Główne elementy danych	:	— numer wagonu, — identyfikacja wyjazdu ze stacji rozrządowej, — data i czas wyjazdu ze stacji rozrządowej.

4.2.8.6.   Komunikat „Wyjątkowa sytuacja wagonu”

Cel	:	RU musi powiadomić LRU, jeśli z wagonem zdarzyło się coś 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 (RU 1) pyta następnego przewoźnika kolejowego (RU 2) 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 indeks 2. 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 indeks 2. 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 wymagania 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.

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 indeks 1) 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 jest nastawiona na dostarczanie wsparcia informacyjnego dla procesu zarządzania kolejowym transportem towarowym, które prowadzi do istotnego podniesienia jakości usług transportowych. W takim rozumieniu jej stosowanie jest niezależne od pojęć nowej/zmodernizowanej lub dziedziczonej infrastruktury bądź środków taboru kolejowego, jak jest to zwykle w innej TSI wymaganej przez dyrektywę 2001/16/WE.

Ze względu na wszechogarniający charakter niniejszej TSI jej wpływ na procesy zarządzające i operacyjne całego europejskiego kolejnictwa będzie głęboki. Ponadto ciągły rozwój międzynarodowego transportu towarowego wymaga ogólnoeuropejskiej perspektywy zarządzania informatycznego. Fakty te wspólnie przemawiają za potrzebą stworzenia spójnego transeuropejskiego planu wdrożenia niniejszej TSI. Plan ten powinien zarówno dostarczać wizji tego, co ma być osiągnięte podczas wdrażania TSI, jak i podawać sposób i terminy migracji od obecnych ram podzielonych systemów informatycznych ku wszechstronnej ogólnoeuropejskiej autostradzie informatycznej, która może przynieść dodatkową wartość wszystkim stronom zainteresowanym w dziedzinie transportu kolejowego – zarządcom infrastruktury, przewoźnikom kolejowym, spedytorom przewozowym, a w ostateczności również klientowi.

Osadzona w tym kontekście, zasadna jest koncepcja Strategicznego Europejskiego Planu Rozwoju (SEDP). SEDP określa docelowy system, który ma być osiągnięty w celu wdrożenia niniejszej TSI wraz z będącym jej podstawą planem wdrażania, co opisano w zarysie w poniższym ustępie.

7.1.2.   Strategiczny Europejski Plan Rozwoju (SEDP)

7.1.2.1.   Cele SEDP

Cel Strategicznego Europejskiego Planu Rozwoju (SEDP) jest trojaki:

1)	dostarczenie wizji dla wdrażania TSI TAF w europejskim kolejnictwie;

2)	kwalifikacja takiej wizji z punktu widzenia wykonalności technicznej i ekonomicznej;

3)	ustanowienie mapy drogowej dla działań uznanych za niezbędne do urzeczywistnienia tej wizji.

Oprócz dostarczenia mapy drogowej dla TSI TAF zapewniającej widoczność całego procesu wdrażania, SEDP powinien nadać odpowiednie miary monitorowaniu jego przebiegu przez różnych uczestników, a mianowicie zarządców infrastruktury, przewoźników kolejowych, spedytorów przewozowych i wreszcie klienta w sposób, który może zagwarantować obronę ich najlepszych interesów. Dotyczy to zwłaszcza mobilizowania przez zarządców infrastruktury i przewoźników kolejowych wymaganych inwestycji w potencjalną modernizację i integrację ich dziedziczonych systemów oraz możliwości systemów opartych o TSI TAF w zakresie efektywnego reagowania na stale rozwijające się potrzeby informacji ze strony zarówno spedytorów przewozowych, jak i klientów.

Osadzony w tym kontekście, SEDP powinien ostatecznie stanowić instrument umożliwiający skoncentrowanie całego europejskiego kolejnictwa na celu, jakim jest rozwój ogólnoeuropejskiego systemu informatycznego, pozwalając jednocześnie na promocję synergii, unikanie fragmentacji oraz skupienie ograniczonych środków na tych priorytetowych kwestiach, które lepiej odpowiadają nadrzędnym celom jakości usług transportowych.

7.1.2.2.   Wymagania SEDP

Opracowanie takiego planu wymagać będzie systematycznej analizy odpowiednich zagadnień technicznych, operacyjnych, ekonomicznych i instytucjonalnych będących podstawą procesu wdrażania TSI TAF. Obejmuje to w szczególności:

1.	Inwentaryzację stosownych dziedziczonych aplikacji informatycznych, które mogą stanowić podstawę dla zbudowania ogólnoeuropejskiego systemu mogącego sprostać wymaganiom TSI TAF (zwanego dalej systemem TAF).

2.	Określenie funkcjonalnych oraz związanych z nimi danych i wymagań wydajnościowych niezbędnych do spełnienia TAF TSI.

3.

Naszkicowanie architektury systemu TAF. Winno to być oparte o analizę konfiguracji systemu zdolnych do potencjalnej integracji dziedziczonych systemów informatycznych przy jednoczesnym zapewnieniu funkcjonalności i wydajności – np. scentralizowanych lub podzielonych architektur klient-serwer, architektur opartych o pośredników.

4.	Ustalenie technicznych i interfejsowych wymagań dla systemu TAF oraz jego potencjalnych podsystemów/systemów klienckich.

5.

Opracowanie ogólnego planu rozwoju systemu TAF w zakresie od koncepcji do dostawy. Powinno to dostarczyć wytycznych dla procesu oraz planowania dla potencjalnej integracji dziedziczonych systemów, a także oceny ryzyka głównych faz takiego planu. Ponadto, powinno to uwzględniać trwającą i planowaną ewolucję dziedziczonych systemów.

6.	Identyfikację odpowiednich struktur zarządzania będących podstawą rozwoju TAF system, jak również jego obsługi w ciągu całego okresu jego żywotności.

7.	Ocenę całkowitych kosztów cyklu żywotności (LCC) związanych z wdrożeniem i użytkowaniem systemu TAF wraz z dalszym planem inwestycyjnym.

Zamiast przebiegać drogą sekwencyjną, analiza ta powinna rozwijać się na zasadzie iteracyjnej zmierzając do określenia optymalnej strategii rozwinięcia systemu. Taki cykl badawczy powinien w końcowym efekcie prowadzić do następującego konkretnego wyniku:

—	pełnego zestawu specyfikacji funkcjonalnych, wydajnościowych, systemowych i technicznych dla nabycia systemu TAF,

—	programu wdrażania od koncepcji do dostawy. Powinno to obejmować szczegółowe planowanie wszystkich tych faz i głównych indywidualnych działań, które prowadzą do przyczyniają się do osiągnięcia końcowych celów,

—	określenia struktury zarządzania (7) leżących u podstaw opracowania, walidacji i użytkowania systemu,

—	planu inwestycyjnego oraz następnej metody finansowo-technologicznej umożliwiającej jego realizację.

7.1.3.   Modalności wdrażania

Modalności zastosowania niniejszej TSI podlegają wymaganiom wspomnianego wcześniej Strategicznego Europejskiego Planu Rozwoju (SEDP).

Do celu opracowania SEDP obowiązują następujące wymagania:

—	Przewoźnicy kolejowi i zarządcy infrastruktury wnoszą wkład przez dostarczenie funkcjonalnych i technicznych informacji o istniejących aplikacjach telematycznych dla przewozu towarowego (8).

—

Organy przedstawicielskie z sektora kolejowego działające na poziomie europejskim, jak określono w art. 3 ust. 2 rozporządzenia (WE) nr 881/2004, ustanawiają Strategiczny Europejski Plan Rozwoju określony w poprzednim ustępie. Przekazują one ten strategiczny plan Państwom Członkowskim i Komisji nie później niż jeden rok od dnia opublikowania tego rozporządzenia. Jeżeli po tym okresie czasu nie zostanie zaobserwowany znaczący postęp, zadanie zostanie przejęte przez Komisję Europejską, która następnie zaproponuje projekt ustawodawczy dla wdrożenia niniejszej TSI.

—

Z chwilą zakończenia strategicznego planu wszystkie działania związane z wdrażaniem podsystemu „Telematyczna aplikacja dla przewozów towarowych” muszą zostać uzasadnione w oparciu o ten plan rozwoju. Wszelkie odstępstwo zaproponowane przez RU lub IM powinno zostać uzasadnione w aktach wdrażania przedłożonych Państwu Członkowskiemu, Europejskiej Agencji ds. Kolei oraz WE.

7.2.   Strategia migracji

Strategie migracji zostały stworzone w celu obsługi okresu przejściowego pomiędzy obecnymi ramami zróżnicowanych systemów informatycznych a wypełnieniem niniejszej TSI, jak nakazuje SEDP.

W tym celu opracowane zostały zawarte w niniejszej TSI koncepcje obsługi informacji, aby ułatwić taką migrację. Uwzględniają one stopniowe budowanie docelowego ogólnoeuropejskiego systemu TSI TAF, zwłaszcza poprzez środki takie jak komunikacja peer-to-peer w oparciu np. o koncepcję repozytoriów zbiorczych danych (tzn. obejmujących metadane komunikatów, katalog danych oraz zezwolenie certyfikacyjne).

Ilustracyjny przykład tego, jak mogłaby w praktyce działać wymiana informacji pomiędzy RU a IM podano poniżej. Przykład ten pokazuje tylko logiczne międzysystemowe zależności komunikacyjne zorganizowane w sposób krokowy bez uwzględnienia jakichkolwiek indywidualnych potrzeb migracyjnych, które mogłyby być wymagane przez indywidualne systemy. Te ostatnie potrzeby powinny być należycie wzięte pod uwagę podczas sporządzania SEDP.

Krok 1: Ogólna architektura opisana w rozdziale 4.2.14.1 (Ogólna architektura) urzeczywistnia koncepcję „centralnego repozytorium” obsługiwanego przez niezależną jednostkę. W miejscu każdego uczestnika w sieci komunikacyjnej określona jest dla interoperacyjności warstwa interfejsowa, która może zawierać pośrednika komunikatów i która może być zbudowana centralnie lub indywidualnie. Części te są pod względem „łączności sieciowej i komunikacji” jedynymi aspektami operacyjnymi wymaganymi dla interoperacyjności. Są one także podstawowymi warunkami wstępnymi dla ogólnoeuropejskiej wymiany danych. Dlatego muszą one zostać zrealizowane i zainstalowane, zanim będzie mogła zostać uruchomiona jakakolwiek inna funkcja.

Po tym kroku może już być realizowane elektroniczne przesyłanie dokumentów (rozdział 4.2.13: Elektroniczne przesyłanie dokumentów) niezależnie od logicznej kolejności innych kroków.

Możliwości dostępne po tym kroku dla
IM	RU
Dana jest podstawa dla wymiany informacji. Korzyść:   Możliwe jest elektroniczne przesyłanie dokumentów w końcowym środowisku.   Mogą być dokonywane testy różnych dalszych kroków w rzeczywistym środowisku.

Krok 2: Równocześnie lub wkrótce po kroku 1 muszą być dostępne „Źródłowe bazy danych taboru kolejowego” oraz „Operacyjna baza danych wagonów i jednostek intermodalnych” (rozdział 4.2.11.3: oraz rozdział 4.2.12.2: Inne bazy danych). Jeśli nie wszystkie dane są już w bazach danych, musi być przynajmniej możliwe ręczne wprowadzenie do „Operacyjnej bazy danych wagonów i jednostek intermodalnych” – dla każdego wagonu w jadącym pociągu – danych potrzebnych do transportu kolejowego, które są wymienione w załączniku A indeks 2).

Możliwości dostępne po tym kroku dla
IM	RU
Dostępne są podstawowe informacje w „Operacyjnej bazie danych wagonów i jednostek intermodalnych” oraz „Źródłowej bazie danych taboru kolejowego”. Możliwe ręczne uaktualnienie odpowiednich danych. Korzyść:   Dane jest wsparcie informatyczne dla żądania trasy oraz dla składu pociągu.   Może być zrealizowany łatwy dostęp do danych o taborze kolejowym przez strony trzecie, np. zarządców parku pojazdowego.

Krok 3: Dla zewnętrznego dostępu do różnorodnych baz danych uniwersalny interfejs musi zostać zrealizowany i zaimplementowany równolegle lub wkrótce po kroku 2.

Możliwości dostępne po tym kroku dla
IM	RU
Przygotowana jest baza danych dla przechowywania informacji o trasie/pociągu. Wprowadzanie danych może rozpocząć się ręcznie. Dostępne jest połączenie online z istniejącymi systemami IM w celu automatycznego wprowadzenia i uaktualnienia. Korzyść:   Dane przychodzących wiadomości mogą być przechowywane, jak dla wersji ostatecznej.	Przygotowana jest baza(-y) danych dla ruchu wagonów/jednostek intermodalnych oraz dla ładunku (ciężar, niebezpieczny towar) wraz z potrzebnymi źródłowymi plikami. Od tej chwili stosowne dane z dostarczonych kwitów konsygnacyjnych (zamówienia wagonu) i/lub dotyczące obecnego składu pociągu mogą być wpisywane ręcznie lub już automatycznie poprzez zewnętrzne połączenie RU z istniejącymi systemami do rejestracji kwitów konsygnacyjnych i do rejestracji składu pociągów. Możliwe jest sprawdzenie danych o wagonach ze „Źródłowymi bazami danych taboru kolejowego”, jak również ocena danych o pociągu z danymi o infrastrukturze. Korzyść:   Wsparcie dla tworzenia składu pociągu.   Dane przychodzących wiadomości mogą być przechowywane, jak dla wersji ostatecznej.

Dla następnych kroków należy zaznaczyć, że proponowana architektura pozwala na bezproblemowe uruchomienie różnorodnych funkcji w celu spełnienia wymagań podsystemu „Aplikacje telematyczne dla przewozów towarowych”. W oparciu o centralne repozytorium (metadane komunikatów, katalog i zezwolenie certyfikacyjne) możliwe jest uaktywnienie wymiany danych pomiędzy dwoma partnerami indywidualnie w zależności od typu wiadomości.

Krok 4: Komunikaty „Żądania trasy” mogą być zaimplementowane niezależnie od następnych kroków, lecz dla kroku 6 niezbędne jest, aby trasa została już nazwana za pomocą numeru trasy.

Możliwości dostępne po tym kroku dla
IM	RU
Automatyczne wprowadzanie danych do bazy danych dla przechowywania informacji o trasie/pociągu. Telematycznie wsparte określenie trasy w połączeniu z „Bazami danych powiadomień o ograniczeniach w infrastrukturze”. Korzyść:   Szybsze reakcje na żądania trasy, lepiej dostosowane do zapotrzebowania użytkowanie trasy, większa rzetelność danych charakterystyki trasy (aktualny status w „Bazie danych powiadomień o ograniczeniach w infrastrukturze”), poprawa wykorzystania infrastruktury.	Możliwe jest pilne żądanie trasy Korzyść:   Możliwe jest żądanie trasy lepiej odpowiadające zapotrzebowaniu. Szybsza reakcja IM na żądania trasy. Większa rzetelność danych charakterystyki trasy. Skrócenie czasów obrotu wagonami.

Krok 5: Dane zamówień wagonów dostarczają podstawowych informacji o składzie pociągu, dlatego komunikaty te powinny zostać uruchomione przed krokiem 6.

Możliwości dostępne po tym kroku dla
IM	RU
Brak dodatkowych możliwości	Automatyczne przejęcie danych listu przewozowego do pamięci danych kroku 3. Automatyczne generowanie i wysyłanie zamówień wagonów do współpracujących RU. Korzyść:   Szybsze rozprowadzanie zamówień wagonów, skrócony czas obsługi w punktach wymiany.   Wsparcie dla stosowania międzynarodowych umów kupna/sprzedaży.

Krok 6: Następnym krokiem jest wejście do działania komunikatów przygotowania pociągu, przez co wysłanie komunikatu o składzie pociągu jest najważniejsze i powinno zostać zrealizowane najpierw.

Możliwości dostępne po tym kroku dla
IM	RU
Otrzymywanie informacji o składzie pociągu z wyprzedzeniem. Większa rzetelność danych. Wyraźny stempel czasu rozpoczęcia użytkowania trasy. Automatyczne uaktualnianie bazy danych dla przechowywania informacji o trasie/pociągu. Korzyść:   Optymalizacja wykorzystania trasy. Wyraźnie określona odpowiedzialność w czasie rozpoczęcia.	Wysyłanie informacji o składzie pociągu generowane przeważnie automatycznie, duża rzetelność danych, automatyczne uaktualnienie do pamięci danych kroku 3. Korzyść:   Wyraźnie określona odpowiedzialność w czasie rozpoczęcia usługi IM, niezawodny czas startu wagonów/rozpoczęcia przesyłek   Pomoc w minimalizacji wydatków i kosztów poprzez ograniczone pobieranie danych na granicach.   Pomoc w skróceniu czasów przesyłek poprzez zagwarantowane przejmowanie pociągów przez RU i IM   Pomoc w minimalizacji ryzyka podczas przejmowania wagonów.

Krok 7: Najpóźniej przed krokiem 8 powinny zostać zrealizowane na poziomie RU funkcje ruchu wagonów „Powiadomienie o zwolnieniu i odjeździe wagonu, Przyjazd wagonu do stacji rozrządowej, Wyjazd wagonu ze stacji rozrządowej, Powiadomienie o przyjeździe pociągu oraz powiadomienie/potwierdzenie dostawy wagonu” wraz z funkcjonalnością planowania podróży.

Możliwości dostępne po tym kroku dla
IM	RU
Brak dodatkowych możliwości	Możliwe jest informatycznie wsparte planowanie na poziomie wagonu i jednostki intermodalnej. System jest przygotowany do obliczania, wysyłania i odbierania komunikatów o ruchu związanym z wagonami i jednostkami intermodalnymi. Korzyść:   Pierwszy krok do obserwowania i śledzenia wagonów i przesyłek na poziomie międzynarodowym.

Krok 8: Dla następnego kroku należy zrealizować komunikaty „Jazda pociągu” oraz „Prognoza jazdy pociągu”. Przy pomocy komunikatu „Prognoza jazdy pociągu” może być wysłany „szacowany czas przyjazdu pociągu” (TETA bądź ETH), co jest podstawą do obliczenia związanych z wagonem/przesyłką ETI oraz ETA. Krok ten zawiera również realizację zapytania/odpowiedzi dla „Jazdy pociągu” i „Prognozy pociągu”.

Możliwości dostępne po tym kroku dla
IM	RU
Wysyłanie w czasie rzeczywistym komunikatu o jeździe pociągu i o prognozie jazdy pociągu do IM oraz do RU Korzyść:   Zwiększone i bardziej niezawodne możliwości planowania, pomocne w efektywnym wykorzystaniu trasy.   Ograniczenie postojów na granicach, pomoc w użytkowaniu trasy dostosowanym do zapotrzebowania.	Dostępne miejsce i szacowany czas pociągu jako podstawa do obliczenia ETI/ETA związanej z wagonem/przesyłką. Korzyść:   Narzędzie do spełnienia pragnienia klienta, aby być poinformowanym, jeśli wystąpią problemy transportowe.   Wraz ze sfinalizowaniem kroku 4 pomoc w minimalizacji wydatków i kosztów poprzez użytkowanie trasy dostosowane do zapotrzebowania.   Zwiększone i bardziej niezawodne możliwości planowania.   Pomoc w skróceniu czasów przesyłek poprzez ograniczenie postojów na granicach.   Pomoc w minimalizacji ryzyka podczas przejmowania pociągów.

Krok 9: Raportowanie o wymianie (rozdział 4.2.9: Raportowanie o wymianie) oraz funkcjonalność z rozdziału 4.2.7 (ETI/ETA przesyłki ) powinny zostać zaimplementowane w tym samym czasie lub wkrótce po kroku 8. Jest to w szczególności istotne dla RU.

Możliwości dostępne po tym kroku dla
IM	RU
Znajomość położenia wagonu w obrębie infrastruktury IM oraz tego, który RU jest odpowiedzialny, nawet jeśli wagon nie znajduje się w pociągu. Korzyść:   Znajomość położenia wagonu oraz odpowiedzialnej jednostki na stacji rozrządowej.	Obliczenie ETI i ETA w oparciu o wartości TETA, automatyczne uaktualnienie danych o ruchu w „Operacyjnej bazie danych wagonów i jednostek intermodalnych”. Pełna realizacja międzynarodowego zarządzania pustymi wagonami. Ukończenie międzynarodowego planowania podróży. Korzyść:   Obserwacja i odtworzenie przemieszczania się przesyłek na poziomie międzynarodowym.   Skrócenie czasów obrotu wagonami.   Wsparcie dla międzynarodowego zarządzania pustymi wagonami.   Wsparcie dla ekspedycji za granicę oraz rezerwowania oferowanych usług.   Wsparcie dla poprawy jakości międzynarodowych przewozów.   Wsparcie dla międzynarodowego planowania podróży.

Krok 10: Częścią kroku 10 jest realizacja funkcjonalności „informacja o zakłóceniu służby” wraz z realizacją zapytania/odpowiedzi dotyczącej opóźnienia pociągu, identyfikatora pociągu oraz pociągu w punkcie raportowania. Na podstawie informacji o zakłóceniu może zadziałać komunikat o wyjątkowej sytuacji wagonu na poziomie RU (rozdział 4.2.8.6: Komunikat „Wyjątkowa sytuacja wagonu” oraz rozdział 4.2.8.7: Komunikat „Wyjątkowa sytuacja wagonu”, Żądanie nowej ETI/ETA).

Możliwości dostępne po tym kroku dla
IM	RU
Raporty dla RU o postępowaniu z zakłóceniem i o zaległościach w dostawach. Korzyść:   Poprawa jakości służby	Zapytania o postępowanie w wyjątkowej sytuacji i o zaległości. Korzyść:   Śledzenie i odtworzenie przemieszczania się przesyłek międzynarodowych.   Skrócenie czasów obrotu wagonami.

Krok 11: Po fazie konsolidacji może zostać uruchomiona ocena przesłanych i przechowanych danych dla poprawy jakości.

Możliwości dostępne po tym kroku dla
IM	RU
Dostępność wyczerpującej statystycznej bazy danych Korzyść:   Dostarczenie danych wejściowych dla poprawy jakości usługi transportowej

7.3.   Zarządzanie zmianą

7.3.1.   Wstęp

Zmiana jest nieodłączną cechą wszelkich rodzajów systemów komputerowych używanych w środowiskach realnego świata. Jest ona wywoływana przez pojawienie się nowych wymagań lub przez zmiany istniejących wymagań na skutek bądź to zgłoszonych błędów w działaniu, bądź też potrzeby poprawy wydajności lub innych niefunkcjonalnych charakterystyk.

Lecz zmianą należy zarządzać, gdyż u jej podstaw leżą względy ciągłości pracy oraz cel zachowania wstecznej zgodności, tak aby spowodować jak najmniejsze straty czasu i koszty ogólne związane z działaniem już rozwiniętego sprzętu informatycznego zapewniającego funkcjonalność TAF (tj. dziedziczonych systemów informatycznych). Dlatego sprawą zasadniczą jest określenie jasnej strategii tego, jak należy wdrażać i zarządzać zmianą dziedziczonego sprzętu informatycznego, aby uniknąć zakłócenia pracy kolei, nie naruszając podstawowego celu, jakim jest zagwarantowanie ciągłości służby i interoperacyjności. U podstaw tej określenia takiej strategii leżą dwie kwestie:

—	ustanowienie ram zarządzania konfiguracją określających normy i procedury dla zarządzania ewolucją systemu. Powinno to obejmować sposób rejestrowania i przetwarzania proponowanych zmian systemów, odnoszenia tych zmian do składników systemu oraz śledzenia zwolnień systemów,

—	polityka wydawania poziomów bazowych systemów.

7.3.2.   Ustalanie poziomu bazowego

Aby faktyczne wdrożenie i rozwinięcie mogło być realne, niezbędna jest stabilność systemów. Ta potrzeba stabilności odnosi się do wszystkich stron:

—	zarządców infrastruktury i przewoźników kolejowych, którzy będą musieli obsługiwać różne wersje systemów dostarczających funkcjonalność TAF,

—	kolejnictwa, które potrzebuje czasu, aby określić, stworzyć i udowodnić ciągłość interoperacyjności.

Poziom bazowy jest w istocie urzeczywistnieniem pojęcia stabilnego jądra scharakteryzowanego poprzez funkcjonalność systemu, osiągi oraz inne niefunkcjonalne charakterystyki (np. RAM) (9). Jednakże dotychczasowe doświadczenie z tego typu systemami pokazało, że szereg wydań wersji (10) wymaga osiągnięcia stabilnego i odpowiedniego dla implementacji poziomu bazowego. Można to zilustrować w postaci poniższego procesu kaskadowego:

Poprzez swoje pętle sprzężenia zwrotnego proces taki jest silnie spleciony. Wyklucza to równoległe ustawienie kilku takich procesów, co byłoby rozwiązaniem prowadzącym do powstania sytuacji niestabilnych, zagmatwanych i utrudniających działanie. Poziomy bazowe należy więc rozpatrywać nie równolegle, lecz szeregowo, jak zilustrowano poniżej:

7.3.3.   Wydanie poziomu bazowego

Na podstawie obecnego doświadczenia okres pomiędzy różnymi poziomami bazowymi można oszacować na około cztery do pięciu lat.

Nowy poziom bazowy powinien w zasadzie być związany z istotnymi modyfikacjami funkcjonalności systemu lub wydajności systemu. Może to obejmować takie aspekty, jak:

—	włączenie zestawu dzisiejszych krajowych funkcji, gdy mogą one być uogólnione, do interoperacyjnego jądra,

—	inne przyszłe usługi tworzące wartość dodaną.

Każdy poziom bazowy powinien również obejmować funkcjonalność poprzedniego poziomu bazowego. Wersje usuwające wady, mające na celu naprawę usterek systemu lub usunięcie wad dotyczących zabezpieczenia, powinny być traktowane jak zwolnienie wersji określonego poziomu bazowego. O ile nie uniemożliwiają tego względy bezpieczeństwa, takie wydania wersji w ramach tego samego poziomu bazowego winny być wstecznie kompatybilne.

Dodatkowa funkcjonalność, która może być zawarta w różnych poziomach bazowych, niekoniecznie oznacza, że różne poziomy bazowe nie są wstecznie kompatybilne. Jednakże aby umożliwić migrację oraz w stopniu możliwym z technicznego punktu widzenia, różne poziomy bazowe powinny obejmować wspólny rdzeń funkcjonalności, dla którego powinna być zapewniona wsteczna kompatybilność. Taki wspólny rdzeń powinien dostarczać minimalne jądro dla umożliwienia interoperacyjnych serwisów danych przy akceptowalnej wydajności.

7.3.4.   Rozwój nowych poziomów bazowych

Zarządcy infrastruktury i przewoźnicy kolejowi nigdy nie będą w stanie z dnia na dzień przejść z jednego poziomu bazowego na następny. Stąd każdy poziom bazowy musi być opracowywany równocześnie z odpowiednią strategią migracji. Ma to na celu zwrócenie uwagi na takie problemy, jak współistnienie systemów TAF spełniających różne wersje specyfikacji TAF, preferowane drogi migracji (tj. priorytet urządzeń przytorowych, priorytet taboru kolejowego, czy równoczesne), jak również orientacyjne ramy czasowe oraz priorytety migracji.

7.3.5.   Proces zarządzania zmianą – wymagania

Jak wspomniano wcześniej, w wypadku dużych systemów opartych na oprogramowaniu zmiana jest naturalnym faktem. Stąd należy opracować procedury zarządzania zmianą w celu zagwarantowania, że koszty i korzyści zmiany są właściwie przeanalizowane i że zmiany są wprowadzane w sposób kontrolowany. Wymaga to określonego procesu zarządzania zmianą oraz związanych z nim narzędzi w celu zagwarantowania, że zmiany są rejestrowane i stosowane zgodnie ze specyfikacjami oraz w sposób opłacalny. Niezależnie od tego, jakie mogą być ostatecznie konkretne szczegóły takiego procesu, proces ten powinien zasadniczo zostać opracowany według poniższego schematu:

Podstawą opisanego wyżej procesu zarządzania zmianą powinien być plan zarządzania konfiguracją zawierający zbiór norm i procedur zarządzania zmianą. Ogólne wymagania dla takiego planu opisano w punkcie 7.3.6. poniżej. Strategia wdrażania zatwierdzonych zmian powinna zostać sformalizowana (na podstawie należytego procesu i należytej dokumentacji) z utworzeniem planu zarządzania zmianami zawierającego w szczególności:

—	identyfikację technicznych ograniczeń leżących u podstaw zmiany,

—	określenie, kto przyjmuje odpowiedzialność za procedury wdrażania zmian,

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

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

Ważną częścią procesu zarządzania zmianą jest określenie odpowiedzialności za dostarczenie specyfikacji oraz zarówno za jej zapewnienie jakości, jak i zarządzanie konfiguracją. Planuje się, że większość tych zadań zostanie zwrócona lub będzie nadzorowana przez Europejską Agencję ds. Kolei (ustanowioną rozporządzeniem WE 881/2004), gdy zacznie to działać. Proces zarządzania zmianą powinien zostać sformalizowany w ramach zestawu dokumentacji wymienionego w załączniku A.

I wreszcie niezbędne jest, aby skład Komisji Kontroli Zmian (CCB), która ostatecznie będzie sprawować ogólne zwierzchnictwo nad systemem, był reprezentatywnym przekrojem wszystkich zainteresowanych stron – tj. zarządców infrastruktury, przewoźników kolejowych, przemysłu dostawczego, notyfikowanych organów, a także organów ustawodawczych. Takie stowarzyszenie stron powinno zapewnić systemowe spojrzenie na zmiany, które mają być wprowadzone oraz globalną ocenę ich konsekwencji. CCB przejdzie ostatecznie pod egidę Europejskiej Agencji ds. Kolei.

7.3.6.   Plan zarządzania konfiguracją – wymagania

Plan zarządzania konfiguracją powinien opisywać zbiór norm i procedur zarządzania zmianą obejmujący zwłaszcza:

—	określenie tego, które jednostki mają być zarządzane oraz formalnego planu identyfikowania tych jednostek,

—	określenie, kto przyjmuje odpowiedzialność za procedury zarządzania konfiguracją oraz za przekazywanie kontrolowanych jednostek do struktury decyzyjnej zarządzania konfiguracją,

—	polityki zarządzania konfiguracją, które mają być stosowane do kontroli zmian i zarządzania wersjami,

—	opis zapisów procesu zarządzania konfiguracją, które powinny być prowadzone,

—	opis narzędzi, które mają być używane do zarządzania konfiguracją oraz procesu, który będzie stosowany podczas używania tych narzędzi;

—	określenie bazy danych konfiguracji, która będzie służyć do zapisywania informacji o konfiguracji.

Konkretne szczegóły procesów zarządzania zmianą winny zostać sformalizowane poprzez specyfikacje, które zostaną ujęte w wykazie specyfikacji zamieszczonym w załączniku A do niniejszej TSI.

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 (11), 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.

---

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

(2)  Dz.U. L 220 z 30.8.1993, str. 23.

(3)  Dz.U. L 75 z 15.3.2001, str. 26.

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

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

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

(7)  Np. normy zapewnienia jakości, metoda opracowania systemu, metodologia badań, planowanie dokumentacji.

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

(9)  Poziom bazowy pełni rolę początkowego punktu odniesienia dla kontrolowanego zarządzania ewolucją systemu.

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

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